Systemd's Plan For Stateless Systems, Factory Resets

[psychoticmeow]

And since people keep asking what's wrong with systemd (although it's been explained over and over) - here's a nice list of most important issues:
http://boycottsystemd.org/

Oh boy, this is exciting!

1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration and other things.

So basically they don't understand the actual architecture of systemd, that the dozens of binaries can be reduced to a very minimal set, and that it is more than an init system, that each binary is responsible for "doing one thing and doing it well".

2. systemd's journal files (handled by journald) are stored in a complicated binary format2, and must be queried using journalctl. This makes journal logs potentially corruptable. Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well.

Potentially corruptable? Says who, and why are they more potentially corruptable than any other log? And how does this discount the benefit of actually having structured data being logged?

And it doesn't need an embedded HTTP server to read them, and when exactly are QR codes served? It seems to be trying to paint a picture of runtime bloat where there isn't any.

3. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.

Boo fucking hoo. Want the functionality? Don't like the developers? Implement the API, you're free to do so.

4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago3.

And dbus is becoming kdbus. What of it? This isn't so much an argument as a simple statement of fact.

5. By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using systemd-coredumpctl4. Besides going against all reason, it also creates complications in multi-user environments (good luck running gdb on your program's core dump if it's dumped to the journal and you don't have root access), since systemd requires root to control. It assumes that users and admins are dumb5.

The unstated premise is that doing this is inherently a bad thing, but it is never explained why, instead they cite a potential system configuration issue as though that is the fault of systemd. I've just checked, and you can in fact access core dumps without being a root user.

6. systemd's size makes it a single point of failure. As of this writing, systemd has had 9 CVE reports, since its inception in March 20106. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.

Again, the init process itself isn't that large, and is the area of primary concern. The author doesn't understand the architecture as discussed previously.

7. systemd is viral by its very nature. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps7. This means GNOME versions >=3.8 are incompatible with non-Linux systems, and due to GNOME's popularity, it will help tilt a lot of maintainers to add systemd. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. It's also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well - blatant coercion8.

Oh no, it's a virus/cancer/conspiracy! People are adopting systemd without justification!

8. systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system goes down. There are several ways that this can occur9. This happens to be another example of SPOF.

This is the third time the authors lack of understanding of systemd has shown through, not everything in systemd is part of the systemd init process. Tries to make a point about how the init can fail, and be restarted safely, but if the restart fails can crash the system. This is of course true, it could crash the system, but is exceptionally unlikely. And some nonsense about how this makes Linux literally Windows.

9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much10.

Ok, is this a problem for Linux users, the platform that systemd was developed for? even then, in the referenced mailing list message Lennart politely declines to accept patches for a libc incompatible with glibc, with a set of reasonable exceptions, so it's not totally out of the question.

10. systemd's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the systemd API, or even patch systemd directly.

The author never explains any scenarios in which it would be necessary for users to patch systemd and assumes that using the systemd API is a bad thing all the while discounting the advanced features you get right out of the box.

11. Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and is just anti-Unix in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.

The author summarises their position by disparaging anyone who disagrees with a whole stream of negative connotations that they have failed to make a valid case for.

None of these arguments stood up to more than five minutes scrutiny, often repeat themselves, and are shrouded in a sea of references to things that are either attack pieces or fairly innocuous statements and documentation.

It's by no means comprehensive but it won't take much time to read and is straight to the point. I'm not the author but I'd sign under every word.

It doesn't even come close to being a decent criticism, of course you'd sign under every word. These same points have been brought up time and time again, only to be torn down as the clear bullshit they are, yet here you are bringing them back up again.

Do you learn prodigy? Or do you wake up every morning with no memory of the previous day?

Here's someone else's rebuttal from 60 days ago: https://news.ycombinator.com/item?id=7640104

[TheBlackCat]

Ever heard of coercion? And no it doesn't mean someone is literally holding a knife to your throat. There are other, much more subtle ways. Systemd is about forcing dependencies and limiting choices as much as possible and in the end distro/software maintainers are affected by this behavior in the same way as regular users. You can't just fork everything even if you know C as the back of your hand.

So, they are coercing KDE and XFCE into supporting socket activation, for example? How exactly did they do that?

[CTown]

I doubt anything can benefit discussions with prodigy. I wouldn't really call them "discussions" anyway. He's on my ignore list, and my life certainly has improved since, but sadly people keep quoting him :/

I'm sorry, I will stop quoting posts that seem a little out there ex. a person who quotes a tiny piece of my long post just to say that he will never run an Android-like OS on a server. Of course not, who would even try that. I thought he wanted to be my friend... then he goes on to insinuate I have a tablet! That guy...