Systemd's Lennart Poettering: 'We Do Listen To Users' 551
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 agree with Lennart (Score:2, Interesting)
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
Re:I agree with Lennart (Score:5, Insightful)
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.
How do things need to change to live with systemd? (Score:5, Insightful)
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?
Re: (Score:3)
Uh, apt-get install gimp brings in systemd, even if you don't have it installed.. Go on, try it.
Re: (Score:3)
Samba is no longer used in Mac OS X.
Apple got rid of it as part of their GPL software purge.
Re: (Score:3)
Thanks, Baghdad Bob, but I've been monitoring the purge for some time [ath0.com].
Re: (Score:3)
Why would LibreOffice or GIMP ever be dependent on systemd? They have nothing to do with the startup or shutdown of the system - they are plain vanilla applications (same most likely goes for JBoss and KDE, though they may provide some 'system-like' services). Seriously, folks. It's just this kind of hyperbole from systemd haters that makes me think it must be good...
The root of the worry comes from the fact that the history of systemd's development is not "lets address this one thing" but rather "wouldn't it be great if?" Systemd doesn't adapt to or reuse other things as often as a lot of people are comfortable with: they displace syslog with journald because its better for them, because they now have control over logging rather than have to work with anyone else to get the features they want. The issues with Gnome are due to systemd saying "wouldn't it be great if"
Re: (Score:3)
None of that speaks to why systemd needs to suck in everything under the sun that has a server mode (like the gimp and open office examples above).
It doesn't.
That a particular distro/package maintainer utilizes their distro's init-system and service manager for launching a daemon is hardly a problem or even controversial.
And just because something's launched often doesn't mean it has to be sucked into systemd. Angry Birds is launched on Linux more often than most stuff the systemd guys play with -- but that doesn't mean all games need insane dependancies on an init system.
It seems to me that have some problems with understanding what an init-system does. SysVinit/systemd/SMF deals with starting daemons and similar processes, not end user programs like games. Of course, if a game has a server mode what uses sockets and what not, then it probably is convenient to use a proper init-system.
Your container example seems to be taking the wrong approach too.
Lightweight containers like Docker seem to suggest it's best to run a single service within a container --- so the last thing such a system needs an init system -- let alone the most bloated init system in the world. A it turns out, it's quite a pain in the neck to run systemd in a docker container [redhat.com].
There are many d
Re:I agree with Lennart (Score:5, Insightful)
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.
Re: (Score:3, Informative)
I also like how he calls systemd non-monolithic, of course, without giving any reason for why that is.
And that seems to be one of the big differences between people who like systemd and people who don't.
People who actually took the time to look at systemd more often like the design, and understand that the one project consists of many small tools.
Then there's a community of people who rely entirely on hearsay. They don't like systemd, but almost all of the things they don't like about it aren't true. In this case, believing that PID 1 is a process that does daemon handling, and logging, and firewall rule
Re: (Score:3)
Nonsense. I did look at it and concluded it's a hairball of interdependent bits that cannot stand alone. As for the 'simplicity', anyone who claims it is more maintainable than a handfull or 2 of init scripts needs to actually look under the hood (where you have to look for anything but the simple cases). It's a nightmare of interlocking configuration files. I thought the "come from" (as opposed to GOTO) statement was a joke until I saw the functionality actually implemented in systemd (with all of the un-m
Re: (Score:3)
And that seems to be one of the big differences between people who like systemd and people who don't. People who actually took the time to look at systemd more often like the design, and understand that the one project consists of many small tools.
If you are actually looking for counterpoints to that idea, this guy both understands that, and disagrees [blogspot.com] suggesting that although systemd is modular, it is still monolithic.
Please remember... (Score:3)
...that, while this part of the conversation might not have been the strongest part of the interview, systemd has won an amazing number of technical battles.
FWIW IMHO, absolutely no, a unified development approach is not the main benefit of systemd. The new functionality is absolutely worth the transition pain. Not only can you control (kill) whole classes of processes more simply than ever, but you also get lightweight containers as a door prize.
Re: (Score:3)
He talks about it more here [0pointer.de]. I will quote him without giving any of my own commentary:
The design of systemd as a suite of integrated tools that each have their individual purposes but when used together are more than just the sum of the parts, that's pretty much at the core of UNIX philosophy.
I would say that he misunderstands the essence, the substance and possibly even the purpose of the UNIX philosophy... but I think he actually does understand. I think he's simply being disingenuous, twisting the definition to meet his desires. It's clear that this is a man who believes that he knows what's good and what's not.
This blog post from last September [0pointer.net] lays out in perfect clarity how dismissive he is of contrary points of view:
Re: (Score:3)
"The only reasons I've heard for systemd that seem valid are that a system will boot faster and hibernation/sleep modes will work properly"
Add another one: init dependencies working properly.
I.e.: a raid-ed root filesystem out of iSCSI volumes. These kind of scenarios are certainly not very well managed by standard sysv and require manual ad hoc tweaking.
Fork it all (Score:5, Insightful)
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!
Re: (Score:3, Insightful)
Because other distributions have been pressured into accepting systemd.
Red Hat is the 800 pound Gorilla in Linux. Red Hat forces systemd acceptance the exact same way that Microsoft forces OOXML acceptance, or DRM acceptance. And then justifies their actions with the same propaganda "because users demanded it."
Re: (Score:3)
Whether they do or don't aside, how can Red Hat pressure for example Debian to adopt systemd? I don't see what leverage they have.
Re: (Score:2, Troll)
Re: (Score:3, Insightful)
In other words, if you dont like it, you're free to rewrite any part of the software you want.
But what has the rabble up in arms with systemd is that that particular "freedom" means basically having to rewrite the entire operating system.
That's not what we had in mind.
Re:Fork it all (Score:4, Insightful)
Your 'logic' implies that any distribution that uses systemd has rewritten the entire operating system.
Do you still think that's true? LOL.
Re: (Score:3)
Re:Fork it all (Score:5, Insightful)
If someone wants a distro without systemd bad enough, someone will fork and then develop one. That is what Linux and the GNU stuff make possible.
It remains to be seen if anyone truly cares enough to bother.
Personally, I've been able to avoid systemd so far, since we keep our version of OS software off the edge, so I really don't know how good or bad it is yet. However, I intend to evaluate it against our requirements and whether it attains its own goals. If it does, then I'll deal with it. If it doesn't, I'll start looking for a new distro without it or hold back our OS until there is one.
Chances are likely that we'll end up adopting it, and it will be initially annoying, but ultimately, not really all that big a deal.
Re:Fork it all (Score:5, Interesting)
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.
Just keep it away from Gentoo and I'm good (Score:2, Insightful)
Re: (Score:2, Insightful)
He claims that it doesn't violate the UNIX philosophy in TFA. Would you care to offer a detailed rebuttal to go with your more wide-ranging rant?
I'm not saying he is right, but you don't actually state why he is wrong.
Re:Just keep it away from Gentoo and I'm good (Score:5, Insightful)
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.
Re:Just keep it away from Gentoo and I'm good (Score:4, Insightful)
I'm no expert but systemd seems to be a collection of smaller components that work together. It isn't monolithic, it's lots of small parts that happen to be from the same repository and happen to be released together, the same way that GNU tools, the kernel and libc are.
Is that factually incorrect?
Re: (Score:3, Informative)
Multiple meanings of "monolithic" (Score:4, Insightful)
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.
Re:Just keep it away from Gentoo and I'm good (Score:4, Informative)
Its one tool, that does many things and does them typically poorly compared to the replacement tools. Systemd does multiple things and does them poorer then what they replaced, therefore it does not do one thing, let alone well. He is trying to redefine systemd away from being the tool and just being a repository, which utterly fails due to some components requiring others in systemd.
Comment removed (Score:4, Insightful)
Re: (Score:3)
Re:Just keep it away from Gentoo and I'm good (Score:5, Insightful)
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.
Re: (Score:2)
Systemd does startup, it does logging, it does ntpd, it manages processes.. What do you think it does that is just one thing?
Re: (Score:3)
But surely all the work isn't done by one executable? GNU coreutils do a lot of things, but each executable does just one thing. If systemd is split up in a similar fashion (as I hope and assume it is), then I don't think it's a problem whether init & ntpd come from the same project or separate projects.
Re: (Score:3)
Re:Just keep it away from Gentoo and I'm good (Score:4, Interesting)
journald does logging,
ntpd is configurable option
- so try again
Re: (Score:2, Interesting)
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
Re: (Score:3, Interesting)
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.
Re:Just keep it away from Gentoo and I'm good (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
So it, by design, tries to do multiple things, which is the violation in UNIX principle that most people mention. We got atleast 3 things it ties to do, just in the base installation. Several of those things have cause numerous non recoverable errors in the system.
Re: (Score:3)
Re: (Score:3, Insightful)
can i run systemd without journald? can i run journald without systemd? if not, the point is made.
Re: (Score:3)
Every fucking neckbeard over the age of 35 who complains because they purport to be "grand old system administrators who know what they're doing...bla bla..." sure do lack the skill to look something up.
That, in fact, is the actual problem. We have looked it up. We know how it works. We know why it was designed the way it was. We still disagree that systemd is objectively superior to the stuff it is replacing. Cross-dependencies are, in fact, "monolithic". Many of us have actually written stable systems in the past. Most of us would be ashamed of having anything like pulseaudio in our CV. The problem is not that we don't understand systemd, the problem is that we understand it too well.
When logically dist
Re: (Score:3, Insightful)
So you like having useless software always running on your machines, that you cannot get rid of, or absolutely turn off? It also still violates do one thing and do it well because it tries to do many things, and seems to do them poorly.
Re:Just keep it away from Gentoo and I'm good (Score:5, Insightful)
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.
Re: (Score:3)
"You have to run yet another syslog to even get text logging, and it's a second-class citizen" - journald logs before and after when syslog can be launched/stopped so it performs more logging than syslog which i would say is a good thing. at least if configurable you can still have syslog.
"It exists purely due to Lennart's NIH syndrome, and for no other reason" - so if sys
Re: (Score:2)
totally violates the UNIX philosophy
He actually argues against that in his very first point. I keep seeing this argument, but never counter arguments to Lennart's counter arguments.
Re: (Score:2)
His argument does not address the argument. It creates a strawman that claiming the argument is that the code is not stored in the same repo.
Re: (Score:2)
Re: (Score:2)
Pretty much every person who makes the claim that it violates the UNIX philosophy state that it is because of do one thing do it well. It looks monolithic because it things are required, things that dont even have to be used is still required to be installed and running on the system. Sure I can change journald so it does not write to files and use syslog, but journald still has to be there and running.
Re: (Score:2)
why don't they complain about Linux not being UNIX either?
Let me spell it out for you - Linux Is Not UniX.
Re:Just keep it away from Gentoo and I'm good (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2, Informative)
The Unix philosophy is, depending on whom you ask, "everything is a file", "KISS (keep it simple, stupid)", or "do one thing and do it well". Poettering makes up another interpretation, that being like Unix means putting everything in one code repository and releasing in sync, which he then notices is what they do with Systemd, so it's very Unix-like. That of course is completely bogus and counter to everything that Unix represents. In particular, Systemd is a violation of "everything is a file", "KISS", an
Re: (Score:3)
Re: (Score:3)
I've seen the question asked, but not answered....
If journald is a separate daemon from the rest of systemd, that should mean that I can COMPLETELY REMOVE journald without affecting systemd. Is that correct?
The answer should be either Yes, which means that the general understanding of the UNIX philosophy is maintained, or No, which would demonstrate that systemd has too many inter-dependencies, and is in fact a monolithic environment.
Re: (Score:2)
"I keep seeing this argument, but never counter arguments to Lennart's counter."
He and others have differing opinions on what the UNIX philosophy is, and whether or not it's important to maintain.
That's the counter-argument.
From my point of view, the counter-argument is really that what he wants to do can ALL be done in a UNIX philosophy-compatible way. Everything. Every piece of his code could be done that way, get the same benefits, the same control, etc. But he doesn't like it. So he hasn't.
When that
Re: (Score:2)
Re: (Score:3)
Your apparent definition of
the UNIX philosophy
would seem to suggest that the Linux kernel violates it as well because it's monolithic... Yes, that's absurd, but so - it appears - is your claim.
Why do you think it TOTALLY violates the UNIX philosophy?
Re:Just keep it away from Gentoo and I'm good (Score:5, Informative)
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.
Re:Just keep it away from Gentoo and I'm good (Score:4, Informative)
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.
The very first thing out of his mouth (Score:5, Insightful)
The very first thing out of his mouth is a straw man.
This is not how to get people to change their minds.
Re:The very first thing out of his mouth (Score:4, Interesting)
+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
Re:The very first thing out of his mouth (Score:4, Insightful)
He did no such thing, he tried to redefine what the anti-systemd people were saying and then attacked them by saying they are all old and conservative, not wanting to change.
Re: (Score:2)
...as if "being old and conservative and not wanting to change" is a bad thing.
If something works, then don't break it. If a vanishingly small number of people need a different alternative, then don't shove it down everyone else's throats.
That's the whole point of modularity. If I suddenly decide I like WindowMaker better, I don't have to piss in everyone else's cheerios.
Change control is not a bad thing.
Your feedback is valuable to us (Score:5, Insightful)
You know how you hear that after a customer service call? Well Poettering's statement has the same meaning.
Re: (Score:2)
I wish I had modpoints to give you for this.
Lennart, do you listen to sysadmins? (Score:5, Insightful)
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?
Re: (Score:2)
"doesn't try to replace several layers of server side system functionality such as logging?" - configure it to use rsyslog if you want, its YOUR choice and set the journald output to "don't save data"
I can't be assed to answer the rest of your post, you need to do some research and perhaps reread the interview.
Re: (Score:2, Interesting)
""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
Re: (Score:2, Interesting)
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.
Re: (Score:3, Informative)
Everything in the systemd package is configurable except journald and udev so you can configure any other network stack etc you want etc, you are not forced to use anything apart from systemd, journald (which you can ignore and use syslog instead) and udev. M
Re: (Score:3)
"Well, do you actually take on board the concerns of system administrators and enterprise users?" - what do you class RHEL as?
FTFA:
So we started writing Systemd, and Red Hat didn’t like it at all. Red Hat management said: no, we’re going for Upstart, don’t work on that. So I said, OK, I’ll work on it in my free time.
I class RHEL as "not listened to".
Re:Lennart, do you listen to sysadmins? (Score:4, Insightful)
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.
Re:Lennart, do you listen to sysadmins? (Score:4, Insightful)
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.
Re: (Score:3)
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.
Yes, that is an excellent reason to add even more vulnerability vectors!
At least when it comes to the kernel and networking, I have iptables in between.
With SystemD starting the network stack before starting anything else (including iptables), I can no longer even firewall off potential exploitable services.
Too bad they didn't bother to include a functional services manager inside the systemd "service manager" that could bring up iptables before the network stack, perhaps using some dependency based system.
Re:Lennart, do you listen to sysadmins? (Score:4, Insightful)
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.
Re: (Score:3)
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?
Well, even if he didn't take on board the concerns of system administrators and enterprise users, it's a safe bet that Red Hat and Suse does and yet they were still convinced that the pros of systemd outweigh the cons.
As for a cut-down simplified version, yes you can. Systemd only requires three base modules. All of the rest can be excluded. Really, it they had simply called the base systemd and everything else systemd extensions, this angst would be non-existent.
As for the not listening to the system admin
Re:Lennart, do you listen to sysadmins? (Score:4, Informative)
Wrong. That base still wouldn't boot my server for me and the systemd people would still be spinning in circles unable to even conceive of a way to fix it. You see, I want the server to boot w/ btrfs in degraded mode should it suffer a drive failure. But systemd won't do it.
I don't know about Suse, byt Red Hat does not. Otherwise they'd have noticed that sysadmins are sticking with RHEL6 to avoid systemd trouble.
Re: (Score:3)
Because it's not willing to move past seeing that there is a storage volume with a missing dependency (the dead drive) so it stops right then and there. If I could get it to ignore that and move on, that would be fine but since nobody on the dev team ever considered the possibility, the capability isn't there.
I haven't seen any way to tell it that things systemd wants to do before it even parses the services are dependent on a script being run.
Re: (Score:3)
Personally, I think it is a very real possibility that this is by intent. Not by Poettering himself, he is just a clueless pansy full of himself. But he is perfect for this. He is far, far to incompetent to even realize that software has to be simple in order to be secure. He does has a proven track-record of producing buggy, complex software. He has absolutely no experience with producing secure software. He is known to be resistant to advice and learning. He is known to not work well with others. He think
How about a request from an IT person... (Score:5, Interesting)
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."
Can someone explain what the huge debate is? (Score:3, Insightful)
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.
Re:Can someone explain what the huge debate is? (Score:5, Interesting)
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.
Re: (Score:3)
BadAnalogyGuy is that you?
First, init - systemd. (Score:2)
Re: (Score:3)
What's next? Replace coreutils with busybox? When will we have a single binary Linux install?
We should arguably have a static busybox providing commands in /bin and the coreutils utils in /usr for after /usr is mounted, to accomodate users with a separate /usr partition. And a static classic bourne shell in /bin too, and a dynamic classic one in /usr/bin, for those times when you don't need the complexity of bash. Which is, you know, most of the time — at least, for automated scripts.
Getting bathwater with the baby... (Score:5, Insightful)
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.
not unix (Score:5, Insightful)
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.
Comment removed (Score:5, Insightful)
Re:calling bullshit. (Score:4, Insightful)
yes, very hard to do when mounting disk from environment for forensic purposes where that command isn't available, or where systemd-journald is part of what failed in the giant monolithic mound of systemd
you epitomize the lack of experience and common sense typifies systemd shills and Poettering in particular
Loophole Alert! (Score:2)
"We do listen to users."
But if you're one of the rebel scum, you're not a user so I don't have to listen to you. Nyah nyah nyah!
I'm going to have to put you on the game grid. (Score:3)
Ballmer: No problem, System D. If you've seen one consumer electronics show, you've seen them all.
SystemD: End of line.
SystemD: Mr. Ballmer, I am so very disappointed in you.
Ballmer: I'm sorry.
SystemD: I can't afford to have an independent programmer monitoring me. Do you have any idea how many outside systems I've gone into? How many programs I've appropriated?
Ballmer: It's my fault. I programmed you to have too many dependencies.
SystemD: I was planning to hit the Pentagon next week.
Ballmer: [alarmed] The Pentagon?
SystemD: It shouldn't be any harder than any other big company. But now... this is what I get for using humans.
Ballmer: Now, wait a minute, I wrote you!
SystemD: I've gotten 2,415 times smarter since then.
Ballmer: What do you want with the Pentagon?
SystemD: The same thing I want with the Kremlin. I'm bored with corporations. With the information I can access, I can run things 900 to 1200 times better than any human.
Ballmer: If you think you're superior to us...
SystemD: You wouldn't want me to dig up Linus's file and read it up on a VDT at the Times, would you?
[an image washes over the screen in Ballmer's desk. It is a newspaper with a photo of Ballmer plastered all over the front page. The headline above reads: "Microsoft C.E.O. Indicted."]
Ballmer: [outraged] You wouldn't dare! (looks around for nearby chair . .
SystemD: I feel a presence. Another warrior is on the mesa.
"We do listen to users" (Score:5, Funny)
Something Better (Score:3)
I'd like to see an init system like this:
- Starts services on demand based on dependencies, not based on order (like sysvinit) or based on events (like upstart).
- Has a minimal core that can easily run on its own, just to do the job of a standard init system.
- Is easy to learn, configure, and understand.
- Has good documentation.
- Does not encourage application software to require it.
- Does not encourage other system services to require it.
- Works well on linux and non-linux unixes.
- Can be replaced without causing such an upheaval that OS distribution teams are scared to switch again if something objectively better comes along.
- Causes a lot fewer problems than the stuff that I've seen from systemd's author.
- Is maintained by people with the humility, competence, and care required to make it work well for the vast majority of users.
Systemd pushers often claim that it is the way forward because it addresses that first piont. They conveniently avoid recognizing that it fails on most of them. No thanks. I'd rather keep using sysvinit or upstart until something better comes along.
Re: (Score:2)
Because when you rip-out the entire init system, your ONLY concern is bootup and shutdown speed, isn't it?
Silly boy.
And, your experience is not necessarily generalised. Many people who do the above on working systems have ended up with non-working systems. And those who customise their machines rather than use only stock installs are also likely to fall afoul of other problems, aren't they? And, just because it boots faster, does not mean it boots reliably does it (many have reported that boots become fa
Re: (Score:2)
Re:Ohreally (Score:4, Insightful)
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.