What's wrong with systemd

http://www.landley.net/notes.html#23-04-2014

by uggedal • 12 years ago

110 109 12 years ago

SEJeff2• 12 years ago

TL;DNR version: systemd breaks the one thing that makes Linux great, it's modularity and ability to swap out individual components with separate discrete implementations.

akerl_6• 12 years ago

As somebody who runs systemd with syslog-ng and cronie and netctl, it seems to handle the use of separate individual components just fine.

I've seen some decent debates about the viability of systemd, but "it's monolithic" is one of the largest false idols I've seen. It's a collection of systems, the vast majority of which don't run as PID1.

SEJeff2• 12 years ago

The part of systemd that provides pid 1 is relatively small and self contained. Sure there is systemd-networkd, systemd-tmpfiles, systemd-logind, etc, but those all speak to systemd pid 1 via dbus mostly. Anything that wanted to pretend to be one of the various daemons can simply speak the dbus protocol. In fact, this was one of the discussion points in the Debian systemd debate recently.

dsr_2• 12 years ago

No, I think you got that wrong.

TL;DR: systemd's supporters treat anyone who doesn't like it as an enemy to be defeated rather than a fellow traveller who is taking a different path.

If I look at launchd or upstart or openrc or runit, I see a project which wants a competitive landscape where they can demonstrate their merits for various uses.

When I look at systemd I see Microsoft.

akerl_6• 12 years ago

This has more to do with the tint of your lenses (and those of the article's author) than the layout of the software.

PeterisP• 12 years ago

Systemd's supporters might as well be devil-worshipping baby eaters, but that's not any argument for or against systemd as such, that's simply irrelevant.

matthewmacleod• 12 years ago

I'm kind of indifferent to system's adoption, but I've heard quite a lot of complaints about it that have subsequently turned out to be false. It can sometimes be hard to filter out the noise.

However, it looks like most major Linux distributions are going to be using systemd. Fedora, Arch, Debian, Ubuntu (eventually), Redhat, SUSE, even CoreOS. What I don't get is why there would be comprehensive adoption across distributions if systemd was obviously the wrong decision.

rossjudson• 12 years ago

Seems like sour grapes from the author of another initialization subsystem (mdev). His argument would seem to apply to any effort to standardize initialization on Linux.

tormeh• 12 years ago

Yeah, that seems to be the point, that initialization shouldn't be standardized or at least should be standardized based on a formal spec. It's his entire criticism.

akerl_6• 12 years ago

The point he's making is that having One True System is the death of one of the biggest strengths of the Linux ecosystem: diversity. What he's ignoring is that the various distros that are making this change have done so because they think it's the best decision for their users.

No higher power decreed "systemd or death" and forced it on the distros. They've adopted it on its merits, and most have retained the ability to run other init systems if the user wishes.

This is a pinnacle of the Linux ecosystem, not a blemish on its record: the larger community is working towards better interoperability between distros.

makomk2• 12 years ago

What the systemd supporters are ignoring is that if the existing init system was as all-encompassing and heavily intertwined with the rest of the system as systemd is, it would be impossible to replace it with systemd no matter how much of an improvement it is.

Niten• 12 years ago

His argument would not apply to an actual standardization effort without the negative attributes explicitly called out in the article. (Non-standard, undocumented moving target, and a community of developers who go out of their way to antagonize competing projects.)

thegeomaster• 12 years ago

I developed an (unjust) animosity for systemd when a `pacman -Syu` installed it and broke my Arch system (which relied on a small password-prompt initscript written by me that I had completely forgotten about) but when I took a fresh look it didn't look bad. I have only a year of so of real GNU/Linux experience so take this with a grain of salt, but I think that even if systemd's got problems, they're not related to it being too monolithic. And although I haven't really measured, my ancient Atom-based MSI netbook seems to boot way faster than with initscripts.

hdevalence• 12 years ago

The systemd developers are responding to upstart and launchd and android init as things they must _defeat_, an establish a new standard by crushing all the competing implementations.

This actually... isn't true. If you feel like wasting valuable time of your life, try reading the Debian systemd flamewar: the people with the most rabid 'holy war' attitudes are the systemd opponents.

People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2].

Fedora/RHEL, SuSE, Arch, and now Debian didn't decide switch to systemd because they were all strong-armed by Lennart's evil cabal or something, they did it because each of them decided that it was a superior system.

Because it is [3], and no other system, save Upstart, actually put in the work required to be a potential replacement.

[1] https://lists.debian.org/debian-ctte/2014/01/msg00287.html

[2] http://www.redhat.com/archives/fedora-devel-list/2008-Januar...

[3] http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWo...

magpi3• 12 years ago

People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2].

I appreciate most of your post, but this line really bugs me because I hear it so often.

Relevant xkcd: http://xkcd.com/743/

Valuing open systems/ecosystems is about more than valuing "shit getting done." You also have to value _how_ it gets done, and people who do value how it gets done should not be dismissed as bloggers writing about "freedom of choice."

mackal• 12 years ago

In most cases the opponents are mainly opposed because of Lennart, not technical reasons, not freedom of choice, but because of Lennart. Most of them will explain their reason with refences to technical or freedom of choice but once you get down to it, its just Lennart.

You know what your average user wants? A faster booting system. In most cases that will be systemd.

rektide• 12 years ago

God save us from software that bends over backwards to help average users. The only thing worth doing with software is pushing it forward.

felixgallo9• 12 years ago

You couldn't be any more wrong. The average user has no idea that she is using Linux. The number of people using a Linux system that reboots frequently enough to be noticed is zero.

JoshTriplett10• 12 years ago

People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2].

Exactly. Half of the complaints I see about systemd don't even bother to make any arguments against it other than wanting to move away from it. For instance, see the most recent round of discussion on debian-devel, in which someone gripes that systemd has dared to take over the functionality of invoking fsck on disks at boot time before mounting them. The horror of this scenario clearly cannot be adequately conveyed in an email, or at least nobody in the discussion attempted to convey it.

pmoriarty3• 12 years ago

"someone gripes that systemd has dared to take over the functionality of invoking fsck on disks at boot time before mounting them"

This is a good example of what the original article complained about: systemd is a step towards monolithic systems and a step away from the unix philosophy:

  "The Unix philosophy emphasizes building short, simple,
   clear, modular, and extendable code that can be easily 
   maintained and repurposed by developers other than its
   creators..."[1]

systemd is feature-creeping bloatware in the Windows mold and it's no wonder a lot of unix fans who value "short, simple, clear, modular, and extendable code" have a problem with that.

[1] https://en.wikipedia.org/wiki/Unix_philosophy

bitwize3• 12 years ago

Actually, one of the goals of systemd is to standardize all Linux distros on a single set of tools. Which means that, yes, alternatives will go insupported. But in order for Linux to transition from just a kernel to a platform, you must have ONE userland stack and ONE set of APIs to cide to... for everything from system calls to UI layers and system management. This is an advantage that Windows had, and systemd finally brings it to Linux

angersock• 12 years ago

And that's why Windows enjoys such dominance in the server market!

asb2• 12 years ago

I fail to understand the swipe at Canonical for having /bin/sh point to dash. Having /bin/sh point to a lightweight POSIX compliant shell seems a wholly sensible choice. Indeed, the ability to swap out one implementation for another (made possible by the POSIX standardisation of the unix shell) seems to be exactly what he's arguing for elsewhere in the article.

byroot• 12 years ago

I'm pretty sure this change was initiated by Debian. I recall it was already the case on Debian stable circa 2008.

masklinn2• 12 years ago

According to each distribution's documentation, Debian switched to dash in 2011 with Squeeze[0] whereas Ubuntu switched in 2006[1]

[0] https://wiki.debian.org/Shell

[1] https://wiki.ubuntu.com/DashAsBinSh

intslack• 12 years ago

The vast majority of distros seem to agree that standardization is a good thing in the switch to systemd. If you don't want to be standardized maintain it yourself, see: GoboLinux.

But modularity of Linux doesn't seem to be going anywhere. Contrary to what the author says, systemd is not monolithic but rather consists of protocols and multiple daemons outside of PID1.

There doesn't seem to be any plans to stop one from using anything other than systemd on say Debian either. As far as I know the only hard requirement for systemd (really logind) is with Gnome on Wayland for user seats, because Consolekit is dead. Gnome seems to be willing to work with the *BSDs et al who have no plans to switch to systemd.

https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...

makomk2• 12 years ago

It consists of multiple daemons which are relied on by userland applications, are so strongly interdependent that the systemd developers don't support running them independently, and which have no stable or documented APIs between the different components. Oh, and many of them are infeasable to re-implement according to said developers.

Now, the Gnome developers may argue that technically Gnome doesn't require logind, and technically they're right. You lose the ability to shutdown, restart, sleep or hibernate your PC from the Gnome user interface - all things that worked before and that normal users expect to be able to do - but you can technically run without it. The API for those things isn't itself terribly complicated, but because the systemd and Gnome developers don't give a fuck about anything other than systemd they've bundled it together with a whole bunch of complicated, poorly-documented multiseat stuff that can only be implemented as one single, monolithic all-or-nothing API.

Which is, I think, part of the reason why Ubuntu gave up and is switching to systemd; they can hardly ship something that requires users to use the command line to shutdown or suspend their PC.

Edit: Also, the bit about how "we specifically approved some patches to allow Canonical to run logind without systemd" is... well, outdated is probably the politest way to put it. Since then the systemd developers have announced that they're breaking the ability to run logind seperately in future, they never supported it in the first place, and Ubuntu should never have done it.

Sanddancer3• 12 years ago

The problem is that while systemd is superficially a bunch of different commands, they are a clinking, clanking mess of poorly documented programs that do their job worse than the programs they replace.

For a moment, let's look at one of these components, systemd-backlight, and it's terribly written manual page, http://www.freedesktop.org/software/systemd/man/systemd-back... . Okay, so what return values can you expect? Where on the filesystem does it store the saved values so you can debug if things do go cactus? Why does it always overwrite the value at shutdown? These are all things that a reasonable program either should not do, or should document why and where they put things. Systemd just is not a responsible, well-engineered project.

Furtnermore, the only real reason consolekit is dead is because Lennart again shows a complete lack of responsibility as a developer with that project. He'd rather shove everyone towards his new baby of systemd than to do a responsible hand-off. This is furthered in his inability to document the interfaces used so that people can write compatible software, so that people can debug software, and so that people can maintain things if he ever gets hit by the number eight bus going downtown. It's just not a good way to run things, period.

JoshTriplett10• 12 years ago

Where on the filesystem does it store the saved values so you can debug if things do go cactus?

Quoting the page you linked to: "On disk, the backlight brightness is stored in /var/lib/systemd/backlight/."

lasermike0262• 12 years ago

I agree with this article. In addition, systemd, upstart, and launchd are just not up to it. Time to go back to the drawing board.

duskwuff2• 12 years ago

The fact that you're mentioning launchd in the same breath as systemd and upstart suggests that you don't actually know a lot about the situation. launchd is a Mac OS X init equivalent. It has never, to the best of my knowledge, been ported to Linux at all.

lasermike0262• 12 years ago

You didn't read the article. Launchd is being ported to BSD. If you knew anything about about any of these inits you would see their similarities.

erikb2• 12 years ago

Aren't the init wars just over? I saw photos from the still running German Linux Tag were people are wearing T-shirts with "I survived the init war" (or something like that) on it. I think we better leave it at that.

vezzy-fnord6• 12 years ago

The init war was never properly "fought" to begin with. It was presented as a false trichotomy between systemd, Upstart and OpenRC, when there were other options lying in plain sight that could have been researched, such as depinit: https://web.archive.org/web/20050206182736/http://www.nezumi...

systemd was simply far more visible and offered more than Upstart, which wasn't all that well engineered, admittedly. OpenRC was largely skimmed over, for some reason. systemd also had that aura of being "innovative," even though most of its concepts are old and were done well by systems such as Solaris SMF (although it isn't without flaws, either).

systemd came in at the right place, right time, was given a boost by a company as renowned in the developer community as Red Hat, and as such was adopted as a solution by people looking for a convenient fix, rather than actually trying to tackle the issue from the core.

sounds• 12 years ago

I've had great success with OpenRC.

erikb2• 12 years ago

I agree that the two developers are really good community people and therefore are able to win over votes that might not be as objective as they should have been. But I think it's also a skill to tackle a community together and focus them on one goal. This also improves FOSS as a whole, even if the software might not be the best.

vezzy-fnord6• 12 years ago

The main source of ideological disagreement between pro-systemd and anti-systemd users is just how much an init should handle. Anti-systemd side insists on init being just an init and not exceeding its duties, whereas pro-systemd are willing to make the init handle various other functions, due to the alleged benefits.

I think at this point it's erroneous to call systemd an "init system," it's far more than that and Lennart himself freely admits it in (ironically) the article meant to dispel systemd myths (http://0pointer.de/blog/projects/the-biggest-myths.html):

Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.

I'm not entirely sure about how optional the whole package really is. I know for a fact LXC tools like systemd-nspawn, Python bindings, etc. can be removed from the build using ./configure, but I don't know the full extent to judge the veracity of his claims.

Olav Vitters of GNOME and Debian (I believe?) later echoes the same sentiment in a somewhat self-contradictory manner: http://lwn.net/Articles/575790/

Systemd is meant to do one thing and do it well: be the basic building block for Linux.

Of course, one must first define what a "basic building block for Linux" is, although that isn't really elaborated.

Personally, I don't have any strong opinions in favor of or against systemd, but I do feel it was introduced in a rather rushed manner. I think it would have payed off better for the community if people researched certain alternate init schemes that were already present before systemd (not talking about launchd/Upstart), such as Richard Lightman's depinit: https://web.archive.org/web/20050206182736/http://www.nezumi...

However, it's probably a bit late by now, since systemd's place has been set in stone, for better or for worse.

revscat• 12 years ago

Could someone with more knowledge about the subject explain why launchd was never taken up outside of OS X? I'm not an admin by any stretch of the imagination, but it seems to fit the bill fairly well, and I've always wondered why it has not been ported elsewhere.

vezzy-fnord6• 12 years ago

Licensing issues at the time. That's what Upstart was initially meant to be, actually: a native launchd clone. If it wasn't for the Apple Public Source License that launchd was under back in 2006, Ubuntu would have probably been using it right now.

vvhn• 12 years ago

launchd makes heavy use of Mach IPC ( http://en.wikipedia.org/wiki/Mach_(kernel) ) which makes a port to any other non Mach derived OS a non trivial effort. There was apparently an effort to port it to FreeBSD - https://wiki.freebsd.org/launchd and more recently https://github.com/rtyler/openlaunchd/blob/master/README.md .

JoshTriplett10• 12 years ago

Partly because launchd didn't have a sensible Open Source license, and partly for the same reason systemd doesn't run on non-Linux kernels: it's designed for its target OS, and makes use of that OS's native functionality to the point that porting would become decidedly non-trivial.

systemd took heavy inspiration from launchd and other sources, but provides extensive functionality that launchd does not.

jordigh• 12 years ago

systemd is essentially a reimplementation of launchd for Linux. The systemd devs explicitly acknowledge this inspiration.

jqm2• 12 years ago

I have no problem with systemd but neither do I have a reason to use it (although I admit, Poettering's general attitude does bother me a bit).

As long as Slackware doesn't incorporate systemd and alternatives remain I'm fine. If alternative disappear, I guess I'll cross that bridge when it happens.

pmoriarty3• 12 years ago

Does anyone have any insight in to why something like runit[1] was never a serious candidate for a sysvinit replacement in any mainstream Linux distro?

[1] http://smarden.org/runit/

zdw2• 12 years ago

A few reasons:

- There's a general opposition to the djb's designs and tools, which has some basis in their licensing, and is why djbdns and qmail aren't in the default distro of most systems. Note that this is being reversed right now with the embrace of NaCL crypto (Salsa20/ChaCha/Poly1305, etc.) as alternatives to the mainstream.

- runit is pretty much an reimplementation of djb's daemontools for service supervision.

- runit/daemontools definitely do things their own way. Service directories make sense, but they tend to be shell scripts all the way down. Logging is quite different and non-centralized. Services need to be set not to fork and do their own daemon management. And the list tends to go on - this unusual-ness is generally not what people want from a core OS part.

So, in short, there's no reason why people haven't used runit, other than "nobody else is doing it" and "it's different and has quirks".

pjscott• 12 years ago

Note that both djbdns and qmail have been in the public domain for years now. The general opposition to their license seems to have long outlived their license.

pmahoney• 12 years ago

I agree with your points, though am disappointed by this reality. I've been aware of daemontools for some years, but only recently read over the design (which I find quite brilliant) and began using an implementation (s6 at the monent [1]).

I know you weren't arguing against daemontools, but just wanted to share some thoughts:

Service directories make sense, but they tend to be shell scripts all the way down

This is true, but what are you doing in your "run" script that is so complex? Also, any executable will suffice. s6 provides 'execline' [2] which simplifies some use cases (and complicates others...)

Logging is quite different and non-centralized

Arguably a feature. I'm quite enjoying the "logging chain" where every service logs to stderr which either goes to its specific logger process or bubbles up to that of the parent process.

The typical usage of syslog is to collect all log messages in a centralized inbox and then (by some pattern matching; log messages must contain enough to be categorized) split them up again and write them to separate files. Skip all that with logger-per-service.

Services need to be set not to fork and do their own daemon management.

Clearly a feature. There is no need for the redundancy of multiple, error-prone implementations of daemonization routines in every service. Also, language nitpick, it's not that a service can't fork. For example, daemontools can happily supervise a Unicorn master process that will fork off its own workers. The service must not background itself by severing ties with its parent (which involves forking of course).

But there are downsides and quirks as you say. Two examples:

If you really want something like Nginx or Unicorn to be able to restart without dropping http connections (e.g. fork+exec new master process, gracefully shutdown and kill old master process), then you will run into issues. It's possible to hackishly wrap this in a helper script. Daemontools would supervise the helper, which would in turn manage nginx via plain old racy PID files, just like init.d scripts.

I'm only familiar with daemontools and s6, but they assume TERM is the signal to use to stop a service, and don't provide configuration to send, say, QUIT which Unicorn interprets as "graceful shutdown". (Upstart also did not allow this until fairly recent versions.) It's one thing to get a service to not daemonize itself. It's another thing to expect upstream to modify its signal handling.

[1] http://skarnet.org/software/s6/ [2] http://skarnet.org/software/execline/

pmoriarty3• 12 years ago

"runit/daemontools definitely do things their own way"

And systemd doesn't?

JoshTriplett10• 12 years ago

Replying to the article:

The first issue is that Linux has always been a commodity white box OS built from interchangeable parts available from multiple sources, just like the PC. Systemd goes out of its way to break that, and in doing so represents an enormous loss of flexibility.

systemd goes out of its way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault. And because of systemd, we're finally starting to get a level of integration that previously only appeared in proprietary operating systems. http://islinuxaboutchoice.com/

Linux is good at evolutionary changes, but not nearly as good at escaping local maxima via large-scale cross-project changes. Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames.

Every time I see someone railing about the UNIX way, I think of how people flame each other about / versus /usr, and how the original motivation for /usr was "we ran out of space on /, put some of the less critical stuff on the user disk". Appeal to tradition is not an argument unless you have a concrete reason why the tradition is better, and I rarely see such reasoning in arguments leveled against systemd.

I've also found that well-articulated and well-founded arguments about problems in systemd don't tend to last long, because systemd will fix them. I'd encourage people who see a legitimate technical problem with systemd to go discuss it on the systemd mailing list; you might be surprised how quickly it gets fixed, if it has substance.

Linux systems are modular, with multiple implementations of anything important.

Feel free to make something better than systemd, document it as extensively as systemd, spend years writing guides to its most compelling features that get people eager to switch, and do as much work as the systemd developers did to help the entire Linux ecosystem adopt it with shockingly few technical problems. There's nothing stopping you; you can even leverage the entire systemd codebase in the process. Fork it and change what you don't like, if you think you can keep up. Good luck; you'll need it.

But systemd isn't like that. It's a single all or nothing blob

Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against. systemd runs incredibly little in PID 1; it has numerous separate single-purpose processes (typically named /usr/bin/systemd-foo or /lib/systemd/systemd-foo), as well as several libraries abstracting out key bits of common functionality for other code to use.

Ubuntu did upstart, but ubuntu also did unity, and mir, and pointed /bin/sh to dash, and their launchpad is based on the obsolete "bazaar" source control system... People not following Ubuntu's technical lead is pretty deeply justified at this point.

Now this one is actually a very well-made point, and it's something few people have stated outright. There's a reason that few other distributions switched to upstart; while it adds a few key features over sysvinit (such as service supervision), it has some serious deficiencies as well. It's not at all clear that switching from sysvinit to upstart would have been an improvement. And the biggest key feature of upstart, service supervision, is actually something sysvinit already has but nobody uses: you can run a process directly from inittab, and sysvinit will restart it when it exits. But rather than using that, every Linux distribution just uses sysvinit to launch a shell script that launches a hundred other shell scripts.

That said, I applaud Ubuntu for actually trying to make major changes to Linux. Unity isn't what everyone wants, but it's certainly an attempt at a non-incremental improvement over other desktop environments, and it has some nice properties. Similarly, Bazaar was an attempt to do better than CVS and SVN, and it's not wildly awful; it just lost to an even better system for a variety of reasons (http://www.stationary-traveller.eu/pages/bzr-a-retrospective...). /bin/sh -> dash is, while not necessarily inherently better, an attempt to enforce an absence of bashisms in #!/bin/sh scripts, and an attempt to improve the performance of such scripts; in that, it has worked reasonably well.

There's no excuse for Mir, though. :)

Android also has a no GPL in userspace policy

Not exactly, though Android certainly pushes back on GPLed code. They're willing to adopt it when there's no viable alternative. But systemd is LGPL these days, not GPL. And even if systemd were GPL, it would still be quite possible to use systemd as an init system to launch proprietary software.

Regardless of Android's allergy to copyleft, permissive-versus-copyleft is an ancient holy war that long predates Android. The only reason the argument comes up so strongly in this case is that systemd is the right combination of rapidly developed and too useful to ignore to make it a serious threat to people who don't want to use it. If systemd were less useful, or otherwise easier to clone, its copyleft license would be less of a concern to the opponents of copyleft. That's a feature, and it's exactly the kind of thing the authors of the GPL and LGPL had in mind: the existence of high-quality software under copyleft licenses that make life difficult for the proprietary software world.

Personally, I was rather disappointed when systemd switched to the LGPL; I would have rather seen it remain GPL.

Those of us waiting to see how it shakes out feel we're having systemd shoved down our throats by a development team actively threatened by the idea of people _not_ using their stuff.

It couldn't possibly be that the software is sufficiently compelling that those without religious objections to it are switching to it to take advantage of its useful features. No, it must be a conspiracy.

But even if it wanted to, android can't easily clone systemd, becuase it's (intentionally) a moving target with no standard and no documentation.

"no documentation" is insultingly misinformed; systemd is one of the best documented software products I've ever seen.

And in any case, why should the systemd developers go out of their way to make life easier for people who don't want to use systemd, when they could instead spend their time making life better for people who want to use systemd?

We can't opt out and see how it goes, we must fight to stay where we are.

Sure you can opt out: just sit there doing nothing, and the world will pass you by. Or you can participate, and do as much work as the systemd developers are doing, in favor of your preferred system. What you can't do is try to stop other people from doing work you don't like without putting at least as much work into a better alternative. Keep up or get out of the way, don't shout "wait up" or "no fair".

asb2• 12 years ago

Systemd detractors seem to view the pre-systemd landscape through rose-tinted glasses or at least completely ignore what has been going on with the desktop. I hardly think ConsoleKit embodied the UNIX philosophy, and if the various desktop environments end up replacing their own subtly different session managers with systemd user session management that seems like a step forwards to me, both for the Linux developer community and for the end user.

JoshTriplett10• 12 years ago

Agreed. In particular, systemd detractors rarely have answers for questions like "so how would you solve that problem?".

felixgallo9• 12 years ago

I can't speak for any other 'systemd detractor', but I can definitely confess that I've completely ignored what's going on on the desktop. Because it's been utter crap for the last 20 years and is clearly getting no better.

The fact that the desktop is now spawning lovecraftian horrors from the deep in the service of 'booting to the desktop faster' and 'supporting hot-plug devices better' and that those awkward, stupid requirements now threaten to invade the standard installation on my servers, that definitely has my attention now, though.

vezzy-fnord6• 12 years ago

systemd goes out of its way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault. And because of systemd, we're finally starting to get a level of integration that previously only appeared in proprietary operating systems. http://islinuxaboutchoice.com

So, basically you're advocating for a walled garden approach, then you link to a novelty domain that points to a Red Hat mailing list discussion where some person rants like a demagogue in a disjointed fashion that doesn't prove jack shit.

Quite impressive.

Or because Linux userland developers have historically been bad at cathedrals? The bazaar has always been more suited to the Linux community, and makes Linux distinct and refreshing compared to BSDs (which are an example of cathedral done right, by the way).

I've also found that well-articulated and well-founded arguments about problems in systemd don't tend to last long, because systemd will fix them. I'd encourage people who see a legitimate technical problem with systemd to go discuss it on the systemd mailing list; you might be surprised how quickly it gets fixed, if it has substance.

If the systemd team's insistence on not taking patches for alternative libcs, Lennart's circular argument on why you should adopt systemd because of systemd-logind being tightly coupled and hard to reimplement (https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...), the recent Kay Sievers controversy and other issues are anything to show, it is that the systemd team very much have their own convictions that are at odds with anyone else.

JoshTriplett10• 12 years ago

So, basically you're advocating for a walled garden approach

You can get integration without a walled garden. There are no walls on the systemd garden; there's just a well-maintained garden that attracts an increasing number of people. You don't need walls to keep people in when you have sufficiently compelling technology that they want to stay.

And you didn't actually respond to anything in the mailing list post about "choice", other than its tone. There's a key point to be learned from that post: just because a alternatives exist doesn't mean they all have to be equally well supported by every Linux distribution. Linux distributions, as one of their primary functions, make choices for the user: they select a set of components and make those components work well together. systemd helps there, by providing a set of components that integrate quite well, and by getting rid of some of the zero-value differences between distributions (/etc/hostname versus /etc/HOSTNAME versus /etc/sysconfig/..., for instance).

Or because Linux userland developers have historically been bad at cathedrals? The bazaar has always been more suited to the Linux community, and makes Linux distinct and refreshing compared to BSDs (which are an example of cathedral done right, by the way).

I actually agree with this, but I don't see how it's a response to what I said. Linux, in not using the cathedral method, has a hard time making major changes to escape local maxima, and when such changes do happen it's typically through the focused efforts of a small group dedicated to fixing a particular class of issues. For instance, the Linux kernel is a bazaar, but major new subsystems are not typically developed collaboratively from scratch, they're provided in a functional initial form and then evolved from there. And when it finally comes time to replace them, they're typically replaced as a unit rather than incrementally evolved.

And personally, I wouldn't mind seeing Linux distributions learn something about organization from the BSDs, not least of which by requiring that all packages appear in the same version control system side-by-side on the same server.

If the systemd team's insistence on not taking patches for alternative libcs

systemd refuses to work around bugs in other software unless absolutely necessary; when that software is FOSS, it can be fixed rather than worked around. And systemd does have some patches to handle less capable libc implementations, such as definitions of system calls that libc implementations might not have. On the other hand, it seems quite reasonable to require functions like asprintf rather than reimplementing them, especially for an init system specifically designed for Linux.

Lennart's circular argument on why you should adopt systemd because of systemd-logind being tightly coupled and hard to reimplement

logind needs cgroups. PID 1 needs to manage cgroups. There's a solution that works today, providing features that desktop environments need, for which alternatives do not yet exist. And if you're not a fan of that solution, there are people working right now to create an alternative solution using cgmanager.

the recent Kay Sievers controversy

In which kernel developers ranted about a bug in systemd that had already been fixed before the discussion ever started, and proposed childish kernel patches like "if PID 1 is named systemd, panic()"...

the systemd team very much have their own convictions that are at odds with anyone else

Per my previous comment: 'Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames.'

Yes, the systemd team is trying to make large-scale changes to the way Linux works. That necessarily puts them at odds with the way Linux currently works. That doesn't make them wrong: Linux is not yet perfect and could use further improvement. (It doesn't make them inherently right, either.)

jude-8• 12 years ago

systemd goes out of its way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault.

Windows goes out of the way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault. And yet, Linux users don't clamor for Windows because of this.

http://islinuxaboutchoice.com/

This is exactly the attitude the author is arguing against. Reaffirming this without justification doesn't make you right. Again, Windows is the operating system for people who don't want choice.

Feel free to make something better than systemd, document it as extensively as systemd, spend years writing guides to its most compelling features that get people eager to switch, and do as much work as the systemd developers did to help the entire Linux ecosystem adopt it with shockingly few technical problems. There's nothing stopping you; you can even leverage the entire systemd codebase in the process. Fork it and change what you don't like, if you think you can keep up. Good luck; you'll need it.

Honestly, sysvinit and the existing userspace does all I need it to do. The extra benefits systemd offers I can do using existing tools. Need to reliably kill a service? Use the cgroups tools and put the service into its own cgroup, and then kill all processes in the cgroup later. Need tamper-evident logging? Use the rsyslog tools. Need dependency-based boot? insserv has got you covered. Need automatic device-node creation, and the ability to run programs based on device events? udev did this just fine before systemd.

Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against.

Systemd's components are tightly-coupled. How, pray tell, do I run logind without systemd as PID 1? How, pray tell, do I remove journald? Oh, that's right. I can't. By design. That makes it monolithic.

It couldn't possibly be that the software is sufficiently compelling that those without religious objections to it are switching to it to take advantage of its useful features.

Or, it could be that people now have to choose between having a desktop environment and NOT having systemd. The tight coupling of systemd to layers above it compels its adoption, arguably more so than its merits.

By contrast, X.org and Xfree86 (an example from the article) were largely interchangeable.

Keep up or get out of the way, don't shout "wait up" or "no fair".

Have fun running over the cliff to your new Windows-ix :)

JoshTriplett10• 12 years ago

Honestly, sysvinit and the existing userspace does all I need it to do. The extra benefits systemd offers I can do using existing tools. Need to reliably kill a service? Use the cgroups tools and put the service into its own cgroup, and then kill all processes in the cgroup later. Need tamper-evident logging? Use the rsyslog tools. Need dependency-based boot? insserv has got you covered. Need automatic device-node creation, and the ability to run programs based on device events? udev did this just fine before systemd.

And yet nothing integrated all those features well enough to get people to widely adopt them. systemd services make it trivial to run a process in its own cgroup, isolate it, log everything about it, activate services as needed, and manage and track services launched in response to devices. There's nothing stopping you from building your own Linux distribution that integrates all of those tools, and there are certainly enough systemd opponents to try. If they build something compelling, people might use it.

(Also, insserv doesn't come close to the parallel boot that systemd enables, via socket activation, bus activation, and similar. If B and C depend on A, insserv lets you start B and C in parallel, but systemd lets you start A, B, and C in parallel.)

Systemd's components are tightly-coupled. How, pray tell, do I run logind without systemd as PID 1? How, pray tell, do I remove journald? Oh, that's right. I can't. By design. That makes it monolithic.

To run logind without systemd, you can wait for the cgmanager folks to provide an implementation of equivalent cgroup management functionality for logind to use. Until then, your complaint is much like the complaints about systemd not running on Linux: Linux has features other OSes don't, and systemd intentionally takes advantage of them, "by design". Does that make the combination of systemd and the Linux kernel "monolithic"?

This is "by design" in much the same way that a program using features from Python 2.7 that don't work in Python 2.6 does so "by design". And it's perfectly reasonable for a project to refuse patches for compatibility with Python 2.6 and say "upgrade to 2.7". Just like it's perfectly reasonable for some projects to say "run Linux" or "run systemd", because it has features that nothing else does.

By contrast, X.org and Xfree86 (an example from the article) were largely interchangeable.

They were in the start, when X.org initially forked from the XFree86 codebase. But today, you cannot drop XFree86 underneath a modern desktop environment and expect it to work; it'll complain about the myriad X extensions introduced in X.org to make those desktop environments possible. And yet, nobody noticed, because nobody cares about XFree86 anymore.

jude-8• 12 years ago

Also, I'm not sure what you mean by "massive integration issues." Can you identify a "massive" (i.e. show-stopping) problem in Linux-based operating systems that (1) is due to software A not correctly interacting with software B, (2) that systemd solves, (3) that existing tools cannot solve, even with proper configuration, necessitating systemd?

I'm having a hard time thinking of any, but I'd love to know of some.

JoshTriplett10• 12 years ago

A few examples, off the top of my head:

Socket activation (and related features like bus activation) are one of systemd's key improvements to the boot process. Activation avoids the need for explicit dependencies, because you don't need to depend on avahi to start using the avahi socket. And because of that, systemd can launch avahi and services using avahi in parallel, by opening the socket for avahi, and letting other services write to that socket before avahi fully starts, only blocking when they go to read from it.

You could do that with inetd or similar, but inetd doesn't integrate with the init system, so an inetd service can't declare any dependencies on other services, and won't get tracked alongside other services (e.g. with systemctl status). So in practice, very few distributions actually launched services from inetd in practice (notable exception: CUPS), while many distributions use systemd's socket activation.

People care about booting quickly. While mechanisms like bootchart existed before systemd, you had to explicitly boot with them to collect results for analysis, and they'd slow down the boot process. With systemd, you can run "systemd-analyze blame" or "systemd-analyze critical-chain" on a production system and see exactly what you need to work on to make the system boot faster. (That was one of the widely lauded features of DTrace: you could safely use it to diagnose production systems.)

Then there's journald's original reason for existence: "how can we make 'systemctl status' show the last few lines of log output from a service?". How would you do that on an arbitrary system running an arbitrary syslog implementation? (For extra bonus difficulty, do so while attempting to track the syslog implementation as a service itself, and avoid deadlocks.) Sure, you could recreate that functionality on a particular system with a particular logging configuration, and there are dozens of systems doing so, not counting the myriad production systems deployed with bespoke solutions for log monitoring. (Even then, most of those systems don't correlate a service's log output with that service.) But systemd makes it easy and universal.

And that integration extends beyond systemd as well. For instance, if fixing a problem requires adding a new kernel interface, they'll submit a kernel patch, and then have systemd use that new kernel interface, rather than hacking around the problem in systemd and producing a suboptimal solution.

gkya2• 12 years ago

This is the longest HN comment I have read that includes exactly zero important things. The ultimate problem is the lack of a standard in the init family of software. If I have to write eight initialisation scripts to support eight different Unices, then the major problem is this, not the features, or the philosophy.

JoshTriplett10• 12 years ago

I was responding to the article, not writing a standalone article about systemd. Regarding standardization, I agree completely, and that's one of the problems systemd is trying to solve: rather than writing eight init scripts, you can write one systemd service file. That's partly due to systemd standardizing various features that distros previously had to reinvent, and partly due to a general philosophy that treats gratuitous differences between distributions as a bug to be fixed rather than a feature to be reveled in. When writing a systemd service, if you encountered an issue that would require you to have a distribution-specific service file, you could very reasonably report it as a bug and get it fixed.

1ris• 12 years ago

http://islinuxaboutchoice.com/

Hands down, this is the one of the most retard "arguments" in the whole debate.

"ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.

Ok, if you think so use OS X, but stop braking linux, please. (By the way, it's 2014 and my network-manager does not work, it randomly crashes and needs to be restarted. Thanks god there is wird and linux is actually about choice.)

felixgallo9• 12 years ago

Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against. systemd runs incredibly little in PID 1; it has numerous separate single-purpose processes (typically named /usr/bin/systemd-foo or /lib/systemd/systemd-foo), as well as several libraries abstracting out key bits of common functionality for other code to use.

Come come, no need to pretend to be dense on this topic. Address the argument, rather than engage in rhetorical bluster.

You know, and I know, and everyone knows because it's public knowledge, that systemd is an incredibly tightly bound bundle of highly opinionated tooling, regardless of how many process IDs it uses. You know, and I know, and everyone knows because the maintainers say so[1], that no piece of systemd can be replaced, and indeed they further astonishingly assert that certain bits of systemd logic literally cannot be reimplemented by anyone else or removed.[1]

You know, and I know, that systemd is attempting to gain creeping control over an ever-growing pool of functionality normally handled by logically separated tools, frequently without regard to merit (e.g., stashing core dumps in a binary log; the 'debug flag' debacle[2]).

So if we know all of these things, then why do you pretend otherwise, and unleash vitriolic insults against people based on your straw-man specious reasoning? And if you can answer that, can you then tell me, why is this not just standard practice amongst the systemd advocates, but rhetorically uniform therein?

[1] https://plus.google.com/+LennartPoetteringTheOneAndOnly/post... [2] https://lkml.org/lkml/2014/4/2/420

blux• 12 years ago

So, why not fork systemd and modularize it...?

jude-8• 12 years ago

I think OpenBSD is working on that this summer.

http://www.openbsdfoundation.org/gsoc2014.html#systemd

Aloha• 12 years ago

I still sorta look at systemd as a solution looking for a problem.

System V style init is just 'good enough' for most applications - and if there is anything I've found in my time, the only people more adverse to change then telecom folks are Unix system administrators.

Workaphobia• 12 years ago

There was a lot of repetition about X, Y, and Z being anathema to the systemd people. I would've appreciated some links backing up these claims of their hostility. I've heard so much against systemd, and so little that wasn't hearsay. (This is not a comment on the merits of the objections against systemd, just on the exposure to the arguments I've gotten from casually browsing hackernews.)

drdaeman• 12 years ago

So the systemd developers are saying a billion android devices aren't interesting [...]

Isn't being anti-GPL (and pro-vendor/anti-consumer) primarily Android's and not systemd's issue?

Even considering that Android is a big thing, it's still possibly unwise to get rid of copyleft just to please Google and be accepted into phone vendors' proprietary blobs.

skylan_q• 12 years ago

The theme of Monolithic vs. Modular reminds me of Linux vs. Minix.

The Tanenbaum–Torvalds debate was a debate between Andrew S. Tanenbaum and Linus Torvalds, regarding Linux and kernel architecture in general. Tanenbaum began the debate in 1992 on the Usenet discussion group comp.os.minix, arguing that microkernels are superior to monolithic kernels and therefore Linux was, even in 1992, obsolete. Other notable hackers such as David S. Miller and Theodore Ts'o joined the debate.

http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deba...

A link to the newsgroup discussion: https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...

jude-8• 12 years ago

More like a tightly-coupled (monolithic) vs loosely-coupled (non-monolithic) debate. Systemd is modular, but its components are tightly-coupled. The key difference between systemd vs the existing userspace, and Linux vs Minix, is that there's ~50 years precedent of loosely-coupled being the winning design paradigm in the long run. This is because a system made of loosely-coupled components allows the user to add, remove, and swap out parts independently of one another without having to drop the whole OS, thereby gaining the ability to adapt the OS to a changing set of requirements with minimal cost. Tightly-coupled systems do not have this advantage, and it makes them brittle in the face of change.

whoopdedo2• 12 years ago

I've been a stick-in-the-mud about changing to systemd until I bumped into an ugly wart of sysvinit. While upgrading a service I moved the old daemon aside in case I wanted to downgrade again, then remembered that I hadn't killed it. So typed `/etc/init.d/myservice stop` and saw it did nothing. Huh? Oh, that's right. The simplistic script won't do anything if the daemon file doesn't exist. I had to manually kill the PID. So would I be correct in assuming that systemd would know the service names of all running daemons and be able to stop them without having to check to original file?

vezzy-fnord6• 12 years ago

Well yes, systemd is far more sophisticated than sysvinit. No one here is advocating for sysvinit, as it does need a proper successor. "sysvinit or systemd" is a false dichotomy, however.

pjmlp• 12 years ago

Interesting how the evolution of GNU/Linux distributions and their interactions with other UNIX systems just look like the second coming of UNIX wars.

What's wrong with systemd

Related Stories