If there ever was a "red herring" in a discussion of Linux distributions, it's the init system.<p>The distro maintainers package the software for their system. It's therefore also their responsibility to make sure a service can be started/stopped and have its status checked.<p>It <i>does not matter</i> what kind of init system a distro has. A single Linux distribution is an Operating System independent of all others. There is no one true portable Linux way, much less for non-Linux-based Operating Systems. You have to treat them all as separate because to do otherwise would not only add complexity to a monolithic "portability" system, it would eventually get so complex you'd have to split it up anyway.<p>Portable software makes 3rd-party software developers' lives easier. But the init system is not managed by 3rd-party developers. It is managed by the OS maintainers. So it does not matter what method they use.<p>Furthermore, it's fucking Debian, the second-oldest distribution still in release. The oldest (Slackware) holds onto the old ways for as long as technically possible, and they're still going strong. So why the hell they care about being "modern" and "remaining relevant" is anyone's guess.<p>(disclaimer: I wrote my own init system for my own Linux distribution, and have modified most others)
<p><pre><code> > This blog post is the third of a series of posts
> dealing with the results of the Debian systemd survey
</code></pre>
Previous posts in the series<p><a href="http://people.debian.org/~stapelberg//2013/06/09/systemd-bloat.html" rel="nofollow">http://people.debian.org/~stapelberg//2013/06/09/systemd-blo...</a><p><a href="http://people.debian.org/~stapelberg//2013/07/01/systemd-transition.html" rel="nofollow">http://people.debian.org/~stapelberg//2013/07/01/systemd-tra...</a>
I sympathise with the fact that Debian considers itself the "universal operating system" but there are limits and the Debian developers have to consider the impact of their support decisions on their major consumer: the Linux OS. The Linux OS is the first and primary OS they should support. And as Michael says, to stay relevant, Debian needs to meet the needs of a modern and dynamic OS. That's why I want to see systemd supported and considered first-class in Debian, my OS of choice.
Especially considering that Debian/kFreeBSD and Debian/HURD are closer to interesting experiments than systems used for real work, holding back the init system solely for the non-Linux Debian variants doesn't seem justified. So this roadmap seems pretty sane.
It's getting harder and harder to find a distro where systemd isn't a hard requirement. I am hoping Debian will keep the choice of sysvinit available.
I could not care less about systemd because sysvinit is working fine here. I hate that you are forced in most distros to choose systemd without any alternative. I want my own initscripts, if a distro doesn't allow me that I won't use that distro.
Previously the non-portability of upstart was seen as a reason for Debian not to switch to upstart.<p>Now the non-portability of systemd is seen as a reason for Debian to drop the ports.
I wonder why Debian didn't go with OpenRC (<a href="https://en.wikipedia.org/wiki/OpenRC" rel="nofollow">https://en.wikipedia.org/wiki/OpenRC</a>) as it is compatible with both Linux and *BSD, which also offers 'Process segregation through cgroups'.
Wasn't looking forward to this "upgrade" ...
The fact that it's from the same dude as PulseAudio is enough to make me anxious, the pulseaudio stuff didn't go smooth. (I'm still of ALSA, yes also is a mess to.)<p>So I hope I won't be forced, to a more crappy system !<p>The fact that it will be handling a lot of stuff more, sounds like a major pita ...
I recently switched from Arch Linux to Debian mainly due to the hard systemd requirement. I hope the Debian transition will be better than what Arch Linux did.
systemd is, in some sense, a very modern-day product - a mess of different "alien" concepts and functionality stuck together into one project with an intention to show other the only true way of doing things. It like some (freedesktop guys, perhaps) will come to Plan9 and would say that all they need is gconf* -like registry to have a uniform configuration, or something of the same level of absurdity.<p>The movement out of shell-based initscripts for non-specialized (non-mobile/embedded) distributions is a cancer.) Remaining BSD guys are much more sane and "conservative" in this respect.<p>There is absolutely no necessity to break what is good-enough and <i>well-balanced</i> - having a standard shell scripts to do the job they were designed to. FreeBSD's rc.d system is a very good example.
Is a cgroups emulator in the future for kFreeBSD and the HURD?<p>I'm curious if faking cgroups (or heck, porting it) would be an easy solution.<p>Not talking about a fake cgroups providing all the real world advantages of systemd; merely a a fake not being too much worse than existing sysvinit.<p>Maybe rephrased actually porting THE cgroups to HURD might be impossible due to design issues or license issues. OK well how about writing a stub cgroups using the API that always gives a pleasant and completely meaningless response to all calls. What, if anything, would be the overall system wide net negative effect of systemd on HURD with a fake cgroups? I have not had much success googling for that.<p>This would not fix the "my /usr is not on my / partition" problem which is a serious concern to a extremely small number of people.
"Maintaining portable code increases complexity<p>Since systemd is written in C, the canonical way to write portable code is by using conditional compilation, for example with ifdef statements. That makes the code harder to understand and reason about, but more importantly it blows up the test matrix."<p>Take a page from NetBSDs effort... <a href="http://www.netbsd.org/about/portability.html" rel="nofollow">http://www.netbsd.org/about/portability.html</a>
When higher-level software begins requiring systemd (Gnome, KDE, etc.), the BSDs and other non-Linux, but Unix-like operating systems will no longer be able to use that software.
This is great. It will give Debian access to features like a faster startup, a sane way of restarting daemons that die, better power management and process management.