Systemd – What You Need to Know

Systemd - What You Need to Know

Unless you have been living under a rock, or worse – you don’t care much about how Linux works, you must have heard of systemd, the (relatively) new init system replacing the old and outdated SysV init recently adopted by most major Linux distros.

What is an init system?

When your Linux machine starts up it will first run some “built-in” code, loaded from the BIOS or UEFI first, followed by the bootloader, which according to its configuration loads a Linux kernel. The kernel loads up drivers, and as its very first job starts up the init process, which being the first gets PID (Process ID) 1 assigned to it.

From the user’s point of view this looks like starting up networking and databases, etc., but in reality there is a rather complex process taking place under the hood. Services are started, stopped and restarted, often parallel to each other. Some are run under different privileges than others, service statuses are being reported and logged, and many other tasks are performed that will make the different part of your system work and be able to interact with its users and environment.


How this is implemented, however, is far from uniform, and this really is where it all stops being common and well-defined.

The old init system

The init system used by most mainstream Linux distros up to recently was System V init (or SysV init in short), which has derived its name form UNIX System V (Pronounced “System Five”), the first commercially available UNIX system. System V OS has had a specific way to run its init process, and SysV init has kept loyal to this over the years.


And it has been many years. UNIX System V was originally released in 1983, making the init SysV init an over 30 years old approach towards starting up Linux machines.

The need for a change

As it has been noted, SysV init has been outdated and long overdue to be replaced. Some of the reasons for this include:

  • SysV init uses /sbin/init to start the init process, but init itself has a very limited role. init does little more than starting /etc/init.d/rc, according to the configuration read from /etc/inittab, which in turn will run scripts to do the real work of the init process. This, unless panelized explicitly (like with startpar on Debian), will happen sequentially, one script starting after the other, making the whole process slow as each script has to wait for the previous one to finish.
  • SysV init does not have access to the PID or the processes it has (indirectly) started. It only reads PIDs and associates them with actual processes in a circumstantial, complicated way.
  • For system administrators trying to modify the environment under which a certain process would start, it’s quite difficult with SysV init. (In order to achieve this they will have to modify the init strcipt that is responsible to start the given process.)
  • There is certain functionality common to every service that SysV does not implement, but each process would have to implement itself instead, such as “daemonising” themselves (becoming a system daemon), which is an elaborate and long process. Instead of implementing these steps once, SysV requires each process to do the job themselves.
  • SysV also leaves certain functionality to external programs and knows nothing about services started by those.

All of the above, and many more design flaws, or rather the outdated system design of SysV, has made the creation of a modern init system long overdue.

Enter systemd

There were many attempts to create an alternative init system, of which systemd is only one of them. Ubuntu used to run its own init system called upstart. Gentoo still uses OpenRC. Other init systems include initng, busybox-init, runit, and Mudur and others.

The reason systemd is a clear winner is that it’s been adopted by most major distributions. RHL and CentOS naturally went the systemd way, as Fedora was the first distro to officially adopt systemd in 2011. But systemd has really become the one init system to rule them all, when Debian 8 officially switched to systemd, bringing Ubuntu and derivatives with it, overcoming Canonical’s (or more precisely Mark Shuttleworth’s) initial opposition towards systemd.

How is systemd different?

  • Systemd aims to provide a single, centralized way to handle the init process from beginning to end.
  • It starts and stop processes and services while keeping track of their dependencies. It can even start a process as a response to another process’ dependency requirement.
  • In addition to start and stop processes during boot time, Systemd can also start any time when the system is up in response to certain trigger events such as when a device is plugged in.
  • It also does not require processes to daemonize themselves. Unlike SysV init, systemd can handle services running without having to go through the long process of becoming daemons.
  • Unlike SysV init, systemd knows and tracks all processes, including PIDs, and getting information about processes is much simpler for system administrators under systemd.
  • Systemd supports containers that are basically isolated service environments without the requirement of virtual machines. This has great potential towards more secure and simpler system designs in the future.


Of course these are only some of the major advantages. For a full discussion on systemd’s advantages, you should read Debian 8’s “Systemd Position Statement


Of course systemd was not welcomed by all. In fact, many have and still do frown upon it, calling it monolithic and cumbersome, some even accusing it of going the “windows way” of having everything centralized. Many argue that it is not “the Linux way”, and certainly systemd does not seem to be in accordance with POSIX standards, and if we consider systemd as a toolkit (beyond just the binary), it is definitely hugae.


Nevertheless, systemd is clearly a step forward, and while it’s not perfect, much of the criticism it has received has been addressed by its original author and developer Lennart Poettering. It definitely is is a much needed advancement and a step up from the old init system. Linus Torvalds, the creator of Linux, does not seem to mind systemd too much, and who are we to argue with “The Creator.”


Having been adopted by all major Linux distributions, systemd is here to stay. Whatever some system admins say for whatever reason, systemd is the future of mainstream Linux, whether individual users like it or not, which, looking at its distinct advantages, is not necessarily a bad thing.

For the average user it brings faster boot times and probably more reliable systems, while in the future distributions adopting it can become more “compatible” with one another. On the user end we will definitely benefit from the more up-to-date and contemporary system design it brings to our desktops.

Attila Orosz Attila Orosz

Attila is a writer, blogger and author with a background in IT management. Using GNU/Linux systems both personally and professionally, his advice stems from 10+ years of hands on experience. In his free time he also runs the popular Meditation for Beginners blog.


  1. It is obvious that your article gives a subjective view of Systemd. While SysV init may be old and inadequate, do we really need a huge init process that does everything except make breakfast? You only mention the advantages of Systemd. Is that because there are no DISadvanatges or because you wish to the readers to see only the positives and thus be better disposed toward Systemd? You also failed to mention any of the newest init competitors to Systemd.

    I find your Conclusion to be arrogant with its “like it or lump it” attitude. There is a lot more that we need to know about Systemd than what you deigned to tell us before we embrace it. Linux is not Windows or OS/X where the developers tell the users “This is the O/S and you WILL like it!”

    Don’t forget that the distro developers dumped SysV init in favor of Systemd. There is nothing to stop them from dumping Systemd, and all the great things that it does, in favor of some other init process. In fact I am sure that another init process will be developed shortly for those that do not wish to use Systemd. The Linux community is very resillient and resourceful. antiX and MX-14 do not use SysV init and there also Systemd-free. There are other Systemd-free distros whose names I cannot recall of the top of my head.

    1. There’s a few problems with your reply:

      1, The most obvious: People who are loudest against systemd are the ones who read about it on some forums, etc. and now repeat the very same things over. Without having any negative experience, or true reason to dislike it. It probably makes them feel smarter than those, who don’t even know what an init process is. Probably they are right and they are really smarter, still, their attitude is arrogant, usually because they will only state “systemd is horrible”, without giving a reason or explanation. That is usually because they have no idea why. Somebody said it, and it’s always cool to stand with the minority “in the know”. ;) Are you one of those?

      2, It is only natural that my article is in favour of systemd, as I am in favour of systemd and I wrote the article. (Whow, such logic.) I have no obligation to be objective. Fact is, I hate to be objective. (If I wanted to be, I would be a journalist, which I am obviously not). If you want to see an article about the downsides of systemd, or one that warns people of this great evil, you are welcome to write one.

      3, No, it’s not arrogant. Whether you like it or not, systemd is here (for a while at least) to stay and this is a fact. And with all the major distros (and base distros like Debian) having embraced it, systemd has a long future. Virtually nobody uses antiX or MX-14, compared to Debian or RHL derivatives. Those few who use these can feel very privileged and as superior as Mac users feel…

      4, Sorry to break this to you, using antiX, or other obscure distros does not make you an expert, and bashing systemd without telling us why, only proves you don’t understand it. If you really want to show off, make an LFS with a custom init process. or install gentoo on at least 7 different setups (with different hardware). That truly makes a difference in your learning curve. BTW Gentoo uses OpenRC, so you can be “free” with it.

      5, “systemd-free” is a hype. It might make sense, but only with an explanation. Without one, saying “systemd is bad for you” a stand-alone statement. Prove your point, if you have one, then I call it a discussion.

      6, I gave due credit to the hurt sysadmins, who cannot accept that sysvinit is gone, in the controversy section. This is all the credit it deserves really, especially on a website that is meant for “Making Tech Easier”, instead of going into “Why I cannot Adapt To New Technology”, like most sysvinit advocates’ case will show.

      7. Please enlighten us, how the average user will benefit from not using systemd? in practice I mean. How will the world be different if it goes systemd-free? How will Average Linuxuser Jane/Joe feel the difference?

      I can help: they will not. The Ubuntu user would not even care if their data is stolen for most of the time. But the point is not really that. The point is, people will only feel that the PC might start faster. Systemd is also a stability improvement. So unless you are Richard M. Stallman’s love-child, the philosophical question of using one init-system over an other remains purely philosophical. That said, your opinion will not change the fact, that mainstream Linux goes the systemd way. And that is a fact. Whether you like it or not. guess what Thorvalds does not mind systemd (see link in article). Are you smarter/know Linux better than the guy who wrote its kernel? I doubt it.

      8, Please provide us with one reason why you think systemd is bad, which was not already covered in a discussion forum, or addressed by its developer (see link in the article). If you find one and it makes sense, then you’ll be talking…

      Of course there were points where you were right:

      1, Yes, I was subjective. (I already mentioned it, but I also agree with your statement on being subjective. I just like being subjective. And I also boot my subjectivity with systemd. Ha!)

      2, “Don’t forget that the distro developers dumped SysV init in favor of Systemd.”

      I did not forget. Hands up whoever forgot. (This is like stating that water is wet. Also makes the same much practical sense.)

      3, “There is nothing to stop them from dumping Systemd, and all the great things that it does, in favor of some other init process. ”

      Agreed. And if they do, there will be an even better init system. Until that there is systemd. Get over it.

      Now to answer your questions, or reflect to your statements:

      1, “Do we really need a huge init process that does everything except make breakfast?”

      Yes, we do. Future implementations of systemd are rumoured to be able to cook bacon and egg.
      (This also proves that you don’t understand sytemd. It is not only an init process… An explanation of why, is way beyond the scope of the short article, or its comments though)

      2, “There is a lot more that we need to know about Systemd than what you deigned to tell us before we embrace it.”

      Before we embrace it? Really? Now who’s being arrogant. please. Embrace it or not, your distro already did, if you are on anything mainstream, which let me tell you, the average Linux user is. So? Do they need to “embrace it”, or just get on with their life and use their time for something useful (assuming they do have a life, that is, a lack of which can be seen from taking time to tell others how bad systemd is.)

      The distros you mentioned and those you did not, that don’ use systemd give plenty of choice. And Linux is abut choice. And choice is you can choose not to use systemd. But you can also choose to go with it, this is part of freedom, isn’t it? the broader community does not have to embrace something for the individual to use/abandon it… but they need to know what they are doing, for it to make any sense at all… For the average user there really is no difference.

      3, ” Linux is not Windows or OS/X where the developers tell the users “This is the O/S and you WILL like it!””

      “The Linux community is very resillient and resourceful”

      Would you mind going back up and read my comment again about water and wetness? So that I don’t need to repeat myself.

      Finally let me ask you something:
      Where were you, when all distros used sysvinit, which was slow and antique, and useless for many things? It had so many problems and bled from so many wounds, it was amazing it could still be held together. Yet you and other vocal advocates of “systemd is the Devil’s work” have been nowhere to protest all major Linux distros having opted for sysvinit. It was forced on you, the same as systemd is “forced” on you now. Why did that not hurt your eye? You’ve been using it for years. Maybe it was because nobody old you when to shout? Maybe because nobody told you it’s supposed to be bad for you, so you did not mind?

      In conclusion:

      The article was for the Linux user wondering what the heck is the hype about.

      The short answer is:

      Not much, your Linux distro is just functioning somewhat better but there are a few know-it-alls who think they are cool, ‘coz they want to differ. But the are not cool. Neither are they different than all the others whose mantras they repeat. That’s it.

      As always, please let me know, if you have any further questions, or if you still don1t understand something, so I can explain/help. ;)


      Before you mention it (again), this reply was meant to be as arrogant as it could be. See, this is arrogant, not my conclusion. Your comment was a nice try in being arrogant, bit I think I just beat you to that. That as well, I mean. ;)

    2. (By the way, thanks for reading through my answer, if you did. I could not possibly read it myself)

      1. 1. Methinks you protest too much. At present, I am neutral because I do not know enough about systemd to make an informed decision. Unless your attitude is that since I did not instantly fall in love with systemd, I must be against it. You sound like one of those Windows fanboys, If you don’t love it, you must HATE it.

        2. There is no danger of anyone mistaking you for a journalist. :-)
        ” If you want to see an article about the downsides of systemd, or one that warns people of this great evil, you are welcome to write one.”
        Silly statement. If I knew the downsides of systemd, I would not be asking you about them, I would tell them to you in no uncertain terms.

        3. No, not TOO arrogant. Just because YOU do not use antiX or MX-14 does not mean that they are any worse than anything you do use. We each choose to go to hell in our own way.

        4. Sorry to break it to you but I never claimed to be and expert. Neither have I bashed systemd. You are making a lot of assumptions and we all know about the “assume”, don’t we?

        5. ” “systemd is bad for you””
        Prove your point. Show me where I said that, or are you assuming again?

        6, 7, 8. Please don’t ascribe statements or sentiments to me that I did not express. Do not set up straw men.

        “This also proves that you don’t understand sytemd.”
        I don’t and I never claimed to. I saw the title of the article “Systemd – What You Need to Know” and I expect to be informed. Unfortunately all I got was fanboi propaganda.

        “As always, please let me know, if you have any further questions, or if you still don1t understand something, so I can explain/help”
        I think I’ll pass. It is obvious that you either don’t know the answers or are unwilling to answer honestly. If systemd is so great, why are you afraid to mention its shortcomings? And please do not say it does not have any. ALL software has shortcomings.

        1. The short version:

          1, Partly

          2, Yes

          3, Right

          4, No?

          5, No

          6, 7, 8, Yes I will, and you cannot stop me.

          The long version:

          1, Of course I do, i am a natural born protester. my ancestors were protstamnts. protest is in my blood. As to your “windows fanboy silliness, I take it for b..thurt is flowing through you and making you write these things. Anyway, if you were not against systemd, you would not protest it and talk about “systemd-free distros”.

          Or, you need to read more carefully: The article was not about “new init processes” or “systemd and alternatives”, or even “an unbiased look at systemd. No. i clearly said I am all for systemd. Even if you don’t like it,. And guess what i wrote an article from this viewpoint, protest all you like. :) BUT, there is somewhere deep inside the text, a link hidden, that brings you to the “living without systemd” website, that will list you all its alleged disadvantages, AND another link with the answers to these. So it’s all there, you see, but you need to really read before you 2assume” something’s missing (you can find them in the “controversy bit”

          As for your own standpoint: from some comments you make on this site, I sometimes think that you are against. Does not matter what (with few exceptions).

          2, I was seriously hoping nobody would mistake me for one, I don’t like journalists much. of course the statement’s silly. I am a silly person. I like being silly and make many silly statements. All day. Every day. I like it this way. Anyway, i must have missed your question “Can you tell me about the downsides”, but only have seen your accusation” Are you saying there are no disadvantages?” Maybe you need to work on your asking style. it comes through as cynical. And to cynicism, I have only one answer: Silliness. If you were not cynical, too bad: I am still silly.

          3, Not TOO Arrogant? Too bad. Then I need to work on my arrogance though. I was always quite proud of being more arrogant than anyone else. i think I still beat YOU to it, which gives me immense satisfaction.

          To address your silly statement (yes you make those too, not sure how intentionally though), I never said anything against either system you mentioned. i only say, those who use them will not be better or know more than say, an Ubuntu user. Personally I quite like antiX, but for practical purposes, like working and juggling daily tasks Debian is the choice of distro. I might even make an antiX review. Soon. I will dedicate it to you. the featured image will also have a dragon in it, hidden somewhere, If you can pick out its mouth, I will applaud you loudly and will confess that I am a Windoze fanboy.

          4, You don’t? Well, you often come off as a know-it-all, anyway. I’m happy for you not bashing systemd. You should try it. You might like it. It’s really quite tasty and only slightly addictive.

          About assumptions: i make assumptions all the time. i am a big assumption. Sometimes I think the world is built out of assumptions. guess what, i like to assume things. Too bad I cannot take it when others assume things. I assume so anyway.

          5, No I don1t need to prove anything. You see I stand on belief. I want to turn systemd into a religion

          6 – 8, why not? it brings the conversation forward, otherwise it would only have remained mindless ramblings and talking vaguely about somebody being too pro-something (although we would never have known why that was wrong). It spiced it up, quite a bit, didn’t it.

          Now to the questions: You did not ask anything, how can i answer (to other questions, there already are answers, see no 1 above)

          I tell you why I’m afraid to mention ts shortcomings: I’m afraid the world will finally discover that systemd is wrong. that it is only some mad people’s attempt to take over the world 8such as myself). You see if I disclose my agenda, before I seize power, i will never get there. i need people to blindly follow me and my new religion I’m about the start. that’s why.

          Any more such serious questions? O yes, about its shortcomings. See my answer number 1 for clews about links in the text…

          “I expect to be informed.” – You can only be informed, if you can really read a text and not only fin the propaganda bits you dislike, bit the information you are looking for. It’s all there, what you need to know, What others need to know, well, that’s a different question.

          Anyway, I like propaganda. I want to move into government propaganda-writing, hopefully into some nice little dictatorship somewhere in the Sahara. I consider this as my training

          9, thanks for proving Luke Jonse’s point (Comment below yours)

          10, As always, I am still here to clear things up, if you still don’t find some answers. if you still feel confused, never hesitate to ask. :)

        2. It’s something of a telling sign when so many systemd advocates are so defensive and bullish when they are attempting to convince others. For those of us who just want clear, unbiased information without some kind of sales pitch it is somewhat revealing that if systemd is indeed a solution to (what some perceive) to be a problem, there’s an awful lot of controversy behind it.

          1. Wrong. He was being personal. calling out names like “Windows fanboy, etc. I am not defending systemd, I am writing against a person, whose comments on this site are usually that of “what you write makes no sense, I know better”. Mr Mouth has quite a history. And his “questions” (which were not), add nothing to the discussion. Look below, there are real people, with real thoughts, not only some bitter keyboard warriors, who comment on everything, but appreciate nothing. my bullying is an answer to cynicism and arrogance,.. only I do it better. Again, for a real discussion, read below. if you dare to face your own views being confronted. :P

          2. And “for those of you who just want clear, unbiased information”, let ,me say this much: There is a link in the article that takes you to the website that made it its mission to rid the world of systemd. they have all the information you need, to know what might be the shortcomings of the init system. to keep a balance, I have also linked to a site, that takes common systemd “myth” and explains them properly. The conclusion (your own conclusion) is up to you. but the article’s conclusion was up to me, and I havw clearly chosen my side already (without choosing sides, really, I have nothing against other init systems, or even sysv, but see its shortcomings, that is all).

            I think that is plenty of unbiased information right there. The point of the article was different: if you are on a mainstream distro, and are going with a never release, you ARE on systemd already. I wanted to explain what you can expect out of it, that is all. if you want unbiassd discussions… well you are right there are not many. I might as well make one up in the future, but this piece was not about that.

          3. “It’s something of a telling sign when so many systemd advocates are so defensive and bullish when they are attempting to convince others. ” that is probably because so much cr*p is posted about systemd, what it is, what it does etc The developers had to post this because of all the cr*p

            “For those of us who just want clear, unbiased information without some kind of sales pitch it is somewhat revealing that if systemd is indeed a solution to (what some perceive) to be a problem, there’s an awful lot of controversy behind it.” Here’s a place to start reading

  2. I really absolutely do not understand the attitude many of the anti-systemd proponents have taken.
    Half the time it sounds/feels like they are just jealous that Lennart managed to do what he has.

    The *only* valid criticism I’ve heard is about binary logging. And to that I say; binary logging offers much more powerful logging and diagnosis, over and above plain text logging.
    “oh but it might get corrupted”
    Yeah? So can plain text.

    Systemd is pretty darn good, and it’s fast, easy to use.
    I’m damned glad the major distros have adopted it.

    1. I did not understand binary logging either, until I read what it can do. I’m still not entirely sure about it, perhaps there would have been a better implementation/or way to achieve similar functionality, but that is way beyond my knowledge/expertise so I’ll be no judge. Systemd’s binary logs are powerful, and that’s a fact. So yea, I pretty much agree with you.

    2. I used to be against the binary logging. However systemd does not force you to stay with journalctl. You can actually have journalctl send to syslog locally or to a central syslog server. also you can still use tools like grep / sed / awk with journalctl.

      I think my only reservations to systemd would be that it is a framework versus just a simple init system. While I have no proof only theory, It would be disasterous if there was a major failure and systemd could possibly bring down the whole system because it in a ways controls other processes. However I would think this could happen with sys v also.

      Again that is more of a fear with no proof just something I have pondered on. Not sure if it is possible or even efficient but it would have been nice to just keep the components separate so that a failure in one can’t spill over and would be easier to troubleshoot.

      However one extremely valid point you made was how much is this truly going to affect most people. In my 12 years as a linux admin / user I can count on one hand when I had to mess with Sys V to go outside of the norm.

      — sorry if I hopped all over the place. I tend to do that with my ramblings.

      1. Thanks for the info, I did not know that about journalctl. It makes systemd’s journaling even more awesome in my eyes. :)

        I don1t think the disaster scenario would really happen. i mean it is a framework, but not like “failure would spill over”. there are sixty odd binaries, that means proper separation. there was a great article somewhere (linked in my article), that actual explains how the separation works, there is proper isolation (probably even more proper than in sysv). So the components ARE being kept separate, this is one thing people misunderstand about systemd (possibly as a result of so much anti-propaganda): Mark Shuttleworth of Canonical once called systemd monolitic. People have been echoing his view ever since. the thing is, Canonical actually moved towards systemd. And Shuttleworth has changed his mind about the monolithic thing, since an answer (and explanation) was given to what he mistook for a monolithic init system. problm is, that people only listen to thesensational news (Canonical bashing systemd), and rarely follow up (Canonical actually acknowledging its error, and even adopting systemd).

        I don’t mind your ramblings, they add to the discussion, so please ramble on. :)

      2. I think your find you’ll need to configure journald (via journald.conf) to forward logs to syslog/rsyslog. journalctl is the powerful beast that allows you inspect the logs and you can also pipe its output into grep/awk etc. journalctl makes the binary storage of the logs appropriate.

  3. Arrogance aside….

    Why fix what isn’t broke? SysV init work perfectly fine by me. I prefer the slow boot process and keeping everything SEPARATE (configs, logs, init scripts, etc.)

    Personally, I’m leaving all my servers / linux workstations on CentOS 6.6 as long as possible. I’m hoping by then, CentOS or another distro will have a competing init system to systemd. Maybe I’ll even get lucky and a new distro will come to life using SysV init.

    Only time will tell. In the meantime, I like keeping things simple and separate.

    Seriously people, we worry about boot times? Tell the manufactures of the servers to fix their blasted long dang hardware boot times. Those take by far longer then it takes SysV init to boot.

    1. My arrogance is only a hobby. (But thanks for the recognition, I work hard on it.)

      Hobbies aside, I think you don1t quite grasp the scenario. This “why fix what ain’t broke” is a commonly repeated argument, but I don’t think you guys reciting it, did really think it over.

      SysVInit is not borken and systemd is not a fix.

      if it was broken and a fix was to applied, that would mean a bew or improved init binary in sysvinit fashion and probably some new or improved scripts. We have seen both happen, it happens all the time, with all software, when a version upgrade comes up, that contains bugfix. If you fix sysvinit (as some system upgrades already did, probably without you being aware, you can just check the version history), it does not get replaced.

      Systemd is a replacement. It’s a whole new init system, that doies not aim to fix what is broken in sysvinit, but to provide an alternative.

      The difference is as big as between building a house and learning to swim, if we move away from IT. In more Linuxy terms, think about it as installing a new version of say OpenOffice, with bugfixes (fixing), versus installing LibreOfice, which gives an alternative (replacing): this does not mean OpenOffice is broken. it means now you use something else (LO), with similar functionality, which probably works better for many things.

      As to why it was necessary there are some hints in the article. Sysvinit is outdated and works in a less then satisfatory way. For example, you can have your processes started then just being forgotten about, as sysvinit does, or track your processes and be aware of their state, as systemd does. it is a matter of preference, but the latter approach will offer disctinct advantages over the former.

      Take the “kill” systemcall for example. In UNIX, it is doen by a signal 0 is sent to the processes. if the PID that was being signalled is not associated to a process, the kill call will just fail (besides just sounding funny to say kill call. Try repeating it: kill-call-kill-call-kill-call. Funny, ain’t it?)

      Now, in sysvinit, the processes have to daemonise themselves (see article). besides this being long and cumbresome (a 15 step process, link in article). This makes little sense on its own, but also results in the init system having no idea of the PIDs associated with the processes.

      There is a workaround for this of course: All processes will have to write their PIDs into the PID file, so that sysvinit can read it an send the 0 signal to the appropriate process. Besides being a workaround, and workarounds indicate poor design choices, there is more to the problem than this:

      There is no guarantee, that the service in question is still running! If the process, originally started by an init script, has been terminated at the time, the kernel could have reused the PID and given it to a different process entirely, this could mean the wrong process getting killed!

      Of curse there is a workaround for this, now being the workaround of a workaround: Besides checking the PID file, /proc/$pid/exe also needs to be checked, if the PID stillb belongs to the correct process, after which the 0 signal can be safely sent.

      Now, you see a simple thing like killing a process requires a workaround, nested into a workaround under sysvinit.

      (And you know what happens if you nest to many workarounds? There will be a singularity, where first Linus Thorvald's head explodes, then he gets merged with Bill gates and there will come a great new monster, nobody dares imagine! Quite fortunately, you only needed to nest two workarounds for this simple task…)

      Anyway, would it not be better if the init system knew the PIDs of services AND the state of any given service? And its dependencies? Systemd does… So killing a process means simply killing a 0 signal to the right PID, without having to cross reference with Encyclopedia Britannica first. just so much more simple.

      And this was only ONE of the many workarounds and shortcomings in and of sysvinit. Juts one simple example. there are many more. Systemd does not fix this, but replaces some poor design choices, not intended for modern Linux systems, with better choices. probably not perfect ones, but better ones. the thing is sysvinit might have been a great init system 30 years ago, on the then contemporary UNIX systems, but today, the systems have evolved, dragging with them sysvinit and patching it up as they went. There is no need for a fix, but a replacement can have many advantages.

      As for slow boot process: systemd is not about speed. Speed enhancement is an effect, but not a goal in it (pun intended).

      About "keeping everything SEPARATE"… again, a mantra. i really wonder how people get to repeat thing without even bothering to read up on it first.

      Consider thes lines from the original author of systemd:

      "If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons.

      Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries are separated out so nicely, that they are very useful outside of systemd, too."

      Now how is that not being separate? By logs, if you mean the logging is binary, that is true, but it does not mean that it is not kept separately. I recommend you read sytemd's documentation to have a better understanding of how it works.

      It is an alternative, not a fix. It offers improved functionality. Sticking with sysvinit, is like sticking with your Commodeore 64 word processor, when there is MS Word or LibreOffice available. You can do your work with it, but the others are more modern and offer better functionality. Of course one who does not take the time to give them a good look and read up on them or try them will say, that they are bloated and that the Commodore's solution is so much neater (see my previous article about distraction-free writing apps, there are some examples of works by such people IRL. Without prejudice of course.)

      And again: systemd is not abut boot times. Faster boot is only a nice side-effect to have. And I don1t think server manufacturers are interested in boot time improvement, as servers shld (ideally) be restarted only scarcely. For Desktop users however, boot times can make a massive difference. Still, it is not the point of systemd at all.

      There are many distros that still don't use systemd, of course, but mainstream ones seem to have adopted it, so systemd will have at least a few years run (as long as Debian stays on it, most derivatives will as well). if any new distro is to emerge, it is probably best not to revert to sysvinit, but go with an alternative, be it systemd or anything else (many were mentioned in the article). Systemd is so far the best replacement. if all goes right, it will be an inspiration for developers to create even better ones. the way to go is ahead, noit backwards, in either way.

      Finally: Can I ask you the same question i faced the mouth of th dragon with, above:

      What exactly is your problem with systemd? From personal experience/understanding, besides ani-systemd propaganda, of course.

    2. Wow, I made a typo ins closing the code block and look what happened. this is, f course sysvinit’s fault too! :P

    3. You should really set up a test server with systemd and use it for a while. Yes, its a learning curve but there are lots of benefits especially when you’ve used journalctl a few times, it will save you loads of time in the long run. The faster boots are a side benefit, not the reason but it helps those that have to reboot instances of VMs when boot time is “expensive” if its slow. You shouldn’t just dismiss it because of a few anti-posters who post things about systemd that are not correct and downright lies.

  4. Wow! This is one of the most informative and sane articles about systemd I have ever read. Thank you.

  5. Just a little comment about those claiming systemd is huge and monolithic. I’m not sure where you pulled your diagrams from, but the one diagram is not correct. “systemd pid 1” does not contain logind, journald, networkd, user session. pid 1 contains systemd only, which is very small and minimal functionality.. PID 1 is very special in unix and has special powers. The less that runs in pid 1 the better. Systemd critics often say systemd puts everything in one basket. It does not. logind, journald, networkd, and “user session” are all other daemons that do not run in pid 1. It’s true that systemd requires journald to be running. But all other parts are strictly optional. And some parts like networkd only are useful in limited situations like containers, as is the name resolver daemon.

    Really systemd is just an umbrella project for a number of optional services and daemons that can work together, that are increasingly important in many apsects of modern Linux use including virtualization, containers, servers, laptops, dynamic storage systems like fiber channel, usb, etc, situations where traditional init systems were really not handling well.

    1. Hy,

      Thanks for the addition. I’m sure those claiming it to be huge and monolithic simply don’t quite understand how it works. pőeople confuse init as in PID1 , and init as in “init system” (that is all the separate scripts and binaries), and by only repeating what they read on forums, without giving it consideration or thought, they make the mistake of calling something huge in the wrong way. I would call systemd huge (as in the whole of it), but it’s rather huge in a way you’d call it robust, than monolithic (which it is not).

      I’ve just noticed the mistake you’ve spotted on the diagram. it comes from Wikipedia (did I forget to put in the image credit? ma’ bad). You are right, it is wrong. Anyway, it was meant to illustrate how processes can run in their own safe containers. Of course misinterpretations like that will not do much good for the reception of systemd, even though the intention was good. I might just alter the image later, so it won’t give the wrong idea abut PID1. (If I will have the time). until then, hopefully people will read far enough, so that they will see your comment.

      Thanks again for reading, and for the valuable input.

  6. Systemd vs other init systems… It’s like emacs vs vi.

    Right now the only things an “average” user will notice are their computer booting faster, and more compatibility between distributions (meaning more software will be packaged for all popular ones instead of for one or the other). These are good things. In the near future, they will notice something very different…

    I expect there will soon be dozens of new init systems (and I’m guilty of contributing to that problem – I’m writing my own). This may not seem like a bad thing, but it is. You see, many “average” users of Linux rely on their friendly neighbourhood techies, and many (like at least 10%?) of those will say “sorry, I can only help if you use [non-mainstream distro with preferred obscure init]”.

    This is caused by a lack of trust in the systemd developers. Part of that is because of memories of pulseaudio, part is because of having had to deal with systemd too early on a bleeding edge distro, part is because of other distrust in redhat/gnome, part is because of the appearance that the systemd developers do not have a plan and are just modifying whatever they get their hands on in ways that do not make sense, and then there are the technical reasons that make systemd look like a bad design (and I’m not going to list those because everyone thinks the sets of good and bad features are different).

    So, being a programmer, what does one do? Continuing to use sysvinit is no real option now the flaws have been pointed out, systemd is not an option if you wouldn’t trust the developers to fold a functional paper airplane, the other inits are okay (I like runit and s6) but not quite good enough now one has been thinking about how init and daemon supervision should work… Yep, one writes their own, incompatible with all the other ones by people who went through the same thoughts.

    It would have been better to leave well enough alone. Sysvinit was booting our systems well enough, I never saw any complaints except from the “faster, faster, FASTER” hobbyists and the “not invented here” of Canonical. Now we have a moment of slightly more standardization, before Linux will once again justify its reputation among non-technical users.

    In summary, the biggest problem with systemd is that some of the people who provide free tech support don’t trust it. More than any technical details or the fact mainstream distros use it because it’s less work than not using it, that is “what you need to know”.

    1. I cannot agree there. First of all, Linux is about choice, as it always was. That said sysVInit having been the “go to” init of most distros did not seem like a choice at all. Systemd now being the “‘one” does not seem like much of a choice either, so probably more inits popping up can be a good sign Think natural selection: Only the really worthy one will survive.

      But developers are making up their own inits at every corner(and no disrespect intended to you), seems a but like an systemd hysteria. Those custom inits might work for them and a small community, but to gain mainstream traction, they would have to be embraced by one of the big distros. This is not likely to happen. and the hysteria will either slowly subside, OR, which is the better scenario, takes a more meaningful form, like that of community built inits, that are a collaboration between people, not individual efforts. To me the latter would be the best possible path.

      That said, systemd is here to stay and will be on many systems for a while. Debian i now on systemd, That mens a very large chunk of the Linux world (all derivatives) willbe on it. with fedora (RHL)Ö and SUSE also following suite, systemd is ALREADY the most widely used sysvinit replacement. Such big dristros often move slow (think Debian) and their decisions are not easy. Also Debian means business (see the link about their systemd discussion), and is likely to stay on systemd for a time to come.

      the way I see it though, and this is where we agree, is that systemd started something: People realize there is life beyond SysVInit, and that is good. Every beginning is difficult, in my view, with this move, Linux just matured to the next level, and made itself even more distinct from its UNIX ancestors. I take change for a good thing. And it is a prerequisite for progress.

      1. Choice is good when it means that if the default is bad, you can use something else. Creating more bad things to choose from does increase the amount of choice but is not helpful.

        Change is something that happens in immature systems. Sysvinit is very mature, obviously. Systemd is not, and while I would have enormous respect for it as a research project, I do not think it belongs on computers that people use for their daily boring work. All progress is change, but for use cases where no further improvement is possible, any change is a potential regression. Besides booting a few seconds faster (which can also be achieved with less invasive changes), is there anything to be improved on for an “average user” currently using sysvinit without even knowing that software exists? Well, their computer boots every time they switch it on, doesn’t it?

        Systemd might be “here to stay”, or it might disappear in a few years. Remember static /dev? Got replaced by devfs, which then together with hotplug got replaced by udev, and if I understood correctly udev as part of systemd will now get replaced with something else. Meanwhile my OpenBSD* system has static /dev and a simple shell script that processes events caused by plugging/removing hardware, and that works just fine. So what exactly was all this complex software passing through Linux good for? It seems to me that only simple solutions that work well tend to stay around for a long time.

        The situation with all those mainstream distros providing systemd is like… all car dealerships have switched to selling the same futuristic self driving race cars, which seems great, until you notice they’re made by Lada. Who knows, maybe Lada has learned how to make good cars, but I’d rather wait and see than buy one today.

        Are small community distros with community inits taking some of the marketshare of the big distros a good thing? In some sense, yes, because there will be more developers listening to users instead of getting wrapped up in silly politics. In another sense, no, because they’re a step back in maturity for Linux as a whole, and because of all the extra incompatibility.

        I think frustration about software maturity might be one of the deeper causes of the arguments about systemd. Every time Linux based operating systems begin to work reliably and predictably, someone influential causes large changes (see also: KDE 4, GNOME 3). Oh well, maybe it’s fair that people who are more interested in having software that is known to work than in what’s new and exciting have to contribute more effort.

        *) I use Linux because of hardware compatibility issues among other reasons

        1. I think we are mashing things up a bit there.Tthe average user will in the longer term benefit from much more reliable systems, that can and hopefully will be developed with moving on from sysvinit. It was mature, yes, but maturity is only good as long as it does not hinder progress. Sysvinit did. Its design was due for replacement. (i wrote all my arguments down about this already, either in the article or in comments somewhere around here).

          AND, this is very important, it is not a case where no further progress is possible. mature as it was, sysvinit was far from perfect, as far in fact that it bled from many wounds, which only the continuous patching up of things couldf cover up. Yes, you can apply as many patches as it finally builds a robust whole, but how about having robustness by design?

          Think of the simple example of sysv not knowing PIDs and states of processes. how many rounds did it have to run just to kill something? Why waste time, and development time on forcing processes to daemonise themselves, etc.?You seem to glorify sysvinit far beyond its merit. it worked yes, but it did not work ideally.

          I don’t say systemd is the ultimate solution. I say a change was necessary and we see things moving now. This way either systemd, or anything that comes after might get the time needed to mature well. Anyway, I don’t see why systemd was so harmful or bad. I have not yet seem any discussion form any systemd “denier” that even made sense for the interpretation we see today.

          Your arguments are more reasonable than of those saying “bleeeeh, systemd”, so I would really like to know why you think it is not worth using. Why would it not have its place on workhorses? it does have on mine, and no disappointment (I had much more problems with sysv systems, and even with the OpenRC of Gentoo)

          I can see where you are going with frustration about software maturity, but I could not agree those, who shun systemd for this simple reason. You see progress is only achievable by change, and we all crave progress. Now the problem is there is a simply psychological factor of resisting change and sticking to the well known (which gives a sense of security), with everything in our lives. This is how our brains are wired. I see much of the resistance stemming from the fact that it is really difficult to ditch old habits (a 30 years old habit to be precise), even though they might harm you (ever tried to quit smoking?)

          To me, it looks like systemd is not a new project. It has been around for time enough for people to start adopting it in daily use. This is reflected by Debian’s decision, and they did not just jump into it, but made their case rather clear (link in article). And this (active usage) is the only way for it to gain true maturity. There will come a time when I would advocate upgrading your servers too, but only if we do give it not only time but a chance as well. I uses it for many months with no problem whatsoever. my PC (that takes quite a but of beating, from wild O/C to demanding usage), is more stable than ever.

          Finally: it is funny that you point at OPpenBSD, then point out the very reason why maturity does not equal usefulness. You can say openBSD is mature as a whole, but its use severely limited by hardware compatibility, etc. in a real world scenario, one must take more than one side of a story into consideration, and in my view, systemd achieves this better than sysv did.

          1. Process supervision (“knowing PIDs and process state”) is a neat feature (that I will definitely implement). It has also been around for a long time, most famously in daemontools and its near-clones like runit, s6, etc. One didn’t even need to replace sysvinit with those to get it, it’s possible to do the first steps of booting and if one wants also the starting of some daemons with the old init, then use the daemontools-like to supervise (the rest of) the daemons. Furthermore one could easily implement the “difficult” daemonizing process needed by sysvinit by copying one of the programs from a daemontools-like and wrapping it in a trivial shell script that’s much simpler than the shell scripts you usually see packaged to be used with sysvinit.

            So, if process supervision matters in the real world, I wonder where all the runit users and daemon developers copying from runit are?

            I really liked Lennart Poettering’s early blog posts about systemd, very interesting. I did not like systemd very much when Archlinux started telling users to migrate to it, for the simple reason that it would not work for me. Or perhaps there was something wrong with the documentation, which of course leads to the same result as a bug in the software itself. It was a big step down from the easy to understand configuration file Arch had before systemd. Before that, I remember fixing sound issues on multiple systems by simply removing pulseaudio (also made by Poettering). More recently, there was the issue of Kay Sievers refusing to admit for a while that systemd DOS-attacking the kernel was a bug, Linus Torvalds had some nice words to say about that.

            I’m willing to believe the problems with pulseaudio were caused by its features exposing bugs in ALSA. And now it usually works flawlessly and is very useful when you have a usb headset, so it belongs on *some* peoples production machines.

            Systemd-init could be similar, maybe it is stable and correctly documented now, so it could have a place on the computers of some people who want some of its other features in addition to process supervision.

            Systemd-the-bigger-project however is in a state where big changes are still made. Since it’s developed by people whose past software has SOMEHOW ended up in “stable” distributions long before it stopped being broken, I would not trust it. If it works for you and continues to do so through all the changes that are still coming, you’re lucky.

            Many people will be lucky, some won’t. Since the problems it solves appear to exist only in theory for most users, why risk it? I know why many mainstream distros are risking it on behalf of their users, it’s part convenience and part the love of cool features. I guess it’s difficult for geeks to pay attention to more social aspects like the reputation of who is upstream. Or perhaps they don’t care what breaks as long as it’s for a minority of users, I wouldn’t be surprised.

          2. Reaching the end of nested replies, no button appears… here there be dragons. :D

            I’ll keep it simple this time, lest we break the universe (also I have other things to do, this article is getting out of control.) :)

            Ifprocess supervision matters? I don1t see why it should not. The “solution” you mentioned was only a workaround. patches and workarounds don1t mean a solid base, they indicate a base full of holes that needs to be patched and obstacles, that need be worked around. It makes sense top part of the init IMO, and I don1t seem to be alone with that.

            As for said developers, they did not seem to have the traction Poettering collected over the years. Pulseaudio surely worked in his favour: people do listen tp what he says, whether they agree or not. :) Not a little political. But if you ask me, he is using this very smartly.

            But all in all, I was expecting somewhat more “concrete” answer as to what might not work. You say things will or could break. What thing in particular? How and why would they break? How can you tell, they will break? aAd why did they not break yet? Or if they did break, what were they, and why are they not breaking now? in short: What would prevent the Average Linuxuser Jane/Joe from using a systemd based distro for daily work? in practice. Everyday practice (not theory or probability).

            Assigning a worting system to sheer luck is like believing in magic, sorry, but I don’t see myself “just lucky”‘, for not having had to touch the init, since I installed Debian. Compare this to the two weeks tweaking of my latest Gentoo, after which I still ran into problems. I like tweaking, but these days I focus more on writing (on this site, and other projects), I have little time for it. Debian “just works”, and I’m not the only “lucky person”, there are a few million others. by the numbers you could just say, if something breaks, the person is unlucky (or screwed something up big time).

            It seems to me, that you are evaluating systemd by the earlier interpretation pushed (foolishly) by Arch and Fedora and other “bleeding edge nonsense” distros (sorry, I don’t take “bleeding edge” for a good thing, unless it is kept for purely testing and not made into systems people use for daily work. Even as a former Gentoo enthusiast.). And in that you might be right, when Arch first made people switch, it might not have been all ready, and probably even caused problems.

            The thing is though, today is today. And today we see even the slow moving Debian making the switch. As for how much it is for “‘convenience”, I believe Debian has made their case:

            You see, there are a lot of smart people out there who have evaluated systemd already, and even tested it. Debian is notorious for testing, if something makes it into stable, it usually means stable, as in STABLE, not always, but most of the time. My experience shows Debian 8 is as stable as any previous release.

            For Canonical’s convenience take their initial opposition to systemd. They held out for a while, even fueling some of the misunderstanding (and plain old BS) surrounding systemd, then they just changed their minds.

            in either case, “convenience” would usually mean sticking with the old, tried and tested, instead of risking to break things and needing to work on fixes. That is in no way convenient.

            For your pulseaudio analogies, I understand your parallel, but things like “fixing sound issues by simply removing Pulseaudio” is like the surgeon healing the patient with simply removing the offending non-vital organ. It’s a shortcut, not a real solution, now is it?

            And, for all that evaluating a piece of software based on its author’s previous work, and the controversy surrounding it), does not seem like a good (or sane) practice. IMO SW should be evaluated based on its own merit (besides you were willing to believe pulse’s problems were in fact ALSA related… which leads us to the more philosophical question:

            If a SW exposes bugs in other code, making the system unstable, whose fault is that? The new software might bee seen as the offender. old mature code has been siting there, silently nursing its bugs, before it was exposed by the newcomer. And what do we do to fix it? Remove the offender and close our eyes to the underlying problem (the bug). If it’s not exposed, we do not see it. If we do not see it, it cannot hurt. But is this a long term solution, or a quick patch? I mean the true offender is still the old “mature and stable” piece of software, whose bug”s) we were blissfully unaware of. now our world has been disturbed by something new: we blame the new, as we are used to the old. (the human psyché resists change with all its might, it is just psychology, but I think i wrote this already down somewhere here.)

            What I mean to say is, it is possible that using systemd will highlight other problems too. Perhaps it will be worth evaluating any instabilities apparently caused by it, to find the root of a problem, it can only result in improved systems. BUT: You have not mentioned any concrete examples. (The bug you’ve mentioned was, if I’m correct, already fixed. Sievers’ reaction was unfortunate, but that still is just a single person). You’re right the future might hold anything. but the present is telling (Things seem to “just work”. Of course systemd is worked on still, but “stable” distros (Debian-like stable, of which there are few, really) will not take on changes as soon as they are released. Which is a good thing. Ads for other distros, who care little about the stability and rush to offer flashy new things just to be in the “news”… it’s the distro maintainers’ fault rather than systemd developers, if you ask me. In the meantime, I’m happy with the way Debian operates (although they were said to switch to higher gear with new version coming more often, of which I’m uncertain, but besides cooking your own distro, to which I still don’t find to time, there are not many good alternatives (please let me know if you know some).

            Anyhow to me the final word about systemd came from Thorvalds himself:

            “I don’t actually have any particularly strong opinions on systemd itself. I’ve had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.”

            Khm. “details, not big issues”. And here’s what most people get wrong: they grab onto the details, to justify whatever minor objection they might come up with against something that, in face of all the hype and anti-propaganda, seems to work just fine.
            on a side note: I’m becoming interested in your init system, perhaps you can give me a shout when you are ready. You seem to be more reasonable than most developers I’ve worked with :D

            PS: Sorry i promised to be short. just does not seem to happen…

      1. Why can’t I do “M-x C-y bootsystem” yet? Seems like some vital functionality is missing from emacs! :^)

  7. Systemd is for early adopters and needs users. SysV init works just fine. Hopefully Systemd will prove its worth after 30 years of use (like SysV init has). I’ve read enough arguments to have formed my own opinion… it’s time to be respectful.

  8. I agree and disagree. Systemd WAS for easly adopters and needs users. now it’s THE mainstream init system for new releasse distros. All major base distros have switched (Debian (Ubuntu), RHL (Fedora), SUSE). In a few years systemd will rule the Linux scene (by way of taking over mainstream distributions), and not upgrading ones system just to stay on sysvinit sounds silly.

    I agree, hopefully systemd will prove its worth, but I personally find it highly unlikely that it would stick around for so long, neither would it need to. the way I see what is happening, is that systemd has opened up some eyes. people start to see that there is life beyond sysvinit. Systemd is a start. Now new init will pop up (probably more serious attempts than anything previous). And new inits can learn from the systemd way, inasmuch as it has fixed some problems found in sysvinit. they might not follow its design, but they must do better than systemd, to be able to gain traction. We, the users can only win.

    Personally I would like to see a community developed init system, and an option to choose in a straightforward way (like at install (time), instead of being told that “if you want this distro, you’ll use this init”, as we see on mainstream distros (not talking about the more flexible ones now). That is a long way away, but there is hope yet.:)

  9. I’ve noticed Debian 7 with systemd boots slower than with SysV. It also tends to experience odd slowdowns and ‘glitches’ at times that don’t happen when not running systemd as pid 1.

    I don’t care for systemd. I also think binary logging is a colossally stupid idea, and having higher level software (like Gnome) depend on a specific init system like systemd is ridiculous. Tightly coupled software is bad design, period.

    1. It might, i could not tell. Debian 8 is out, if you’ve noticed. For quite a while too, and this is the first Debian “officially” built on systemd, so if you want a stable systemd experience, you should rty Jessie. Since I upgraded my work machine boots approx 3 times faster, which is nice. Yet systemd is not about speed… (This has been discussed here so many times, that i am most reluctant to repeat it. I rather fill the space with a meaningless string of characters which you are reading even now.) :)

      I perfectly understand though,. that you personally don’t care for sysrtemd. I would not have if I did not change to Debian (used gentoo before, that means I did not care for sysv either). As I’ve learned from a comment above, binary logging is more verstaile than it seems, and does not need to be “kept binary”.

      As for GNOME: I have good news: You don’t have to use it, there are plenty of other DEs that don1t depend on systemd. But this is GHNOME’s choice and not systemd’s, so the argument is somewhat (a lot) out of scope. Still I get your meaning, only I don’t mind GNOME using a framework. You know it’s a framework right? From there on, saying, higher level software using frameworks is a colossally stupid idea reeks of not understanding software: But let’s not go into that. You’ve made an even more amusing remark there:

      “Tightly coupled software is bad design, period.” – I assume you do not you use a Dektop Environment, an Office Suite, or anything built on e.g, GTK+ and/or Qt etc. You must be using individually developed applications, that struggle to interact with each other, because of the stupidity of tightly coupled software. :) Your PC must be really unique (bjut your life rather difficult). As for what design choices are poor and which ones are good, a previous commenter already suggested that it’s so subjective, it could change by changing perspective.

      But let me say: talking in the absolutes about almost anything is a poor choice of words. Period. :)

      1. “Tightly coupled software is bad design”
        Tightly coupled as done by *buntu where every app is tied into the “ubuntu-minimal” package. Any attempt to remove software such as “cowsay” or “fortune” or unneeded language packs results in the removal of “ubuntu-minimal” and disabling of the system.

        1. That is (the ubuntu-minimal METApackage) a question pf packaging and has nothing to do with what frameworks are used by the software in question! It’s like comparing development with marketing. One can live without the other, and they could be used together in a poorly designed, binding fashion (as is the case here).

          GNOME does the same thing (poor packaging choices), but this does not mean the packages that are bundled together the same way, as for example GNOME depends on systemd! The two mean very-very different things.

          Still gnome’s own components, that work together to create a consistent desktop environment (not like the meta-packaged libreoffice, but like gnome’s core component)s are tightly coupled, which absolutely makes sense. In this same case you see tight coupling by good design (gnome core), and bad design (libreoffice), in the SAME meta-package.

          Ergo: Tightly coupled software is not bad design. Only bad design is bad design! I still say, talking absolutes is bad design (of words).

        2. And, in case you did not know, the removal of fourtune will make you head implode. It is said to be the most dangerous mistakes single man can commit! No wonder it was packaged into ubuntu-minimal…

      2. Actually I’m a long-time developer and don’t suffer from “not understanding software”.

        I said nothing about not using frameworks, my gripe with Gnome (which I no longer use) is about depending on PARTICULAR pieces of software.

        Tightly coupled design IS bad design. That is in no way debatable. Here:

        Good software has high cohesion and low coupling. Unfortunately systemd is practically the opposite of this.

      3. I didn’t say anything about frameworks. My gripe with Gnome (which I no longer use, as GNOME3 sucks ) is depending on SPECIFIC software.

        I’m a developer, so I don’t suffer from ‘not understanding software’ as you put it. Tightly coupled software IS bad design. This point is not debateable. Any developer worth his salt knows this:

        Good design is high cohesion with low coupling. Unfortunately systemd is pretty much the opposite of this. Things like the binary logging are merely symptoms. The typical statements about systemd not being monolithic because it has lots of different binary files just showcases ignorance of what coupling is. How many files you have is irrelevant. Their dependence on one another is. Once higher level components buy into systemd’s way of doing things, It is difficult to write a replacement for systemd without also buying into its way of doing things, i.e. you have to write a virtual systemd clone to replace systemd, which defeats the entire point.

        The main problems with systemd are that is exposes a large and changing interface to higher level components, while simultaneously dictating policy on how systems should run. The policy thing is a problem with GNOME as well – software should never dictate policy. It must remain flexible to be able to handle jobs the author never even considered as valid uses. It’s pretty clear from past disagreements between systemd developers and kernel developers that systemd developers feel they should be able to do this because they ‘know’ what’s right. They are wrong.

        1. Yea well, GNOME 3 sucks or not, it works. I personally find it functional, and also the first GNME I ever considered even using. I always hated GNOME’s guts, it was ugly and dysfunctional and did not let you do things, configuration seemed to have been made elaborately difficult, etc. Some of this did not change, but at least it now does its job. (And I happen to like its idea of Desktop interaction, more productive than the old ones).

          Anyway, as it was pointed out by another commenter, GNOME was offered an alternative, and GNOME chose to go this way. It’s GNOME’s decision, ergo GNOME’s design. Don1t mash things up.

          As another commenter pointed out: Only 3 out of systemd’s binaries are mandatory, all the rest are optional. How is that tightly coupled then? You can opt for using all, or none. In fact, most systemd tools can be used WITHOUT systemd being PID1: Wow, such tight coupling….

          You protest that you understand software. Well, you might, but you did not do your homework about this specific one.

          About higher level code buying into systemd’s way of doing things: Now that would be the higher level code developer’s choice, systemd only provides a way of doing this. It also allows for not doing this. Either way, it’s not systemd’s “fault”, and not only systemd’s “poor design” (Although we have already busted the myth of your tight coupling, all those elements being optional, haven’t we?) The thing is, they can APPEAR tightly couple, or even behave so, but that does not mean, that they are by design. I used to oversee dev teams, I am perfectly aware of the individual developers poor understanding of higher level design, (and often anything that goes beyond their codebase). In this scenario, being a dev is not necessarily an advantage for your understanding.

          As for what you got right: About policy dictation, etc, I agree in general. I also agree with the coupling in general (when you finally explain what you mean and don’t leave it up to us to guess, what, or how much you really understand by it, in which case I tend to assume you know just too little to be more specific).

          I don’t agree that systemd dictates policy though. It offers choices. With gnome it might be true, but again, it’s not systemd’s fault. you are mashing things up.


          “The typical statements about systemd not being monolithic because it has lots of different binary files just showcases ignorance of what coupling is.”

          Let me reverse this: The statement that systemd is tightly coupled just showcases ignorance of what systemd is. (See above why) :D

    2. ” I also think binary logging is a colossally stupid idea,” how about telling us why. try using journalctl for a while and see if you still think its stupid. See how long it takes you to write a script(s) that pulls out all the log records for a specific time period and merge them in order to produce a log trail worth reading – here’s the journalctl way “journalctl –since “2015-01-10” –until “2015-01-11 03:00″ – if you want to know more:-
      ” and having higher level software (like Gnome) depend on a specific init system like systemd is ridiculous.” it doesn’t have to, LPoettering wrote a library for Gnome not to depend on systemd but GNOME chose not to use it. Maybe they know something more than you do.
      “Tightly coupled software is bad design, period.” its modular, the only depenedent modules are systemd, udev and journald, everything else is optional.

      1. binary logging – corruptibility and inaccessibility without specialized tools come to mind

        I can write a script to parse out log files no problem. Why would I need a special tool to do that?

        1. I am yet to see any incorruptible logging too, including your own script. The inaccessibility might be right, but the specialized tools advantages often overwhelm its disadvantages. I’m keen to see the script you write, that can do as much as journalctl. It made me a cappuccino this morning, i kid you not.

          And viola, here’s another comment (above yours), pointing out how wrong you are about coupling.

          1. Ok, this will be my last comment. The fact that I had to explain what coupling is means my arguments are lost on someone who doesn’t understand software design, yet has the nerve to say I don’t.

            One last time for those that still don’t get it: Coupling has nothing to do with the number of binaries you have. The argument that “its modular, the only depenedent modules are systemd, udev and journald, everything else is optional” is misleading. Here’s an exercise for the stubborn: Compile a minimal (and functional) systemd as PID1. How many lines of code are involved and how many libraries? What type of interface does it expose and how flexible is it? Does that interface change over time, such that writing your own external tools against it is difficult? Do this and come to your own conclusions. Until you have done this your speculation on its design is just that, speculation. I have done it already and have moved onto other things instead of wasting my time dealing with systemd’s garbage.

Comments are closed.