Systemd 244 Released With New Init System Features For Black Friday

[usta]

To almost all of "you" who have written here :
it is written systemd, not system D or System D, or even SystemD. And it isn't system d either.

[Britoid]

Btw, in most cases it's the BSD people that have something to lose if Linux forges a path of its own, so all people that can't run stuff on their favourite BSD because it requires Linux API or OS infrastructure or hardware support have actual real-life reasons to be angry, as any win for Linux is usually a loss for them.

It's not just phylosphical "FOSS is a big familiy and we should stick together"

The idea is that Linux should be kept stale and back because of another kernel/OS is stupid.

[aht0]

To almost all of "you" who have written here :
it is written systemd, not system D or System D, or even SystemD. And it isn't system d either.

How about süstemd, Systemd or perhaps system-d? Maybe the best terms would be "system-bitch" or a "systemd-itch".

[aht0]

The idea is that Linux should be kept stale and back because of another kernel/OS is stupid.

And then you guys get all whiney because someone somewhere would think that making special effort to include something called Linux would be just stupid. (hint: commercial gaming for example)

[starshipeleven]

The idea is that Linux should be kept stale and back because of another kernel/OS is stupid.

Ah come on, that's excessive.

They just don't want to be left behind.

[starshipeleven]

And then you guys get all whiney because someone somewhere would think that making special effort to include something called Linux would be just stupid. (hint: commercial gaming for example)

Can we cut the football team assumptions here? There are idiots in both camps, let's not assume everyone is like them.

[starshipeleven]

How about süstemd, Systemd or perhaps system-d? Maybe the best terms would be "system-bitch" or a "systemd-itch".

sYsTeMdDdD

[jacob]

Ah come on, that's excessive.

They just don't want to be left behind.

I also don't get this notion that the Linux community should somehow always make sure that its core components work on other OSes and should not be "allowed" to move ahead. No other OS does that. Windows' svchost.exe only supports Windows, launchd only supports MacOS, even BSD init systems don't assume anything other than their own variant of BSD. Yet the fact that systemd is tightly coupled with Linux somehow makes it evil? Well, no. I for one am not interested in making Linux the lowest common denominator among obsolete operating systems.

[starshipeleven]

I also don't get this notion that the Linux community should somehow always make sure that its core components work on other OSes and should not be "allowed" to move ahead. No other OS does that.

It's a more complex phenomenon.

There is no "Linux OS", you can assemble whatever you want on top of Linux kernel.

Technically speaking, stuff like GNOME or KDE or whatever are not officially "linux core components". As are most other userspace components.

What is happening now is that this "neutrality" is decreasing, and even disappearing for some of these components.

BSD init systems don't assume anything other than their own variant of BSD.

BSD init systems use scripts so porting init scripts is easy.

It's technically a piece of cake to port systemd service files too, so init system per-se is not the thing here.

The issue is Linux kernel features used, either alone or through some helper daemons that are of course linux-specific (like Logind) and require a fork to be made generic (like Elogind)

Yet the fact that systemd is tightly coupled with Linux somehow makes it evil?

No it isn't but from their side it looks like being left behind.

This (not just systemd) is forcing otherwise unrelated opensource projects to choose a side, as if they want to use features offered by systemd or other non-portable Linux distro components for convenience, fun and profit then they have to maintain multiple fallbacks if they want to have "kernel freedom", and this relies on the fact that someone actually cares enough to do so, and maintain that in the upstream.
So it will not be "official", but the porting effort will become harder and harder, and the minority projects will not be able to manage it anymore, effectively cutting them out.

See the issues Debian is facing by trying to uphold their "init freedom".

This process is defining what will become the "Linux OS" in the future, and everything that will choose the "Linux OS" side will not be usable anymore by the minorities.

[ermo]

Oh, this is very nice.
(...)
the reality, at least the one I've experienced, is that SystemD simply has far more functionality, and works better, than any other init system I've ever used.

I understand that others disagree, and I'm all for init freedom, but as I said I don't understand the vehement derision of SystemD. If you don't like it then simply use or create a system without it.

If you're a pragmatist, systemd has already won, since it was designed by pragmatists for pragmatists.

For purists, the most common stance I've seen is that systemd as a concept is ok-ish, but that the implementation is *terrible*. The most common complaint is that systemd is stuffing too much functionality into PID 1. As a reminder, the kernel starts PID 1 after it finishes doing whatever it is kernels do to initialise system hardware etc. and PID 1 will then stay running until the point where the system is turned off/rebooted. If PID 1 crashes, it will take the whole system with it, so it stands to reason that it is a good idea to have PID 1 be as simple as possible (or so the argument goes). The other complaint I've seen is that systemd tends to absorb functionality that was traditionally separate from the init system and the service manager.

For conservationists, everything that isn't SysV init with rc-init scripts is a bad thing, since it's what they're used to running and they have managed to laborously craft scripts that are mostly functional over the years and know how to manage them. It will take years and years to convince these people that e.g. systemd (or upstart, openrc or any of the daemontool-derived service managers) are any good, because they all do away with the SysV rc-init scripts they are used to .

But as I see it, the real problem is that none of the purists or the conservationists can seem to agree on a "best" alternative to systemd -- each camp has their own pet peeves and sacred cows, which makes it very, very difficult for a unified front to emerge as a counterbalance to systemd. In the mean time, systemd keeps having engineering resources poured into it, so the gap widens even further.

This capability gap is the main reason that ISVs and larger distributions are hard pressed to NOT pick systemd, because the uniformity it represents -- and the hard problems that it is attempting to solve once and for all -- will generally allow the ISVs and distribution maintainers to focus on their core competencies, which is development, maintenance and integration. If picking systemd means that you don't have to maintain service management scripts for umpteen different paradigms and logging daemons, and if it means that you get a really useful set of system functionality out of the box, then why *wouldn't* you pick it?

Personally, I'd love to see a credible, reasonably unified alternative to systemd emerge, which puts its money where its mouth is and develops/rallies around a (daemontools-family?) alternative init/service management system with a set of drop-in tools and well-specified APIs that will work on both Linux and across the BSDs. Bonus points if this alternative can take systemd .service/user/tmpfiles.d/etc. files and map them to its own (declarative?) format with no degradation in functionality. Hell, I'd even donate to it, just to ensure that Linux doesn't turn the sprawling *nix landscape into a monoculture.

Why? Because competition improves the breed -- if a single credible alternative emerges, it will be able to clearly point out the deficiencies in systemd and provide a better alternative implementation for systemd to learn from. A credible runner-up will likely also be much more relevant to systemd than the current small army of also-rans that we're currently stuck with.

Ironically, it seems that by this point the only real way to fight systemd is to accept it -- and then go about critiquing it by implementing an improved version of it(s interfaces) and ensure that this improved version also works on the BSDs.

The question is if any of the purists can find it in themselves to be pragmatic enough to lead such an effort?