Forgot your password?
typodupeerror

Comment: Re:Err... (Score 3, Interesting) 447

by ThePhilips (#47959451) Attached to: Fork of Systemd Leads To Lightweight Uselessd

But the kernel is monolithic, [...]

Wrong. Linux kernel has modular architecture, but monolithic design. The precise opposite of the systemd.

I know that the uninitiated see the kernel as a big black box. But actually Linux very well structured and highly hierarchical.

systemd can monitor dæmons (only if they use the systemd watchdog facilities) and automatically restart them if they stop talking.

The question here is about the case when systemd itself "stops talking".

Some time ago that would have been theoretical question, but actually there were already such bugs in systemd where it was simply stuck because the daemons which compromise it couldn't understand with each other. This is precisely the consequence of monolithic architecture in combination with modular design: the singular logic is spread across many "modules" (the *-systemd binaries) and when the modules do not agree with each other, things go south pretty quickly.

Comment: Re:Err... (Score 5, Interesting) 447

by ThePhilips (#47959073) Attached to: Fork of Systemd Leads To Lightweight Uselessd

Yes. No. Wait - yes. No... no. Uh....

The systemd has modular design.

But monolithic architecture.

Literally everything inside systemd is intertwined using the D-Bus.

So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.

The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.

On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.

Comment: Re:Err... (Score 1) 447

by ThePhilips (#47958835) Attached to: Fork of Systemd Leads To Lightweight Uselessd

My sid/unstable doesn't have it yet, but I'm exploring options for leaving Debian since its developers for the most part seem to be pushing systemd.

Switch to what? I want relatively up-to-date Debian based system with relatively good KDE integration.

Anyway, the way I'm using Debian at home, I do not really care what init system it has. In office, systemd and the rest of the RedHat/GNOME aberrations are simply not applicable and not employed.

Comment: Do not simplify. (Score 1) 183

by ThePhilips (#47954059) Attached to: KDE's UI To Bend Toward Simplicity

I think "simplifying" would only cause lots of pain.

KDE is already pretty well structured. What they need to do is to simply develop a new "front-end" for all the back-end goodies.

And why stop there - make a framework so that almost anybody can easily experiment with front-end development.

That would be, IMO, the most KDE-ish way to do it. Everything else would lead to the debacle like the KDE3 vs. KDE4 was.

Comment: Re: Boom in the EU = Boom in Redmond (Score 3, Interesting) 249

by ThePhilips (#47896811) Attached to: City of Turin To Switch From Windows To Linux and Save 6M Euros

We heard this argument many times before.

The problem with it is that with Windows you are pretty much forced to buy such solution, either from MS or from 3rd parties.

With Linux, it is really an option, a "nice to have".

For example, a small engineering company in Germany. They actually bought it for 12 desktops in their office. (One desktop is actually server.) Not because they had to, but because it basically freed them up from having a full time admin. (They have admin, but he wanted to go into the CAD/design, and the Ubuntu managed solution simply allowed him to.) (Why Ubuntu? They have tried it - it worked for them well and they have stayed with it.)

Comment: Re: Er? (Score 1) 314

by ThePhilips (#47853249) Attached to: GSOC Project Works To Emulate Systemd For OpenBSD

LANG=Japanese appname in the terminal makes so much more sense.

The problem with that, is that very few applications are now isolated these days. You typically have a DB back-end, data export/import and RPC to other system services. Setting a different locale is error prone since some data might be simply misinterpreted and end up corrupted. And that is real problem, since lots of user data are actually stored in textual form (even in DB!).

IME, the per-application locale has its uses, but in real world it causes more problems than it solves. In fact, since most Linux distros support quick account switching, the cheapest solution right now is to use two accounts with different locales.

Forcing systemwide language settings is a broken concept. The fact my Japanese wife has to set her whole iphone to English to get google maps to say street names in the US while driving is a great real world example.

There is no sane way to solve that problem on the level of OS. (Even "primary language; secondary language" is not enough, since for example I have to deal daily with three languages (Russian, English, German).) Most of the time this ends up being in the responsibility of the application developers: if they care enough, they offer a possibility to use a language different from the system one.

Think of the flip-side: you might accidentally force all Japanese and all English iPhones to download both English and Japanese locale data. And this is pretty large amount of the data to just sit around idly, just in case when user might once decide to hear the street names in different language.

Comment: Re:Needed by who? (Score 2) 314

by ThePhilips (#47852167) Attached to: GSOC Project Works To Emulate Systemd For OpenBSD

Wait, who actually needs to do those things?

Desktop applications.

For example, you change time zone or locale in system settings and your organizer app automatically picks up the changes.

And if the services do not depend on systemd, why are they part of the package?

Pottering is maintainer of all of them. So he brought it under the systemd umbrella.

Sounds like a made-up scenario and some bad packaging. Not a real-world need.

Applications "need" the services. They do not care who provides the services. As was said many times, the daemons - with few irrelevant changes to the source code to remove hardcoded systemd depedency - run fine without systemd.

Certainly fits the systemd reputation for taking over already-solved problems without any reason, though.

Yes.

Pottering also enjoys the confusion he has seeded with the organization of the systemd. He claims simultaneously (depending on the context; and to his advantage) that systemd is modular and monolithic. While in fact systemd has monolithic architecture and modular design. Pretty much the worst combination possible - prominently featured in the MSWindows, why comparison with Windows is highly relevant. (Ideally you want modular architecture, while design could be either monolithic (e.g. Linux kernel, optimized for performance) or modular (e.g. GIMP with the tons of the plug-ins, geared toward extensibility). But monolithic architecture is pretty much the worst thing you could ever do to a software project.)

Comment: Re:Er? (Score 1) 314

by ThePhilips (#47851571) Attached to: GSOC Project Works To Emulate Systemd For OpenBSD

The three services are actually needed.

For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.

For applications. To handle properly when user changes the system settings.

These daemons are primitive at best. There were more comments written about them then there is source code lines in them.

Note, I'm in no favor of systemd itself. Debian in the past exemplified that you can actually use GNOME on a system without systemd, with only slightly patched up systemd-*d daemons. Which makes a lot of sense to me. But their maintainer is Poeterring, and he merged that all into the systemd, and there is no replacement for the daemons, so...

The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.

Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones.

Nobody dismisses the multi-user-ness of the *NIX. In fact, the services should improve that by allowing a user to easily change his own locale/time zone without the need for log-out/log-in cycle.

The blank the services are filling is allowing application to perform application-specific tasks *when* user changes the locale or time zone. Editing a text config, and then restarting everything is, sorry, but horribly outdated. (We can update kernel on the fly - but not locale!? WTF?)

Comment: Re:Er? (Score 5, Informative) 314

by ThePhilips (#47850975) Attached to: GSOC Project Works To Emulate Systemd For OpenBSD

The three services are actually needed.

The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).

The systemd-timedated does almost the same for the date and time.

And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.

The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.

In no way the services itself depend on the systemd - they are simply part of the systemd package. Nothing more.

"Irrationality is the square root of all evil" -- Douglas Hofstadter

Working...