Debian debates systemd

By kragilkragil2

July 28, 2011

But wasn't Lennarts prominent sales pitch for systemd "Everybody will switch to systemd except Ubuntu!". If that was a lie how many other lies did he tell?

And if the way systemd works is so superior why don't the BSD people come up with a similar BSD-specific solution. Last I heard was that the BSD kernel has most of the features needed.
Maybe the solution to this problem is just waiting a release and letting the dust settle.

8:28 UTC

By rgmoore

July 29, 2011

>> And if the way systemd works is so superior why don't the BSD people come up with a similar BSD-specific solution.

I suspect this is a good example of the difference between the Linux and BSD development models. When Mr. Poettering decided it would be a good idea to invent a new init system, he went off, implemented his idea, and convinced his distribution to try out the new system. Now that it looks good, they've switched to the new system and other distros are considering it. If it hadn't worked, his distro would have rejected the new init and gone back to what they were doing before. It produced at most a small fork between the distros, but nothing really major. Even within other distros, it's producing some heat and disagreement, but no serious threat of anything more.

I doubt it would have played out the same way in the BSD world. If a BSD had the same kind of rancor as displayed in the Debian discussion, it would probably be the first step in establishing Yet Another BSD Fork. That would wind up diluting the developer manpower to the point the new project would be very slow to turn the new init into a production system, and it would take even more time before the other BSDs were willing to adopt it.

0:51 UTC

By viro

July 29, 2011

It still might end up with a fork - if Debian puts that piece of shit into squeeze+1, I'll have very little choice. I prefer to spend time working on kernel, but I do need tolerable userland for that. And pissed'em'd would cross that boundary, even if its author had not been such a... politician, for the lack of printable terms.

I'm not fond of that possibility, to put it very mildly - running autobuilder is not my idea of fun and even though I need only a smallish subset of packages, build-deps make the set grow greatly. Not that doing that for all architectures I need would be fun either (x86/amd64/sparc64 as minimum, probably mips as well)...

I really hope they DTRT and send that crap packing. And I suspect that I'm not alone in that among the kernel developers...

3:53 UTC

By patrick_g

July 30, 2011

>> I really hope they DTRT and send that crap packing.

Unfortunately your post is very light on technical details. Why systemd is crap? Care to explain?

10:56 UTC

By viro

July 30, 2011

I have - many times. It hasn't seen an extension it wouldn't love; unfortunately, quite a few of those are badly written and Lennert doesn't seem to be able to realize that such a thing is possible at all. Reading kernel/cgroup.c is enough to make one puke; that's one hell of a badly written lump of code. Yes, it got into the kernel. The best thing to say about it is that it can be configured away, but only if userland does not rely on it. Another equally nasty piece is fanotify, and IIRC systemd also relies on that one. D-bus is spectaculary ugly as well, and contrary to the claims in this thread there *is* a saner replacement - plumber, that is. Yes, it would depend on kernel being Linux (or something supporting 9p), so it probably wouldn't make kFreeBSD crowd any happier, but porting 9p to FreeBSD kernel is not impossible (or to Hurd, for that matter, assuming that anybody cares; I definitely do not).

It's not about using non-POSIX stuff; there are perfectly POSIX-enshrined FPOS APIs - look at POSIX ipc for starters (interface and, unfortunately, implementation as well). And I've no problem whatsoever with Linux-specific things being used - I could hardly claim that after having done Linux implemantation of namespaces, after all. Or after having helped Ram Pai with shared subtree implementation - the latter being unique to Linux, as far as I know (Plan 9 has namespaces, albeit somewhat different, but not this one).

The problem is that Lennert seems to treat everything in the kernel, no matter how optional and badly written, as fair game for making mandatory. And _that_ is a bloody bad idea, no matter how many deficiencies sysvinit has. Init replacements are not optional, thus pinning their dependencies down.

If you want kernel/cgroup.c code review, I can probably post it a bit after -rc1. Assuming I survive writing it - high blood pressure and all such... Not sure if lwn would be the right place for that, though.

16:31 UTC

By rahulsundaram

July 30, 2011

It is upto user space developers to cross check which kernel API's are bad or not. If they are bad, kernel developers shouldn't have merged it. Besides, cgroups *is* a optional dependency for systemd.

19:04 UTC

By viro

July 30, 2011

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.

20:23 UTC

By gerdesj

July 31, 2011

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

0:01 UTC

By viro

July 31, 2011

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.

0:50 UTC

By anselm

July 31, 2011

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.

15:52 UTC

By viro

July 31, 2011

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.

16:39 UTC