The Grumpy Editor's guide to surviving the systemd debate [LWN.net]

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 4:03 UTC (Thu) by jonnor (guest, #76768)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by timtas
Parent article: The Grumpy Editor's guide to surviving the systemd debate

If you are arguing against how the systemd project is set up, why are not not arguing as fervently against the Linux kernel project? It is constructed in a possibly more monolithic way. You cannot run Linux together with another kernel at the same time. They refuse to write code that works also on BSD kernels, GCC is the only supported compiler. All drivers and functionality are supposed to be in _their_ source tree, there is no stable ABI/API for modules. It does networking, disk, audio, video, security policies, IPC, process and memory management, performance monitoring. All in one project, over 10 million lines of code!

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 8:28 UTC (Thu) by timtas (guest, #2815) [Link] (9 responses)

So, where did I use the word monolithic? Sometimes, it seems that you systemd fanboys all have a copy of Lennart's "30 myths about systemd" in front of you and then randomly throw one point of it at anybody having any issue with systemd.
I was actually talking about the intrusiveness of systemd and in that respect Linux generally alwas played along nicely with the unix ecosystem: it just does what a kernel is supposed to do and nothing else. And kernels naturally have to be a bit platform dependend on the inside, as they talk to hardware, you know. Yes, the internal abi for drivers is unstable, but the API of a kernel is called syscalls and while Linux has added a few over time (we're talking about more than 20 years here), it always made life easy for software developers to support the standard ones up until now. And believe me, that was sometimes quite a fight, but Linux always stuck to the principle: once an api has been in use by software, it is a regression to change it and a no-go. Now that's hardly comparable to systemd's approach of apis, systemd for instance just broke rtkit because Lennart decided to throw something out and the response is not: sorry, I put it back in, but it is of course: oh, we might just integrate rtkit into systemd as well.
And about the 10 mio lines of code: a large part of it is drivers for the tons and tons of sometimes buggy devices Linux supports, by working around their bugs so users like you and me can run Linux on all sorts of hardware. Now, if Lennart would have written a kernel, it would have of course never supported buggy hardware, which probably means it had supported scsi disks from two vendors, no ide, because it's obsolete shit anyways, one graphic card, one soundcard and two nics. Like Apple does. But there people that chose Linux, because it is not like Apple, you know.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 8:48 UTC (Thu) by rvfh (guest, #31018) [Link] (5 responses)

> (...) systemd fanboys (...)

Common, grow up! A lot of us in this community are 40+ years old with at least 10 years of Linux use/dev behind us, and because we like systemd's features better you call us fanboys?

I installed systemd on my Raspberry Pis as a try and it turns out it just works, makes them slightly faster to boot, and make the service file for my daemon short and clean. FWIW I have also written the upstart service file so I could understand both systems.

This is not being a fan, this is being pragmatic.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 18:06 UTC (Thu) by bronson (subscriber, #4806) [Link] (4 responses)

This sounds fascinating! Any chance you wrote it up? I've been meaning to do it too but haven't found the round tuits yet.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 16, 2014 11:22 UTC (Sun) by jonnor (guest, #76768) [Link] (2 responses)

systemd on Raspberry PI you mean? I use Arch Linux on my RPis, which comes with systemd by default. I'd expect installing systemd on RPi on the default Debian-based image to be like in https://wiki.debian.org/systemd
In general I'd recommend not installing the package which replaces /sbin/init until working with init=/bin/systemd has been confirmed. Its just good practice.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 12:37 UTC (Mon) by peter-b (guest, #66996) [Link]

I use systemd on my Pidora print server. It works beautifully. *shrug*

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 13:41 UTC (Mon) by rvfh (guest, #31018) [Link]

Well, I have a spare one that I use for all kinds of tests before I apply them to the 'production' ones (those that manage my lights, gates, radiators...)

I also run the upgrades on that one to make sure things don't break before upgrading the rest :-)

Example of SysVinit and SystemD configs

Posted Nov 17, 2014 13:46 UTC (Mon) by rvfh (guest, #31018) [Link]

If you look in http://sourceforge.net/p/hnet/code/ci/master/tree/etc/dae..., there are two files of interest:
* hnet is the sysvinit script
* hnet.service is the systemd service file

Seems I did not commit the upstart one but I can do if that's of interest to somebody (I'll have to test it first though...)

Also, I am not sure the sysvinit one is on par with the systemd one, as systemd restarts my daemon if it disappears for any reason...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:00 UTC (Thu) by jonnor (guest, #76768) [Link]

Monolithic was perhaps the wrong word, swap it out for "intrusive" and parse again. My point is that, in many ways, the systemd project (of providing a core base system) is set up like the Linux kernel project. Which seems to have worked out pretty ok. Despite arguments by for instance A. Tannenbaum for a more minimal core and looser coupling of components, which seems like quite analogue.

The only major difference I can see in terms of "intrusiveness" is that the Linux kernel has always* been there and worked this way, whereas systemd is a change to how things were currently done in the base system plumbing.

* Since free operating systems became prevalent at least.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:45 UTC (Thu) by pgoetz (guest, #4931) [Link] (1 responses)

> I was actually talking about the intrusiveness of systemd and in that respect Linux generally alwas played along nicely with the unix ecosystem

Reading your comments gives the strong impression that you don't know very much about systemd. Lots of words, very little relevant content.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 18:13 UTC (Thu) by bronson (subscriber, #4806) [Link]

Also, the flame wars with the Solaris and BSD guys 1992-1997 demonstrates that Linux has definitely NOT always played along nicely with the unix ecosystem. You can pick almost any subsystem and find traditional Unixers howling that Linux is doing it wrong.

And often it was. :)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 8:40 UTC (Thu) by Felix (subscriber, #36445) [Link]

You could also mention that all of this code runs with an even higher privilege level than root (for being in the kernel).

But I think we all should just calm down and let's see what happens. Debian developers will have their GR, numerous upstream developers will either rely on systemd functionality (or not) and many many distro packagers will spent their time as they see fit.

The systemd developers will continue to do their stuff as they are doing it now. Let the code speak for itself! I personally will try to abstain from any systemd debate for at least a couple of months and I guess in 2-3 years we'll know how everything played out.