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!
System is broken by design and totally violates the UNIX philosophy so it doesn't really matter if Poettering claims to "listen to users" (which he doesn't anyway) or not. What I see as most important moving forward is to encourage free software developers to make support for it optional and not mandatory. We get real problems when important software starts making it a requirement (like GNOME, though they like to pretend it's not but good luck trying to actually compile it). Even Tor git had systemd as a requirement for a few days last week.
9/11: Never forget it was a false-flag operation
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've been using GnuLinux for aabout two years now, I've mostly stuck around the 'buntu/Debian detivatives: Elementary OS, Ubuntu Studio, Crunchbang, Mint, primarily because I use GnuLinux fkr work and those always require me to fiddle with them the least (though Elementary OD has really been getting on my nerves after constantly having broken packages added). I understand the need for a freedom of choice because there are things some of us use our computers differently for, but for the life of me I can't understand why the fuck everyone hates SystemD to this degree. Yeah it's not always the best and causes some pain between kernel developers and SystemD developers, but DEATH THREATS OVER A GOD DAMN COMPONENT THAT YOU DON'T EVEN NOTICE IN USERSPACE... WHY.
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.
Linux has almost two orders of magnitude more code than systemd, and it changes all the time. Security vulnerabilities are far more likely to be in the monolithic kernel.
Higher Logics: where programming meets science.
How many professional SysAdmins and enterprise users are regularly tinkering with their init settings? It is usually a set it and forget it type of thing.
As I see it, this is just general IT Ranting because something is new.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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!
My issue is that systemd requires a lot of code changes for applications to work. With changes come bugs, and since systemd is as privileged a process something outside kernel space can be, it is only a matter of time before show-stopper security holes start happening and being exploited. Especially the code giving systemd full network access. Even if that code is 100% enclosed in a container, a kernel bug can bypass all that protection and allow a remote root exploit, potentially on the scale of the RTM worm, if not worse.
Has systemd even seen a code audit? This is vital stuff here in the enterprise, and both Oracle and Microsoft can guarentee that their code has been through a proper audit process. It doesn't mean it is 100% bug free, but it has been analyzed by someone looking for any potential security threats.
These are not trivial complaints either... if RH and other distro makers lose this gamble, they lose the enterprise.
First, Systemd is neither unwanted nor dangerous, until and unless you can give me a specific example.
This thread is full of evidence of both. Don't be deliberately disingenuous, nobody likes a liar.
No one is putting Systemd into stable releases yet, its still going through the vetting phase.
Yes, that's why we are arguing against it now, to try to prevent it from becoming a part of "stable" releases. Because it isn't.
Third, are you running Upstart? That was a new technology once. It also had to be vetted, but You would be laughed out if you referred to Upstart as unwanted and dangerous
Not at all. Many felt that way about it, too. But the impact was not as widespread, so neither was the interest.
The dastardly way Pottering got all of these distros to switch to Systemd was to present it on its merits!
False. Systemd was used for some downstream projects (like GNOME) because at the time, the existing interfaces for doing certain things were in flux. Now they aren't, and the systemd dependency is coming out of GNOME.
Systemd is winning, and quickly, because
...embrace and extend. HTH, HAND.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
As for TFA? Sadly Pottering is another one that MSFT and Apple really should send a fruit basket to, because its him and the devs of his ilk that keep Linux in the backroom instead of the showroom and the reason why is simple...they will NEVER EVER let Linux become fucking stable! I swear these devs and their "itch scratching" are from bizarro world, they are like "Oh noes, things am stable and most stuff am working! This is no good, users am happy and can update without breakage! Quick lets change enough internals that many devices am broken and stability worse than Win2K, that will make users miserable!".
I mean for fucks sake you had MSFT being run by STEVE "Buzzword McBingo" BALMER and you STILL can't gain share, ever wonder why? Well you had the DE devs help out MSFT by taking a steaming dump on the UI with the barely alpha quality KDE 4 release, The Gnome 3 mess, or yeah and Linus made sure to fiddle with the kernel just enough to cause serious driver issues, not to mention the Mickey Mouse Pulse audio which to this very day is usually the most crash prone part of any Linux build. Then you had the whole "What is gonna replace the shitty X Server" mess, Mozilla having to disable hardware acceleration in Linux (which frankly is still piss poor and a decade behind Windows), not to mention here it is 2015 and Linux STILL doesn't have a simple GUI for rolling back drivers or the system if an update takes a steamer on the system (something Windows has had for a decade and a half) and the driver situation is still such a mess hardware OEMs can't just put a penguin on the box and a Linux driver on a CD because hey, what works now may not work 6 months from now!
Sadly at the end of the day Linux is never gonna get any better, its just gonna get different. This is why Linux is getting its ass handed to it by "other" because at the end of the day the devs would rather crank out a new version with new bugs and new problems than fix what they have. Cranking out new software is a hell of a lot more enjoyable than bug fixing, regression testing, writing docs, hell this is the real reason why Linus won't allow Linux to have a stable driver ABI, something every. other. OS. has. because it might mean he couldn't just tweak and twiddle with the kernel like its still 1993 and Linux was only a hobbyist project!
I think you have it backwards.
The stability you're arguing for is a feature for servers, an area where Linux traditionally does well.
To get the penetration into userland you want you need the new features, you need attempts to support buggy new hardware that was written to work under Windows and has weird behaviour in other places.
As for the topic at hand Systemd helps fix the problems you're talking about. Part of the bugginess is from different systems interacting and the amount of complexity those devs have to deal with. Systemd takes a chunk of that complexity away from those systems and moves it down one level. Even if the critics are right and this is a disaster for servers it should still improve stability in userland.
I stole this Sig
So you trust that the journald binary reads the "don't save data" boolean value and doesn't just ignore it, or worse, ignores it and executes this shell script:
Or, more plausibly, does all that in a binary blob? Sure. It's open source. Sure I can check the code and compile it myself to make sure it meets my need for security. But one of the things about using these "pre-built" distros is that I'm probably using it to save time and money, which means I don't want to be bothered with doing a code check and recompile on every single init package. That's the beauty of init scripts that everyone has apparently missed in this debate. One human readable script for each daemon running, so the configuration of a daemon can be gleaned over for any questionable bits and edited in less than 10 minutes. And being scripts, they're all plain text that's automatically executable. I don't need to read over source, find an issue, edit it out, and then recompile the entire init code into a binary for that daemon to make use of it. That goes for PID 1 as well. If it's not a script that can be quickly edited and then it's ready for the next boot cycle without wasting process cycles for recompilation I don't want it on my production server.
There is a confusion of two aspects of "monolithic" here, and unfortunately Poettering did not clarify it well:
1) "Monolithic" in terms of a single repository for all code. The systemd project is monolithic in this respect, and Poettering is absolutely correct that this is the classic Unix way. All the *BSDs are maintained this way. Linux is thus, as he correctly points out, the anomoly.
2) "Monolithic" in terms of tools that depend on each other. The systemd system is not monolithic in this respect. The only two required components are journald and udev. Everything else is entirely optional and replaceable, but "recommended" in the sense that the people working on the project really think that these components, written from scratch, are of better quality and consistency than the existing components they replace. But some hysterical people hear this recommendation as "forcing it down our throats". Distro makers will decide which components to use, whether those in the systemd project or the existing ones. Obviously, the existing ones have the benefit of maturity.
Also, he doesn't point this out in this interview, but these new components are also better at reporting errors in a way that the whole init would be more robust when certain components have partial failures (and systemd knows how to deal with them). This is especially crucial for servers with complicated, layered network stacks. People say that systemd is for desktops, but really it is just as important for servers to have a robust initialization of services.