Do you like systemd?
This could turn into a mighty flame fest, but here we go: are you a fan of systemd? If you’ve only heard of it in passing, it’s a collection of integrated programs for booting and managing a Linux installation, replacing the shell scripts and tools that we’ve used for decades. systemd aims to make the boot process faster and simpler, while providing consistency across different distributions, and reducing code duplication. Most major distributions have adopted it – or are in the process of moving to it.
But not everyone likes it. This article argues that its designed is flawed, while the good people at Debian had an extensive discussion covering the pros and cons of systemd and its alternatives. The lead developer of systemd has written a rebuttal to many “myths” on his website.
It’s a complicated topic, but we’d like to hear your thoughts: do you think systemd is a step in the right direction? Is it time to move on from the old init system, or should we pay more attention to the “traditional” Unix way of doing things? Or do you simply not care, and just want a machine that boots and gets stuff done? Let us know in the comments below for our upcoming podcast!
Related Posts
About The Author
Mike Saunders
Mike stores his data by printing out hex dumps and laminating the sheets. He's the author of The Haynes Linux Manual and the creator of MikeOS, an operating system hand-built from assembly language.
while i’m not technical enough to rate systemd i would say that the fact that linus thorvald had to ban a systemd developer from trying to fix systemd by patching the linux kernel indicates a lot of problems in systemd.
when he comments on a technical issue in such a way that the entire user base of linux gets to hear about it someone has fecked up.
I am pro-systemd. I’m also pro-PulseAudio (which comes from the same guy). Not necessarily because either system is perfect, but because both projects are aiming to apply fresh design patterns to ageing systems within the Linux ecosystem, making things both simpler and more flexible.
The old init-script method of booting had the particularly nasty issue of not being capable of ensuring that the systems it started remained running healthily after boot. This was a pretty major flaw, and required separate monitoring daemons to restart failed services on servers. Either that or someone would just reboot the system when it stops working (again!)
In this day and age, we expect our machines (especially servers) to have a degree of self-analysis and graceful recovery from failures. Systemd’s state-machine-like approach to service management makes good sense.
There are many other reasons why systemd is better than the good old init scripts we used to use, but they’ve been explored thoroughly elsewhere 🙂
I’m old school. I like the rcN.d structure. When I first encountered Slackware I hated the rc.XXXX structure, but learned to live with it for all its other benefits.
But whilst adequate for serving the needs of booting a fixed-purpose server, the demands of modern user machines (with hot-pluggable peripherals, and dynamic services) calls for a new approach. I’m not sure if systemd is it. I’m prejudiced toward the old ways. Time will tell.
systemd may have it’s detractors (including me), but the fact is that working code speaks volumes louder than any opinionated mouthy developer (inclusing me again), and until a better pile of working code gets written, it’s going to be here to stay.
upstart is also working code, albeit one that is burdened with a CLA.
I am convinced that systemd will eventually wind up trying to replace the Linux kernel too
systemd by the same guy that made PulseAudio.
Anything else to add?
System v IS working code. Those of us who like system v do not have to go and code something new for wasting times sake. I like old unix like Linux. Not systemd takeover and policy kits and free desktop dot org stuff. The system d people have even proclaimed that virtual consoles will be removed from the kernel in the future and you’ll have to use there thing completely. They are a wrecking crew. There needs to be a fork of the whole Linux software ecosystem.
It is not fair that these new people can come in and take over and ruin out operating system.
It feels like a bunch of Java developers have had a go at messing around core components of the OS.
I mean hey it works on my workstation, lets just tar it up and roll it out on live.
The need to manage and administrate servers with speed and agility should completely outway some benefits that really only benefit desktop users, tablets, phones.
The idea that API’s and Binary are a good substitute for clear text files that can be edited in vi or read with egrep and a bit of regex is just nonsense.
Why should there be an extra layer of complexity to make it supposedly easier to use but at the same time hide whats going on behind the scenes.
I haven’t had to touch a systemd-based system yet, but having heard a lot of the fuss about it, my gut is telling me that I won’t like it. The main flaw it seems is in its design philosophy of trying to do and be everything. [1] The Unix philosophy of small tools that each do a single job well and can be interfaced with one another is one of the things that draws people to Linux, and I think we ignore it at our peril.
[1] https://lh3.googleusercontent.com/-bZId5j2jREQ/U-vlysklvCI/AAAAAAAACrA/B4JggkVJi38/w426-h284/bd0fb252416206158627fb0b1bff9b4779dca13f.gif
That Unix philosophy is why I like using Linux. Small tools that each do a single job well and can be interfaced with one another.
Its what makes Linux more useful than alternatives.
It keeps the user having control.
The Unix philosophy is a good philosophy; it has stood us in good stead and is one of the reasons Unix and Linux are such robust and adaptable systems.
Systemd might streamline and speed things up now, but I can’t help but think it’s storing up a whole lot of hurt for the future.
The UNIX philosophy is not universal to everyone, and the particular point you bring up is one of the many tenets that apply to users and developers in different ways.
For developers, splitting tools on the basis of them doing different things is not useful. It creates management overhead, and disconnects the project from the reality of how it will be used. ImageMagick, as an example, is a single project that does a lot. It does not make sense for mogrify, convert, or display (individual commands) to be developed in different places, as they work towards solving the single task of image manipulation. systemd from the perspective of a developer makes a lot of sense, as system management is a single task one would perform.
Your image, while humourous, does lend a good example. Cron is a foundation of the historical Linux system, but what it actually does isn’t that different from Upstart or Systemd as service/daemon managers. Add timer functionality to either of them, and you not only have something largely capable of replacing cron, but somthing that also adds handling of dependencies (start 5 minutes after service X if Y is finished) and failures, with very little work. It also has the benefit of not being crontab, and instead using the standard service file syntax.
With users, it really doesn’t matter how big the project is as long as sufficiently interoperable command-line tools are provided. I have yet to encounter a command that switching to systemd has removed and not replaced. If anything, systemd has added commands and functionality that simply was not previously available. One example springs to mind – OpenRC not cleaning up leftover resources and child processes of services, which broke GDM in the event it was started again, until the Gentoo GNOME maintainers implemented it.
Well, most people use GNU (which isn’t even Unix, it just tries and seems to rather succeed to be compatible with it) without caring a wee bit about the philosophy behind it!
What’systemd ? No but yes but honestly if Linux can boot faster go for it. Despite windows 8 many faults it boots in under 10 seconds with me, where as my manjaro xfce takes longer.
Do I like systemd? God NO!
Is it time to move on from the init system? Hell YES.
We do need to work on a modern replacement for the init system, but systemd is not the one we should be looking at.
Systemd is definitely more modern, but it didn’t make things simpler, it’s very cryptic and tries to take over the whole system (proprietary style where there’s one big blob -the OS of sorts- that does everything and you can’t distinguish one part or function from another).
Init might not be up to scratch with modern needs, but the philosophy behind it is still valid: KISS and one function one program.
I only have systemd running on one of my boxen at the moment but so far I’m impressed. The unit files are pretty easy to understand and compared to upstart the CLI interface seems a lot richer. I’ve read an aweful lot of flame wars around systemd and they mostly seem to boil down to two arguments a) it’s not the “UNIX way” b) it’s written by Lennart. The second argument just seems to be pure ad-hominem based on the history of PulseAudio which depsite the early breakage has pushed the state of audio on Linux forward. The first may have a point but if the alternative is SysV init scripts then give my systemd. By all means build/point to a better engineered more UNIX-y solution that solves the problems modern booting but until then talk is cheap.
systemctl status gives a bit more useful information than previous solutions.
Otherwise, can’t tell the difference.
As an end-user I would go for anything booting faster with easier configuration. I don’t like the idea of systemd doing all sorts of other things. But then again, what’s stopping people from forking it and throwing out everything except the initialization module ?
However …
If the flaws of http://ewontfix.com/14/ are real, I think all bets are off. Introducing security risks and imposing reboots after updates are in my opinion serious regressions. I’d rather go for a longer boot time (which is already pretty fast).
The article is pretty bad to be honest, the author sort of has a point but fails to aknowledge that there might need to be some trade off to actually have a functional system that works for people.
PID 1:
The systemd PID 1 is as small as it can be in order to provide the functionality it does. While the author is right that this added complexity could make systemd more prone to crashing, in practice however it has not been shown to crash more or less than any other PID 1.
It’s important to remember that not everything systemd does is in PID 1.
Attack Surface:
These claims may be true, although without any data to back it up “Using systemd then more than doubles the attack surface” comes across as a made up statistic.
Reboot to Upgrade:
This isn’t true at all, and in fact the author aknowledges such later on in the article saying “systemd’s systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted” and then later claiming that “if re-execing itself fails, the whole system goes down” which is true for any PID 1.
The rest of the article strikes me as FUD, or at least seriously misinformed about what systemd is and what it’s goals are.
I’m not that technical, but at my level I prefer systemd. I find it works, it’s fast (about 5-6 seconds to boot into openbox from an SSD), enabling and disabling services is easy with systemctl, and journalctl provides pretty good logging for troubleshooting. (The guy who has Windows8 booting faster than Manjaro has something else going on. I would guess a typical “premature” Windows desktop, Windows being 1st on the hdd, or some service delaying his Manjaro boot.)
I picked up some PC magazine recently as it had an article comparing ubuntu and win8. It was actually quite fairly done. Win 8 did beat ubuntu to the desktop, but they both took the same time to boot and launch firefox.
I’m sure you’re right, but there is a difference between Unity (or Gnome3 and all the zeitgeist/tracker “stuff” that is autostarted) and xfce. I know when I boot into Gnome3 waiting for the desktop portion is half my boot time.
Not exactly on point, but Ubuntu uses upstart not systemd.
I have not noticed any difference between systemd and the old init scripts. I think it is supposed to be more flexible and technically superior, but I can’t really motivate myself to have emotions towards it.
Systemd was, speedwise, a revelation.
Especially on my 13′ subnotebook with
(early, hence slow) ssd it went to 8 sec
from switch on to desktop.
13′ doesn’t sound like a subnotebook, it sounds like a monster! ;-P
I think systemd is misconceived in that it breaks from the traditions, in fact, the philosophy, that underpins the power and success of UNIX-like systems. The two often cited examples are that it has binary logs instead of text files and more importantly, it tries to centralise too much, instead there should be many small tools for specific tasks.
I’m not qualified to comment on the implementation and code quality, but it’s clear that too many that are experienced (e.g. Torvalds, T’so) are very concerned about that.
Pulse audio is relevant I think. I was never clear on what problem it solved, and friends who used it had way more problems with sound that I did with using good (but far from perfect) old ALSA. I’ve still not been forced by any software to use pulse audio, which also puzzles me a bit.
> The two often cited examples are that it has binary logs instead of text files
You can have your text logs if you really want them, journald can be configured to forward messages to syslog. However a binary journal beats your text logs hands down any day for it’s versatility. It has a lot of features that simply didn’t exist before because parsing text logs for meta information is seriously dodgy business. Have a look at these examples on how to use the journalctl command:
https://wiki.archlinux.org/index.php/systemd#Filtering_output
> it tries to centralise too much, instead there should be many small tools for specific tasks
Actually systemd is modular, it comprises of many components that can integrate using dbus APIs, and several small tools for specific tasks (see journalctl for example).
The man pages index gives you a good idea of just how many tools are provided: http://www.freedesktop.org/software/systemd/man/index.html
> Pulse audio is relevant I think. I was never clear on what problem it solved
It’s feature list is actually fairly extensive (from Wikipedia):
– Per-application volume controls
– Ability to discover other computers using PulseAudio on the local network and play sound through their speakers directly
– Ability to change which output device an application plays sound through while the application is playing sound (without the application needing to support this, and indeed without even being aware that this happened)
– The ability to combine multiple sound cards into one
– The ability to synchronize multiple playback streams
– Bluetooth audio devices with dynamic detection
See here: http://en.wikipedia.org/wiki/PulseAudio#Features
> and friends who used it had way more problems with sound that I did with using good (but far from perfect) old ALSA. I’ve still not been forced by any software to use pulse audio, which also puzzles me a bit.
PusleAudio got it’s bad reputation largely because its development caused bugs in ALSA drivers to be discovered and fixed. Not that PulseAudio itself, and the teams integrating it into distros didn’t cause their own share of bugs.
My dad just this week sent me a long (too long) email about how fashions in motorbike engines have changed. I won’t go into it, but at any one point in time its one of sort of engine that’s all the rage (i.e. the inline 4) at another time is all about the v-twin.
In truth, they have different characters, but what makes them good or bad is not their basic design, but how well that design was implemented and refined.
I think that maybe we spend too much time in the opensource community arguing about the potential merits and problems of some idealistic concept. The one that wins out in the end is the one where the developers persisted and made it good.
But I am a hypocrite. I’ll happily believe that linux is inherently more secure by design than windows no matter what they do to it, but I know I’m probably not right.
System who??
My main reason for using Linux in the first place was its reputation for stability and reliability and I know that the init scripts work really well in that respect.
Having said that, I really didn’t like KDE4 when it first arrived and after convincing myself to give it a go (on the basis that fear of change is fundamentally irrational) I found that I ended up preferring it to KDE3.
I think that if systemd can demonstrate that it’s as reliable and secure as the current rc.d scripts (and if it’s easier to use as well) then why not give it a go?
I’ll hang on until then though (Pulse Audio etc. etc.)!
On an old podcast I remember one of you guys saying that Linux on the desktop would never succeed as long as PulseAudio existed. This is the latest form the same guy. Nuff said.
I am so tired to hear those “systemd is bad because of Lennart Poettering”
First of all, most who complain have no idea who is this guy.
Second, Systemd has hundreds of contributors. It is not made by a single person. Among them are highly respected key kernel developers.
Beside of technical details, systemd seems to do something which is highly needed in the Linux-vers… unification. In systemd, things work the same among dozens of different distros. This was not true for the dozens of different initscripts dialects.
Yep, I like it!
Maybe in 5 years I like something which even better, who knows. This is part of the deal you have to deal with, if you use a community driven OS.
I didn’t care about this issue at all until I heard that systemd was written by the same guy who wrote pulseaudio. Now I just want systemd as far away from me as possible – pulseaudio is a horrible horrible system which is broken at the core (for example, why does it do software mixing on my creative labs card which has a hardware mixer?). I *DO NOT* want my init system to be of the same quality.
So you’re misinformed about PulseAudio and therefore anything to do with one of it’s developers needs to be shunned?
Maybe you should read up on the things you’re criticising, and perhaps file a bug report?
Oh, yes, I’m ignorance embodied.
This assertion that I should “read up” on pulseaudio is an excellent suggestion, I hadn’t thought of that – thanks!
So I took a tour of the documentation. I was a big fan of http://www.freedesktop.org/wiki/Software/PulseAudio/TOC/ – a blank page is always helpful.
I searched for things like ‘pulseaudio multichannel hardware’ and ‘pulseaudio hardware mixing’ and came up with a guide on disabling pulseaudio so that alsa does hardware mixing sanely for me (like it has done for about 15 years now): http://fds-team.de/cms/articles/2013-05/activating-sound-hardware-mixing-on-ubuntu.html
I’d note that if the official advice for people in my position is to disable it, then why would I want it installed in the first place? Secondly, why does it make the assumption that it’s necessary, even when it is easily able to determine that it is not (i.e by querying whether the ALSA device supports multichannel audio)?
I looked up the FAQ to see how I enable sane behaviour (i.e: disable the use of software multichannel in favour of my dedicated hardware), and I couldn’t seem to find any mention of hardware mixing or multichannel audio at all – I can’t even seem to find any indication of whether pulse is doing the multichannel mixing in hardware of software if the hardware exists.
Allow me to clarify on my “I’m not interested in anything else from Lennart Poettering” position: I’m not interested in anything else from him right now, because I tend to think that you should finish your previous projects before working on a new one. Pulseaudio is *at best* unfinished, since it doesn’t do anything to detect hardware which does the same thing and disable itself.
Just because it happens to seem to work most of the time on your laptop with no real audio hardware which is rebooted every day does not mean it’s a good or useful audio system. We already had things which solved pretty much everything pulseaudio gave us on the existing stack: alsa has a ‘dmix’ module which does software mixing to allow multichannel playback, jack does low-latency audio and network transparency better than pulse does. The only actual improvement I can think of that we got is per-application volume controls (which I do admit are a nice-to-have, but only a nice-to-have, and easily doable with jack). Pulseaudio is NIH syndrome at its worst and I expect that it could have all been done as a couple of alsa modules and maybe a new alsa configuration gui. I particularly enjoy the irony that pulseaudio wasn’t just implemented as a set of alsa modules, yet it requires alsa. i.e they didn’t want to do any of the real hard work of interfacing with hardware – they’re not an audio driver system, just a wrapper framework. That wants to act like it’s a driver system. Sitting there all the time doing unnecessary things. I think that the only reason it needed to be a separate project from alsa is because people who write alsa modules don’t get fortune and glory. Not-Invented-Here-Syndrome.
File a bug report, huh? I did ask around when I first noticed this behaviour back when pulseaudio was consistently using 5-10% of my 800mhz processor just when it was sitting at idle, and more whenever I tried to play back multiple audio streams at once, and the response I got went something along the lines of ‘you don’t need pulseaudio since you have a multichannel card, it’s not intended for you’. Yet it’s installed by default in most distros these days and doesn’t disable itself when it’s unnecessary – it makes the assumption that I want it without even bothering to check whether it’s a good thing or detrimental. Furthermore it encourages use of the pulseaudio API, meaning that my audio apps which support (or, worse, require) it will tend to pull in pulseaudio as a dependency whether I want it or not.
I spent many days trying to figure out why I get a ~1second latency when running applications through padsp. I never solved that one, instead I just can’t play Unreal Tournament anymore ever since pulseaudio took over OSS compatibility.
I’ve also spent a bunch of time ‘reading up’ trying to figure out why pulseaudio seems to randomly die when I’m using audio in wine.
When was the last time you had a good response to ‘ dies randomly’ bug report? Does that sound easily replicable to you?
Furthermore, why should I file a pulseaudio bug report, given that I don’t actually want any functionality that it provides or anything to do with the project?
To clarify the situation: I don’t actually have any audio problems at the moment, because I have pulse set up to not run unless necessary and I have most of my audio applications set up to use alsa (or jack, depending on what I’m doing).
But this took about 3 days of work. As opposed to 10 years ago when multichannel audio just worked, 100% of the time, out of the box.
But I’m obviously misinformed and wasn’t just making a quick post to voice a concise summation of a perfectly valid opinion based on long experience, so let’s just disregard my opinion.
Agree with everything you say about Pulseaudio.
ALSA does 100% of what 90% of the users want, and specialist programs like Jack do the remaining stuff better than Pulseaudio… but somehow we ended up with Pulseaudio being imposed on everyone for no particular reason.
Having said all that, ALSA configuration is mind boggling. It’s good, it works, but I can’t make head nor tail of the documentation and the only way I get it to work is by cutting and pasting bits from google search results until sound starts by accident.
There is very much a space for some sort of way to manage ALSA devices in an easier system. Possibly just a better introduction to how to write config files, or something that shows you what’s going on.
… and Pulseaudio seems to be the way most people connect to bluetooth devices. Not sure if there’s a good reason for that or not.
If that’s the only useful job it does then I think a little daemon to just do that job would make more sense.
I do not have the technical insight to judge the long-term merit of Systemd.
I am a Slackware user and will remain so. But I must admit to being impressed by the startup speeds of such distributions as Manjaro.
The Linux Action Show guys have been doing some interesting stuff on systemd.
The systemd group has a proposal for universal software management scheme for all Linux distributions. We’ll share the technical details, debate the philosophical impact & explain why it’s all powered by btrfs. http://www.jupiterbroadcasting.com/65847/one-packager-for-all-lup-56/
and:
The majority of systemd hate appears to be coming from just two sources. At least that’s what we suspect & call them out. http://www.jupiterbroadcasting.com/66417/systemd-haters-busted-lup-57/
I completely forgot I had not added the Linux Action Show to my podcatcher since my HDD crashed. Thanks for the reminder!
One of the biggest things I hate about it, is not having clear text control over the logging directly and the annoying way it puts things into binary.
It is also pointless to start things in parallel with anything that will be used as a server, as it stops people having clear visability of where things are failing on startup.
Its only benefit would seem to be for desktop users or android phone and device users. The idea of having everything startup quicker, not that there has been a huge problem with startup times.
Any power users or Server users would suffer with Systemd.
In some of the large deployments for companies where RHEL 7 is being used, System admin/devops/principle/whatever are hating it for some of these reasons. Seems like Debian wont be the answer either.
There was a coup within debian where the system d supporters filed the lack of default systemd use as a technical bug while they had a man of theirs as the technical committee chair. There was no general resolution amongst the debian developers.
> Any power users or Server users would suffer with Systemd.
Not really, no. Systemd provides a great set of integrated features, just because they are different doesn’t make then worse.
> One of the biggest things I hate about it, is not having clear text control over the logging directly and the annoying way it puts things into binary.
Actually journalctl is really powerful, you can do plan text things with it too, see the Arch Linux wiki: https://wiki.archlinux.org/index.php/systemd#Filtering_output
It probably is high time that linux stopped pretending that the same distribution should be both a server and a desktop. There are many reasons to specialise.
I can imagine something like systemd is a good idea for when you are installing a host system that will just run KVM instances (as an example). You want fast boot, a streamlined platform, and flexibility is not particularly important.
Then again, if all you want is to run a web browser and boot fast then Android is not too bad. *shrug*
When using linux in a server environment you avoid downtime and the need to reboot is not a frequent thing. Most likely only when certain core hardware needs to be swapped out.
Monitoring is usually done network wide with monitoring tools i.e nagios or non free HP openview, BMC Patrol etc. Monitoring teams receive alerts, prioritise the alert, send it to the correct team and services are looked at to see why failure happened. Most of the time you wouldnt want a service to restart by itself without you first looking at hopefully non binary logs.
Uptime of your environment while some services/daemons are down on a single server is maintained because you have clustering or load balancing doing round robin etc. This helps by giving you time for diagnosing those faulty services before bringing them backup into your cluster or LB environment.
Even easier with Virtualised/Internal Cloud environments where if enough resources prevail you can spin up a replacement to keep performance and fault tolerance of your cluster.
Init scripts are easy to understand and clear whats going on.
So I dont think your reasons are good enough for server environments and change should be better than what we have not just change because its apparently old.
> Even easier with Virtualised/Internal Cloud environments where if enough resources prevail you can spin up a replacement to keep performance and fault tolerance of your cluster.
It’s even easier with Linux Containers which systemd lets you make use of easily.
> Init scripts are easy to understand and clear whats going on.
Init scripts have always been overly complicated and horrible to maintain (especially across distros). Maybe if you live in init scripts day to day it becomes easier and more logical, but I have to say I much prefer configuring a service rather than scripting a service.
It was only ever 3 or 4 lines of code which you could just carbon copy from another Init script that you had previously created.
As for maintaining Redhats style of chkconfig, that was pretty easy as well, just add the appropriate lines to the top of the script.
Nothing difficult and plain as day.
Easy to grep the /etc/init.d for scripts and easy to spot the run levels by looking in the rc{1,2,3,4,5}.d directory.
If this is too hard, should the person be running linux in a server environment.
The method you describe with configuring a service is more in line with a windows system logic.
I like the level of control and flexibility scripts give me.
I think the difference here is people who live their lives in the Shell and People who live their lives in X Windows Gui.
Most of my work life is using the Shell.
At home ill use a Gui a lot.
If you use the Shell, you want to maintain the flexibility to control your environment, I dont even install a Gui or any Gui component onto any work server. In fact i keep the packages installed to the minimum required to do the task that the server is for.
Systemd seems more directed at the Gui workstation user.
Sorry, this was in reply to Paul Dann
http://www.linuxvoice.com/voice-of-the-masses-do-you-like-systemd/#comment-469785
I have no real understading of the history of systemd, or why people have don’t like it. I’ve heard vague things about not adhering to the unix philosophy. As a user of systemd though I like it. It easy to create a startup script, and I’ve never had any problems with it. I of course also never had problem with init scripts. After arch switched to systemd, I’ve used it, and I can’t complain.
You are just a user. A consumer.
At this stage it isn’t a case of liking sytsemd or not, it is inevitable. Since logind will be a required component of modern desktop environments like Gnome, pretty much every desktop user will be using systemd soon.
The reason this happened is because they (systemd) did the work. The opposing camp either didn’t do the work when it was needed or—in the case of Upstart—attached a contributor license agreement which scared off supporters. In my opinion it was the Canonical CLA which tipped the very close race within Debian in favour of systemd.
That is not to say that systemd doesn’t bring many nice features which are helpful for a lot of server configurations also. But the inescapable requirement for systemd in Gnome is why almost every distribution will be defaulting to systemd.
And you know what? It’s going to be fine. Most people will not even notice.
Those competent enough to be using minority desktop environments that perhaps don’t rely on logind are also the same people who are perfectly capable of switching to a different init system.
No. Debian Linux comes with source code DVDs. You do not have to upgrade. You can stay with the old and best of Linux.
You and we do not have to accept being lead by the nose. We can stay on wheezy forever and just upgrade the kernel for hardware support and patch with grsecurity for protection.
If it ain’t broke don’t fix it, ricer.
Yeah, I predict CentOS 6 will have a surprisingly extended lifespan.
http://devopsreactions.tumblr.com/post/97126865868 seems rather timely. 🙂
Using it on Manjaro hasn’t been too bad so far, however, I have had issues with it and am actually looking for another distro that doesn’t use systemd to replace this.
It is trying to do too much in a way I personally don’t like (probably because I’m used to the old ways).
I agree that things need to move forward and Linux on the desktop needs to match and beat others OS’ out there, but I don’t feel that systemd is the right way to do it. Even from a cold boot computers these days can get to login screens within a few seconds, does wasting an extra 1-2 seconds once, twice, 10 times a day really ruin your day that much?
> does wasting an extra 1-2 seconds once, twice, 10 times a day really ruin your day that much?
Boot times are not what systemd is about, just a nice side effect of how it operates.
All I want is a computer that boots quickly and efficiently. It must run the applications I use reliably and securely. That’s it!
Another thought. Most speed gains have more to do with hardware than software. Try running older OSs compared to newer ones on the same hardware. Perhaps that will explain why my old computers appear to be slowing down? Bring back Linux Mint 9, all is forgiven.
the descriptions of what systemd can do sound awesome, so that I want.
Linux is the system that these ideas can be tried out, and the best will win on technical merit. The philosophic augments against have merit, but these are secondary to performance, stability, useability.
I’ve been using systemd for the last few years (since openSUSE 12.1 moved to it)
and personally I think it is awesome, both from a user perspective and a
developer perspective. I do get a little bored of the childish, petty bickering
that surrounds it, which is often utterly misinformed.
What I like about systemd is:
* Simple, declarative service definitions, no more horrid cargo culted init
scripts. Which lets be honest, few people actually understood the differences
between each distros /etc/functions.d/
* Improved dependency management, systemd actually understands the relationships
between services and where possible lets the kernel deal with it. By extracting
the socket setup, by using autofs, systemd can start services when they are
actually needed. This also removed the need to specify dependencies between
services manually in a lot of cases.
* Able to track service processes, by using cgroups systemd knows exactly what
processes a service has forked and thus what need to be killed to shut the
service down. So much nicer and safer than pgrep! The use of cgroups in
theory allows for resource usage limiting and accounting of each service.
* A sane CLI to manage services and a dbus API, I can check a service status
programmatically, with out the need to screen scrape script outputs.
* How fast systemd boots. Especially handy on servers to reduce downtime.
* Templated services, I can restart one out of many OpenVPN instances without
restarting all.
* Capturing of logging, reduces the complexity of writing a daemon.
From what I can see, most people who dislike systemd are just resisting change.
Systemd gives Linux the service management system that it has been missing for
years. Ultimately systemd is launchd for Linux.
The people who talk about systemd not following the ‘Unix philosophy’, I would
argue that systemd does one thing and one thing well. It manages services, and
it does it exceptionally well, yet we shouldn’t forget this is a complex problem.
The people who say ‘if it ain’t broke don’t fix it’ have their heads in the sand.
SysV init is woefully inadequate and horrifically broken, the fact it worked (for
a given value of work) doesn’t mean we shouldn’t look for better solutions.
Previous service management solutions have not gone as far as systemd goes, in
being able to handle dependencies, isolating and supervising processes.
Oh and you can restart systemd without a reboot, the command is: systemctl daemon-reexec
All I wish is people would read ‘The systemd for Administrators Blog Series’ and
use systemd before rubbishing it with misinformed rhetoric.
PS: journald is pretty neat too.
Hands up everyone who believe everything your newspaper tells you…you lot are going to like SystemD. The rest of us cynical folks don’t like things that 1) has unnecessary dependencies 2) virally cause dependencies 3) needs separate tools to configure or view the logs 4) doesn’t really speed up the boot process (unless you by a new computer with your new boot manager) etc. I think SystemD makes little sense and just adds more bloat.
I do like systemd, yes. I find it a far simpler and more robust way to control services.
In terms of its technology it’s an absolutely necessary modernisation of Linux which opens the way for incredible innovations, making Linux capable of doing stuff other OSes (even the BSDs) can’t do.
It’s time that Linux established its own identity and purpose, aside from being ‘just’ a Unix-clone. SystemD, alongside other emerging technologies, is a huge part of that.
The conservative elements within the community will resist, as they always do in the face of the new and unfamiliar, but I think soon the advantages will be too profound and apparent for any major distro not to embrace SystemD.
I am a fan of systemd and I am very happy using it.
As an aside, I have not had an issues with PulseAudio for a long time now – so continued reference to that project seems ridiculous.
There is a LOT of misinformation and F.U.D. being propigated about SystemD and/or Lennart, often by people regurgitating the F.U.D. without even trying systemd for themselves. Oh, and despite what many think – systemd is not ONE monolithic package, it is made up of a whole slew of separate binaries, the majority of which can either be disabled or replaced using the API – sounds pretty UNIXy to me!
As for Lennart – he is something of a polarising personality – as are MANY Linux project leads. I personally don’t think that he deserves the amount vitriol that seems to be sent his way – and equating PulseAudio with SystemD is just being petty! Besides, alot of the complaints against PulseAudio are misinformed also – PulseAudio suffered from being the ‘messenger’ in a lot of the earlier issues that it had, and got shot accordingly.
Also, none of us are perfect, so discounting something because it was made by Lennart is like having somebody completely dismiss you for the rest of your career because you were associated with some project that suffered initial set-backs. Grow up people.
It appears to me that many of the SysV defenders are people with little or no experience in the difficulties that SysV has and the enourmous number of ‘hacks’ and sidecases that are needed in a lot of bigger Linux environments.
That being said – for home/SME users, it is mostly fine – so systemd introduces ‘another new thing’ to learn. That can be very disconcerting for some people.
Like everything in the land of Linux, SystemD must continue to prove its value or face being replaced by the next ‘Init system’ – so far it seems to be doing just that.
Here’s the “systemd cabal’s” post on unifying package management: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
It really needs to be asked what value the “UNIX philosophy” has in 2014. It has no application to graphical programs, as they simply can’t be chained together. Your kernel doesn’t follow it. Your display server on top of your kernel doesn’t follow it. Your window manager on top of the display server on top of the kernel doesn’t follow it. Your browser on top of your window manager, and so on does not follow it. Complex programs can not follow it purely by the fact they are complex programs, and have complex dependencies.
But that isn’t why the sacred scripture is ignore – the reality is that most developers do not follow the UNIX philosophy because it is needlessly restrictive. Decades ago it made sense for UNIX to be bare-bones (and as a result, portable) – it was sold as a system to be heavily modified. IRIX, HP-UX, AIX – all built from the scaffolding UNIX provided. This situation simply does not happen in 2014 to Linux; partially because of the GPL, partially because it is such a massive project.
As for systemd’s interoperability with non-Linux systems, which is frequently mentioned – they are irrelevant. FreeBSD, NetBSD and OpenBSD wish to be rid of L/GPL software in their core. They obviously are not going to want something as system-critical as the LGPL’d systemd.
So yeah. I guess I like systemd 🙂
While implementing systemd might give a bit of headache I do belive that it will become an important asset for Linux distros in the medium and long run. I realize that this statement is controversial, but in my view there are sudden areas where some degree of standardization will benefit the entire community.
I’ve not been using systemd enough yet to comment too much, as I’ve only just swapped over to ArchLinux as my main distro (thanks LV!).
However, I have done an awful lot of research over the last few days and I have to say, IMHO, it seems the systemd guys really seem to know their stuff and, on the whole, I really like what I’m reading/where they’re coming from. Also, as others have said, they have working code and a lot of distros are using it now; says a lot in itself I think?
I can also say that, what little I have used of it thus far, I DO really like it. And what I’ve read up on — that I haven’t used practically yet — I’m also liking…
Finally, I would have to say that if Linus has no problems with it – then I sure as hell don’t! 🙂
http://www.itwire.com/business-it-news/open-source/65402-torvalds-says-he-has-no-strong-opinions-on-systemd
Those of you whose main objection to systemd is its feature creep, you might be interested to know about uselessd:
“uselessd (the useless daemon, or the daemon that uses less… depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.”
http://uselessd.darknedgy.net/
Systemd have too much power i dont like that.
sysinitv just works very well why need change ?
hummm you think evolution maybe oh yeah evolution ok.
there another options,
the problem is
they forcing us to choose systemd and this is the real problem.
Well, I’ve liked what I’ve seen.
systemd is easy to create services for, fast, manageable via scripting, simple (compared to other components such as a DE, anyway), and stable. I’ve yet to try it out on my really resource constrained hardware – 32MB of RAM, Pentium w. MMX – which currently boots in 20 seconds using an ‘old fashioned’ init system, so until then I’ll hold back from my ‘final’ _user’s perspective_ judgement.
From a (distro) developer’s perspective, it seems a pain to package – but no more than quite a few other pieces of software like any modern browser.
PS> Some people in the above thread seem to think things become slower as they get more modern. Maybe – but then again, maybe not… I like modern Linux 🙂
The older hardware just requires a lot more work to get up to speed…
Honestly I have no problem with Systemd.
As a user I don’t really touch my initsystem, so as long as it works and it makes a positive change compared to what came before it(which as an Ubuntu user is Upstart) I’m fine with it.
I also never had a problem with Pulseaudio, so I don’t see the big problem with mr. Poetterings work.
Systemd has problems. More reboots now for updates because it handles more stuff. Whoever thought binary logs was a good idea is a complete moron that hasn’t worked a day as a sys admin.
I liked the old system and the change to systemd has caused a few headaches but, providing they don’t change it for many years, I am happy to live with it.
I see why things had to change but the fracturing of OS’s because of it is not a good sign.
If systemd is anything as “reliable” as avahi and that other thing it will drive people crazy.
The guy should go look for another job or at least wait until he gains some maturity. He’s a fiend of system administrators, wants to be the Dev in control.
He’s a willing puppet ( or an idiot ) in a hostile takeover. Leading to empowerment for big money, singular control and poor design ( politics driven )
“The old init-script method of booting had the particularly nasty issue of not being capable of ensuring that the systems it started remained running healthily after boot. ”
Thats the job of the Kernel. Not the Init system. The job of the init system is to start programs at startup and stay small. Systemd does neither of these things very well.