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.
There needed to be change. Change occurred. It's being worked out for the better. Lennart is right about being more UNIX like. I started out my IT life with actual UNIX and UNIX derivatives like BSD/OS, SunOS, FreeBSD. The engineering model for UNIX has always been better than the freakshow that is Linux. I was a Linux user for many years, both at work and at home. The fractured state of Linux development and how things are cobbled together has left me uneasy over the years, whereas FreeBSD leaves me with a feeling of security and trust that everything was done right. I wish Lennart well, but I've gone back to UNIX-like operating systems like FreeBSD because they are engineered vs "grown" like Linux.
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."
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 ? Systemd is a collection of relatively small components, which all do pretty much one thing. They are all collected under the systemd project. Note that you do NOT have to enable or use all the components in the project. People keep shouting that systemd is monolithic, but it is not -- it is a collection of small programs, just as many other projects are (eg. Gnu Compiler Collection). Also, if somebody feels like writing a replacement component for any component in systemd collection; I don't see why that couldn't be done.
Also, broken by design ? How exactly? As long as we are just writing down our opinions, it seems to be working pretty well for my laptop!
Systemd is a tool, not just a project. Systemd as a tool tries to do many different things, and it does many if not all poorly. You may not need all of the components to work but you need several, such as binary logging that you cannot disable.
When you cant win, ad hominem.
""Well, do you actually take on board the concerns of system administrators and enterprise users?" - what do you class RHEL as? "
As a RHEL sysadmin, I can say that RHEL seems to be treating servers as a distinct 2nd class citizen to their desktop users.
Many of the system defaults expects a desktop over a server (eg: the buggy mess that was the version of NetworkManager that was released with RHEL6).
Security in depth is sacrificed in favour of new features. (Many packages were changed in RHEL6 because they supported IPv6, even though they didn't have the security features of the packages they replaced, eg rpcbind).
How big is the deployment base of RHEL7 servers at this point? RHEL6 is still fully supported, and I know many sysadmins may have experimented with RHEL7, but they're sticking to RHEL6 for production systems. The reluctance between RHEL5->RHEL6 was nowhere near this level. (The really crappy parts (ie: NetworkManager) were optional components, and there were some useful improvements)
This has been a trend at RedHat since RHEL5, and is part of the reason why the systemd is such a big issue with sysadmins, it's the straw that broke the camel's back.
Right now it seems that RH is aiming for two areas, workstations/terminals and cloud.
They seem to expect that anything on traditional servers will transition to (their) cloud alongside going from RHEL6 to RHEL7.
Systemd does startup,
journald does logging,
ntpd is configurable option
- so try again
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Isn't it funny how people only really have problems with monolithic cultures when they don't like the monolith?
Sounds like a pretty mundane truism. I think rather the problem is that monolithic projects don't match a diverse user base well. You will have a lot of discontent because the monolithic project doesn't do everything people want it to do well.
Here, I think there's some mendacity as well on the part of Red Hat. Systemd absorbed several RedHat-run open source projects that should be stand alone (D-Bus and udev, for example) and not require a dependency on systemd. That's classic Microsoft-style "embrace and extend" behavior.
+1
Basically, his arguments are :
* systemd haters have no clue about UNIX
* RedHat took a long time to notice my genius
* Gentoo users are old-farts that don't like beautifully written shiny new stuff
* Debian users are even older assholes
* You can use Gnome without systemd, but it won't work
* I listen to users, but they're all idiots
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.