Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

[TeamBlackFox]

Have you ever heard the concept of "Attack Surface"? here you can read about it: http://en.wikipedia.org/wiki/Attack_surface
A system deamon that has lots of features, runs as system process, and has its own built-in network services is a intruder's wet dream.

I just wanted to take a sec and say that I did not copy your post contents one bit. Here I am mentioning attack surface and glory holes and you come up with almost the exact same thing. Its odd. I guess people who hate systemd think alike. What OS do you use, I'm curious.

[nachoig]

For me, as a user, Linux is about diversity. If I don't like something, I use an alternative. It's not a "choice" but a real choice. Now, if you are telling me that I will be forced to use systemd, because the applications I like depend on it and won't work without it, then THAT is a "choice", an illusion of choice from those who defend something. That's what prodigy_ meant with "Windowisation", I think: you have "alternatives", but they are not real alternatives.

Linux is not about choice

[Ericg]

Have you ever heard the concept of "Attack Surface"? here you can read about it: http://en.wikipedia.org/wiki/Attack_surface
A system deamon that has lots of features, runs as system process, and has its own built-in network services is a intruder's wet dream.

I have heard of attack surface... do you know how to read? How many times has it been said on here, on blogs, on mailing lists, and god knows where else, that the only thing that runs as pid 1 is the service manager? Everything else is its own binary with its own permissions.

[liam]

By making it all about boot times, as if that's all systemd has to offer, your argument loses a lot of merit. It loses even more merit by your attack on Lennart.

Making cheap pot shots will not stop distros and DEs from adopting systemd.

Well, it's good then that systemd does not have built-in network services. networkd is a separate daemon, it's not in PID1. PID1 basically just contains the service manager, which includes cgroup handling. The rest is outside PID1.

What's more, pid 1 is TINY, around 5KB. That's not a huge attack surface.
Another priviledged process is udev (systemd-udevd

[Ericg]

[Mega post]

The article you linked is probably the most humorous thing I've read all day. Side-note, that article was from 4 years ago... a lots changed since then. BUT I will still point out flaws in the argument made.

This announcement caused a bit of surprise and concern for those who didn't know it was coming. Lennart's work with PulseAudio remains a bit of a difficult memory for some users (though it seems to be working well for most people now), and some people had thought that the initialization problem was solved with the growing adoption of upstart.

I love how in a post about systemd he brings up PulseAudio-- which, admittedly, wasn't perfect but lets face-facts that a big chunk of problems at the time was driver bugs exposed by the at-the-time new PulseAudio model.

Beyond that, though, some people have concerns about the use of cgroups in the first place. Peter Zijlstra worries about adding yet another feature which must be built into the kernel for the system to even boot. The Debian community does not like the use of the "debug" group, which is not currently configured into its kernels. Systemd may eventually get a more appropriately-named cgroup subsystem for its use, but it is not going to work without the cgroup feature at all. So people wanting to boot systems with systemd will need to have cgroups built in. Lennart has this message for people who don't like that:

Next time something is added to the kernel please mark it as "Hey, please don't use it, this is only here so that you don't use it. Thanks!" Maybe then dumb-ass folks like me will notice and refrain from using it.

Really? People are complaining about having to use a kernel feature?? Features are meant to be used!

[liam]

By making it all about boot times, as if that's all systemd has to offer, your argument loses a lot of merit. It loses even more merit by your attack on Lennart.

Making cheap pot shots will not stop distros and DEs from adopting systemd.

Well, it's good then that systemd does not have built-in network services. networkd is a separate daemon, it's not in PID1. PID1 basically just contains the service manager, which includes cgroup handling. The rest is outside PID1.

What's more, pid 1 is TINY, around 5KB. That's not a huge attack surface.
Another priviledged process is udev (systemd-udevd), and that's a whopping 1.5KB.
Linux is in lucky to have such a nicely architected process managment system.

[TeamBlackFox]

I have heard of attack surface... do you know how to read? How many times has it been said on here, on blogs, on mailing lists, and god knows where else, that the only thing that runs as pid 1 is the service manager? Everything else is its own binary with its own permissions.

Can you be anymore snarky? Having the service manager in PID 1 is still too much. Ugh this is the hard part to explain - PID 1 should only contain the init binary and the role of killing process zombies. Having anything else on there, it's like putting up an rlogin server against the web with no kerberos and allowing root to login remotely. Init should start up the system, setup the core processes and then in a separate binary and process ID should be the service manager.

Let me give you a real world example. I had a desktop running Arch. I was running a lot of programs at once at high load to my system, this included KDE, Tomahawk, Xnp2, Firefox with about 20 tabs htop and Thunderbird. I had recently upgraded to systemd after months of holding off and boy was I in for a surprise. After running all of this for a bit, my system hung, X died then I was back at my TTY I had logged into. Except I couldn't do ANYTHING. That's when I learned systemd had crashed. Seriously, I had been running stuff like this for months then all of the sudden my machine became unstable at high load. I rebooted with a hard reset, and all went back to normal, except it happened again and again at random. Systemd just decided to lock up and make me reboot. So I began moving my resources away from Linux distros that either committed to or had already switched to systemd. FreeBSD has been great since and since then I ditched KDE for Enlightenment so overall I had a net gain as E17 is BSD licensed.

[slojam]

systemd is in fact very modular, besides the well documented compile time options, there is even info on how to reduce it even further in size by removing features:

http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

Systemd is the best thing that have happened to Linux for a very long time. It is really good stuff, with good code, good documentation, good leadership, great many developers.

Har har good one. ANDROID is the best thing to have happened to Linux for a long time. Linux is truly everywhere now. Some would even suggest Steam (not me tho).

Systemd? Remains to be seen IMO. My computers are not doing anything today that they weren't doing 4 years ago. Are they doing anything *better*? i'm not sure about that. At least systemd is free and open source, I'll say that for it.

[chrisb]

Thank you all for detailed responses.

I understand why systemd is useful for login managers and starting the environment. I still think they should be soft dependency, but here the integration makes perfect sense.

The previous poster strongly suggested that classic GNOME apps would refuse to run without systemd, and that seems ridiculous.

That is why I refered to "Gnome Apps" and not "Gnome applications". Classic GNOME applications will still run, but who is going to use them? The situation is going to be just like Android - your distribution came with GnomeApp-v0.8, but the version on the Gnome App Store is already up to v1.5, so your Gnome desktop "App Store" app downloads the new GnomeApp for you and launches it locally whenever you click the "GnomeApp" icon. It's going to be done that way for exactly the same reasons that Google started to put their apps on Play instead of relying on phone manufacturers to update the versions of, say Gmail and Gmaps, on the phone itself. And once that happens, there will be very little incentive to package apps for distribution on a regular packaged Linux platform - who is going to waste their time packaging obsolete versions of GnomeApp for Debian/Fedora/etc. when the desktop has a built-in default system that will recommend and autoupdate to a newer version on the App Store - a version that is better supported, because it comes direct from the authors of GnomeApp, and not some guy writing packaging scripts for random packages in his spare time?

An *application* shouldn't, in most cases, and I think it unlikely that Gnome apps will start depending on systemd

See Apps for Gnome Desktops and Video: Sandboxed applications for GNOME (August 2013). IMHO, as I explained, it is highly likely in a couple of years the vast majority of Gnome apps will be shipping on the Gnome App Store and will therefore depend on the Gnome app runtime environment in systemd. iOS and Android already proved that this model works better than the traditional Linux model, so it's not a massive surprise that the Gnome developers want to bypass the Linux distributions and ship their apps direct to users.

[prodigy_]

Linux Philosophy superseding the Unix Philosophy

First, it's more like Lennart Poettering philosophy. And second, it hasn't superseded anything because everyone sane from what used to be the Linux crowd is on BSD now.