LWN: Comments on "Debian debates systemd"

Debian debates systemd

raven667 — Wed, 06 Nov 2013 15:55:49 +0000

I'm going to propose an alternate view, for core system features especially competition happens between different operating systems but is far less useful within an operating system unless you are talking about replacing an older subsystem with a newer one that includes compatibility hooks for the old way of doing things (like Wayland and xorg or systemd and sysvinit). There is a diffuse cost borne by everyone when application developers have to port their applications between the different infrastructures provided by different distributions and versions of what should be the same operating system. You don't get any internet points for being gratuitously different, it just makes things pointlessly complicated as they have to deal with all the variability rather than just having a standard way to do things.

Debian debates systemd

ras — Wed, 06 Nov 2013 00:44:11 +0000

Personally, I prefer they choose anything but systemd.

One of systemd's author primary arguments for systemd nothing else does what it does. If true, this is a problem - the same sort of problem we have with xorg. Everything should have alternates.

If Debian decides to use something other than systemd, it means there will be alternates for the magic it does cgroup's, udev and so on.

Debian debates systemd

juliank — Tue, 05 Nov 2013 21:38:59 +0000

(Free)BSD caught up, AFAIK.

Debian debates systemd

pgoetz — Fri, 15 Mar 2013 22:03:04 +0000

Sorry, I read the article the same way. Far too much focus on "Lennart is annoying" when I and other's don't even agree that he is annoying at all in his responses. You need to get out more if you're seeing Poettering's responses and vitriolic.

Debian debates systemd

pgoetz — Fri, 15 Mar 2013 21:59:32 +0000

> Reading kernel/cgroup.c is enough to make one puke; that's one hell of a badly written lump of code.

That's completely irrelevant. cgroups are an absolute necessity in modern multi-user systems.

Debian debates systemd

pgoetz — Fri, 15 Mar 2013 21:57:38 +0000

You must be running very simple systems then. We've run into a number of hard to solve timing issues with SysV init scripts (services that inexplicably refused to start) that required various random kludges; e.g. randomly inserting sleep 5 or some such in the init script.

Debian debates systemd

raven667 — Wed, 23 Jan 2013 22:33:57 +0000

While a bikeshed argument on whether you like the style of plumber or DBUS better is probably not worthwhile I think there is an interesting point worth making and that is that even 15+ years ago the creators of UNIX thought that a system wide standard IPC protocol and daemon was an important thing to have, such that they implemented it. That's an important point to highlight because there are still so many who believe that the idea of a standard IPC system is non-UNIX and some sort of abomination and it should be pointed out how wrong that is.

Debian debates systemd

Cyberax — Wed, 23 Jan 2013 18:42:58 +0000

Code quality is not the problem here (it can be reworked, patches are not that big), it's the opposition to the idea itself.

Debian debates systemd

rleigh — Wed, 23 Jan 2013 18:30:53 +0000

Being in (allegedly) wide use has zero bearing on the quality or suitability of the code for going into the kernel. It's good to see that at least the networking maintainer has an ounce of sanity here. Being pressurised to include this on merits other than quality does not paint this (or the people doing it) in a good light. It's not good to see things being pushed hard by people with agendas which don't necessarily align with what's technically the best path to take, circumventing the review and criticism such a drastic change would normally have.

Debian debates systemd

Cyberax — Wed, 23 Jan 2013 17:30:17 +0000

So, I found the documents about the plumber (http://doc.cat-v.org/plan_9/4th_edition/papers/plumb). What a freaking POS.

How is it even _comparable_ to DBUS? It can't be used to send file descriptors or credentials, it has no schema support for messages (they are free-form text), it has no central naming directory, it has no support for activation (though we can probably use systemd's socket activation for it). Oh, and it also mixes in weird routing rules that work on the basis of regex matching.

Do you even *know* how and why DBUS is used out there in the real world?

Debian debates systemd

Cyberax — Wed, 23 Jan 2013 17:26:30 +0000

a) It's pretty clear - kernel message routing implementation reduces context switch overhead and the number of data copies.
b) Last time network subsystem maintainer refused even the idea of AF_DBUS - we evidently should use IP multicast. So people went the usual way - write something, ship 10 million devices with it and present it as a fait accompli.

Debian debates systemd

andresfreund — Wed, 23 Jan 2013 16:46:52 +0000

Which says approx. nothing about a) the need to put into kernel, b) the quality of the patches submitted.

Debian debates systemd

Cyberax — Wed, 23 Jan 2013 15:58:00 +0000

Plumber? What is that? Care to provide a URL?

DBUS is _used_. It's actually _used_ in the freaking _real_ _world_. At that point saying it's "ugly" and everyone should just rewrite all their software to use my-obscure-and-useless-implementation is, shall we say, madness.

Debian debates systemd

pgoetz — Wed, 23 Jan 2013 10:21:36 +0000

> If you want kernel/cgroup.c code review, I can probably post it

Did this ever happen? Also, I'm curious to know your reasons for why plumber is better than D-bus.

Debian debates systemd

nye — Mon, 08 Aug 2011 10:51:59 +0000

>ESD? Shudder. When they finally abandoned it, it still had battery eating daemon/lib error-handling/busyloop bug(s).

Battery-eating isn't the end of the world - especially back when ESD was written since we didn't have all the CPU power states we do now, and hardly anyone had a laptop, so it didn't end up making much difference. The real problem with ESD was the randomly high latency and the fact that it was buggy and unstable.

That said, even today it's the only reliable-ish method of forwarding sound from a Linux machine to a Windows machine. Fortunately it looks like some brave soul has been working on getting PA running on Windows, so maybe within a year or two this crawling horror can finally be put to rest.

Debian debates systemd

jubal — Fri, 05 Aug 2011 18:42:35 +0000

Dear me! A true fanboy! :-)

Debian debates systemd

oak — Thu, 04 Aug 2011 21:25:48 +0000

ESD? Shudder. When they finally abandoned it, it still had battery eating daemon/lib error-handling/busyloop bug(s). KDE's sound daemon wasn't any better in the bugginess department. And I think these bugs were in the daemons themselves, not in the audio drivers.

Debian debates systemd

jake — Thu, 04 Aug 2011 17:25:22 +0000

> Just look at Lennart's response compared to the ad-hominem attacks
> and vitriolic rants prominent kernel developers are spreading in
> this thread.

Well, obviously I couldn't compare 'rants' that came afterwards to what Lennart said in his reply. I tried to strike a balance regarding *how* Lennart seems to respond to things, but it would seem that I failed there. I *do* think that lots of the criticism of systemd is overwrought and often unfair, but I don't think that Lennart's tone (here and elsewhere) helps his case at all.

> It's the first time I've seen LWN try to do a mainstream media
> style sensational beat-up.

Eh? For whatever it's worth, that was not the intent here at all. The part about Lennart's response is a few grafs in a fairly lengthy piece. I thought it important to report that piece of the puzzle, though evidently I failed to do that well, but I certainly didn't dwell on it or sensationalize it. I think the sentence above is a pretty unfair characterization of the article. YMMV ...

jake

Debian debates systemd

Zizzle — Thu, 04 Aug 2011 17:14:27 +0000

I had the same reaction.

Just look at Lennart's response compared to the ad-hominem attacks and vitriolic rants prominent kernel developers are spreading in this thread.

It's the first time I've seen LWN try to do a mainstream media style sensational beat-up. Disappointing.

Good on you Lennart, keep up the good work.

Debian debates systemd

raven667 — Thu, 04 Aug 2011 16:55:41 +0000

The notion of systemd only working on Linux is dumb, since it is obviously possible to port it to any OS, albeit perhaps with varying degrees of functionality and performance However, anyone wanting to use *BSD or something else should be expected the porting work himself.

This is the same way that OpenSSH works, OpenSSH is OpenBSD-only and makes full use of that OS' capabilities but a separate patch set is maintained to turn it into Portable OpenSSH which can run everywhere else. I don't think that managing systemd that way would even be as much work as OpenSSH because I would expect systemd to stabilize over the next couple of years and not have a lot of churn after that.

Debian debates systemd

slashdot — Thu, 04 Aug 2011 13:03:30 +0000

Hopefully Debian will switch to systemd, which will likewise hopefully lead to Ubuntu switching too.

Once this happens, all software will be able to assume that systemd is available and ditch initscripts, thereby simplifying daemon development.

Systemd's design is clearly the best, since on-demand activation is the only way to run the minimal possible set of daemons needed, and in the correct order.

Sysvinit is broken because there is no way to run daemons in the correct order other than giving up parallelization and defining the serial order by hand, while Upstart is broken because it launches everything which is installed on the system, as soon as dependencies are available (both of these approaches totally fail to scale to lots of daemon packages)

Conversely, with Systemd you can install a new daemon, and the system behavior won't change until you use it, but when you do it will work correctly.

The only issue is that activating daemons on-demand can be slower due to delaying their start-up; however, this should be fixable by adding a facility to store dependencies across boots, so that if a daemon activated another on the previous boot, then that other is preemptively started in anticipation of it being required on the current boot too.

The notion of systemd only working on Linux is dumb, since it is obviously possible to port it to any OS, albeit perhaps with varying degrees of functionality and performance

However, anyone wanting to use *BSD or something else should be expected the porting work himself.

Debian debates systemd

rahulsundaram — Tue, 02 Aug 2011 07:46:10 +0000

I just did the initial packaging work and got it into the distribution and wrote up the feature page so Lennart and others have time to do the real work. Feel free to look at the source when in doubt. These patches will get you a system that boots but won't have all the functionality that relies on cgroups.

https://bugzilla.redhat.com/show_bug.cgi?id=628004

http://cgit.freedesktop.org/systemd/patch/?id=e5a53dc7463...

http://lists.freedesktop.org/archives/systemd-devel/2011-...

Debian debates systemd

Cyberax — Tue, 02 Aug 2011 06:33:43 +0000

Systemd maintainer in Fedora: http://lwn.net/Articles/441149/

Maybe he's incorrect, I've no idea.

Debian debates systemd

FraGGod — Tue, 02 Aug 2011 03:35:02 +0000

What on earth gave you guys that idea?

systemd ties units to a processes via cgroups and cgroups only, it's an absolute requirement for systemd to run. No cgroups support in kernel = no systemd. Period.

That said, you can disable resource controllers, like cpu, blkio, etc, they are indeed optional, but not the cgroups feature itself.

Debian debates systemd

Trelane — Tue, 02 Aug 2011 02:34:33 +0000

Perhaps, but at least it says that Linux device drivers aren't the same as Windows device drivers, leading to bugs in the hardware getting exposed to Linux and not Windows. See also mjg59's stuff on the importance of Doing It Like Windows.

Debian debates systemd

bronson — Mon, 01 Aug 2011 19:40:34 +0000

> If I had to bet my life on something working properly, Debian's init scripts would definitely make the short list.

Really??? I guess we'll miss you when you're gone.

Half of Debian's init scripts don't even support restart properly. Ever purged a package and found the daemon still running? Ever tried /etc/init.d/blah stop, seen no error, yet you need to go hunt down the daemon by hand? Happens to me all the time.

I love Debian, but please never ever bet your life on its crawling mess of always changing init scripts!

Debian debates systemd

Cyberax — Mon, 01 Aug 2011 19:07:47 +0000

Not so. I've had persistent problems with ALSA (and OSS) before the PA.

Your USB issue seems to be related to your USB devices. I have a USB camera/microphone and they work just fine.

May be you should file bugs?

Debian debates systemd

sfeam — Mon, 01 Aug 2011 17:50:05 +0000

The difference being that once you have an ALSA configuration working, it stays working. Whereas in my sad experience pulseaudio's configuration only stays working until the next suspend/resume or reboot or phase of the moon. For USB sound, chances are about 50/50 that after a resume pulseaudio will refuse to admit the device still exists. The only reliable fix I've found for this is to blow away ~/.pulse and restart from scratch. Now maybe there is a configuration option that I've failed to find - one that says "pin this device across suspend/resume; even if you don't see it immediately, it _will_ come back." If so, I may be falsely blaming the implementation when it is more correctly a documentation failure.

Debian debates systemd

Cyberax — Mon, 01 Aug 2011 16:41:24 +0000

It says that sound drivers are crap.

And I really find it hard to believe that it all magically works with ESD without having a lot of fun with ALSA config files.

Debian debates systemd

sbergman27 — Mon, 01 Aug 2011 16:38:46 +0000

Right. All my machines for the last several years have had crap drivers. If that's the case, what does it say about Linux?

Odd thing, though. If I disable PA completely and replace it with esd, all those problems magically disappear.

Debian debates systemd

foom — Mon, 01 Aug 2011 12:49:09 +0000

Inability for contained processes to escape. Ability to get notified when it's empty.

Debian debates systemd

lyda — Mon, 01 Aug 2011 09:22:16 +0000

Just out of curiosity, what does cgroups give you that process groups didn't already give you? Besides a new namespace?

Debian debates systemd

Cyberax — Mon, 01 Aug 2011 08:48:00 +0000

Hm. It looks like your drivers are crap.

I've been running PulseAudio on tens of different devices without any problem at all for a couple of years now.

Debian debates systemd

Cyberax — Mon, 01 Aug 2011 08:45:36 +0000

LOL ROTFL.

I've had many many many problems with Debian init scripts over the years. Right now, on one machine BIND init script hangs the shutdown process (luckily not after SSH is shut down). I've no idea why and too lazy to check it.

I've seen problems with Apache init scripts, lighttpd init scripts, postfix init scripts and so on over the years. All in Debian (I don't really use other distributions).

That's why I consider systemd to be such a good idea. Getting rid of these scripts is a great way to improve Linux.

Debian debates systemd

Cyberax — Mon, 01 Aug 2011 08:39:05 +0000

systemd can work just fine without cgroups.

You will lose reliable kill support, but it'd still work.

Debian debates systemd

viro — Sun, 31 Jul 2011 16:39:28 +0000

And vice versa, the people who don't want to enable cgroup/fanotify/whatever weird shit Lennart decides to use today won't use systemd. Exactly my point...

Look, I've dealt with more than one entangled mess in the kernel code, thank you very much. I am *not* volunteering to fix cgroups; it's not just badly written kernel/cgroup.c - the interfaces on *both* sides (userland and the rest of kernel) are seriously misdesigned. As far as I'm concerned, configuring it out solves my problem nicely and those who want it are welcome to produce and submit patches. l-k is over -> that way...

And as for fanotify... *shudder* No way in hell I'm taking over that one. Eric is whole-heartedly welcome to that monster; as long as that fuckup can be configured away, I definitely will do so. On all my boxen.

Debian debates systemd

anselm — Sun, 31 Jul 2011 15:52:17 +0000

The traditional SysV init itself can fail in all sorts of interesting ways if its components aren't in the correct place or otherwise broken. Most distributions have figured out by now that depending on bash-specific stuff in »#!/bin/sh« scripts called during the init process is a bad idea if people install a different (POSIX-compatible) shell as /bin/sh, but it was not an obvious thing at the time. Personally I wouldn't look to SysV init as a paragon of robustness.

OTOH, it is reasonable to assume that distributions that come with systemd as the default init subsystem will make sure that the kernels provided with the distribution have the necessary features enabled. This is no more or less reasonable than to assume that distributions that come with a DHCP client have networking enabled in the kernel. It is also reasonable to assume that people who insist on tweaking their kernels will leave cgroups etc. in if they expect to use systemd, much like they will leave networking in if they expect to use TCP/IP.

Debian debates systemd

riel — Sun, 31 Jul 2011 14:27:19 +0000

The problem is with systemd not running when one of the optional kernel features it depends on is configured out (or the interface changes).

This is a serious lack of robustness for something that's supposed to replace /sbin/init...

Debian debates systemd

anselm — Sun, 31 Jul 2011 11:59:33 +0000

It isn't quite clear to me whether you have a problem with the idea of cgroups in principle, or with the current implementation of cgroups.

If it's the latter, then with all possible respect why is committing to producing your own distribution (if only for your own personal use) for the indefinite future a better course of action than (contributing to) cleaning up or replacing the current cgroups implementation and being done with the issue? If nothing else it would be good for the Linux community at large, either by improving a feature that many people want to use (even though it is implemented badly), or else by making a feature that some people don't want to use (because it is implemented badly) more acceptable.

Also, many other parts of the kernel are »optional« in the sense that there is a switch in the config file that would make them disappear, but that doesn't mean it's a good idea to do so. Some of these might even be badly implemented (I'm not a kernel hacker, so probably wouldn't be able to tell), or might have been badly implemented when they were new and have since been cleaned up. If people are not supposed to make use of »optional« kernel features because they're, well, optional, why offer them in the first place?

Debian debates systemd

sbergman27 — Sun, 31 Jul 2011 02:10:33 +0000

I would consider most init scripts to be 'perpetually alpha quality software'.

Really? If I had to bet my life on something working properly, Debian's init scripts would definitely make the short list. Not so, systemd. Look, Debian is not Fedora. People simply expect Fedora to be shiny and have problems. And they expect Debian to be boring and work right. And I'll take boring and working right any day of the week. I'd give both systemd and upstart a pass until Debian x+2.