Debian debates systemd

Posted Jul 30, 2011 20:23 UTC (Sat) by viro (subscriber, #7872)
In reply to: Debian debates systemd by rahulsundaram
Parent article: Debian debates systemd

I agree that shit shouldn't be merged. Mistakes happen; some of them - with worse reasons than other. It doesn't make stepping into a pile of shit any smarter, especially with this kind of exhuberance, but Lennart's lack of taste is his problem; having to enable that crap on my boxen is mine and maintaining a set of patches to affected packages in Debian I happen to care about + running autobuilders to generate binaries is more attractive for me than paying that kind of price.

Debian debates systemd

Posted Jul 30, 2011 21:37 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (11 responses)

Let's say I am a user space developer who isn't knee deep in kernel politics and I have no idea which interfaces are considered a terrible mess or which is awesome. If I like the functionality that cgroups offers (and my understanding is that even kernel developers who say it is bad code recognize the value of the functionality), I will use it and let the developers worry about the implementation details. I will trust kernel developers not to merge crappy code. Blaming user space developers for using interfaces that are merged and advertised as available in the kernel seems like just passing around blame. If it just the implementation that is problematic, it can be fixed although you will have to keep compatibility at the interface level. It is not ideal but not the first time it has happened either.

Debian debates systemd

Posted Jul 30, 2011 21:47 UTC (Sat) by riel (subscriber, #3142) [Link]

There should be no reason to keep compatibility in the kernel/user API for something as specialized as cgroups. There is a reason libcgroup abstracts that stuff away.

Debian debates systemd

Posted Jul 31, 2011 0:01 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (9 responses)

... and you sir are spot on.

There is kernel space and there is user space.

The kernel exports a feature called cgroups and this is found useful and used in user space.

It is of absolutely no consequence whether the kernel code is ugly, pretty, has a nicely proportioned ankle or is downright gorgeous. It has an interface, and that is what is used.

To denigrate a user space system by arguing that the kernel implementation that it relies on is flawed is ludicrous to the point of disbelief.

Cheers
Jon

Debian debates systemd

Posted Jul 31, 2011 0:50 UTC (Sun) by viro (subscriber, #7872) [Link] (8 responses)

What the fuck? The interface in question is optional; it's *NOT* guaranteed to be present in any kernel. Disbelieve all you want, but that fact does depend upon your beliefs. Incidentally, the code behind that interface is a misdesigned piece of shit, best configured out unless there are extremely strong reasons to enable it. Not everything that can be enabled should be.

I don't give a rat's arse for denigrating or lauding systemd, its author or its fanboys (OK, beyond the usual allergy to fanboys of any persuasuion). The trouble with systemd is as pragmatic as it gets - due to architecture decision by systemd author(s), running it means that several really badly-written pieces of code will be executed in kernel mode all the time. It doesn't matter how the blame is to be distributed - I simply don't care. Not interesting. It's not about judging Lennart (FWIW, my opinion is simple - (a) obnoxious luser; (b) not my luser, thanks $DEITY), it's not about something systemd might "deserve". The only thing I do care about in that story is what code ends up running on my boxen and what can I do about that.

Debian debates systemd

Posted Jul 31, 2011 11:59 UTC (Sun) by anselm (subscriber, #2796) [Link] (3 responses)

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

Posted Jul 31, 2011 14:27 UTC (Sun) by riel (subscriber, #3142) [Link] (2 responses)

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

Posted Jul 31, 2011 15:52 UTC (Sun) by anselm (subscriber, #2796) [Link] (1 responses)

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

Posted Jul 31, 2011 16:39 UTC (Sun) by viro (subscriber, #7872) [Link]

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

Posted Aug 1, 2011 8:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

systemd can work just fine without cgroups.

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

Debian debates systemd

Posted Aug 2, 2011 3:35 UTC (Tue) by FraGGod (guest, #63193) [Link] (2 responses)

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

Posted Aug 2, 2011 6:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

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

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

Debian debates systemd

Posted Aug 2, 2011 7:46 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

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-...