What’s New in systemd, 2015 Edition

Mattias Geniar, Sunday, February 1, 2015 - last modified: Sunday, August 2, 2015

This post is part of a series of notes I've taken at FOSDEM 2015 in Brussels, Belgium. If you're interested, have a look at the other posts.

A packed room at Fosdem for Lennart Poettering's talk on systemd, the 2015 edition.

systemd is now a core component of most major distributions. In this talk I want to give an overview over everything new in the systemd project over the last year, and what to expect over the next year.

fosdem talk description

There were no slides. None whatsoever. No presentation. He just talked.

lennart_systemd_fosdem_2015

Notes are scribbled down really quickly, so errors may occur. Don't quote this directly. If you spot any errors, please let me know. ;-)

Video available

The video recording of the talk is now available online. Someone was kind of enough to mirror this on YouTube -- I'm not sure if this is allowed by Fosdem, but for the time being I'll embed it here.

If you're not interested in the video, the talk is written down below!

Transcript

  • user space components in systemd for dbus are mostly done (new library for C developers)
  • nspawn (a minimal container manager) was originally made to test the init-system, without rebooting the box every time (for testing systemd development). It grew over time to a viable (minimal) container manager. Supports RAW images and docker-like containers.
  • machined: a virtual machine registration manager, takes inspiration from Solaris' "zone" concept
  • in general: more container features are to be expected
  • the goal is have all tools be "container" aware, so journald can show the logs/messages from the host as well as all the containers running on it
  • next version (released in ~2 weeks) of systemd will have additional btrfs support
  • minimal firewall support, which is service oriented. Ie: allow Apache access in the firewall instead of saying "allow port :80" access. Gives better support for the variety of ports services can listen on. Would also prevent port-hijacking from other services, since it's bound to the service.
  • consoled: support for high DPI screens and unicode
  • systemctl-cat, systemctl-edit: cat the config file of the unit you specify, so you don't need to know the path on the system (ie: systemctl-cat apache2.service). The systemctl-edit apache2.service immediately opens the unit file to edit. After a save, the service can get reloaded automatically.
  • nss-getmyhostname: a function call to get the local hostname, in case /etc/* is entirely empty (for stateless hosts).

fosdem_2015_systemd_room

Part deux

  • ping gateway: automatically resolve the gateway of all interfaces and ping them, very useful for network troubleshooting and the question "am I online?". The "ping gateway" gets resolved automatically (so you actually type ping gateway at the CLI).
  • networkd: because networking is such a basic function of the OS, he believes it should be in systemd
  • networkd: systemd wrote their own dhcp library (compatible with dhcpv4 and dhcpv6)
  • combining nspawn (containers) and networkd (dhcp) allows for easier network management of containers. Networkd can also run inside the container. Outside the container networkd can pick a free DHCP IP for that container. Allows v4 to v6 network masquarading automatically. Does not involve dnsmasq, everything is routed via IP on the kernel (no bridging).
  • auditing: implemented for when your application needs to be NSA approved (that appeared to be the main reason, Lennart himself said he's not a big fan of it). Can log all system calls made to /etc/passwd etc to the audit log. Auditing is integrated with journald, audit-tools to read the logs have been improved.
  • Linux distributions are moving to "stateless" systems, with only /usr content available/writable. If /etc/ and /var are unpopulated, the system (systemd) will do the minimal bits to boot up the system. Only your own changes would make it to /etc. systemd adds better support for these kind of setups.
  • resolved: adds support for multiple resolving (use case: connected to a remote VPN which then loses the local DNS resolving). A request can be sent to every interface in checking for a response. Resolvd maintains a DNS cache per interface. Adds support for LLMNR (link
  • local multi
  • cast nameserver resolution, used by Windows). Resolvd was recently discovered to be vulnerable to a DNS cache poisoning attack.
  • journald-remoting: the binary logger now has remote support (aka: remoting) via HTTP (instead of the syslog protocol, which isn't standardized (ie: no timezones, single-line logs only, ...)). Journald has a pull and push model. Pull = HTTP GET request for a JSON stream. Push model pushes via the HTTP POST request to a remote journald instance. Allows for "simple" implementations of programs (PHP, Ruby, ...) to send data to a remote journald endpoint, since it's just HTTP POST. Could replace syslogging.
  • service management: can set up minimal namespaces for services (ie: marking /usr or /home read-only for that particular service).
    • Configured in the init files. Minimal sandboxing/chrooting.
    • Can also hide partitions instead of making them just read only. For instance, if /home is "hidden" it will appear as an empty directory.
    • Can also give a private /tmp to each service, so no longer a server-shared /tmp directory that everyone can access. This uses subdirectories in /tmp (so you still have partition control over /tmp) but it's separated from the other services.
    • Can also hide /dev/* devices and hide all the physical devices (like /dev/sda, ...) and only keep /dev/zero, /dev/null, ... for particular services.
    • By using other systemd tools (not mentioned), you can limit access to /dev/* devices to particular services and block it for all others
  • timesyncd: the idea is to not run an ntpd on every device anymore. timesyncd is a trivial ntp client (not a server!), a simple as possible. Integrates with networkd (networkd learns the ntpd servers and passes them on to timesyncd). This is also needed for stateless machines without an /etc/* directory, which at boot would not have a notion of time.
  • GPT (GUID Partition Table) auto-discovery: since /etc/fstab can be absent on stateless systems. Auto-discovery of the GPT is very nice. Discovers swap devices (since it has a very distinct UUID in the GPT) and root partitions, even without the /etc/fstab configs.
  • read ahead implementation dropped: in the age of SSDs the benefit is not big enough to have this. All systemd developers have SSDs and no more spinning disks, nobody could/wanted to support this anymore. The idea was to read-ahead the bits needed during the boot process and remember it next time, for faster boots. But with SSDs, this support is dropped.
  • a new secure boot implementation: this is a work-in-progress, to have more validation of the boot process that it hasn't been tampered with. It will integrate a new method of signing images and initrd's.

Update

Updated for correctness:

State retention

systemd will add support for restarting services without losing state. Every daemon will store a minimal system state on disk, so if it's restarted it can resume the original state. This will allow daemons to restart themselves without harm. Lately, journald has received support for this as well.

This concept builds further upon the socket activation. When restarting a service, systemd can push the used sockets/file descriptors of that service to the sytemd daemon and pass it again to the service once it restarted. This way, no sockets/fd's are lost.

Key takeways: most of what is in systemd is optional (except for journald). If there are parts you don't like or disagree with, you can just not use it. Documentation is being worked on and is considered a priority in the systemd project.

If you're interested, I have another post on resources for learning systemd you may find interesting. It also has some interesting comments.

Update 3/2/2015: I've removed some truly offending comments. I do not approve of hate and threat on this blog. You are free to discuss the pro's/cons of systemd -- but any form of threat against anyone's life will be deleted straight away, no matter if it's meant as a "joke".


Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. If you're interested in keeping up with me, have a look at my podcast and weekly newsletter below. For more updates, follow me on Twitter as @mattiasgeniar.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

Emanuele Aina Monday, February 2, 2015 at 22:55

Read-only systems with writable /usr seems a bit funny, specially considering that split-usr is being deprecated.

Was it read-only systems with writable /home?

Reply


    Mattias Geniar Monday, February 2, 2015 at 23:14

    I honestly can’t remember in detail. I do remember there were different options to make /usr, /home, /etc, … read-only or appear empty.

    Right now, I would assume you can mix those options? So a read-only /usr and an empty-looking /home for instance – or vica versa.

    Reply


      Emanuele Aina Tuesday, February 3, 2015 at 11:21

      Yep, I guess there are two separate features here: using namespaces to protect/hide parts of the filesystem from services and booting with only /home writable.

      In the first case a writable /usr is the default but you can set it read-only for services that don’t need to alter the OS files. In the same vein it may be desirable to protect /home by making it read-only or completely hiding it so it looks like an empty folder.

      The second case is really useful to cleanly boot live CDs and cloud images without persistent storage.

      Reply


    intelfx Tuesday, February 3, 2015 at 08:28

    /usr split into another partition is *not* being deprecated, and *never was*

    What’s deprecated is not mounting /usr partition from initramfs. And, to a lesser extent, not symlinking /{{s,}bin,lib} -> /usr/{bin,lib}.

    Reply


      Emanuele Aina Tuesday, February 3, 2015 at 11:15

      Right, bad wording on my part. Thanks for the clarification!

      Reply


Emanuele Aina Tuesday, February 3, 2015 at 17:19

Thanks Mattias for the write up. It’s a shame that everytime somebody touches some special topics there are people having issues with their caps lock while hiding behind multiple anonymous nicks.

Reply


Kirk M Tuesday, February 3, 2015 at 20:51

Appreciate the article, Mattias. Systemd has really captured by interest of late (I’m running the latest version of Manjaro/XFCE in a test partition on my desktop PC). I find that working with systemd as a non-developer is much easier than working with the old sysVinit even though the commands can be longer depending on what I want to do. Even then, systemd commands seem to make more sense to me and “init” commands.It has it’s problems yet of course, no init system is perfect.

But I have to laugh at comments left by people like “amused_penquin” (and his other monikers) with their NSA/corporate/government conspiracy blather and who always end up reducing the conversation to the level of the personal attacks in the end.

All the years I’ve used Linux distros I’ve heard a cry for “Linux on the desktop” which could never really happen because there was hardly anything common among distros. Everyone went their own way as far as how “their distro” worked. Even when “based on” distros became the norm there still existed a whole lot of controversy and infighting which seems to be the norm these days. And still the cry for “Linux on the desktop” is heard yet

…when someone finally comes up with an “init” system that actually offers some common ground between distros (well, the most popular ones anyway) that’s needed to possibly get “Linux on the desktop” off the ground, there’s an unprecedented reaction from many of the so-called “Linux community” from mild all the way to:

“He must be hanged, drawn and quartered – because “systemd” is an obvious act of high treason”

Anyway, don’t hesitate. Take “smart_penguin”, “the_smartest_penguin”, “amused_penguin” or whatever he/she calls themselves and boot “them” off your blog. Trolls always stifle the conversation.

And please forgive any typos. Thanks

Reply


    Mattias Geniar Tuesday, February 3, 2015 at 21:37

    You’re right, I’ve removed the offensive posts altogether. Life’s too short to be worrying about trolls.

    Reply


    not a troll Wednesday, February 4, 2015 at 00:15

    Some of us are already using ‘Linux on the Desktop’, so we don’t see the need for further work in this area, and we’re quite frankly terrified at what systemd implies for ‘Linux on the Server Farm’ given what we’ve seen so far.

    Having run systemd in production against my will for 8 months now, from what I can see – ‘Those who do not understand existing Linux userland are condemned to reinvent it, poorly.”

    I very much regret the language being used and the hate being spewed towards Lennart, but I understand the frustration – running systemd in a cluster of 1000+ nodes can do strange things to your mental health!

    He’s a special kind of fanatic, the kind who will ‘never change his mind and refuses to change the subject’. Anyone sane and reasoned is working on ignoring him and his work; all that remains are the neophytes and the psychopaths.

    Reply


      Kirk M Wednesday, February 4, 2015 at 20:29

      @not a troll – I tend to agree with you on systemd on sever farms, it probably shouldn’t be there as the traditional, shall we say(?), “init” set up makes more sense in these cases. While I do believe that systemd for distros installed on “personal” machines could actually work pretty well, it may be more of a liability than an asset on the server. Then again, this is not my area of expertise. It just may be that some future IT admin and/or tech who starts off working with a Linux server set up that incorporates systemd as the default init system might find it odd if they suddenly had to work with servers that used sysVinit as it’s init system.

      Of course, there’s the thing about you having to work with systemd “against your will” when you would have set up the servers differently if it had been up to you? That’s a rough go.

      Personally, there’s part of me that hopes that the so-called “Linux on the desktop” never happens so those of us who do run their distro of choice as their main OS retain our bit of obscurity. I mean, if one day Ubuntu or Mint came pre-installed on OEM machines instead of Windows then those distros would end up being attacked as much as Windows is today.

      There are times when the status quo is preferable?

      Reply


    Anonymous Coward Thursday, November 19, 2015 at 11:38

    I think you misunderstand and misrepresent what the more serious and objective criticism of systemd is.

    There will still be differences between distros – after all, every distro maintainer wants to make his distro distinctive. Regardless of the init system.

    What systemd has gotten wrong, and shows no intention at all to fix, is its take it or leave it approach. It may say it’s modular, but it’s not. Modular means individual modules can be replaced with alternative implementations, and that you can choose which modules to deploy and which not.

    Systemd allows neither. You always have to install it fully, because of the high coupling between all of its modules. This is a problem on hardware-constrained platforms (arm-based systems , linux on phones, system on a chip based boards for IoT etc.). And you can’t provide alternative implementations of modules, simply because there are no specified, stable, published and documented interfaces to implement.

    Systemd is in the most proper sense a big ball of mud – http://laputan.org/mud/mud.html. It exhibits one essential trait: it works. It doesn’t mean it’s something that should be kept around forever, or that it will last forever. If its developers would heed the advice contained in that old article I linked to above, they could start transforming it into something long-term viable – so far, they haven’t shown any intention to do so.

    Reply


      intelfx Thursday, November 19, 2015 at 14:01

      It may say it’s modular, but it’s not.

      Oh yes, it is. It is monolithic and modular at the same time.

      Modular means individual modules can be replaced with alternative implementations, and that you can choose which modules to deploy and which not.

      Correct, and the whole purpose of systemd’s bus-daemon-plus-client approach is to allow and to make it easy to swap out individual components of it. And you certainly can choose — with the exception of three main components — what to deploy. We talked about exactly that at second day of systemd.conf 2015 (I’ve attended that conference).

      Systemd allows neither. You always have to install it fully, because of the high coupling between all of its modules.

      This is just complete bullshit. Note that this is not an offense, but rather a statement of fact. This is untrue, as demonstrated by packaging at least in Debian and ALT Linux, so please stop spreading lies any further.

      And you can’t provide alternative implementations of modules

      This is grossly untrue as well. Take a look, for example, at LoginKit (reimplementation of logind), systemd-shim (reimplementation of PID 1 d-bus interface), systembsd (reimplementation of a couple of ancillary components) and timedatex (reimplementation of systemd-timedated *which, AFAIK, has replaced the original timedated in Fedora itself*).

      simply because there are no specified, stable, published and documented interfaces to implement.

      Oh, now this counts as FUD. Take a look: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

      Reply


      Kirk M Thursday, November 19, 2015 at 19:23

      @Anonymous Coward (not too sure here but my typed response seems to have defaulted to italics. We’ll see when it publishes)

      Misunderstand? Very possible. Misrepresent? Absolutely not. As I said previously, I’m speaking as an end user, not a programmer or developer. I’m also peaking from personal computer viewpoint, not an IT viewpoint. I did spend over 30 years in computers, peripherals, R&D, etc but the fields I worked in never touched on programming or server maintenance.

      In other words, it’s simply my opinion. I hope to understand thing better as time goes on.

      Reply


Fernando Ramirez Wednesday, February 4, 2015 at 02:40

read ahead implementation dropped: in the age of SSDs the benefit is not big enough to have this. All systemd developers have SSDs and no more spinning disks, nobody could/wanted to support this anymore. The idea was to read-ahead the bits needed during the boot process and remember it next time, for faster boots. But with SSDs, this support is dropped.

No everyone uses SSD, specially on desktops and workstations. Removing a feature because you don’t use it is bad development. Specially when something is being used on multiple distributions for multiple use cases. You cant have a one size fits all.

Reply


    intelfx Wednesday, February 4, 2015 at 02:45

    You have specifically tried to ignore “uninteresting” parts of the text, haven’t you?

    The reason is not “because they don’t use”. The reason is:

    nobody could/wanted to support this anymore.

    The removal heads-up and a call for maintainers has been posted 2.5 months before actual removal. There were no people willing to watch over this tool and maintain it, so it has got removed, with explicitly stated possibility of re-adding it if someone expresses interest. Dead simple.

    Reply


      Rob Nelson Wednesday, February 4, 2015 at 23:53

      My confusion lies in why it was removed. Was it not functioning properly? Were the a number of extant bugs that needed addressed? Or was it simply removed because the ‘maintainer’ field was null? The first two reasons are legitimate reasons to remove code. The latter is IMO not a valid reason. I don’t know the reality of the situation, but the presentation gives the impression of the null maintainer only. That’s not a good perception to run with.

      Reply


        intelfx Thursday, February 5, 2015 at 00:16

        Sorry for broken formatting.

        On the mailing list, Lennard said in the heads-up post:

        […] nobody tries to optimize it in any way. And it probably needs a lot of looking after and love to still be useful as general purpose systems, instead of just slowing them down…

        And there was a “confirming” reply from a third-party developer (Auke Kok):

        heh, ouch X_X

        I can understand your sentiment, though. I’ve identified plenty of cases where readahead just isn’t working out well at all, and the constant tweaking has left it … quite a bit messy.

        So it’s not just about empty Maintainer: field. However, even if it were so — who would want a chunk of slowly bit-rotting code in their own repository?

        Reply


          Mattias Geniar Thursday, February 5, 2015 at 10:38

          I’ve deleted your old comment (the one with broken formatting), hope you don’t mind. Thanks for the feedback!

          Reply


        Mattias Geniar Thursday, February 5, 2015 at 10:41

        Or was it simply removed because the ‘maintainer’ field was null?

        I would actually think that’s a pretty valid reason to remove the feature. What’s going to happen a few months for now, when this turns out to have a security leak in it? Who’s going to fix it?

        Who knows the code and the impact of the changes that need to be made? Software needs maintainers, if there aren’t any – it’s a dead piece of software and a liability. It would also give systemd a bad name (you know, because it has such a good rep now :P ) if bugs are reported but never fixed.

        Especially on such a crucial part. If the system doesn’t boot because of bugs in the code, it’s a major functionality break and quite possibly a disaster to fix.

        Reply


      Jeannie Monday, February 9, 2015 at 12:40

      Just because YOU devs don’t want it anymore, WE still are more people who use HDs than people who use ssds out here.
      Your attitude is so anti social, do you ever think about users or do you jus programm to suit only the needs of the systemd dev team?

      Reply


        Mattias Geniar Monday, February 9, 2015 at 12:42

        Have you volunteered to maintain the codebase and support HDD’s?

        It’s very easy to be negative about decisions made, it’s an entirely different scenario when you think about the effort involved in actually supporting it and maintaining the codebase over the next X years.

        Reply


          Jeannie Monday, February 9, 2015 at 18:24

          It’s very easy to say: We as elite dev group don’t need it, now, world, follow us and replace your hdds with expensive, less value for money ssd so you also don’t need read ahead anymore.
          But Our way or the highway seems to be exactly the systemd attitude.
          When will we get kerneld and systemd as only components of a complete linux system? When will Lennart take over kernel development?
          Ultra pissed off by your attitude.

          Reply


            Justin Tuesday, February 17, 2015 at 01:35

            Jeannie, even if everyone wanted to keep it around, there’s no one writing code for it. It doesn’t work well to begin with and no one wants to fix it. Seriously, what more can be done? Can’t hold a gun to someone’s head and say, “fix this code now!” So if you can find someone who wants to maintain the code, awesome! But no one wants to touch it, so into the garbage bin it goes. Wanting to keep it and working to keep it are two totally different things. There’s a ton of people who want the first, there is no one who wants the second.

            Reply


          Kirk M Monday, February 9, 2015 at 22:33

          In a way, I have to agree with Jeannie in that just because systemd developers only use SSDs is no excuse to drop read-ahead support for hard drives. I would have to believe that the majority of real world users of Linux distributions still use hard drives and not just for storage. And most folks don’t have new machines that come with SSDs by default and not all new machines come with SSDs yet.

          With the most popular of the desktop Linux distros that have already moved to or will be moving to systemd in the near future, it’s kind of a fallacy to even consider that read-ahead support will not be required.

          It’s also kind of weird that a Redhat developer (a software company that caters to businesses) would not take into consideration that businesses, both large and small, are notorious for not upgrading their equipment until they absolutely have to. The world of business is full of OSs installed on spinning disks and that’s not going to change anytime soon.

          And meaning no offense at all, your answer about volunteering to maintain the codebase and support HDD’s is a very “old school” response from the days where “Linux” and Linux OSs and software were developed by developers for developers only, the regular user need not apply. This is not the case these days as the majority of Linux distro users today are not developers, just users.

          Understanding that this is solely my rather experienced opinion (but just my opinion nonetheless), systemd is supposed to be as a drop-in replacement for sysVinit. If so, then systemd needs to be a complete replacement for sysVinit. Not for the ancient legacy code that supports hardware that hasn’t existed for years certainly, but hard drives are still widely used and will be for some time yet.

          Again, just my opinion. And again, please forgive the typos.

          Reply


            Mattias Geniar Monday, February 9, 2015 at 23:02

            Hi Kirk,

            Thanks for taking your time to respond with well thought arguments.

            And meaning no offense at all, your answer about volunteering to maintain the codebase and support HDD’s is a very “old school” response from the days where “Linux” and Linux OSs and software were developed by developers for developers only, the regular user need not apply.

            Agree, it is shortsighted.

            And I won’t hide it, while I’m no systemd fanboy, I do not oppose the direction Linux is heading in. I’m looking forward to working with systemd (at this point), which you may have guessed by my other responses in this thread.

            As a “pro” guy, I read most of the “con” arguments to systemd as very small yet very aggressive comments. The same feeling I had with Jeannie’s comment of “why stop developing the read-ahead implementation, just because you devs all have SSDs?“.

            To me, that sounds a lot like “damn, I wanted this feature but now no one is developing it anymore“. It’s OK to be disappointed by the decision, but at the same time you’re getting systemd for free. You’re getting Linux for free. How about a little gratitude for the all the work others put into these tools, so we can benefit from them?

            (Apologies if either of you is a major open source contributor, most Linux users simply aren’t and are consumers of the source, not contributors. Tearing down the work others do is always easier and often more appealing than helping to build the tools in the first place.)

            … systemd is supposed to be as a drop-in replacement for sysVinit. If so, then systemd needs to be a complete replacement for sysVinit. Not for the ancient legacy code that supports hardware that hasn’t existed for years certainly, but hard drives are still widely used and will be for some time yet.

            It is, actually. It replaces sysvinit (and a lot more). The read-ahead implementation that would “remember” the blocks on the disk for faster boot times doesn’t exist in sysvinit. It would have been an entirely new feature, no functionality is being dropped by stopping the development.

            Spinning disks are of course still supported, just this minor feature isn’t anymore.

            And that’s what gets to me. A lot of systemd opponents – even though they have very valid reasons to – have their rifles aimed towards some very specific parts of systemd, and focus all their energy on it. The aggressive tone a lot of opponents carry must have built up over months & years, but it doesn’t play in their favor. It just paints them of as trolls, which is a shame because it undermines their – again, often valid – arguments.

            It doesn’t leave room to appreciate some of the good parts of systemd.

            Again, just my opinion. And again, please forgive the typos.

            I appreciate your opinion. I also like how it differs from mine, as that gives room for discussion. If everyone would take the time to build up a case and have a proper conversation, the entire systemd vs something-else debate would happen with a lot less blood shedding.

            Oh, and as far as I could tell, there were no typos. :-)

            Reply


              Kirk M Monday, February 9, 2015 at 23:19

              Ah, it slipped my rather old mind that read-ahead (like “ureadahead”) was a separate package outside of sysVinit. Can’t remember everything I guess.

              And yes, Jeannie was a bit blunt in her comment and response so I kind of figured that might have been behind your response to her. Glad you understood my point. Nothing like constructive conversation is there? I rare thing these days. ;-)

              And no typos? I must be slipping.

              And as I’ve already stated (I think?), I’m also very interested in systemd as you are


        Anonymous Coward Thursday, November 19, 2015 at 11:43

        I don’t like systemd as a whole, so I’m going to switch to one of the few distros not installing it by default, with the next upgrade of my personal machines. But I don’t think your criticism is fair.

        The maintainers of systemd, regardless of how they behave, are volunteers. Whether they do or don’t maintain/do or don’t include a piece of code in what they maintain is their choice alone. Nobody not being involved, not paying for and not working on the issue doesn’t really have any right to demand something from them.

        Reply


lucius.cornelius Wednesday, February 4, 2015 at 09:47

It’s just breathtaking to behold how this issue has developed. How anyone who disagrees is tarred and feathered as a “conspiracy theorist” and “a hater”. These are classic debate control methods. I have participated in a number of debates online, in various locations, about this topic and without fail it’s always the systemd proponents who are rude, dismissive, dishonest, patronising, etc. The only thing worse than the behaviour of these people is the fact that to a man/woman, none of them understand why this is not a healthy development for Linux. It’s just heartbreaking to behold.
Your average Linux user these days is someone who seems to say “Microsoft? Apple? Meh, not to be trusted, I use Linux” but who then think it just fine and dandy that Red Hat (a Corporation that obeys the same economic principles that the others do) now controls most distros and the direction they go in.
So, have a happy life as you and those like you throw a magnificent creation down the toilet to keep a bunch of cash obsessed psychos happy. And when, in a few more years, there is no meaningful opposition to total Corporate rule remember that you were part of the death of that opposition.

Reply


    intelfx Wednesday, February 4, 2015 at 10:00

    How anyone who disagrees is tarred and feathered as a “conspiracy theorist” and “a hater”.

    Nah. The one who disagrees is called an opponent, or a disputant.

    On the other hand, the one who backs his words not by correct arguments, but by any form of conspiracy theory — is called a conspiracy theorist.

    The one who does not back his words by anything, but blatantly ignores the other side’s arguments in favor of their own emotions, or resorts to trolling and demagogy in order to discredit the other side instead of proving their own words — is called a hater.

    By the above definition, you are a conspiracy theorist. You have written nothing aside from a completely random analogy, whose fallacies have been pointed out, discussed and beaten to death numerous times before.

    As it has been so eloquently put together: “You cite no new arguments to a previously well-debated question. Therefore, just saying that you are wrong is a sufficient response.”

    Reply


Mircea Popescu Wednesday, February 4, 2015 at 20:28

There are no “pros” of systemd.

Obviously anyone is welcome to reimplement Microsoft/Apple nonsense in FOSS, that’s the point of it being FOSS. Neverthless, the utility of such an attempt is not unlike a reimplementation of malbolge : perhaps a funny if entirely pointless exercise. The sort of pointless but informative endeavour beneficial to adolescents – they’re generally the ones who don’t know what’s funny yet.

Reply


Michael Wednesday, February 4, 2015 at 23:38

Poettering has also said that systemd is heavily inspired by Solaris SMF. SMF is suitable in large servers, with 32 sockets or so, taking long time to boot up. SMF will parallelize the boot process by making sure all dependencies are obeyed when starting a large software system, monitor software systems if they crash, etc etc etc. This means a large Solaris server can boot and shut down fast. Compare this to a IBM POWER p570 that takes 90 minutes to boot. Yes, 90 minutes, because everything is done sequentially, one after another.

So systemd should be used in large Linux servers, booting many software systems. systemd is not helpful on the desktop because the boot process is already fast, and there are not that many software systems that needs to be monitored by systemd.

In my opinion, Poettering has drawn inspiration by Solaris without really understanding the purpose of Solaris SMF (usable only on large servers). And now systemd is getting more and more bloated, to the point that takes more and more functionality from the Linux kernel. I think Poettering misunderstood the Solaris SMF purpose. What do you say? Do you agree?

Reply


Gabe Thursday, February 5, 2015 at 22:53

Although I like the unix philosophy, do one thing and do it right, I also believe that when there is an opportunity to improve then we should take that approach. Systemd created such opportunity by increasing boot speeds and in (most) cases simplifying management. On the other hand, systemd has (in a way) become “bloated” however since *it is* open source you can go in and tinker with it to your heart’s content. Meaning all the extras can be safely disable and leaving you with a barebones init. The only real dependency is Journald and optional (but recommended) udev. In my tests (in embedded) I have managed to get my router running OpenWRT go from a full off state to loading the kernel and userspace in just 7.5 seconds! Compared to procd which took about 29.5 seconds. Yes, I will admit, systemd is big, like really big, compared to sysV or procd. But if your hardware can handle a bit more storage then systemd will truly be a step forward. I only hope that bugs are fixed and the team pay attention to other’s input rather than disregarding them (talking about embedded Poettering >:( don’t just make a great piece of software with a meh, I don’t care about embedded).

All the best!

Reply


Lettuce Not Forget Friday, February 6, 2015 at 02:13

I’ve been using Unix as a desktop happily since the early 90s. I don’t think I’m going too far out on a branch saying that systemd has been and will continue to be an amazing boon for the BSD communities. They’ve remained quite healthy over the years, and they’re quite viable and pleasant to run today.

Reply


jay Monday, February 9, 2015 at 12:58

cool – this talk was the best @fosdem – it was so packed that I had to sit on the stage on a table – if you had just turned the camera to the right

Reply


    Mattias Geniar Monday, February 9, 2015 at 12:59

    It was indeed packed and incredibly hot! Sorry I missed you in the picture :P

    Reply


USA Eric Tuesday, February 10, 2015 at 11:34

The problem is who want write a software only support linux?
Gnome and KDE already get fuck now they can’t run on bsd and cygwin.
Since there no plan for porting systemd to bsd and windows, I just see many software will become linux only.

Reply


SJS Wednesday, February 11, 2015 at 00:42

If there are parts you don’t like or disagree with, you can just not use it.

I’ve heard that a lot over the years. And it’s always turned out to be a lie.

You can, in theory, if you work hard enough, accept that most advice you will eventually receive will be inapplicable, and exhibit near-superhuman determination, be able to ‘not use it’. But then people will look at you funny.

Eventually, you’ll get some folks to agree that ‘it’ was a bad idea, but it’ll come with the concession that it’s too late to do anything about it _now_.

Reply


    intelfx Wednesday, February 11, 2015 at 01:02

    And it’s always turned out to be a lie.

    This cannot be a lie. Unless someone forces you to use software, which most probably isn’t happening. No one forces you to use modern distributions. No one forces you to use Linux-based operating systems.

    But you apparently want to use them, and at the same time you do not agree with the way they are done. This is an entirely different claim, and you’re out of luck: no one volunteered to do things as you want them to be done.

    Decisions are made by those who do the work of developing new software. Decisions are proliferated by those who do the work of integrating the said software.

    Reply


      erix Thursday, February 12, 2015 at 07:11

      This cannot be a lie. Unless someone forces you to use software, which most probably isn’t happening. No one forces you to use modern distributions. No one forces you to use Linux-based operating systems.

      The word “lie” is quite appropriate when documentation is missing or faulty and instructions are inapplicable. When the devs say that systemd is modular but then it turns out to be monolithic, it was basically a lie when they said “modular”.

      Reply


        intelfx Sunday, August 9, 2015 at 16:43

        This (regarding modularity vs. “monolithicity”) is a completely different statement. Nevertheless, it is still wrong.

        First of all, software can be modular (== comprising a number of easily identified parts, each doing an independent task and communicating with others via well-defined interfaces) and monolithic (== functional only as a whole) at the same time. The first and foremost example is the Linux kernel itself. Is it modular? Yes, `insmod` is there for a reason. Is it monolithic at the same time? Yes, you can’t run a module without the kernel.

        systemd is pretty similar. Moreover, it is less monolithic: a decent number of its modules in fact can run without systemd core. Just look at Arch circa 2013. Next, there is a couple of modules (systemd itself, logind and journald) which indeed depend on each other. But that’s all of it. Nobody prevents you from launching networkd without systemd, or the other way around.

        Reply


Lib Sunday, February 22, 2015 at 15:24

Lately, I tend to use one of the methods of sySTEmd fanboys, saying the same thing again and again, so here it is :

We need to evolve the way we see things

Yes we do.
We also need to progress in our way to talk about them.

There’s one distro barebone becoming bigger and bigger, this distro is the Gnome-Systemd Linux (let’s call it RHGSDL) and it has quite a lot of derivatives which will become more and more similar : RHEL, Fedora, Debian, Arch, Opensuse …

The core idea of this distro is that, to ‘fix’ linux, the whole system must rely on a unique process which control every other thing and that package/software dev/maintainers will work for that distro only (by making all their softwares/packages dependant on SystemD). The developpers of systemD think that most will do that because it’s ‘easier’ than to work for themselves and the whole community with other distros.
Maybe they are right to rely on lazyness and selfishness of those who make the strengh and diversity of GNU/Linux but, on the other hand, those who chose to give their time and skills in a free softwares unpaid work have maybe other higher motivations. Time will tell.

Time will tell also if the technical choices, and, among them, a single point of failure were good for this distro. Also their political choices. Some of the derivatives force SYSTEMd as default and do just not support alternatives, some are pretending to support alternatives while, by playing with recursive (sometimes ‘forged’) dependencies and compatibility break, they make it installed quite silently with other packages and almost mandatory once it’s installed. And they are the first distro who openly wants to either eat or destroy any other distro by orphaning them and systematically casting a slur/talking down/dissing anyone who legitimatly criticises SYStemd.

Still, RHGSDL is only a distro and we need to help and support the others who want to offer the choice to their users. I mean : LFS, Gentoo, Slackware, PCLinuxOS, Refracta, Crux, GNU Guix, Kali Linux, Sorcerer, Source Mage, Void Linux, Plop Linux, Pisi Linux, Bedrock Linux, GoboLinux, 0Linux, 4MLinux, Puppy Linux, Tiny Core… (plus LSD Linux, Trios and Devuan, if they ever become real forks) and all their derivatives.
There are also other kernels and, in particular, BSD. FreeBSD/PC-BSD/MidnightBSD seem to be quite good to give it a try without knowing much of it.

Now, there’s something I would like to say to the sysTEMd fanboys.
You say that it ‘fixes’ Linux, it handle things ‘better’, it is the only way to use the ‘newer’ functionalities, it is ‘needed’, it is ‘The Future’, it is ‘The Progress’, there’s ‘no alternatives’, no-one is able to develop alternatives following the ‘awesome development speed’ of it, others “do not respect the LSB” when sysTemd does, others “do follow stupidly the LSB” when systeMd do correct it, the users and devs who don’t think alike are just idiots or know nothing, the unix philosophy is obsolete, those who don’t follow you are of no interest etc.
If you’re right, then the linux kernel is not able to suit your desires and -fortunately- it doesn’t depend on SyStEmD yet. If you believe in what you’re saying, the Unix way and the linux community doesn’t suit your needs.
Then, the best way for you, SysTemD dev and al., is to take a break with the linux world, make your own kernel, going along with your system, and your own community, according with your philosophy, and it will be really easy for you as you are the ones ‘who know and do better’. You do no need,previously, to waste GNU/linux and our time.

Reply


kaddy Friday, April 24, 2015 at 17:01

“auditing: implemented for when your application needs to be NSA approved ”

Does anybody have any detailed information what this is all about?

Reply


Swall Monday, April 27, 2015 at 15:06

Systemd is a stunning piece of software. I truly don’t understand all the hate. I’m glad that the devs are able to ignore all the morons.

Well done systemd peeps – keep up the great work!

Reply


Disturbed Sunday, August 9, 2015 at 16:20

Yes, Goym. Integrate SystemD into your buils, just do a favour to the NSA Agency. You have nothing to hide, haven’t you? Hmm?

Reply


Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links