Guest post by Over the past year I’ve been reading a lot of opinions on the new init technology, systemd. Some people think systemd is wonderful, the bee’s knees. Others claim that systemd is broken by design. Some see systemd as a unifying force, a way to unite the majority of the Linux distributions. Others see systemd as a growing blob that is slowly becoming an overly large portion of the operating system. One thing that has surprised me a little is just how much people care about systemd, whether their opinion of the technology is good or bad. People in favour faithfully (and sometimes falsely) make wonderful claims about what systemd is and what it can supposedly do. Opponents claim systemd will divide the Linux community and drive many technical users to other operating systems. There is a lot of hype and surprisingly few people presenting facts.
One discussion thread I read recently compared systemd to other “holy wars” that have happened in the open source community. People are always picking fights between the BSD license and the GPL, the GNOME desktop and KDE, the vi editor and Emacs. Wherever there are differences there will be people to argue over which option is better. Some people are claiming the debate over systemd is different, that it is bigger, that is will do more to fragment the Linux community. Others see systemd as just one more argument in a long, long line of arguments and (while a few opinionated people fight) most of us will continue to get along as we always have.
At first I thought these folks, the ones who saw systemd as just one more small argument in a giant pile of open source debates, were right. Really, there isn’t anything special about the systemd debate that sets it apart from other topics. We have followed similar flame wars between fans of Clang or GCC, micro-kernels and monolithic designs, GTK and Qt. So what if there is one more argument over init technologies?
Well, after some consideration, I do believe there is something about the systemd debate that sets it apart. There is something bigger about the fight over systemd that gives it additional weight. Specifically, the other arguments I mentioned, the many debates over technologies that have appeared in the past, were almost always between two choices that were widely available to most people. The large majority of Linux distributions ship both Clang and GCC, almost all of them provide both GTK and Qt libraries, most of the big name distributions ship KDE and GNOME desktops (or have community editions that do it for them). Just about every Linux distribution makes both Emacs and vi available. There are plenty of distributions that use RPM packages and lots that use Deb packages and if someone really wants to use both, there are tools to convert packages between the two formats. In the Linux community whenever there are choices there is debate. Whenever there is a choice, most distributions ship both options and let people select the utility they like best. (There are a few distributions which specialize or have an exclusive focus, but these are relatively rare.)
What sets the debate over systemd apart is distributions are, for the most part, not offering a choice. When we install CentOS or openSUSE or OpenMandriva there isn’t an option screen offering one init technology or another. Very few distributions make it (reasonably) easy to switch from one init system to another. The new option, systemd, came along and suddenly the old init technology (SysV or Upstart) was tossed aside, no longer available to users who wanted the alternatives. This is unusual. When a new text editor or window manager or compiler comes out distributions usually don’t throw the old technology away in favour of the new one. When a new toolkit becomes available we usually do not throw away all other options, we keep them all, letting people decide which utilities work best for them. With systemd most distributions are pushing the issue, insisting users adopt systemd or move to another distribution and the list of distributions offering alternatives to systemd is rapidly shrinking.
Most distributions accepted systemd fairly quietly. Fedora and Arch are experimental and usually adopt new technologies, so people in those communities accepted systemd as they would most other new, shiny software. It seems openSUSE and the Mandriva family also accepted systemd with a relatively small amount of fuss. However, when systemd was chosen as Debian’s new init system and it was accepted as a dependency for some software, there was a strong backlash. At first I found this odd. I wondered why Debian users would react so strongly against adopting systemd where others had quietly accepted the new init software. I think part of the reason Debian users are so up in arms is Debian is a very conservative project and it does not change quickly. Debian holds out for tried and true technology, for mature software, and systemd isn’t there yet. But I think the bigger issue is choice. Debian tries to be universal, to offer countless choices. You can run Debian on a huge number of architectures and there are several ports using different kernels. But now Debian’s leadership wants to adopt one (and only one) init technology.
I want to let that sink in for a moment. The Debian project lets us choose which operating system kernel we want (Linux, Hurd or kFreeBSD), but soon Debian users will have the choice of just one init technology if they want to be able to run all the software in Debian’s repositories. That strikes me as backward and I think it feels wrong to many Debian users, people who are used to a buffet of choices, too.
There is currently a debate in the Debian camp as to whether Debian should allow users to pick their own init technology (systemd or SysV) and I am very curious to see how it turns out. Debian, the distribution that traditionally offers the most freedom of choice, will soon decide whether to tie people to one init software or to allow choice. The fact that question is even open for debate feels strange to me and it goes to show just how surreal the debate around systemd has become. Debian will soon either turn its back on its tradition of freedom or it will become one of the very few Linux distributions to continue to offer opinions. If Debian’s leadership is even half awake at the helm they will realize just how many new users they can gain if they continue to offer freedom of choice where init is concerned. Choice about whether to use systemd or not is something that is quickly disappearing from the Linux community and Debian has the opportunity to be one of the few projects holding onto the philosophy of user freedom. Let us hope they choose widely.
Well written piece.
I’d just like to add that it’s kind of funny how much controversy the startup sequencing in Linux causes, considering it’s a non-topic on other OS’s.
Edited 2014-11-05 10:33 UTC
Other OSes aren’t generally flexible enough to specify a different init on the kernel command line, either.
Not really. Boot initialization is a complete mystery to nearly every Windows user (and admin). OSX caters to people who don’t *want* to know what’s under the hood.
So really, that leaves linux. And the reason that systemd has gotten as far as it has without controversy is because until now, it hasn’t hit the server admins. Now that Debian and Red Hat are moving to it, the “old school” admins are getting into the discussion.
We don’t care about boot times– a reboot happens (maybe) once a month during the maintenance window, and frequently happens unsupervised.
We typically don’t care about dependencies, because init/upstart handles it well enough (these stories about race conditions in init just don’t happen in production systems– Not once have I had a race condition in the past 20+ years. I have however, had systemd insist a path wasn’t mounted when it had already reported the path as mounted, and as a result, it wouldn’t start services).
We *do* care about troubleshooting, and logging, and while we can send a dmesg log to a central syslog server, a binary log is a bit more painful to deal with, and for me, systemd seems to go out of it’s way to hide what’s happening.
I don’t need that.
All of these wonderful things that systemd promises, don’t help me with my job. They make it more complicated, and they don’t improve the performance of the web/database/file server, or make the system any more secure.
Fortunately, my puppet infrastructure is well developed enough that for the most part, I can ignore systemd.
On my home computer (openSuSE), it’s only mildly irritating (see “mounted path not mounted” dependency issue).
That’s because it isn’t just the startup process – it’s absorbing more and more things every day.
Well, I run testing on a non-prod server, and it switched to systemd after one of the updates a while ago. While it wasn’t that painful, it was still very surprising. I didn’t follow the mailing lists for a while, and I couldn’t believe my eyes for a second there. While it seems to work OK and didn’t cause much pain up to now, I’m in the against-systemd camp and wasn’t happy about it. However, sysvinit is still in the repos, so at least one can’t force you to switch – yet. What will happen by the time testing becomes stable… nobody knows.
This is nitpicking to the next level but if this is an “editorial” then it should not be signed. I know it is difficult to have an unsigned post but “editorial” means some opinion that the editor (as an anonymous entity) supports…
Edited 2014-11-05 10:45 UTC
My way of showing how much I liked systemd was to simply move to an OS that doesn’t use it.
What gets my goat is the entwinement of desktops/programs with systemd and how that will affect open source software. It’s this diregard of the wider picture that is causing the majority of the discord as far as I can tell.
Personally, I don’t mind. If it means better-quality software for Linux then by all means. At the moment it seems to me like many things are being held back when people insist the same stuff must run the same on *BSD, *nix and whatnot.
Systemd is about unifying Linux with a Core OS that is rigorously tested and well integrated, as opposed to the hodge-podge of random bash scripts that people used to have to write for sysv.
There’s really no need for choice in init systems; upstart is soon to be unmaintained, openRC is not capable, sys V is a joke.
Systemd is the only modern option, and by leveraging every strength Linux offers, and ignoring BSD compatibility, it pushes forwards the Linux platform.
The individuals arguing against systemd seem to not understand that *none of the upstream developers* want to have to keep reinventing wheels and having overhead in maintenance when they can get universal, superior options from systemd, such as logind.
In short, the future of Linux is systemd. If you don’t like that, move to an actual unix.
I’m so happy that we have you to make decisions for every one else. Imagine if we had to study the issue, analyze the facts and make a decision on the merits or lack thereof ourselves! What a lot of effort and wasted time! Fortunately, we have you to do that for us so everyone else can get on with their lives and forget about the issue. It’s truly kind and noble of you to sacrifice so much so that the rest of us can don’t have to.
It’s a non-issue, I’m just pointing out the way the wind’s blowing.
There are *zero* benefits to using sysv init on a pure Linux install-base, and Linux has been held back by limiting itself to the lowest common denominator for far too long.
Now we have proper, seamless cgroup usage in init! Using containers is simpler and nicer than ever, all of the core os binaries are rigorously standardised, documented and unit-tested, in cooperation with each other. The level of innovation at the userland level has never been this high.
It’s no surprise application and distro developers want to make use of all of the great features and opportunities systemd provides. It’s not up to them to work on legacy init-system support instead of stomping bugs and adding features that directly relate to the program, as opposed to being about the management of programs by the OS.
If you want sysv support for applications, write some scripts.
If you want sysv support in a distro, make one.
Most projects have already decided; that’s crap that they’re sick of having to do, and systemd provides a superior future.
There’s no downside to you, either: don’t like binary logging? Set journald to use files.
Want to write bash scripts instead of reliable, predictable service files? Go ahead, sysvinit scripts are fully supported.
Systemd just means more stability and a more common core os for all distros. If we’re lucky, a lot of the distros will die off, sparing us that ridiculous duplication of effort.
Edited 2014-11-05 12:16 UTC
Well the problem is for software that depends on SysV init. Their software will just stop working suddently and they will have to invest a lot of time making work on Debian if they even bother. I understand the argument in favor of Systemd but saying there is no downside is just wrong.
Edited 2014-11-05 12:58 UTC
You are aware that sysv scripts can be run by systemd, right?
That being said, given that Slackware is the only major distro that still defaults to sysv, if a project isn’t popular enough to get a unit file written for it, it’s probably not popular enough to matter.
It’s good that systemd can run sysv scripts, though: it means this isn’t a problem, so if you can’t get a unit file written (they’re really dead easy compared to sysv scripts), you can still run your software on Debian, Ubuntu, Fedora, CentOS, Arch, SUSE, Mandriva, etc..
I’m aware you can run some SysV init scripts in systemd but the devil is in the details. Many scripts won’t work. Those who depend on env variables like $HOME for instance will break. Moreover it will break a lot of other stuff that depend on /etc/init.d, runlevels and such things of SysV init. It may seem trivial but actually this kind of small details can bring hell. Each script will have to be tested against systemd. Some developers just won’t bother and their software will suddently stop working.
Just for the record I’m not defending sysv, I’m just pointing out there are drawbacks. The benefit may be worth it, I don’t have an opinion about that.
Edited 2014-11-05 16:45 UTC
It’s not like their software will just stop working, though… The developers who can’t be bothered to update their scripts for systemd if they have hard dependencies on a particular script environment will either reduce the number of platforms they support, or update it.
If they’re not going to run it at all, it’s unsupported anyway, so any users that want to keep using it would have to take up maintainership.
You’re right that “no drawbacks” was a bit hyperbolic, but if they’re not going to update their software to run on their current platform, chances are they weren’t going to fix bugs in it either.
Actually, Slackware has never used SysV init. They’ve always used BSD init which, though also script based, is a different thing.
…. you mean choice, right?
You know Linux started out as a “ridiculous duplication of effort”, yes?
There’s choice, then there’s 1000+ distros.
Most of them are just someone’s custom theme on top of Ubuntu/Debian, too. Why should that be a distro, instead of just being a theme?
Why use something that is *almost* $BIG_DISTRO_Y instead of $BIG_DISTRO_Y itself?
If your distro doesn’t really have anything to set it apart from all of the others, should it really exist, or is it just unnecessary time spent without any real reward or purpose?
Linux on servers only really uses the big distros, same for the destkop.
Unless you’re actually doing something unique like nixOS, there is no benefit to not just keeping around an ansible/puppet config to build a custom image of the big distro your custom one would have been made from.
Linux was a hobby project, which is not duplication of effort – it’s someone doing something for the purposes of learning.
If minix or HURD were suitable for Linus at the time, he would have gone with them by the way.
“If the GNU kernel had been ready last spring, I’d not have bothered to even start my project: the fact is that it wasn’t and still isn’t. Linux wins heavily on points of being available now.”
http://lwn.net/Articles/395150/
You utterly and completely missed the whole point of the article. *CHOICE*. We are losing it at a rate that is like a Borg ship in a movie! People like *you*, who believe we don’t need choice and who think you’re opinion about what’s best for the rest of us peons are what’s wrong with this planet as you are doing nothing more than aping the way governments grow and eventually become something *NOT* very good for the people it governs.
Actually, it’s up to the people who write the software and maintain the distros.
*They don’t owe you anything*
If they don’t think it’s worthwhile supporting your favourite tool or methodology, it’s up to you to support it.
Compatibility with multiple init systems isn’t just a magical free and easy thing that falls from the sky.
Maintenance takes real work from real people.
He is not making the decision… I find it funny that people are always banging on about how great linux is, because if you don’t like something, you can view the code and rewrite it yourself… poettering has… and everyone is complaining that he shouldn’t have… well that’s what happens if you keep banging on about people being able to write their own code.
If you and the other grey beards want a unix like OS, use one. I use linux, not unix, couldn’t care about recursive accronyms (and whether or not they are funny), I couldn’t care about the unix way of doing things. If you do, you know the drill: write your own code, submit a patch, if all else fails fork it.
To be honest, as an end user – I really couldn’t give a fuck what is used, whether it is teh DE, the display manager or anything else… I can understand why some people hate poettering (see: https://www.youtube.com/watch?v=ZTdUmlGxVo0) but all he is done is do what linux/unix advocates have been advocating for donkey’s years.
While I’m sure you can find a few quotes of individuals saying Poettering should never have written systemd, that isn’t the stance of most people who oppose it. They don’t object to the existence of systemd. They object to it being a dependency on a substantial number of other programs. That’s what this editorial was about. It becomes effectively impossible to use the distro without it. And that most certain is someone else making the decision for everyone.
That’s the point though: If you don’t like software depending on systemd, it’s up to you to fork the software, because clearly the people who actually write it aren’t interested in sysvinit compatibility.
That’s why we have eudev, uselessd, and consolekit.
They all have serious downsides, but at least the devs are putting their money where their mouths are, and writing alternatives.
tl;dr: Software becomes dependent on systemd. Choices:
a) Fork sotftware
b) Use systemd
c) Switch to another distro which doesn’t use systemd
Yes, everyone understands that that is, in fact, largely the choice users face. You either use systemd, you switch to another of the vanishingly small distributions which don’t require systemd, or you take on the onerous task of building a complete fork of your chosen distribution. While the last option is technically possible, it’s far beyond the capabilities of most users and an enormous task even for those with the technical chops to pull it off. It’s an option but not a reasonable option for most users. The question isn’t what choice users face. The question is whether it’s fair or reasonable for the distributions to put their users in the position of having to make that choice.
And of course the distro leadership CAN put their users in that position. It’s certainly not illegal, and it’s not immoral in any larger sense of the word. But because a leadership body CAN do something doesn’t mean that they SHOULD, nor does it mean that the users of that distro can’t express their opinions about the action taken by the leadership. Most distros are communities. They value the opinions of their users. They EXIST to provide a valuable and useful operating system for their users. When the body of users of a distro shrinks beyond a certain point, the distro usually dies. It might thrash about for a bit or remain a peripheral player for an extended time, but it generally stagnates and disappears. Leadership certainly can’t please everyone, nor should they try. But they can and generally do consider the opinions of their users, and try to work out accommodations and compromises where feasible. It’s in their best interest to maintain a large and diverse body of users. If a significant chunk of users break away and stop supporting Debian, everyone loses.
Your original post essentially said “STFU and go away – your opinion and preferences don’t matter because they differ from mine.” You’re entitled to that opinion, of course, but I’m also entitled to mine. You can’t make me STFU and you can’t make me go away, no matter how much arrogance you exude.
How long can you guarantee that option C will be there?
With the mission creep of systemd, more and more user facing projects are likely to develop some kind of systemd dependency for some “reason” or other.
End result is that if you want to use program X, you now have to have systemd sub-system Y, and that again depends on systemd running as pid1 (init).
At no time in the past have user facing programs cared what kind of init the system is running.
The people who do the actual work, as in making/providing the software, are indeed the ones who get to make the decisions for those who aren’t.
There’s nothing new here, if upstream chooses to take their software in a different directon than you want you can certainly ask them not to, but in the end the choice is theirs.
Your choice is to either step up and maintain a fork/patches which corresponds to your needs, or vote with your feet.
Actually in this case it’s not even that. Most software in Linux doesn’t depend on SystemD; only GNOME does.
Distros are switching because they want to support GNOME and the easiest path to do so is to switch the whole system over regardless of whether the user uses GNOME or not.
So, in the end, the decision of the GNOME folks to take a hard dependency on SystemD is screwing everyone else.
KDE on Wayland is going to have a dependency on the logind interface too, btw.
I think it’s a “tip of the iceberg” scenario.
For now, it’s Gnome and KDE. What’s next?
Of course, you’ll always be able to run your favourite TWM on X on BSD, so if you’re the kind of person that gnashes their teeth about losing init scripts, you’d probably be more comfortable there.
Is it KDE or Wayland that makes that requirement?
My guess is Wayland as KDE will operate on Windows too without SystemD; and it runs just fine with Xorg without SystemD.
And again, Wayland is optional – you can still use Xorg.
http://blog.martin-graesslin.com/blog/2014/10/libinput-integration-…
Straight from the horse’s mouth.
Essentially, it’s about using libinput for input handling.
By making use of logind, they can improve security without needing to write and maintain yet another KDE-specific library.
Thanks for the quote proving my point 😉
Essentially, libinput is needed to properly support Wayland; libinput requires a logind interface. Thereby Wayland requires logind.
However, KDE’s (and likely Wayland’s too from the description) integration is such that they don’t care if it is logind or something else that provides the same D-Bus interface with respect to KDE on Wayland.
KDE on other systems (Xorg, Windows, BSDs, etc) is not affected.
In otherwords, they did it right.
Need to remind nobody stepped up to maintain ConsoleKit despite GNOME warning for years. GNOME uses logind and KDE recently adopted it. Those are a few example where most non systemd people only talk but do nothing.
Edited 2014-11-06 22:26 UTC
See http://www.osnews.com/thread?599215
KDE did not take the hard dependency that GNOME has; and even then, it’s only for KDE/Wayland.
Here is why in the case of GNOME:
http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-…
When someone from non-systemd branch is willing to support API like consolekit (look how OpenBSD and FreeBSD did) maintain it for a while, GNOME will have no problem adding it. GNOME has no obligation keeping dead and non-maintained software in their repository.
That is not really true, but you are close.
The problem is not that SysV or OpenRC are not working, they are working fine and will continue to be maintained sufficiently. The problem is that everything else isn’t maintained with them. There are probably a thousand open source projects that would need to have special handling of alternative init systems, and those scripts are unlikely to be maintained, and is also why Debian is not making an easy choice for maintaining a choice. They don’t want to maintain all those scripts and patches to make projects that only support systemd out of the box support other init systems as well.
Don’t get me wrong, I’m fully aware that this is the case
By sysv and OpenRC are inadequate, I meant either through lacking features such as are provided by logind and journald, or by lacking core systemd features which mean proper process management.
All of these developers aren’t swapping for no reason, even if that reason is “it’s easier to maintain unit files, and journalctl is really nice.”
In other words, developers are just as lazy as the rest of us…
I wouldn’t necessarily call it lazy.
I’d be more inclined to call writing bash scripts to look after starting and stopping software unnecessary, project-unrelated maintenance.
Why do something that is harder, more prone to errors, and less reliable?
That is one of those things i keep seeing pop up, that the project dev is the person to maintain the boot scripts.
Why?
The program being launched is a binary with a set of command line switches, no? There is no secret sauce that the scripts need to obfuscate are there?
You still need *someone* to write the scripts.
If not the project lead, then the packagers for each distro.
Given that the project author is the most familiar with the software, it’s been common to see such scripts written by them, so as to prevent each distro’s packager for that software from having to do as much investigation.
The point is, though, that since all you really want is to pass a binary name with a few arguments, having a dedicated script written to control each package is madness, and leads to potential breakage.
It might be “…rigorously tested”, however systemd has bugs, and the attitude towards those bugs from the developers (from Poettering down) is cavalier. https://bugzilla.redhat.com/show_bug.cgi?id=1023737 Is one example of a fundamental task that does not work as it should. There are others. That bug is a year old.
There’s a very good argument for diversity in init systems, notwithstanding the fact that administrators know how they work, can troubleshoot them, and customise them without knowing a black-box language like C. What, specifically, are OpenRC and Sys V not capable of? Choice is a cornerstone of the Linux ecosystem.
Upstream developer laziness is not the fault of users; and reinvention of the wheel is an ironic argument to use in the systemd discussion, being as that is one of the prime reasons people do not like it. There is little that systemd does that is not already a feature of current systems. They were not first to use cgroups, parallelisation, or socket activation. All of these are available already.
It is monolithic (Even Poettering’s argument against this is essentially semantic), tightly coupled, enforces dependencies for no good reason than to grow itself, and will be extraordinarily difficult to replace if it continues to supercede GNU core utilities.
You should find this worrying if you’re a supporter of Linux; it is walking down a road one cannot easily come back from.
Oh, that’s lovely. Wonder if Red Hat 7 has the same problem. I’ll have to test my (currently only) production RH7 box.
Appreciate the info.
All software has bugs. This one has a workaround posted on that very page.
Also, you can use mount units instead of fstab, you know?
http://islinuxaboutchoice.com/
Linux is not about choice.
Systemd is very well documented, with all of the defaults explained at length in the man pages.
They’re much more predictable than having to read through a bunch of shell code that will differ from distro to distro and version to version.
The primary advantages of systemd, apart from the increase in predictability, reliability and ubiquity, is that of its project, as opposed to systemd the daemon.
The matrix of programs that fall under the project umbrella are all constantly unit tested against each other, so as to give a solid base platform that can be relied upon, as opposed to each distro needing to attach different binaries for different purposes.
How is it lazy for developers to not want to have to support code that is not actually related to the point of their project?
Why should they have to write init scripts for their software, when all they want is for it to be reliably started and stopped?
Why should they have to maintain their own helper libraries for functionality that exists in most modern linuxes out of the box?
Time spent on those helper libraries could be better spent improving their actual projects.
Systemd may not have been the first to have those features, but it was the first to make them simple to take advantage of from everywhere.
The kernel is monolithic; what’s your point?
The APIs of all of their binaries are well documented. Want to use a different getty? Go ahead. You’ll just have to take care of making sure it works with the other binaries in the userland… which is what you already had to do anyway.
Projects are brought under the umbrella so as to remove uncertainty in OS design and state. If the whole of the core OS is in one tree, like with the BSDs, you can more easily ensure it all plays nicely together, and releases are in a state where everything works with everything else.
The only argument that isn’t one to tradition (“It’s not following the Unix philosophy”… GNU’s Not Unix) that I’ve heard is that the current maintainers may lead the project in a direction that is bad for others.
In that case, it’s all non-CLA’d and GLP’d. Fork the lot from the last good state.
It patently is, and a snarky website doesn’t add anything to the discussion.
I note you do not address any concerns relying bug fixes, or administration transparency. The latter is a big, big deal in server land. Workarounds are a symptom of good design. Also, this particular slice of slightly disingenuous pie by proponents has been going since 2010:
I’m sure you know full well that is not at all straightforward (by design), and has been the source of some pretty big headaches for shim projects. The API most definitely is not stable, by LP’s own words.
If portability isn’t important to you (or anyone else), that’s your prerogative. I’ve no problem with that, or proprietary software and practices. There’s room for everything. However, UNIX philosophy is not an ‘argument to tradition’, it is a set of tried and tested design ideas that have been proven to work, and have contributed strongly to the considerable progress of both Linux and the *BSDs.
It is a choice, but that is not what it is about. It is about providing a freely available unix kernel. Or at least, that is what it was originally about.
Trying to make Linux about choice is what is killing or has killed it as a viable desktop OS.
The only thing that has kept Linux useful is that many companies are making those choices for people and imposing a vision (by paying developers to make it meet their needs), and rest assured, none of those needs is to have a million startup or init systems.
I did, actually.
Transparency if provided by every single unit file using the same default configuration.
Once you know the defaults and behaviour for one, you know them all, unlike having to read a script for every single service.
As for bugfixes… C is orders of magnitude easier to understand than bash, so those are made easier. Also, you get the advantage of helping everyone, instead of just you/your distro.
GNU’s Not UNIX.
Linux does not, and should not, limit itself to Unix design methodologies and techniques, instead of making its own way.
It’s all well and good to strap together binaries and utilities to give greater functionality for end users and admins; piping shell commands into each other is ridiculously powerful.
However, when the whole system is designed like that, you end up with slower development due to increased complexity of interactions.
It’s no secret that plan 9 hasn’t taken off, and that’s more unixy than unix.
I’d say it’s for the same reason Linux won out over HURD; many independent moving parts is far more flexible, but far more difficult, and maintaining those parts, increasing functionality and performance without breaking them, just gets harder as time goes on.
Systemd has all kinds of issue with mounts, NFS mounts in particular.
Apparently someone thought it would be clever to delegate the task of mounting to systemd rather than leave it in the hands of mount.
end result is that systemd keeps barfing over slightly odd fstab files that mount has no problems with.
Or do things like yank down the network before dismounting NFS mounts, and then dead hang on the dismount step of shutdown because NFS just wont let go.
This kind of crap is why unix have “do one thing and do it well” binaries tied together with shell scripts.
But here comes systemd and replace a binary that has worked for decades, because “reasons”.
The idea behind integrating that into the systemd project (as far as I can tell), is that a fully external utility couldn’t be properly integrated into the boot sequence, whereas with mount units, you can specify exactly which dependencies exist for each mount, so you don’t get non-core mounts sitting there trying to probe for a non-attached network interface, for example.
By specifying your own mount units, as opposed to automatic generation through fstab, you can have a great deal more say over how and when your mount occurs.
NFS mounts are a problem in itself, and does not need systemd to be one.
It isn’t the only viable option, there is still Apple’s launchd. Modern, still under development, compatible licence (Apache).
But as systemd is more or less linux’s answer to launchd I guess there isn’t much to gain by using launchd instead.
Edited 2014-11-05 17:16 UTC
didn’t knew that launchd was Apache licensed. If it’s freely available, how exactly does launchd stacks against systemd?
Ah yes– “We know better than you do, so shaddup”.
Perfect example of why I left Gnome years ago, and can’t stand the default desktop setup in Gnome.
https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU
“It’s not entirely fair to charge all of this to Systemd’s account, but I think one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers — go away, you’re clueless, we know better than you, and besides, we have commit privs and you don’t, so go away.”
RHEL seems to think differently and they are gambling their 1+ billion $ a year business on that.
Plus, I’ve got large number of *production* servers (some are near-5’9 high-availability servers) w/ systemd and its stability is exemplary. (Personal experience, I know, but the numbers don’t add up).
As for this being a different argument, I agree, but for a different reason:
People tend to forget that open source is not democracy but rather a meritocracy (“those who do, get to make the decisions”), and as long as the anti-systemd groups are limited to spamming systemd-related articles in news sites and forums, their voice will simply be ignored by the major distributions.
Only when these groups start doing something constructive, such as developing an alternative base system *, this argument will become as relevant as the KDE vs. GNOME, vim vs. Emacs and Linux vs. BSD arguments.
For now, its pure white noise.
– Gilboa
* One should keep in mind that systemd *project* includes a large number of modular processes – one of them being the systemd init process.
Edited 2014-11-05 12:07 UTC
I think you’ve nailed the issue perfectly without realizing it. FOSS software being a meritocracy doesn’t hold true anymore especially in the context of systemd. That’s because systemd is fundamentally a RedHat technology. It’s free, the source’s available, etc… but the majority of the development is done by paid RedHat employees and decisions on its direction are taken by RedHat employees. There’s no way a pure volunteer-based effort can take on that both for lack of resources and for inability to make an impact (suppose that a new, better init system came out, do you think RedHat would take it in its distro after having sunk that much money and time into systemd development and education for their userbase?).
So I find unsurprising that part of Debian’s userbase is unhappy with the choice. They weren’t really given the choice – as in, it lived alongside other init systems for a while and was overwhelmingly preferred by users over alternatives.
It’s a RedHat technology that’s been introduced in RedHat, or RedHat-sponsored distributions because RedHat management decided that it was the best option for them and now it’s becoming Debian’s default by virtue of other pieces of software having significant dependencies on it. No merit was involved though systemd does have its merits.
Meritocracy is meritocracy no matter if it was done by a individual, a loose group or a corporation.
If it happens to be RedHat that funds the development of software pieces that Debian though to be important enough to compel then to choose SystemD, the merit is all upon RedHat, their management and the quality of their developers.
The mere fact that systemd is also/mostly developed by payed developers is irrelevant. This is just as true when it comes to kernel, Qt and other large OSS projects.
Plus,
1+ billion dollars in *paying* RHEL and Oracle Linux customers seem to point at the exact opposite (Let alone millions of CentOS and Scientific Linux users).
Again, if systemd was a “management decision” made by RHEL, I would imagine that the millions of RHEL systems would be flocking to a non-systemd distribution.
Thus far, I only see movement in opposite direction.
Again, you fail to explain what stops the million of oppressed anti-systemd developers and users from forking the latest non-systemd distribution and going on, on their separate way?
Can it be that most of the OSS developers are actually in-favor of a Linux/systemd based system?
– Gilboa
Edited 2014-11-05 21:52 UTC
It’s relevant in the sense that the original approach taken when developing FOSS software is essentially gone. Since Debian is a volunteer based effort, they’re sensible to this change. As you point out that holds true for the kernel and various other technologies (browsers, GUI toolkits, etc…).
Why? I never said it was the wrong decision, it’s most likely the right one as I had mentioned below. Systemd *has* its merits (a phrase you seem to have missed from my post) but it’s not a volunteer based effort and it’s becoming the default in Debian because no other projects has the economical resources to take on a commercial entity such as RedHat. That doesn’t compare to something like the traditional discussion about which software is better in the FOSS community. Simply put, there’s no alternative and that’s why it’s being chosen.
Huh? I never mentioned oppressed non-systemd distributions. Personally I’m using Fedora which has been using systemd for a while. Did my mention of systemd being a paid-for commercial effort just like MacOS X or Windows somehow hurt your feelings for it? You seem to be overreacting.
Leave Debian and other volunteer based distributions one of two options: Go with the flow, or face stagnation.
I agree that it doesn’t.
One side is willing to put a lot of resources on developing a new modern base system infrastructure while the other side, *unlike* VI/emacs, KDE/GNOME or BSD/Linux that actually set out to drive their own unique view of such a solution, are currently limited to to very vocal, border-line abusive forum activists that define themselves by what they hate, as opposed to what they want to achieve.
Place the blame of RedHat for actually trying to be constructive is plain wrong.
My comment was not directed at you personally, and you know it.
You personal attach was childish and uncalled for.
– Gilboa
RedHat is not being constructive for the sake of it, it’s being productive for its own sake. They’ve got a product to sell and they need to improve it for their paying users. Users of other distributions (including RedHat-based free ones) are an afterthought. That’s not something “bad”; it’s how a commercial company is supposed to act if it’s to make any profits and stay in business.
Let me quote you again:
That comment was an attack, it was straightly directed at me (unless “you” means something else) and asked me to explain something I had not even said. That’s what I call childish.
So?
The OSS was founded by people and companies that had “an itch to scratch”.
At least theoretically, the anti-systemd group has a massive itch to scratch, but thus far, they rather trade personal insults (hint) as opposed to actually doing anything constructive about it.
I never claimed or hinted that you are a part of said “oppressed anti-systemd developers and users”, its for *you* to decide if you belong to said group, and the mere fact that you turned an honest question (one which you continuously refuse to answer) into a *perceived* personal insult and a reason to start trading personal insults, puts you square in the middle of this said group.
Edited 2014-11-09 08:49 UTC
You’re compeltely off way. You said that I failed to to explain what stops the million of oppressed anti-systemd developers and users from forking the latest non-systemd distribution. Except that I’ve never mentioned “oppressed anti-systemd developers” nor suggested that they should fork it. You just pulled that ridiculous term out of thin air.
Why should I answer it? I never mentioned them nor brought up the idea of forking systemd.
Posting this from Fedora 20. I’ve been using Fedora as my main distribution since Fedora 8 thus I’ve been using systemd for a *long* while, even when it had some pretty rough edges.
You sir are a fanboy, and one so blinded by your fanboism that you didn’t even bother to read my posts otherwise you’d know this already since I’ve already mentioned I had been using a systemd-based distro. Heck, in my first post I even explicitly said that systemd has its merits but that went way over your head.
Ignoring a long list of rude personal insults… Blah Blah Blah.
Let me start by saying that I don’t really care if you’re using Fedora 20, 19, RHEL or work for RedHat. As shocking as it may seem to you, this question and non-of-the-posts above aren’t about *you personally*.
In a last ditch effort to treat you like a gown up that can actually answer simple questions with simple answers without degrading this discussion into a flame fest, let me ask again.
And for the love of God, try to be civil, shell we?
Lets assume that I’m a stupid fanboy and that your superior intellect far exceeds my meager ability to understand your super-human posts, forcing you to use big words and talk s*l*o*w*l*y.
Let me reiterate my question: OSS was founded by people with an itch to scratch. Assuming that there are indeed *many* (here, dropped the millions) people who really, really, really dislike system as it goes against everything that is true and sacred (dropped the oppressed), how come we’ve yet to see any real effort to create a real, modern base system infrastructure that rivals systemd?
And before you point a finger at RedHat, keep in mind that Microsoft/IBM together with the large Unix players ruled the world unequivocally when Linus Torvald released a playground OS in an obscure ML.
Remember: Systemd Itch, no one (besides RedHat) wants to scratch even though forums are full of itchy people. Why?
– Gilboa
Oh… Needless to say, I won’t even bother to read your post if you continue use childish insults. (And fanboy? Really? This is the best you can do? Ran out of “your mamma” insults?)
Edited 2014-11-09 22:32 UTC
Systemd was started as personal project by a Red Hat employee and Novell/Suse employee who will be later hired by Red Hat in their own spare time to address the shortcoming of Upstart mainly due to Canonical hostile Clause Licensing Agreement (Very similar to OpenOffice under SUN and later Oracle).
https://plus.google.com/+KaySievers/posts/C3chC26khpq
During its early stage, an Arch contributor and other industry from GENEVI, Tizen, Jolla will add their contributions and the project moved to freedesktop.org host. Systemd was never hosted on Red Hat website.
Add the adoption from embedded industry from Angstrom to GENEVI via Tizen from both Samsung and Intel. Over 500 contributions show systemd is hardly Red Hat project.
Looking at the systemd mailing list, some of features and conventions came straight from Debian contributors themselves like /etc/os-release and /etc/hostname. Systemd contributors active participations to one Debian convention were a clear example.
Sysvint is a walking dead never designed to fully take advantage of Linux. OpenRC still relies on bash scripts, Upstart was fundamentally flawed by design as pointed out by its original creator and its CLA did not help the cause. kFreeBSD and Hurd are virtually experiment considering their usage so portability is very irrelevant.
It is a sum of over 500 contributons including Arch, Debian, Ubuntu, Open Suse, Jolla, Gentoo, Tizen and more.
Edited 2014-11-06 07:51 UTC
Let’s be intellectually honest, shall we? Grep’ing systemd’s git log shows >80% of contributions coming from RedHat employees. There might be more as I didn’t bother to track down all RedHat employees not using their professional e-mail addresses but it shows a project that is predominantly directed and developed by RedHat. You’d be naive to think that its future direction wasn’t approved by RedHat’s management. Contributions from the entities you mentioned above are a few tens of commits over a total of >17k. That’s not even counting the size of those contributions by line changes which are likely to even more overwhelmingly favor RedHat.
I can count tens of commits from Debian contributors and in many cases they’re the bare minimum to adapt a very RedHat-centric design to work on a different distribution.
You can repeat that as many time as you want. It doesn’t change the fact that the project is largely a RedHat one. The data readily available in the repository shows a completely different picture than your quote.
To drive another couple of points: systemd has practically zero penetration in the embedded market. The predominant startup system for Linux-derived embedded uses is Android’s ‘init’ which can be arguably considered even more primitive than simpler alternatives such as openrc. That’s just to show how much the embedded market cares about systemd.
Second note: my primary distribution has been Fedora since version 8 IIRC which means I’ve been using systemd on my primary machine for as long as I can remember. It boots fast, it provides relatively easy tools to manage what little changes need to be done in a desktop’s startup procedure and it only gave me a couple issues. I’m fine with it. I don’t like certain choices they made but they’re not hard to change via configuration & helpers. I’m fine with it. Does this make it any less RedHat-centric? No, and that’s why the user-base of a volunteer-based effort such as a Debian’s is resisting this kind of change.
That’s the issue isn’t it ? Systemd could be a could piece of software, but the fact that it can be traced to the only distro which care about putting some money in that kind of modern problem solution is enough to discredit that very same solution.
I am not a systemd fan by the way, but I am becoming more and more pissed of by the blatant bad faith I am reading from the Against camp : Red Hat seems to be the root of all evil, and I refuse this for its sheer stupidity.
No, that’s not the issue, unless you’re taking into account the most rabid posters which are not really interested in discussing the problem but only taking a pro/against stand. The issue is that RedHat and its paid developers will care mostly – if not only – for RedHat products. So support for a distribution like Debian will be an afterthought. This is not an unsurmountable issue as Debian developers can join the systemd development process and try to pull things their way. But the behavior of some of systemd’s most prominent contributors (“it’s my way or the highway” & “I don’t care about your specific use-case, I only care about my stuff”) has turned down a lot of potential contributors, and is not really encouraging for the future.
Note that some extremely partisan systemd supporters are trying to make things look different, claiming against all evidence that systemd’s is not a RedHat-centric effort. This is also not helping because the issue is not that the project is largely a RedHat one per-se, but rather that it’s not been very welcoming of use-cases and requests coming from a more diverse set of distributions and users.
Again that’s only if you listen to the most rabid posters on both sides. Personally I usually ignore their comments and try to focus on the actual issues at hand.
Funny how so much of systemd’s recent feature creep has to do with what is to be a business focus for RH going forward: cloud computing.
Various other “features” seems to also fit in the DoD’s “trusted computing” concept.
Edited 2014-11-06 18:26 UTC
How is this different from how it is with the kernel, xorg or other big projects. Almost every kernel dev with influence works for “The Linux foundation”, Red hat, google or another big company.
The problem with this kind of argument on software is when two things start to happen at same time:
1) it get ubiquitous so most of people that need them have to conform;
2) the developers behind it keep pushing more tight integration/interdependency.
It make things very hard to replace as the cost to build alternatives become increasingly step. We have many examples on file formats, applications, and protocols to attest it, and as far as can see this is happening on systemd right now.
Even if I think systemd is, for now, a superior solution and even like the way it handle the system init steps, I really would prefer they drop the tight coupling. It would help if they were a bit more inclined to accept small compromises to their “vision”. For example, I always hated the binary log from the start and thought that user-space firmware loading was a bad idea.
One thing not discussed is that Debian is very popular for servers, what is not the case for openSUSE, Arch, Fedora and other distributions. I guess, that reason alone explain why the echo chamber noise is way more powerful on it and why it is more a concern to the members in its trenches.
I don’t doubt that maintaining a non-systemd based Linux will be increasingly impossible.
The reason for that are quite obvious:
* The old sysv + million of loosely coupled binaries was severely broken. (Hence the large number of projects that sought to replace it).
* At least to me, it seems that most of the developer community is happy to switch to systemd, leaving less capable people available to maintain a non-systemd fork on one hand, while creating a ever increasing gap on the other.
That goes back to the meritocracy: Unless the anti-systemd group manage to pull sufficient number of capable developers to lead the effort, its just a matter of time until all the major distributions fall in line – including Debian.
BTW, keep in mind that if you are old enough, things may change. XFree86 ruled the world for years, and vanished within a space of a year (replaced by X.org) once they got too arrogant.
– Gilboa
I think it’s neither a democracy nor a meritocracy. It’s software. The people who do are dependent on other people who do. When they move X11 to Wayland for instance they break the work of many people. It’s not easy to take the right decision as a community of packagers like Debian but that’s what they do. Debian is the aggregation of all the work of all the other upstream projects into a coherent final product at the hand of the user. They are the ones who judge and select the work of others and Debian is actually structured as a democracy.
But Debian is not alone, and with all due respect to the “Democratic” nature of Debian someone will have to do the heavy lifting of keeping a non-systemd based Linux in an echo-system that slowly getting tightly coupled with the systemd infrastructure / base system. Without the man power to do it, Debian will either stop in its tracks or join the flow.
Are *you* willing to do the heavy lifting?
– Gilboa
Except that RH is paying the head devs of systemd. This means that they can directly dictate where the project is going without airing such “discussions” on mailing lists or bug trackers.
RH is pushing heavily into cloud computing, and systemd have had a massive influx of cloud related “features” recently.
In the end systemd will go where RH things the money is. And right now it seems to be cloud and US military contracts (hello logind and “seats”).
Last time I checked, most of the kernel and Qt developers were also getting a paycheck for it.
Again, nothing stops you from forking the last systemd-free version of your favorite distribution, a creating a cross-distribution Linux/InitV SIG.
As I asked in another comment. Are *you* will to do the heavy lifting?
– Gilboa
Edited 2014-11-05 21:53 UTC
I wanted to add something:
My company develops a complex network security system that has a large number components (some user space, others kernel space, with multiple processes, users and capabilities).
Needless to say, all of this must be started in-order and there are a lot of inter-dependencies.
Back in the pre-systemd days we had a huge arrays of bash scripts that used ugly waits, sleeps and cat /proc/pids to get the system running. (I was the idiot who wrote many of them).
The scripts never worked – mostly due to external problems. (E.g. You can never reliably check if /etc/init.d/network actually managed to initialize the [many] network devices correctly.)
We actually reached the point that we actually had helper C-based init services, to help us circumvent system initialization issues. (Upstart was no better).
But then came systemd, and we simply throw out all the ugly, never-really-working scripts and replaced them with (simple!) unit files.
Suddenly, I don’t have to worry about ulimit, chroot, init.d/network not being set or initialized correctly, suddenly I don’t need to manually manage the order in which each component is started, stopped and restarted.
I simply write a 10-20 line unit file, maybe add a small bash script to set some environment switch that systemd doesn’t support and I’m done. Heck, we reached the point that we actually have a helper bash script that automatically write most of the systemd unit file based on a template file and a configuration file.
It works in the first time. It works in the 1000’th time and I no longer need to worry about it.
As the saying goes, you’ll have to prey systemd out of my cold dead hands.
– Gilboa
Edited 2014-11-05 22:18 UTC
And here is the thing. In the past, deciding what kind of init to use was up to the admin in charge.
But with systemd and the ongoing feature creep and near insistence that if you want to play you need to use APIs (the alternatives are rickety: http://ewontfix.com/15/) result in a removal of choice.
I am right now running a distro with a somewhat esoteric boot system. But i can still get things like consolekit up and running. but if i want to upgrade to a more recent Gnome i need to bring in logind and therefore systemd.
Now if i could set systemd to run in a minimal fashion on top of what i already have, i would not be sitting here commenting. But all of a sudden i have to redo my setup from the init up because i want to upgrade the point release of Gnome?!
That’s bullshit. Admin are using default init. If they weren’t, the systemd outcry would not have been, ever.
I understand your pain, I really do.
But you must understand the Linux was *way* overdue to have a coherent int *and* base system infrastructure. As an embedded and kernel developer I can say, that as much as I dislike Windows and the Win32/WinNT APIs, Windows’ service and service environment management was *light* years ahead of Linux’.
Once such a coherent base system infrastructure started getting built, other projects (GNOME, KDE, etc) were bound to support as it solved a lot of pain on *their* end.
More-ever, the so called feature creep is neither “feature” nor “creep”. The idea behind systemd is to create a *complete* base system infrastructure, either by assimilating other projects (udev) or by creating modern alternative. I’d venture and guess that its just a mater of time until NetworkManager find itself under the systemd umbrella.
Now, people that dislike systemd for both valid or invalid reasons are left with one of 3 options:
1. Be constructive: Develop an alternative base system infrastructure that supply the same systemd APIs without the so-called bloat and while keeping to the original Unix way (Hard, but possible).
2. Completely fork the current user-space part of Linux, and maintain a pristine systemd-free OS from ~2013, forward forking new features from the systemd world (Doable in the short run, may become impossible in the long run).
3. Expect (vocally) that somehow their appeals will be heard and the train will reverse back to the station (Won’t happen, sorry).
In my view Debian, by itself, may have sufficient man power to select option “2” for a year or two, but not more. Option “1” is feasible, but it’ll require cross distribution cooperation on a massive scale (Just like, err, systemd).
3 is a non-starter, and I would imagine most people already understand it.
– Gilboa
Edited 2014-11-07 08:01 UTC
And given the level of activity in the Linux community, it is going to continue to evolve, kicking and screaming, and there’s nothing that the “conservatives” can do about it.
Systemd solves problems that distro maintainers feel are problems. If it didn’t, they wouldn’t adopt it. Moreover, although there have been other prior attempts (e.g. upstart), no other solution in this space has gotten this much traction. Systemd appears to be the best alternative to prior solutions and is the best way forward that we have. That doesn’t mean it’s perfect. Just like how most politicians suck, systemd sucks in a lot of ways, but given the momentum, we have little choice but to accept it and beat it into submission so that it does that job well.
We do have a real need for an init system that (1) saves memory and time by starting only the services we need on-demand and (2) makes sure the services are restarted when they crash.
Also, like how ODF combined existing technologies, so does systemd, including things like DBUS and devfs/udev.
I’m forced to use ASCII.
Systemd v.s. other “init” (and they don’t just init and go away) is like the kernel itself, so fundamental you can’t just change that part.
I haven’t been looking in enough depth, but my only worries is if the code is a too complex to be secure or reliable blob, and if there is a community and not just one vendor.
A good article that I think sums it up: http://www.zdnet.com/linus-torvalds-and-others-on-linuxs-systemd-70…
Linux is a monolithic, not microkernel, but it is well engineered and clear. Systemd is monolithic but needs work to be more than a desktop underlay
Systemd is not monolithic. People who haven’t actually bothered to learn about how it works and what role it fills need to go do that before they continuing throwing fuel onto the fire.
It is not monolithic but it has tight coupling, what many see as almost the same.
I like the system services initialization part but would prefer if the strong interdependency was dropped.
Anyway, it is the best init system we have right now and reality always trumps ideals.
Well keep an eye on uselessd anyway.
The protocol between the various “parts” may well be a black box unless you feel like parsing the complete source of systemd. They may be seen as different processes by the kernel, but they are joined at the hip by requirement of having systemd as pid1 and intermediary.
It’s not vi vs emacs or KDE vs GNOME. You can’t have both easily. Vi and emacs have very few dependencies. You can just have both installed and they both work. Systemd and SysV have deep impacts on the whole Operating System. You can not have both installed and expect both to work. It has more impact than the kernel itself. I don’t think it’s reasonable to ask Debian to maintain both. They would have to actually maintain 2 separate OS. It would be less effort to just split the distro in 2 distros and have a team for Debian-SysV. It would be lika asking Debian to use both rpm and deb packages. While probably possible with a lot of hacking it’s better to have 2 distros for that.
So I think it’s a binary choice: SysV XOR Systemd. I understand both sides and it’s not easy. Systemd is probably better than SysV but all software has to be migrated and maintained, which may end up with forks and waste of developer time or some projects just giving up support either for linux or for other Unixes.
It’s really a hard question.
Actually, you can have both systemd and SysV installed at the same time and have them both work. Obviously they don’t _run_ at the same time, but you can set them up so you can switch back and forth. Since systemd is mostly compatible with SysV scripts, it is possible to maintain SysV init and just switch to running sysetmd when you want to. Chances are the only people who want to do that are testers and systemd developers, but let’s not pretend there is somethign special about init that prevents you from installnig multiple implmentations.
Each package has to know if it has to start with systemd, sysv init or both and install the scripts at the right place with symlinks and has to be tested 4 times. That’s some work but thinking about it you are right it’s not as hard as I first thought. Still a lot more work than packaging vi and emacs and making sure they work.
To be fair, I think you could only use SysV init scripts and then SysV or systemd would both work since systemd is backwards compatible; then you wouldn’t have as much duplicate but you’d lose every advantage systemd is bringing, so not really a solution
In a few years, systemd will either be refined to the point where everyone is content with it, or it will simply be replaced by the next init system.
Edited 2014-11-05 13:46 UTC
systemd is controversial for many, if not most people, because it uses dbus rather than pipes for communicating between the various separate parts. When old school Unix guys think about how to send information from one app to another they think pipe. There is a better, safer way to do that now for system components, called dbus. If you understand that, you understand that systemd is more of an evolution of Unix philosophies, than a replacement.
Also, correction from the editorial, systemd is only default init on linux kernel systems. sysvinit is still default on bsd and hurd.
I, personally, don’t think the lack of choice is the main issue. There are plenty of other parts of a linux system that have no alternative, but no one has complained about it.
systemd is mature and production ready for most systems.
s/offer opinions/offer options/
OK, it may adds nothing to the discussion here but, somehow, gives an audio pulse of how much the subject is mobilizing and polarizing the Linux community.
https://github.com/Xylemon/xlennart
Edited 2014-11-05 15:09 UTC
As an Archlinux user, I’m accustomed to systemd’s presence and haven’t had any real qualms or problems with it. I believe it can help unify distributions by providing a new standard way of initalizing and managing services, among other things.
However, I think systemd’s has greater implications in the BSD community. As FOSS software devs begin toying with the idea of adopting systemd technologies upstream, such as logind, it becomes more difficult for other Unix-like OSes, such as FreeBSD and OpenBSD, which don’t support systemd, to support software that relies on it. This essentially can turn *nix software into Linux-only software and leave others OSes out to dry.
This is the problem with systemd.
Replacing the init system, who cares. Solaris SMF, Mac Launchd, BSD init, SysV Init, SystemD, at the “init level”, they’re basically silent and unintrusive. While the software impacts system management tasks, they don’t impact actual software.
SystemD, however, does impact software. Now you have software that depends on SystemD, and that dependency is not simply an extra library you need to install along with the software, it’s something more fundamental, more active. Because SystemD is not an idle participant.
If SystemD didn’t have such a large collateral impact, I think the uproar would be non-existent. Because then SystemD would be an actual choice, like vi vs Emacs. Instead, it has a much large external footprint.
Because it bundles logind and udev.
And soon enough it will take over your network management as well (hello networkd etc).
Setting aside the fact that networkd is not intended to replace NetworkManager, would that really be such a bad thing?
Pretty much all of the network management solutions out there suck hard, with the possible exception of Arch Linux’s netctl.
If systemd can ship a network management tool that gets rid of NetworkManager, more power to them. The NetworkManager command-line interface is atrocious, and given that Tom Gundersen (Arch developer) has been behind most of networkd, we may see something as excellent as Arch’s netctl come out of this.
This article is properly written but it doesn’t present sources to some of its claims.
This part is pure flaming of systemd. I would like to see an example of those false claims.
The things people praise systemd for are socket activation and other service management mechanisms, and the use of various modern Linux features.
What part of that is false claims?
I would like to add to this that some of the tools that ship with systemd like systemd-networkd and plenty of patches for systemd-journald have been contributed by Arch Linux.
Other distributions don’t seem very keen on contributing code.
I also need to mention that systemd needs a few months of feature freeze while bugs are ironed out. 217 was just released and the archlinux package already has a few backported bugfixing patches from trunk.
Edited 2014-11-05 16:18 UTC
One false claim is that systemd is faster than SysV at booting the system. Almost every discussion I’ve ever read concerning systemd has proponents that claim systemd boots faster. In some edge cases it might, but in all my tests systemd has been slower or the same speed at SysV.
http://distrowatch.com/weekly.php?issue=20141027#qa
Another is that systemd will unify Linux distributions, making skills cross-platform. This is false for two reasons. 1. Distributions have many other compatibility issues that have nothing to do with systemd. 2. There will always be outlying distros (Slackware, Pisi, Gentoo) that do not conform. And the point is not really relevant to anyone who uses Linux + other operating systems. For example, many people switch between FreeBSD and Linux and will not gain unity.
Another is that when systemd orders a service to stop it always stops. This is also false, I’ve seen several cases of systemd ordering processes to stop and the function fails.
Finally, some claim systemd is 100% compatible with SysV. This is not true and I know of a few daemons that have had to be patched to wrk with systemd and its quirks.
Having four machines running Arch, and all of them booting and rebooting faster with systemd than with sysv, I offer different anecdotal evidence
There will always be ‘outlying distros’ for every aspect out there, from which libc they use up to what desktop wallpaper they ship as default.
Unification around systemd is already happening, Red Hat, Suse, Arch, Ubuntu, Debian, Mageia, CoreOS, NixOS are already defaulting to systemd or in progress of doing so, these include the largest Linux distros who will all be defaulting to the same core functionality (init + system tools), that is certainly a huge unification across the Linux distro landscape which previously was more or less Linux kernel+glibc as far as ‘standard’ went.
Huh ? This was no more true before systemd either, I fail to see what your point is here.
As for the editorial, the whole Debian ‘freedom of choice’ is not something that is magically conjured out of some ‘community spirit’, whatever choice there is ends up being provided by Debian maintainers, and when they loose interest that choice goes away.
KFreeBSD, part of what you are using to paint this picture of a ‘buffet of choices’ is on the verge of being dropped, not because of systemd, but due to lack of developer interest (as in keeping it up and running).
The ‘tying of people’ to one init system only happens when developers no longer want to work on supporting alternatives (just as the case with kFreeBSD, Hurd etc), and the debate here is not of people not being able to continue using sysv, they can, the discussion is instead about software which relies on functionality provided as part of an init system.
Currently Gnome is dependent on systemd because it uses logind, a user login daemon which replaces the no longer maintained consolekit.
Now it doesn’t have to be logind, it can be any other daemon offering the same functionality, and systemd-shim is such a project but it is apparently not very actively developed and lacking in compability with systemd.
Which again brings us back to the actual point, any choice you have in FOSS is there because someone steps up and provides it, not because there is some distro consensus of ‘offering choice’.
When developers no longer want to work on things, the ‘choice’ they offer is no longer available.
Now the group within Debian which proposed this GR want to force developers wanting to use systemd functionality to either provide alternatives for said functionality or not use said systemd functionality, else the package won’t be allowed in Debian.
The result of this is a burden on maintainers that they are very unlikely to carry, and if the GR supporters are expecting that this grandstanding will affect upstream then they are deluded indeed, upstream chose systemd because it offers the functionality they want/need while ridding them of lots of maintenance, they are happy with systemd.
Not that it really matters since I’m dead certain this GR will be voted down.
I assume you meant ‘options’ rather than ‘opinions’ ?
Either way, options are again only there when someone actively provides them, and it’s not as if Debian supports alternatives for glibc, udev, gcc, if you want to run alternatives you are on your own, just like with alternatives to systemd.
That is what the ‘freedom’ in FOSS actually boils down to, not some branding of ‘choice’ which you decided to place on Debian in order to support your rather one-sided narrative.
This editorial is missing the objection that i, and others, have with systemd.
It has long since moved beyond being “just” a init.
It incorporates udev (yes, you can compile “just” udev. But it still involves downloading the whole systemd tarball and using special configure switches), networking, dhcp, dns, a cron alternative, and i have long since given up on tracking the mission creep.
But the real bugbear is that interacting with systemd involves APIs, thus you can have things like the login portion of Gnome depending on logind (a systemd sub-system) that again depends on having systemd running as init.
That is a tightness of connection that no Linux project in the past has had.
The flexibility of Linux have come from the various parts being loosely connected, allowing parts to be added or removed as the admin/user found fitting.
This meant that what you were running as a UI didn’t care how you got your system up or running, just that useful daemons were running or not.
Systemd breaks with this, and breaks quite sharply.
Exactly; and the decision by GNOME to use it is being forced on everyone else.
I use KDE; I don’t use anything from GNOME; some Gtk based apps (namely Pidgin) but that’s it. My system does not require SystemD, yet because it is easier for the distro (e.g Ubuntu) to support it than rip it out, they use it.
It is so interwoven by GNOME that it is extremely hard for distros to support GNOME and non-GNOME desktops and give users a choice of whether or not to use SystemD.
And THAT is where the problem comes in with the design of SystemD – people that do not want to use it are being forced to simply because of GNOME.
And that’s not right.
1) It’s systemd, not SystemD.
2) KDE with Wayland is going to require the functionality provided by logind, so don’t go too heavy on the gnome bashing.
Again, It’s probably a Wayland requirement not a KDE requirement.
As so the GNOME “bashing” I’ve simply been noting that this came about because GNOME took a hard dependency on SystemD in a way that made it very difficult for distributions to remove it when they want to support other stuff too.
That’s hardly “bashing”; just relating facts. “bashing” is going beyond facts to opinions as well being derogatory – neither of which have happened here.
And best i can tell, Poettering was strongly lobbying for Gnome to take on that dependency in their mailing lists. F-ing politics…
they don’t fix their attitudes, let alone the code.
http://news.softpedia.com/news/Linus-Torvalds-Block-All-Code-from-S…
I’ve been running OpenBSD using cwm (for when I need graphical stuff) and just a serial console or ssh to the shell otherwise. My operating systems don’t restart more than once or twice a year if I can help it.
Obviously systemd won’t ever become a part of OpenBSD (or any other BSD), so largely I’ve been ignoring the yakyak around the program.
On the whole, the systemd software appears complex and full of magic, moreover it doesn’t seem to be in keeping with the traditional philosophy of keeping stuff small, simple and independent of each other.
I took a moment a minute ago to download the latest systemd tarball and looked at the source. Some things jumped out at me:
– 37.5 MB in uncompressed stuff
– 12.8 MB of c source (This is huge!?)
– Dependencies: dbus, udev, cap, attr, selinux, pam, libaudit, others?
– Dependencies of dependencies: Rabbit hole, but there are some here, like X11.
– Presumably these are all statically linked into the binary so that emergency booting is possible (like if I cannot mount /usr or /var or something else important).
All that to turn some software on and off.
My opinion is that this is way too complex for an init system; for me to use something like this I’d want to see less than, say 6 (arbitrary!) c source files each with less than 2k lines of code and probably a dependency to libevent and imsg for a small privsep state machine. Then you’d at least know what you’re getting into.
Even then, the small collection of sh (not bash) scripts that starts my handful of daemons is just immensely preferable for me.
It’s often the BSD people that get it.
Edited 2014-11-05 20:04 UTC
That’s the problem, the “traditional philosophy” stuff is being dropped on Linux.
Linux is here, trying to gain desktop market share for the last 20 years, and never went above 1%. Some people on distribution and desktop environment development are growing increasingly tired and frustrated by this. They want to try new, bold, strategies.
It’s is clear that it is near impossible to build a desktop operating system that “just works” using traditional UNIX development philosophy. On desktop, strong coupling of kernel, underlying components and desktop environment is crucial.
Having a desktop made of disjointed pieces patched together by scripts and lots of manual configuration can by fun for a geek, but for the average user and corporate users, this is simple not a option.
I remember 15 years ago when my desktop was a heavily customized Window Maker setup, a hand compiled kernel tailored exactly for my PC, a customized init sequence, a really bugged ALSA manually configured for my 4.0 audio setup, and that i had to record DVDs using command line applications. Why i used such thing? Because back then i found this to be funny and desktop environments (KDE and GNOME) also was far more primitive, so a desktop environment did not had such importance.
But that’s it, back that time, you could not even eject a cd from your drive without a command line. Your system could not even detect that you plugged a headphone on your laptop. Could not properly regulate power levels. Could not setup screen brightness. Getting a webcam to work was a epic journey to the guts of your system. In some distros, even getting two applications to use the sound board at same time could require manual intervention (do you remember artsD? esd? dmix? the oss vs alsa battle? The bugged alsa oss emulation layer?). Something as trivial as replacing a harddrive could become a unbelievable mess.
Now the Linux kernel and all userland are far more evolved. We are in a point that we have the man power, the technical foundations and the corporate backing to make a desktop that “just works”.
So, the philosophical question here is: we want desktop Linux to be finally popular or we want it to be a eternal niche project?
systemd is more of a meta package that contains an init system as well as some optional services that are developed by the same people in the same repository. Kind of like KDE is a a windows manager, desktop environment and assorted utilities and applications. You can’t take a look at just the size of all of KDE and make a value gross judgment on it. If you approach it with an open mind, at least you’ll be able to appreciate the motivation behind it.
The various parts communicate via dbus and it uses cgroups to keep track of everything. The operating philosophy is to improve system management on linux. So it has lots of optional tools for doing that including things like hostnamed, logind, journald, etc.
Take a look, its pretty cool!
http://www.freedesktop.org/wiki/Software/systemd/
I have looked; the code idioms are preposterous. I would fire any of my employees who wrote software like that.
Well, judging by your “some things jumped out to me” section in your first post, I don’t think you’ve looked at it enough to understood very much about systemd.
Unchecked string slinging for starters; check how many times snprintf is used and how many times its return result is checked.
I see 138 instances. Can any of those overflow? maybe, but we cannot tell nobody is looking.
And what is with all the calls to fput{s,c}….
And missing memory checks on the error paths, I’ve seen at least 3 of these in 5 minutes.
And missing memory check on memory allocation from a string length
Probable memory leak (allocating memory and no call to free)
Hands up if you know what is wrong with this line:
src/shared/util.h:694: return malloc(a * b);
There is another glaring issues from my point of view:
I don’t see a privsep mechanism, so all this stuff is running as root, which just tells me that the devs are:
– crazy
– inexperienced
– stupid
Keep promulgating it, you clearly know what you’re talking about.
Sheesh, just go take 1 friggen minute and run this:
grep -Rn malloc *
grep -Rn realloc *
grep -Rn alloca *
I can see tons of misused calls to those.
……
You know how the openbsd site says 2 remote issues in a heck of a long time, guess what one of those was.
Edited 2014-11-06 17:34 UTC
“some optional services”
For how long?
If you think systemd is complex and large (and mind you, system is Linux base system / infrastructure and *not* mealy an init system), you should take a look at the Linux kernel.
– Gilboa
Yes, the linux kernel is very complex. I’ve dilly dallied with it in the past.
Edited 2014-11-05 23:26 UTC
I was looking at the article in my phone and this is the advertising that showed up. Bahahahahahhahaha.
http://m.imgur.com/owD4mHV
And considering sys.tar.gz from OpenBSD’s FTP has only 20 MB, you can see how insane they got.
As almost all software gets bloated, I’m always looking for well-designed, less bloated software. It’s not uncommon today to see software with orders of magnitude of difference in size with basically the same functionality.
Again, insane.
Under Red Hat 7, the combination of systemd and Fedora’s “improved file layout” (ie, move /bin into /usr/bin) means if you have a system that has /usr on a separate partition– It cannot be upgraded to Red Hat 7, and may or may not work (systemd relies on /usr being available when it starts).
Minor issue in the grand scheme of things, but it means my group can’t upgrade any of our servers in-place to RHEL7.
Does make you wonder about the size of the initramfs, though.
There are ways around the /usr thing, but it depends on using a initramfs that do the initial boot and mount of /usr.
I think their plan is to use this for cloud VMs, so that a shared /usr can sit on a SAN and be mounted by any number of minimal VMs as they are spun up by the load balancer.
Frankly all that is coming out of systemd and Gnome these days seems oriented at two things.
1. cloud computing.
2. multi-seat government/military installations.
For either of these the feature set of systemd is pure gravy. but for most outside of that it is straight overkill.
It really boils down to what is the best choice for people building (Linux) distributions and what gives them the least amount of work in supporting it.
Apparently using systemd results in less work for maintainers and that is why they like it and use it. As a user you can hate(?) it, but that is not relevant. You are not the one putting in the work to keep the (sometimes) fragile shell scripts running and debug them.
Even developers like it! It makes their work easier, they can delegate a lot of work to the system. And it magically works on all Linux distributions!
As usual, the people yelling the most are the ones not doing anything to make the world a better place.
Less work because if they want to ship Gnome as a desktop option they need to support logind, and that means either systemd or systemd-shim.
And the latter is chasing the former much like Wine is chasing Windows.
The author of this article forgot that before systemd, we never had a choice anyway. And that was never a problem. Nobody complained.
Now that it is possible to have a choice in init systems people are complaining, but most distros are right in making only one init system available because it deeply affects everything. You might as well make two separate distros. And who wants to spend the effort when one is clearly better than the other?
Edited 2014-11-05 21:06 UTC
>> “The author of this article forgot that before systemd, we never had a choice anyway. And that was never a problem. Nobody complained.”
Why would they complain, they had a working init system? People aren’t complaining because they want addition options, they are complaining about their previous option being taken away. If you have vanilla ice cream and you like vanilla, of course you won’t complain. If someone else says you can have vanilla and chocolate, again there is no reason to complain. But if someone comes along and takes away your vanilla option and says you must always eat chocolate now, of course people will get upset.
>> “most distros are right in making only one init system available because it deeply affects everything”
There in lies the problem. A good init system should not affect everything. Init software is supposed to bring up the system, reap zombie processes and (in some cases) manage services. That’s it. Nothing about that should affect any other software packages if init is implemented correctly.
In fact, I would like to point out it is currently trivial to swap between SysV and systemd on a Debian installation. It takes two short command lines and the system works exactly the same with either one. Obviously init does not affect large portions of the operating system or that would not be possible.
And after systemd, they will still have a working init system, so why complain?
Server admins may have to learn a few new things (which may be a reason for their resistance), but users will never see or care, unless it is in reduced startup and shutdown time.
It is more like a company changing the ingredients in vanilla. As long as it tastes the same….
Untrue.
We had several init choices (I was a initng user for quite a long time). Swapping between them was an adventure, but certainly doable. To this day there are tens of init replacements to choose from. In Debian there were talks about a “metainit” system.
Err, no.
https://en.wikipedia.org/wiki/Init#Replacements_for_init
Many of those came before systemd, and did what systemd does at its core (async daemon startup).
Some of them can either be init or run on top of init.
Btw. What we call init does not have to be sysv init.
Slackware use BSD init, and Gobolinux use bootscripts that it on top of the syv init binary.
The likely reason for sysv to live on was that it already booted fast enough for most, and it was easy enough to grok and debug.
Edited 2014-11-06 18:53 UTC
systemd: solutions looking for problems.
If I add a line to /etc/inittab like
hell1:2345:respawn:/usr/local/bin/helloworld.sh
Why cant a systemd or upstart version of ‘/sbin/init q’…parse up the /etc/inittab…
when it sees something new like hell1, automatically create a /etc/init/hell1.conf for me ?
Then everyone using unix for the last 40 years can go back to normalcy…
Okay. Usually with things like this, I keep an open mind and try to adopt new tech in experimental distro’s because it’s going to make it’s way to the big end which I do have to support at work. I’ve fidgeting with linux since the 0.9 announcement on usenet so it’s not my first bbq.
Systemd in my opinion, has too many moving parts. When a system breaks, I like to be able to pull up single user mode, check the logs. Stroke my chin, pivot root and go fix it. Move on with the important tasks I’m both paid and interested in.
That’s my most important basic requirement with init and logging systems. I’ve had over the last 5 or so months, three systemd systems that’ve bricked during updates requiring a re-install. There has been others that’ve bricked, and been fixable. Of the three bad brickings that necessitated mode +clobber && re-install, okay, it’s experimental I can partially agree that it’s acceptable. What I hated was:
a) binary log format
b) zero-byte log files.
c) no other indicator of “what broke” and being told in a loop which useless commands to issue to interrogate it.
It’s not simple by design. Too many moving parts. One part goes Fut ™ .. and your blind, in the dark and generally otherwise porked.
This has cost me massive amounts of time. Think ‘experimental cluster’ with heavy emphasis on testing. You’ll know where I’m coming from.
I’ve *REALLY* wanted to like systemd and to learn new things, but frankly with the amount of time it’s caused me and more importantly how brittle it is, sorry, your off the Christmas card list. F#$% it.
You can set the method of log storage journald is using from binary to normal text logs (that is, logs that are forwarded to syslog daemon, so the ‘old’ method of log storage – /var/log/messages, etc). This makes more than 66% of your argument list a non-issue
.
Indeed! Hence the “zero byte size” comment. So did that.
Seriously, when it’s not sufficiently robust that something can brick this that easily then I’ve not a high opinion of it.
So.. sensical.
Edited 2014-11-06 05:03 UTC
Then journald breaks and syslogd get nothing.
The truth is Redhat and Debian have always been the two big players in the Linux world. (even with the popularity of archlinux, Ubuntu, mint, Gentoo, etc…)
Debian has two issues with this:
1) systemd is pure Linuxism and Debian supports different kernels.
2) They feel using something redhat came up with is making them twitch.
So yes Systemd’s advantages are over inflated. Does systemd break some unix principles? definitely yes lol. Does systemd set a bad precedence? yes.
Should be care? NO!
I also need to mention that I have a giant amount of respect for Debian and I wish this petty drama would stop.
Right. We have less choice regarding init systems now with udev and logind being part of systemd. Again, should be care? No. Does it change the way we use our computers? Again, no.
I mean I’m not going miss lunch or lose sleep because I don’t have much choice in what init system I have to use on my computer lol.
Why waste time arguing about this?
http://xkcd.com/386/
Edited 2014-11-06 13:53 UTC
1) systemd is an umbrella of multiple software components, this differs from “systemd the init system”, most software depend on some components like “logind the login manager”, if anybody doesn’t want to use systemd-logind he just needs to write something that implements its functionality (the dbus apis for login manager), software depends on logind because nobody wrote a counterpart, only systemd-logind implements these apis, systemd sub-modules offers functionality that nobody else is offering.
2) “Debian holds out for tried and true technology, for mature software, and systemd isn’t there yet”
RHEL 7 and SUSE 12 use systemd, I think its mature enough, they don’t use expermental software.
3) Debian users can install and use another init system, this proposal wants to oblige package maintainers to not package anything that depends on a systemd component, or write the missing components themselves if it was not provided by upstream. So if the upstream software depends on logind, the maintainer must patch it to support another (non-existent at the moment) login manager (don’t tell me about ConsoleKit, it is deprecated).