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

[prodigy_]

As a system admin who has experience with almost every modern UNIX with the exceptions of Oracle Solaris, NetBSD, QNX, AIX and a few obscure variants who's names escape me at the moment, I have to say systemd is not something I enjoy using.

You're wasting your time, mate. Your complaints will be ignored no matter what they are. Especially here - Phoronix is choke full of rabid systemd fanboys.

[prodigy_]

Linux is not about choice

No wonder your link points to RedHat website. And no wonder systemd is their creation. Of course they don't want Linux to be about choice. They want to get all the money and total control over the ecosystem while the community does the bulk of the kernel and userland development for free.

[Ericg]

No wonder your link points to RedHat website. And no wonder systemd is their creation. Of course they don't want Linux to be about choice. They want to get all the money and total control over the ecosystem while the community does the bulk of the kernel and userland development for free.

...Red Hat writes 10% of the kernel commits. They aren't getting "The bulk of the kernel for free." They are #2 in per-company contributions topped ONLY by independent contributors at 13%*

*As of September 2013.

[lano1106]

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.

if NSA is somehow sponsoring the project, then it is not bug, it is a design feature. Add in pulseaudio capability to route any audio capture device to a network stream and you have an amazing spying device waiting to be exploited.

[Delgarde]

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.

Highly *unlikely*, in my opinion. There's certainly interest in doing an app-based model, a lot of talk about it, but as far as I can see, it's all at the "wouldn't this be cool?" stage... no actual work, or clear ideas of how to implement.

[asdfblah]

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.

That's how it was marketed in the first place: "fast boot times!", "see, we are faster than windows!"... and it has become a gigantic monster, fed, it seems, by the gigantic ego of its creator.

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.

I've been using linux for 8 years (I'm relatively young)... currently using Ubuntu 13.10, but I'm starting to think about changing distro, or even OS...
I'm a infosec enthusiast, that's why we think alike.

Linux is not about choice

Wow, the irony here is astounding! Have you read the arguments given by people defending systemd? "systemd also supports scripts", "you can use other init system", ... also, have you seen what RED HAT IS DOING? they are developing: a DE, an init system, a network manager, etc. Exactly the contrary of what the guy wrote... as if there were none before they started developing them. BTW, I wonder what RMS or Linus think about that post.

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.

Hah, did you read what TeamBlackFox wrote? because that's exactly the same thing I was thinking: the problem is not only the PID1 thing, but the whole monster. Also, is not only about trusting that the devs won't put keyloggers in the software. This is way deeper than that... programmers make a lot of mistakes, and anyway, you CAN leave backdoors with no one noticing them.
Who will maintain each and every little program and library used by systemd? Who will make sure there are no vulnerabilities? How do those processes communicate? Does the network service talk directly to a critical process that is running as root? MANY things can go wrong, and you would be surprised at how advanced are the techniques used to exploit software these days... have in mind that a 0day exploit in the black market for, say, flash, sells for $50k++. Imagine how much would a linux/systemd root exploit cost...

[Chousuke]

As a system admin who has experience with almost every modern UNIX with the exceptions of Oracle Solaris, NetBSD, QNX, AIX and a few obscure variants who's names escape me at the moment, I have to say systemd is not something I enjoy using. This is for countless reasons, but for consciseness I will keep it to three main points:

1. The performance gains of systemd are far outclassed by the complexity and insecurity drawbacks of it. Security has a multitude of approaches, but I like to approach it by taking a single point of failure caused by a monolithic program or process and break it up into several small programs. This reduces the attack surface from a huge monolith to a bunch of ants, more or less. The issue is, I don't like that systemd handles a good deal of unnecessary things in PID 1. This means a security exploit in those routines or roles can spread to the role of init, which means your machine or server is toast. BSD has an init system ( no, not BSD- style sysvinit ) which does the absolute bare minimum needed: starting and stopping the system from a set of run commands and handles zombie processes. Windows has the exact same issue, everything process related is handled by only a few programs, and need I say how many security exploits target their equivalent of init? Needless complexities are why OpenBSD and the other BEDs like FreeBSD would not want systemd even if it was portable.

2. It's completely unsuitable for servers and it is not even the above reason why. For a server everything is about fault tolerance, reliability, and ease of debugging. Shell scripts are easy to debug as they're basically a text file full of automated commands run by rc to start up and shut down By comparison systemd's .service files have a lot less of the code and basically contains parameters for start up and shut down, not the actual process followed by systemd. If there is a bug in a shell script I can easily run through it and review what it is doing and fix it right then and there. If you find its not a parameter issue with systemd then you have to learn C or hope that the error is in the logs, and even then you need to know what to search for. Its just a train wreck waiting to happen for a server.

3. Finally I think systemd is not the answer to the problems with process supervising in UNIX. Upstart was somewhat better, but an ideal system should leave init alone entirely, just using a standard BSD rc init is fine, and instead use supervision isolated from PID 1, and it should still use shell scripts, and have a modular design, meaning different packages for different applications.

So yes this is why I don't like systemd and why I am moving to BSD for most applications. I think if this systemd dependency BS continues then BSD will develop its own alternative. Look at LibreSSL and OpenSSH, both are forks or alternatives to inadequate solutions.

Point 1 is an empty argument unless you can show how the systemd suite of services (Unlike what people seem to think, systems is far from a monolith) is needlessly more complicated than the collection of daemons and shell script hacks needed to provide the same feature set. All sysvinit has going for it is the fact that it has been used for a long time.

As for 2, the mention of shellscripts being easy to debug is enough for me to dismiss the rest for now.

[prodigy_]

Red Hat writes 10% of the kernel commits.

Do you still think it's a good thing?

[prodigy_]

dismiss

This is the key word.

Systemd fanboys don't argue with you. They dismiss your reality and replace it with their fantasies (usually about how systemd is modular and easy to manage).

[psychoticmeow]

1. The performance gains of systemd are far outclassed by the complexity and insecurity drawbacks of it. Security has a multitude of approaches, but I like to approach it by taking a single point of failure caused by a monolithic program or process and break it up into several small programs. This reduces the attack surface from a huge monolith to a bunch of ants, more or less. The issue is, I don't like that systemd handles a good deal of unnecessary things in PID 1. This means a security exploit in those routines or roles can spread to the role of init, which means your machine or server is toast. BSD has an init system ( no, not BSD- style sysvinit ) which does the absolute bare minimum needed: starting and stopping the system from a set of run commands and handles zombie processes. Windows has the exact same issue, everything process related is handled by only a few programs, and need I say how many security exploits target their equivalent of init? Needless complexities are why OpenBSD and the other BEDs like FreeBSD would not want systemd even if it was portable.

It does do the bare minimum in PID 1, just because you think it should do less does not mean that it can do less in PID 1. If you want to demonstrate that it's flawed, point out some fucking exploits instead of "it could be", and if you find something why not report it and make sure this becomes a non-problem instead of a possible problem.

2. It's completely unsuitable for servers and it is not even the above reason why. For a server everything is about fault tolerance, reliability, and ease of debugging. Shell scripts are easy to debug as they're basically a text file full of automated commands run by rc to start up and shut down By comparison systemd's .service files have a lot less of the code and basically contains parameters for start up and shut down, not the actual process followed by systemd. If there is a bug in a shell script I can easily run through it and review what it is doing and fix it right then and there. If you find its not a parameter issue with systemd then you have to learn C or hope that the error is in the logs, and even then you need to know what to search for. Its just a train wreck waiting to happen for a server.

I don't see how maintaining a bunch of scripts is going to be any better than having one tool that's polished.

3. Finally I think systemd is not the answer to the problems with process supervising in UNIX. Upstart was somewhat better, but an ideal system should leave init alone entirely, just using a standard BSD rc init is fine, and instead use supervision isolated from PID 1, and it should still use shell scripts, and have a modular design, meaning different packages for different applications.

Isn't this the same argument as #1?

This is the key word.

Systemd fanboys don't argue with you. They dismiss your reality and replace it with their fantasies (usually about how systemd is modular and easy to manage).

Fuck off troll. How have you not been banned because of your constant shit posting?