It's not the end of Linux. It's the final death of the idea that Linux should just idly continue to act like a clone of some vague Unix of old because it was better when men were men and their computers had obscure RISC processors with billions of registers.
Linux hasn't really been that way for an incredibly long time, but a large proportion of the userbase still cling to this notion, some for ideological reasons, and some out of sentimentality.
Systemd is most problematic because of its own-everything monolithic nature, and the changing of kernel interfaces to match. The vast majority of Linux systems are not desktops, and probably not servers either. The kernel and the core utilities around it (like init) should be designed with multiple implementations and all machine types in mind. This means phones, set top boxes, TVs, routers, automation hardware, supercomputers, and more.
If the core utilities around the kernel and the interfaces they use are well-documented, designed, and modular, then different machine types can pick and choose the components they need, and easily write their own by opening a well-defined API on something in /dev. If systemd continues to take over and alternatives smothered, very quickly the kernel will become useless to any system where systemd makes no sense, especially non-desktop embedded systems.
systemd makes a lot of sense for embedded systems:
* Embedded systems use watchdogs. systemd implements a watchdog supervisor chain, where systemd supervises applications, and the hardware watchdog supervises systemd.
* kdbus: efficient IPC
* networkd: simple network setup, very fast DHCP client
* fast boot times
* handles many complexities, so that embedded developers can focus on their application
That all sounds fantastic, but what do you do if just one component of systemd doesn't work for you? Or if you only want to use one or two components of systemd?
Regarding the first question: Then you use something else instead of that component. For instance, the existence of networkd does not preclude the use of (say) dhcpcd or your own network setup scripts. Of course, there are a few components that are more central (e.g. journald, udevd). In that case you file a bug report and/or fix it. Same as when one component of the kernel (which is vastly larger than systemd) doesn't work for you.
As for the second question: certain parts of systemd can certainly be used on non-systemd systemd (such as udev or nss-myhostname). But most would require at least some changes.
We are selling embedded device with systemd Debian since this spring and they work just fine. And it not some 5$ board made once and then sold as is. It is a big and very advanced device in the hundred thousand dollars bracket and all of them are constantly improved and upgraded. And they will be maintained for many more years.
I developed and marketed my own embedded Linux products. It would have been difficult to do some of the customizations I did if the kernel, DHCP server, logging system, HAL/udev, etc. were all adapted to the one systemd way of doing things with dbus.
You should educate yourself about FUD, I recommend the Halloween documents, where they explain the unfeasibility of FUD tactics against an open source project, e.g. if someone tries to do it they won't get anywhere.
If you read over Wikipedia page of systemd, you will find out - it just does not replace `init` system, but whole lot more. Systemd is a collection of 64 binaries which manage login daemon, networking (DHCP) etc.
In other words to some it seems like lot of not-so-tested software replacing software that was well tested. from an outsider perspective two things seem problematic:
1. A lot of Linux software worked on principle of, don't break userland. Systemd appears to break userland here and there.
2. From any such large software replacing a well tested infrastructure, bugs are expected. The problem appears to be, in many cases systemd developers push the blame of breakage to other subsystem devs (sometimes it could be Kernel dev, sometimes it could be end user apps written on top of KDE/GNOME). This is the part which makes lot of people angry apparently.
Upstart was tested enough to ship in RHEL6.
It does not mean it works perfectly and has no bugs.
But systemd IS NOT only an init system.
So if systemd 208 (until 213) by default saves the core files in the journal and your core file is bigger that what systemd devs decided was appropriate in a .c file (around 768MB, IIRC), you lose it. That is _inacceptable_.
And while we (=the company i work for) still have not officially started our evaluation of the platform, if RHEL7(.0) does not have this bug fixed then I will be strongly against supporting it officially, since in case of crash we would not be able to get or pass up to the devs the core file for analysis.
> So if systemd 208 (until 213) by default saves the core files in the journal and your core file is bigger that what systemd devs decided was appropriate in a .c file (around 768MB, IIRC), you lose it. That is _inacceptable_.
Is that not, however, a simple fix? There might be a case of death by million cuts but that's true of any new software that replaces any existing software.
RH still offers support for RHEL6, and will do so for years to come. It will be interesting to see how quickly 7 gets adopted outside of cloud instances.
This line of reasoning is drifting dangerously close to the conformist call of "nobody ever got fired for buying IBM" or in this case, RedHat. If systemd turns out to be a mistake in RHEL, it wouldn't be the first time something enterprisey did something wrong. We (Linux users) can't afford to let enterprise thinking, which is often more political than technical, dominate the community.
I don't agree with the article that it is 'end' of Linux, whatever that may mean, but the article argues that because SystemD is changing what Linux stood for - simplicity, never break userspace, keep as many things in user space as practical, and keep the kernel version dependencies on userspace to a bare minimum and in addition is also rewriting lot of battle hardened software like resolvd and in doing so it will introduce instability and security issues.
I guess the point is end users will shy away from the short term mess and move to another system like FreeBSD.
While I don't know if SystemD is a vastly superior design and implementation to any of the already existing things and I am not sure how much of a stability/security/complexity concern it is, I think that the 'end' of Linux will not be due to SystemD - it has a lot of momentum going for it. It will take something bigger to derail Linux at this point.
It's important to note that the blog post doesn't mean, "Linux is done for," but rather, "Linux is going to be a different kind of system than it has been historically." Some people think this is a good thing, and some think it is not. EDIT: I want to emphasize that I am trying to write this comment neutrally, not endorsing either side, so while my biases may sneak in, my intention is to be fair to both sides. Both sides have arguments in their favour, and I'd hope people consider both before coming to a conclusion.
All Unix-based systems start by running a single process known as 'init' which is responsible for setting up the system, starting all other programs, and managing various services as they run. The change under contention is the widespread inclusion of a relatively new piece of software called systemd, which replaces the historically popular sysvinit, Ubuntu's alternative known as upstart, and various other competing systems. All of these are different approaches to building an init system.
In contrast to some of the other systems, systemd is written less in terms of traditional Unix-style tools (like pipes and plain text files for storage), choosing instead to build on newer and more elaborate communication interfaces and store in specially designed binary formats. Systemd consists of a large family of interrelated pieces of software, many of which are nominally optional but generally expect to be used together. One point of contention is whether systemd is "too large", as proponents argue that developing these pieces together will increase their quality, while detractors argue that this makes it too difficult to substitute components if necessary and that these pieces should not be part of the same conceptual package.
Additionally, the architectural choices of a large, widely-used package integral to the functioning of a running system will influence the design and assumptions of other pieces of software and even Linux itself. Already, the Linux kernel has incorporated the newer communication systems used by systemd into the operating system itself (the mentioned KDBus), which many believe to be a sign that the inclusion of systemd will change the way that Linux operates and the way programs expect to interact with the kernel and with each other.
An important factor here, whether good or bad, is that these choices make Linux into a very different system than it has been historically, and very different than other Unix variants. Proponents argue that this is a step forward, as the facilities offered by Linux historically might not be appropriate tools for the current uses of Linux. Detractors disagree. Either way, the conclusion is that systemd is a change in the way the operating system is structured and used which has been a major point of contention in some communities.
I know we don't have access to the OSX code in its entirety, but could one argue that they actually did change how init works in FreeBSD? And perhaps that is one of the reasons the OS is stable? It's not far to assume that the Linux folks are going for more control over init for specifically this reason.
They did change init, but it is not about stability, the main reason was support of hotplug and dynamically adding and removing services. You expect stuff to happen if you plug in a new device and so on, and that is integrated into "init", so it is not so much "init" as an ongoing service that deals with events as they happen.
The mail from 2102 that is linked from your url contains this paragraph, wonder what happened to that plan?
"Ubuntu plans to take over maintainership (more precisely Martin Pitt
from Canonical), to maintain it as long as they still need it, and will
change the name while doing so."
Tried to find out some time back. All i could find was a empty Consolekit project in Martin Pitt's name over at Launchpad. The mailing list didn't seem to hold much more info until Poettering closed it because he didn't want spam...
