Slashdot Mirror
Systemd's Lennart Poettering: 'We Do Listen To Users'
M-Saunders writes: Systemd is ambitious and controversial, taking over a large part of the GNU/Linux base system. But where did it come from? Even Red Hat wasn't keen on it at the start, but since then it has worked its way into almost every major distro. Linux Voice talks to Lennart Poettering, the lead developer of Systemd, about its origins, its future, its relationship with Upstart, and handling the pressures of online flamewars.
I don't care bout the unix way, I don't care about if it's monolithic or not, I don't even care about how annoyed I am by the mere mention of his name.
I care about the fact that they seem to want to force their way into everything and everyone's business and ridicule anyone who tries to maintain a choice between systemd and other systems. (i.e Gentoo)
I'm a user and a hobby developer. No, I don't maintain 2000 servers, I don't need 2 second boot time, I don't need to hotswap drives. But I do need choices. I need to be able to decide what I want to use so I can get on with my fucking day and do what I want.
"But systemd is the best, why don't you want to use it?"
But Emacs!
But firefox!
But chrome!
But but but but!
The very first thing out of his mouth is a straw man.
This is not how to get people to change their minds.
You know how you hear that after a customer service call? Well Poettering's statement has the same meaning.
Well, do you actually take on board the concerns of system administrators and enterprise users?
What a lot of people are concerned about is that this entirely new and largely untested (in the 'wild', as it were) and very very large, complex piece of software which runs at a very very privileged level in the operating system is going to become the main source of security vulnerabilities in Linux.
Can we have a cut-down, simplified version of systemd for servers and doesn't try to replace several layers of server side system functionality such as logging?
Its clear that you listen to desktop users. How about listening to the system administrators?
In the free world the media isn't government run; the government is media run.
I am personally neutral on SystemD... but as someone in IT, it is quite worrisome that there is new, untested code sitting as the core userland... code that can make network connections, and has not ever seen any reviews or audits.
SystemD could be the best piece of coding on this planet... but without documentation or assurance that this is something trustworthy, a major security hole can cause major trouble. Network connections mean remote root holes. Even without that, there is the problem of local privilege escalation, which I worry hasn't been thought of, much less engineered to deal with. If there is a major show-stopper in SystemD that allows remote root, this can kill Linux as a whole in the enterprise.
This code was also forced on us, as in "you need to have SystemD on your job, or else you don't have a job". No transition time, no time to change applications to meet this, just "here you go. Deal with it. Better get used to binary logs, because it is that or nothing."
So, as someone who uses Linux in the enterprise, SystemD is something that is resulting in a lot resentment, due to time spent with making build documents, workarounds for existing applications, procedures to make custom code work... all for relatively little benefit other than "hey, this is new and shiny, and you have to deal with it."
He says it does not break the UNIX philosophy because everything is in the same code base purposely ignoring that it does not do one thing and do it well. He was creating a strawman.
When you cant win, ad hominem.
I too have some experience with SCO UX, HP UX, OSF/1 - when something was broken there, then it was broken. You could not really go and replace a DNS server with something else. Or the vi editor. Or syslog deamon. If it wasn't there you could wait for next release and cough up the money or you were SOL. You also could not take a package for HP-UX and install it on a BSD. Or recompile. What makes linux great is that if you don't like the component X then you can google up a replacement pretty quickly. It may not be so polished and it may need some work to get it working (because the most popular choices get most exposure and thus polish), but it is possible.
But we are now 1 or 2 decades later. We don't only run simple software on our machines. I fear the day when samba, JBoss, KDE, LibreOffice, GIMP, ... start to be dependent on systemd. When that happens it may or may not work for me. If it does, fine. If it does not then fixing the problem myself will be made complex exactly by difference of complexity between a shell script or alternative package installation and a C code. The may be low, but the potential loss is high.
I can understand the perspective that a single repository for more of the userspace resembles the *development* of traditional Unix systems, the argument made is usually not about where it is developed, but reducing the principle of having small simple utilities with straightforward interactions with other componets. For example, Most traditional Unix systems have terrible implementations of a shell interpreter and things like fileutils. It is an awkward, but not too terrible a situation since you can replace that stuff with GNU equivalents trivially without horribly breaking the OS. An administrator that understands enough to write scripts can discern the nature of interaction even if that administrator isn't a full-on software developer. systemd design trends in many ways toward requiring someone needing to dig in to have more development competency than previous designs. As a developer, I understand the attraction of some of the architecture choices, but I think they lose perspective of what it's like to be an administrator on the ground. Someone who doesn't live and breath your code has a harder time wrapping their heads around how it should be working when something requires customization, replacement, or debug.
In general, systemd is all-or-nothnig about a lot of things. They figure out a way to achieve what could be considered a sensible goal, but then go about it in highly disruptive ways. The sense is they throw up their hands and say 'well, this is the only way to do it, and it's worth it' rather than rethinking how the end could be achieved in a less disruptive way.
XML is like violence. If it doesn't solve the problem, use more.
Isn't the main problem that while systemd might solve problem, it's sharply going away from the simple solution that worked to make Unix good?
Systemd isn't simple. If it's not simple, I don't think I want it on my Linux.
PA and Gnome isn't simple either. And creating more problems (albeit while solving others). I believe the same thing will be true about systemd.
It's a lot better than openrc, which is needlessly slow due to being written in bash and fails at running tasks that don't depend on each other in parallel. I've converted both my desktop and laptop and now more concerned with keeping openrc away from Gentoo.
OpenRC is written in C for the most part. Each init script is shell based though and works fine with pretty much any shell.
You can use bash if you want to, but I prefer to run dash.
As to the parallel start up - well, some users do have an issue depending on what services they have installed and configured.
I personally have no problem with it and use it all the time.
As to the speed? Well, it gets me to the desktop in the same number of seconds as systemd.
You can use syslog but you cannot get rid of journald, it has to be there running, increasing overhead. This is not, and has never been about learning something knew, that is nothing more than a fallacy created by the pro systemd movement to attack the people who dislike it.
When you cant win, ad hominem.
Exactly! I have used openRC since it was in beta and it works really really well. Parallel boot works well, the cgroups container stuff works well as well (before some processes were just not being fully killed...)
My system boots equally fast to desktop as with systemd. The major speedup for me was NOTHING todo with openRC or systemd... it was HDD -> SSD (even before sysd ~= openrc).
Only slow thing is dhcpcd but that is more router based then openrc/dhcpcd/sysd.
OpenRC is really really good.
users: Systemd is broken, undocumented and a single point of failure
Pottering: no ones forcing you to use it, use something else.
users: KDE and Gnome wont work without it and you never fixed pulseaudio, which is now default in almost every distro.
Pottering: no ones forcing you to use it, use something else
users: Why is there binary logging? I cant grep anything and dont know why the system crashed. the way user switching works is a huge security hole
pottering:no ones forcing you to use it, use something else
DEBIAN USERS:: Lets seriously reconsider the use of SystemD. its very controversial, it flies against the unix ethos, and there are some valid points raised about it security
open source community: we've forked it and made it slightly more useful.
Pottering: HOLD ON WE DO LISTEN TO USERS!!
Good people go to bed earlier.
I fear the day when samba, JBoss, KDE, LibreOffice, GIMP, ... start to be dependent on systemd.
When I was looking at systemd, one thing I wanted to see in the documentation is how to convert my own home-brew daemons to interface with it properly. Specifically, how to take SysVInit based starts and convert them to use systemd and journald. (Ditto taking UpStart scripts and convert to systemd.) The result needs to work exactly like daemons running under SysVInit. I spent three weeks with CentOS 6 trying to get my daemons to work right under UpStart, and never did get the exact functionality. I had to go back to crontabs for some of the work! So this is not an idle concern to me.
One of the gripes I have is that I want the University of Delaware version of NTP running on my edge boxes. As the group there make tweaks to NTP based on their continuing research, I don't want to wait for another group to do a re-port. That's why I would like to see a published way to interface with systemd/journald that would have minimum impact on the rest of the code base for a daemon.
I can see where daemons need to change. But do they have to be rewritten?
Lennart is right about being more UNIX like.
Wait, what?
*reads TFA*
Hahahaha, oh well:
Lennart Poettering: [...] most people who say Systemd is un-Unixish have no idea what Unix is actually like.
What’s typical for Unix, for example, is that all the tools, the C library, the kernel, are all maintained in the same repository, right? And they’re released in sync, have the same coding style, the same build infrastructure, the same release cycles – everything’s the same. So you get the entire central part of the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was!
The Linux model is the one where you have everything split up, and have different maintainers, different coding styles, different release cycles, different maintenance statuses. Much of the Linux userspace used to be pretty badly maintained, if at all. You had completely different styles, the commands worked differently – in the most superficial level, some used -h for help, and others ––help. It’s not uniform.
If we put a lot of the glue in one repository, it’s not all the way towards Unix, but it’s half way between traditional Linux and traditional Unix. We do not put libc and the kernel in the same repository, just the basic things. So that’s a misconception that I’m always bemused about, and I’m pretty sure that most people who claim that have never actually played around with Unix at all.
Wow... Just.. wow.
TL;DR his sole argument for systemd being "like traditional unix" is that they're maintaining it in one (as opposed to dozens of) source code repos.
I think this is the dumbest reasoning i've ever heard. I also like how he calls systemd non-monolithic, of course, without giving any reason for why that is.
CLI paste? paste.pr0.tips!
"Their impotent wails of despair give us sustenance."
According to wikipedia: "The Unix philosophy emphasizes building short, simple, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design.".
Okay, so how exactly does systemd violate this ?
There's more to it than that, and systemd also violates some of those principles anyway; many here have complained about the lack of code quality. But the Unix philosophy also includes a love for flat, human-readable files, and systemd's syslog shits on that. You have to run yet another syslog to even get text logging, and it's a second-class citizen — it gets the log messages after the binary logging system gets them.
Also, systemd is a thing without a reason to exist. It doesn't actually provide anything we didn't have before. It exists purely due to Lennart's NIH syndrome, and for no other reason. As others have pointed out, openrc does the things which systemd's init functionality does. That means that its original basic reason for existence is nonsensical. As many including myself have pointed out, most of it can be handled by very small shell scripts. Some rail against this, but shell scripting is also part of the Unix philosophy. That's part of the core idea of the operating system! There's nothing wrong with using scripting to make things happen.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Because journald is part of systemd, it is able to start logging earlier in the boot process and continue logging later in to the shutdown process. This is an improvement over syslogd.
look, either journald is part of systemd or it isn't. If it is, then systemd does multiple things, and should be broken up into more parts. If it isn't, then your argument is nonsense. The truth is that it is sort of both, but only in all the worst ways. journald and systemd depend on one another, so you have to run them both. So in that way, they are part of the same thing. But wait! journald is actually another process. There's no reason another syslogd couldn't have been modified to permit it to save logs in memory until the log storage filesystem was mounted, so that it could be started very early in the boot process and be able to capture logging information for everything. But instead, we got an extra-special log daemon which depends on the extra-special init daemon which provides no functionality not already provided by OpenRC.
So yes, the early boot logging (though nothing else) is an improvement over existing syslogds. However, the only reason which it was implemented in a journald-specific fashion is that Lennart was deliberately trying to break interoperability to force you to use his syslogd. If something was NIH, he won't use it and considers it inferior to his new, improperly tested code. And we have no reason to trust him; his prior claim to fame is an unfinished nightmare which again has no reason to exist. JACK was around when pulseaudio was created, and spending the effort on making JACK more user-friendly rather than creating a new daemon which shits the bed much of the time would have been better for everyone except Lennart. And that's precisely the situation we have today: we've got a new init+everyotherfuckingthing daemon which often shits all over itself, which is being hailed as the solution to some comparatively minor problems we used to have where it would have been nice to have some more logging, and where some very stupid people can't understand init scripts but want to be able to call themselves Unix admins anyway. So now init scripts are evil, and unit files are the best thing evar.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I WISH I didn't notice it in userspace.
Some people run servers that MUST be up and running. They have no time for bullshit. They have no time to pick through a bazillion little config files when it's not up and running. They need the machine to just do what they tell it to and do it now. Systemd just thumbs it's nose at that. It does only a limited number of things and only in the way that it wants to do them. If that's not what you need done, too bad.
The hate is amplified by the concerted effort to cram systemd down their throats. That's a perfectly understandable reaction IMHO.
For example, I built a test machine with btrfs and set it up to mount in degraded mode such that even if a disk fails, it should still boot up. In production, it would email me that a disk failed and I could decide between replace the disk immediately or rebalance to make sure everything is still redundant.
Systemd absolutely refuses to do it. It won't even attempt the mount command because it has decided that a drive isn't there and even though it is completely redundant systemd calls it a show stopper. Nobody can seem to tell me how to make systemd issue the mount command anyway (the systemd maioling lists have discussed that very problem wrt RAID and can't seem to solve the problem), nor can anyone give me a solution to make systemd ignore fstab entirely and run a script I wrote instead (a script that only needs one command, 'mount -a'). Apparently, you can't actually do that.
Consider, RAID and similar are high availability features. Their whole reason to be is making sure the system is available even if a drive fails. Systemd single-handedly defeats that whole purpose by refusing to even try to mount the root filesystem. That's really a poor showing, but the insight it gives me into the project is even worse. It tells me that in spite of the importance of redundancy (some enterprises spend gadzillions on it) and the fact that it has worked well under SysVinit for over a decade, not one person on the systemd team even considered it. Not one. Now that it has been brought to their attention, they can't even come up with a workaround for it (see what I said above about do what I say and do it now). All I need is an unconditional 'mount -a' and apparently it can't be done. In spite of that, the various systemd boosters refuse to admit the problem even exists. I have even had a few claim it's a feature meant to protect my data.
So there it is. It's not a matter of opinion, it's a simple boolean: "Did my system boot" and the objective answer is no. There is the followup, "how then, can I make systemd boot it" and the answer is [crickets].
Fortunately, it was just a VM I stood up for testing and not an actual server that I needed up. As a quick test, I replaced systemd with sysVinit using apt and suddenly, it just worked.
And that is why everyone is so keen on making sure nothing else becomes dependent on systemd.