Hacker News new | past | comments | ask | show | jobs | submit login
Without Systemd (without-systemd.org)
63 points by turrini on May 9, 2015 | hide | past | web | favorite | 88 comments



I'm looking forward to 2 or 3 years from now when we can look back and laugh at all the fear and apprehension about systemd.

That said though, I did just recently upgrade to Ubuntu 15.04 (which is all systemd now) and it is noticeably slower to boot up compared to my old upstart-based 14.04 LTS install. Hopefully there's some more optimization that needs to be done to bring the boot-up speed to parity with the previous versions.


I like many things systemd has brought.

However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1].

All good lessons learnt from package managers? Gone. Nix? Forgotten.

Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands...

It's really scary. Linux has become such a nice OS partly because many distros created great package management tools.

These systemd guys make things terribly complex for no reason. Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. Pulseaudio is slow and unreliable. Dbus is quite inefficient. Etc.

Things are getting ugly. They are messing up with the Linux userland and ignoring core Unix principles.

[1] http://0pointer.net/blog/revisiting-how-we-put-together-linu...


> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either.

No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities.

> However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous.

I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind of system. I also get the impression that it is targeted more toward special use cases than intended to replace traditional package managers.

> Pulseaudio is slow and unreliable.

While anecdote is not data, I never had any issue with it.

> Dbus is quite inefficient.

They did not invent Dbus, and using the foremost userland IPC mechanism to communicate is not unreasonable (since, as mentioned above, systemd is a bunch of utilities, they do need some form of IPC). I don't think it has an impact in practice.


> Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities.

Ahh, there's the talking point I mentioned in my earlier post[1].

What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).

As an example in the opposite direction, consider busybox. While it compiles into a single binary, the features provided by busybox are very modular. You could remove any of the utilities it can emulate without that change cascading into lots of other unrelated features (with build system support), and I could replace any of the utilities with something else (i.e. the standard non-busybox version) by simply removing a symlink.

Systemd is designed in the opposite manner, on purpose. They put every but of code the project absorbs into the same repository, claiming it makes development easier. Of course it does... initially; you get to skip the all those clearly and rigorously defined interfaces. They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run.

[1] https://news.ycombinator.com/item?id=9515413

[2] See the "Rule of Modularity": http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...


> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).

Designs don't run under PID 1, or any other PIDs. Binaries do. You can't both complain about how insecure systemd is because it has a lot of code under PID 1, and then claim that the size of the code actually running under PID 1 is irrelevant.


Many of the binaries provided by systemd indeed have a non-public interface between them, but they are all compile-time optional, with the exception of journald.

Would you say that the people who claim they are migrating to FreeBSD because of systemd are all misguided because FreeBSD, having all of its kernel and userland plumbing in a single repository and tightly coupled, is a monolithic system by design?

Here's a bug on Debian/kFreeBSD about a FreeBSD 10 kernel ABI change breaking ifconfig:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740509#51

Would you call postfix monolithic too, given that you cannot replace any of its binaries with one from e.g. qmail because the interfaces are different? Is postfix any better than sendmail in this regard?

> They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run.

Public interfaces aren't without cost - putting public interfaces where they don't belong is one of the best ways to add accidental complexity to your project and make it much harder to maintain.

If you find some minor design flaw in a non-public interface, you think about what the ideal interface would do, and then you just change the existing interface because you have control of both client and provider of the interface.

If it's a public interface it has to be versioned and you never can remove the implementation of older versions because you have no idea who is using it and what would break, and introducing a new version adds enough extra work that some minor design flaws in the interface will never be fixed because the effort-to-benefit trade-off is different if you have to keep compatibility in mind.

See this article from another successful monolithic project for some good reasons to have internal-only interfaces.

https://www.kernel.org/doc/Documentation/stable_api_nonsense...

If monolithic systems are so obviously inferior, why are micro-kernel implementations of UNIX mostly a historic curiosity?


> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into.

What you're not understanding is that these other binaries do not run as PID 1, which is what nextos wrongly claimed.

> This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity).

Which is the exact opposite of what has happened during the sysvinit times.


> other binaries do not run as PID 1, which is what nextos wrongly claimed.

I never claimed they did. Obviously, I was replying to this claim:

"Systemd is not a monolith, it is a bunch of various utilities."

> Which is the exact opposite of what has happened during the sysvinit times.

I never mentioned anything about sysvinit, which has nothing to do with the bad design in systemd.

Regarding those times, I would agree that the older sysv-rc/initscripts were not that great either, which is why many of us moved to OpenRC a long time ago.


This honestly seems like FUD. Currently the Sys-V like serialisation of services at startup hasn't been efficient, and sysvinit doesn't handle event based kernel features at all well. And it's definitely not modular.

As for this argument that it's monolithic in its code organisation - lolwut? You don't need to have a seperate repository for each binary, hardly anyone does that. When you talk about clearly and vigorously defined interfaces, it seems to already have them - and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant. Heck, it's not even necessarily easy to troubleshoot if things go wrong. The systemd source is in one git repo, sure, but I can't see why maintenance will be a burden. What in particular concerns you?

You do realize that there are only a few binaries? Let's look at them:

networkd: handles network events - when a network device is created it handles setup. No, it does not supplant udev. Read here an overview: https://coreos.com/blog/intro-to-systemd-networkd/

Not a bad idea here: and very sensible aspect of systemd.

journald - collects log data from a variety of sources and puts it into a binary indexed data file. The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change.

Or, you can swap out the component: https://fitzcarraldoblog.wordpress.com/2014/09/20/change-sys...

logind handles logins

systemd-user-sessions.service allows restricting user logins via PAM

Then there are the systemd units - it handles sockets for socket activation, which is a key reason Debian chose systemd over Upstart. It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers.

I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events. All the technical arguments I've seen so far, with the exception of binary log files, don't hold any water. There are apparently security concerns over PID 1 - but they seem rather specious. Have a look at the dependency list here at https://people.debian.org/~stapelberg/docs/systemd-dependenc... if you don't believe me.

There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.


As for this argument that it's monolithic in its code organisation - lolwut?

I think what the parent poster meant is that despite being modularized into several components, systemd has interdependencies between them, its individual subsystems not being able to be seamlessly swapped out. Indeed, many components (nspawn included) depend on systemd-as-PID1. As such it is monolithic.

...and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant.

You're confusing sysvinit with sysv-rc.

You do realize that there are only a few binaries?

Have you actually compiled systemd? The binaries probably exceed a hundred at this point. The count given for 204 was 69.

The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change.

With two caveats: Forwarding to other sources has a priority loss and doesn't have the same reliability/ordering/completeness guarantees (even if the claim is they "try hard": https://wiki.freedesktop.org/www/Software/systemd/syslog/), journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard.

logind handles logins

Far more than that. It handles user sessions, seats, suspend/hibernate, some device enumeration, gettys and as of recent, system shutdown. It's basically an extension from system init to session init.

it handles sockets for socket activation

Do you even understand what socket activation is? It's a marketing buzzword for an old and simple concept, and the systemd definition in particular conflates multiple use cases. See this commentary by Laurent Bercot: https://forums.gentoo.org/viewtopic-t-994548-postdays-0-post...

It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers.

Mount points and swaps are just small unit wrappers around the mount and swapon/swapoff binaries. It's oversold. Once again, path-based activation is a buzzword for reacting to file system changes, which you can do by leveraging inotify(7) or fanotify(7) independently.

There's pretty powerful cron replacements these days that can take the place of timer units.

I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events.

Those features could be part of a process manager or a process supervisor, not init(8) itself. init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.) It should not entangle the state of the system with the state of the OS processes, which systemd does quite egregiously. For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.

How do you define a "dynamic event"?

Have a look at the dependency list here...

Your list is for systemd-204, which is heavily outdated. systemd moves really fast.

There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.

Too bad it's apparent that you didn't do much of it yourself.


I think what the parent poster meant is that despite being modularized into several components, systemd has interdependencies between them, its individual subsystems not being able to be seamlessly swapped out. Indeed, many components (nspawn included) depend on systemd-as-PID1. As such it is monolithic.

Uh, that's what I would have expected from an init system. And nspawn is for testing and debugging, not for production use.

...and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant.

You're confusing sysvinit with sysv-rc

No, I was unclear and referring to the source package, which was a bit silly of me. But you knew what I meant.

You do realize that there are only a few binaries?

Have you actually compiled systemd? The binaries probably exceed a hundred at this point. The count given for 204 was 69.

What's your point? Let's look at utility and core binaries:

Utility binaries, don't rely directly on PID 1:

/bin/journalctl /bin/loginctl /bin/machinectl /bin/systemctl /bin/systemd-escape /bin/systemd-inhibit /bin/systemd-machine-id-setup /bin/systemd-notify /bin/systemd-tmpfiles /bin/systemd-tty-ask-password-agent /bin/systemd-ask-password /lib/systemd/systemd-ac-power /lib/systemd/systemd-activate /lib/systemd/systemd-backlight /lib/systemd/systemd-binfmt /lib/systemd/systemd-bootchart /lib/systemd/systemd-cgroups-agent /lib/systemd/systemd-cryptsetup /lib/systemd/systemd-fsck /lib/systemd/systemd-initctl /lib/systemd/systemd-modules-load /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-quotacheck /lib/systemd/systemd-random-seed /lib/systemd/systemd-readahead /lib/systemd/systemd-remount-fs /lib/systemd/systemd-reply-password /lib/systemd/systemd-rfkill /lib/systemd/systemd-shutdown /lib/systemd/systemd-sleep /lib/systemd/systemd-sysctl /lib/systemd/systemd-update-utmp /usr/bin/busctl /usr/bin/hostnamectl /usr/bin/localectl /usr/bin/systemd-analyze /usr/bin/systemd-cat /usr/bin/systemd-cgls /usr/bin/systemd-cgtop /usr/bin/systemd-delta /usr/bin/systemd-detect-virt /usr/bin/systemd-nspawn /usr/bin/systemd-path /usr/bin/systemd-run /usr/bin/systemd-stdio-bridge /usr/bin/timedatectl

Relies on PID 1:

/bin/systemd

Important binaries that rely on systemd, but that don't run on PID 1:

/lib/systemd/systemd-bus-proxyd /lib/systemd/systemd-hostnamed /lib/systemd/systemd-journald /lib/systemd/systemd-localed /lib/systemd/systemd-logind /lib/systemd/systemd-logind-launch /lib/systemd/systemd-machined /lib/systemd/systemd-networkd /lib/systemd/systemd-networkd-wait-online /lib/systemd/systemd-resolved /lib/systemd/systemd-shutdownd /lib/systemd/systemd-socket-proxyd /lib/systemd/systemd-timedated /lib/systemd/systemd-timesyncd /lib/systemd/systemd-user-sessions

With two caveats: Forwarding to other sources has a priority loss and doesn't have the same reliability/ordering/completeness guarantees (even if the claim is they "try hard": https://wiki.freedesktop.org/www/Software/systemd/syslog/), journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard.

What? Where are you getting this from? Prove it. You misquote them though, as they say:

"Note that journald tries hard to forward to your BSD syslog daemon as much as it can. That means you will get more than you traditionally got on /dev/log, such as stuff all daemons log on STDOUT/STDERR and the messages that are logged natively to systemd. Also, we will send stuff like the original SCM_CREDENTIALS along if possible."

logind handles logins

Far more than that. It handles user sessions, seats, suspend/hibernate, some device enumeration, gettys and as of recent, system shutdown. It's basically an extension from system init to session init.

You are correct, I was not very clear. Not sure I see the problem here though.

Do you even understand what socket activation is? It's a marketing buzzword for an old and simple concept, and the systemd definition in particular conflates multiple use cases. See this commentary by Laurent Bercot: https://forums.gentoo.org/viewtopic-t-994548-postdays-0-post....

Yup, I do. Interesting comments from Laurent Bercot, unlike you he sees that the idea has merit.

But a few things:

1. He's claiming that Pottering claims to have invented the concept of a superserver, where it was invented in inetd. Small problem: Pottering openly states this in 2011, here: http://0pointer.de/blog/projects/socket-activation.html also he seems to be claiming that Pottering says he invented pre-opened file descriptors? Guy is being a bit of an idiot as Pottering never said this.

2. He's complaining about a registry of predefined sockets in configure files. Seriously? That's his big concern? You deploy a daemon that can do socket-activation and you can't either create a configure file or include one with the package? Wake me up with a real argument, please.

3. He misses the point that socket activation means that you don't have to predefine the service order, by using sockets the service will block till the other service starts. I guess my only concern (that I've just though of) is how systemd handles deadlock conditions, but that isn't a stated concern about reliability by Bercot. Bercot's main concerns are: 1. what happens if a dependent service hangs, and 2. What happens if it's in the middle of a transaction.

I guess my response is: 1. Yes, it will block forever - but if your service was reliant on a serialised startup then I'm not sure what difference this makes: what happens if an earlier service hangs and dependent services can't run until that service has started? That used to happen to me on RedHat 5 when I accidentally forgot to turn off my misconfigured NFS server :-) 2. If you are in the middle of a transaction then again, I can't see how it's any worse than the scenario I just presented.

Those features could be part of a process manager or a process supervisor, not init(8) itself. init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.)

init doesn't reap orphaned processes, it reaps zombie processes. But actually, there are pretty decent technical reasons for it to handle these duties - like it handles misbehaving daemons that orphan themselves.

It should not entangle the state of the system with the state of the OS processes, which systemd does quite egregiously. For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.

What... What?

"After the system is booted and the kernel is running, launchd is run to finish the system initialization. As part of that initialization, it goes through the following steps: It loads the parameters for each launch-on-demand system-level daemon from the property list files found in /System/Library/LaunchDaemons/ and /Library/LaunchDaemons/." https://developer.apple.com/library/mac/documentation/MacOSX...

But, uh - ever heard of systemctl?


What about systemctl? It talks to systemd-the-PID1 via D-Bus method calls. That the system state is fused with the OS process state remains the case.


What, I answered your questions and that's all you've got? I mean, you've made a few basic mistakes here, like nothing reaps orphaned processes, only zombie processes. And launchd does actually parse plist files directly.

So much for your devastating rebuttal I guess :-) what's your point with dbus by the way? It's just a form of IPC, and uses a bus daemon to transfer the message. Are you implying that's a problem? If so, how?


Fine, I meant orphaned processes get reparented to it by default (unless a subreaper has been defined explicitly via prctl() flag). As for the launchd thing, I'll need to do further research.

Your implication that nspawn isn't for production use strikes me as quite odd. CoreOS based their Rocket platform on it (at least, initially - they might have swappable backends now).

That you expect interdependencies from an init system strikes me as more of a personal bias than anything else, given all the counterexamples - s6, nosh, perp, etc.

Your list of utility binaries that don't directly rely on PID1 is a false one. systemd-activate very much depends on systemd-as-PID1 to perform method call(s) on it, journalctl talks to journald which expects systemd as PID1, systemd-inhibit talks to logind which needs systemd-as-PID1, systemd-readahead is deprecated, systemd-analyze can't possibly work without a systemd PID1 to profile its Manager object, systemd-run needs it, so on and so forth...

I never made a claim that any of those binaries run as PID1... it's pretty obvious only one can be PID1. You're strawmanning too hard.

I haven't tested their claim, that it makes handwavy promises like "tries hard" makes me skeptical. This is hardly the only issue with journald though.

Where the hell did I say that "socket activation" (superservers, fd passing...) is without merit?

I'm pretty sure the escape from predefined service order comes from the dependency system and transaction reordering parts of systemd, not socket activation. Not directly, at least.

I never intended my rebuttal to be "devastating".

And of course, you never did respond to what a dynamic event is, or even my point right now that your assertion about system and process state being separate because systemctl exists is totally wrong... You also didn't respond to your dependency list being outdated, nor my rebuttal to your feature listing about udev devices, mounts, swaps, etc.

Ultimately, it seems like you have a vested interest in defending systemd. That's fine. If it serves you well, all power to you. That all arguments against systemd are misguided as you so boldly claim, is simply wrong.

EDIT: My point is your argument is completely nonsensical. How does controlling systemd from a utility program (like virtually every daemon) rebut my assertion about state?


Ah, the old "you must have a vested interest" argument. Good luck with that. You also haven't raised those counter examples till now.

I've responded to the dependency list being outdated - I asked you to provide me with a later dependency list. I still am - given you stated hundred of binaries, when there aren't I'm curious what you'll come up with!

nspawn isn't for production use, or so says Lennart Pottering, numerous times.

That list of binaries is what is included in Debian Sid unstable. It's not hundreds of binaries. Heck, I've even listed a deprecated one there. If you disagree, it's easy to disprove me: list them.

You quoted the commentary of someone who strongly disagrees with socket activation. I'd assumed you quoted it because you agree. You also asked me if I "even knew what it was", which I do :-)

There is one binary that runs PID 1. The original argument speaks of PID 1 as a key problem, which is the reason most folks don't like systemd.

By dynamic event I mean an event such as a hardware device starting a service, a timer event initialising a service, etc.

Your entanglement argument uses an example that is incorrect, I didn't make this up :-) that's your argument, not mine!

Not all arguments against systemd are misguided. When I first learned systemd ran as PID 1 for what I though was everything, I was concerned. Then I looked into it further and it was all piss and wind, so far as I'm concerned. The one that I find most conducive is binary logs, I'm not a fan. But that seems to be the only thing that even folks like Linus talk about. His real beef is that some of the devs were being dicks, which is really a very Gnome like mentality.

You read into their documentation. They phrase things badly, and those looking for it read into that which I'd not there - like your claims about syslog compatibility, which you can't seem to back up.

Any ctl program needs a way of signalling to the daemon to change its state. Systemd uses dbus: so? What's the issue you have with that?

Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either, it just so happens that because it is PID 1 then it's what becomes the parent by default - unless you have a kernel > 3.4 and as you say the child reaper big is set on the parent process.

You seem to have a problem with a process running PID 1 handling dynamic events like hardware changes. I don't think you've given particularly strong reasons why.


Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions. I've had enough of it, so this will be my last reply.

I've responded to the dependency list being outdated - I asked you to provide me with a later dependency list. I still am - given you stated hundred of binaries, when there aren't I'm curious what you'll come up with!

Where did I say hundreds? I said -likely- reaching a hundred. Single.

There is no official count - the article you linked was written with a special purpose. Nonetheless, I took an i386 experimental deb for systemd-219 (https://packages.debian.org/experimental/i386/systemd/downlo...) and roughly counted 77. I'm not sure what build was actually run (number could be lower than total), and due to the quick unveiling of new interfaces, the number has been higher at one point. Things move fast at systemd, and the fact that you linked an article measuring 204 as evidence for the present shows you're simply out of touch.

nspawn isn't for production use, or so says Lennart Pottering, numerous times.

Well, then it seems everyone is violating that quite tremendously. CoreOS must be incompetent, I don't know.

It's not hundreds of binaries

Nowhere did I say such.

Your entanglement argument uses an example that is incorrect, I didn't make this up :-)

So the fact that systemd, the PID1 which handles both the system state and the OS process state at the same time, isn't true? Bullshit. Deliberately misreading me to push your agenda.

When I first learned systemd ran as PID 1 for what I though was everything, I was concerned. Then I looked into it further and it was all piss and wind, so far as I'm concerned.

Well, of course. systemd doesn't put everything into PID1. That you're picking to focus on this low fodder argument out of everything that has been said by more acquainted people is just disingenuous.

like your claims about syslog compatibility, which you can't seem to back up.

I never mentioned anything about compatibility with syslogd.

Any ctl program needs a way of signalling to the daemon to change its state. Systemd uses dbus: so? What's the issue you have with that?

Now, this, is a total non sequitur. As in, you completely and horrendously misread everything that I said and deliberately projected your own biases into it. This isn't worth responding to simply because it's based on your own odd incredulity.

Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either...

Where the hell did I say any of this? I specifically mentioned they get reparented to init(8), and nothing about zombies. Once again, putting words in my mouth.

I've had enough of this nonsense.


Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions. I've had enough of it, so this will be my last reply.

I could characterise your responses the same way :-)

Where did I say hundreds? I said -likely- reaching a hundred. Single.

Even over one hundred is way off. There are now 76, I checked myself.

There is no official count - the article you linked was written with a special purpose. Nonetheless, I took an i386 experimental deb for systemd-219 (https://packages.debian.org/experimental/i386/systemd/downlo...) and roughly counted 77. I'm not sure what build was actually run (number could be lower than total), and due to the quick unveiling of new interfaces, the number has been higher at one point. Things move fast at systemd, and the fact that you linked an article measuring 204 as evidence for the present shows you're simply out of touch."

You were close: 76 binaries. Of which the new ones are some extra utilities. Things don't move that fast, and they haven't been increasing their scope - it's stayed pretty much the same as what it was at version 204. I currently have systemd v208 installed, but out of curiousity I checked what libaries it links to:

  0x0000000000000001 (NEEDED)             Shared library: [libsystemd-daemon.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libudev.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libwrap.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libpam.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libaudit.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libkmod.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libdbus-1.so.3]
  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
  0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
Then I checked systemd version 219 - exact same libaries.

nspawn isn't for production use, or so says Lennart Pottering, numerous times.

Well, then it seems everyone is violating that quite tremendously. CoreOS must be incompetent, I don't know.

By "everyone", you mean CoreOS, right? CoreOS contribute to systemd, they probably know what they are doing. The man page does say "systemd-nspawn - Spawn a namespace container for debugging, testing and building" and also "Note that even though these security precautions are taken. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container." I'd certainly hope anyone who uses it in production had read the man page first. If not, yeah - must be incompetent.

So the fact that systemd, the PID1 which handles both the system state and the OS process state at the same time, isn't true?

Can't follow what you are trying to say here. systemd is not a proposition. Could you restate that?

That you're picking to focus on this low fodder argument out of everything that has been said by more acquainted people is just disingenuous.

"Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions."

I never mentioned anything about compatibility with syslogd.

Yeah, you did actually. You said "journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard."

Now, this, is a total non sequitur. As in, you completely and horrendously misread everything that I said and deliberately projected your own biases into it. This isn't worth responding to simply because it's based on your own odd incredulity.

You wrote "For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.", which is wrong and you admit that you need to look into this more closely. I mentioned systemctl thinking that you believed that launchctl parsed the configuration files for launchd and somehow launchd communicated with this to get the configuration info. Of course, I assumed that's what you thought - otherwise what was your point? systemctl also parses configuration info. Maybe I got the wrong end of the stick, but given you were wrong in the first place I'm not sure what point you were making now.

In this case, it's less that I deliberately misread you, it's more that you weren't very clear!

Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either...

Where the hell did I say any of this? I specifically mentioned they get reparented to init(8), and nothing about zombies. Once again, putting words in my mouth.

In case you aren't following along: an orphaned process won't get reaped. You stated that "init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.)". You probably meant that init reaps zombie processes - you can't reap an orphaned process, an orphaned process is still running and is reparented by the kernel to PID 1. init doesn't do this.

You were therefore wrong on two counts:

1. The kernel detects when a process is orphaned and reparents to PID 1, which just happens to be init. init doesn't actually do any reparenting, which is sort of key to your argument as you believe that init should be the process that reparents a process when it's parent dies.

2. An orphaned process doesn't get reaped, because it's still running. A zombie process is one that has exited but is still in the process table and the parent process hasn't reaped it yet. You don't seem to understand the difference between the two, so I explained it. I'm explaining it again.

I've had enough of this nonsense.

That's good to know, so have I :-)


> Systemd itself is a monster running as PID 1

I have yet to see a convincing argument for this. Is the binary bigger than other inits? Does it do that much more? Link please.



Extremely outdated. In the 15 versions since then, systemd has evolved quite tremendously with too many things to list succinctly.


Ok, I'll bite. What does systemd itself link to now?


  0x0000000000000001 (NEEDED)             Shared library: [libsystemd-daemon.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libudev.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libwrap.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libpam.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libaudit.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libkmod.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libdbus-1.so.3]
  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
  0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

They've replaced libattr with librt, otherwise the linked libraries are the same. Also, the package dependencies are the same.

What's this about being out of date? Systemd changes very fast, but no additional libraries are linked to and one was changed, and no additional package dependencies required.

I'll have a look at interface changes next.


So, not that many major changes:

205:

* systemd-machined daemon added for VMs

* systemd-run utility added for transient units

* added scope, slice and transient units

* some new functions added

206:

* new features added

* no new binaries or files

207:

* new tool for save/restore backlight across reboots added

* variety of tweaks and changed - none effect the interface

208:

* tweaks, bug fixes but no interface changes or additional files/dependencies added

209:

* introduced systemd-networkd component

* systemd-socket-proxy for added to help services that can't support socket-activation natively

* rfkill utility added

* 3 new API headers

210, 211

* no new files, no interface changes, no dependency changes

212:

* systemd-journal-remote added

* some new functions added

* No new dependencies

213:

* new timesync daemon added

* new systemd-resolved added

214:

* Dependency on libattr dropped

215:

* no new files, no interface changes, no dependency change

216:

* networkctl tool added

* systemd-firstboot component added

* bus API changes for PolicyKit

* new library systemd-terminal added

* new tool systemd-journal-upload added

217:

* systemd-consoled daemon added

* multi-seat-x tool removed

218:

* no new files, no dependency changes

219:

* new API sd-hwdb.h added

* systemd-importd for importing container images into nspawn


I get the impression, e.g. from Ubuntu's "new package format", that NIH aside (always a big factor with Ubuntu), that many of these efforts are mostly targeting "simple apps", i.e. standalone applications that don't require any kind of complicated wiring into the system. It looks like they'll still need a "real" package format to actually do things like update the system, install kernels, libraries, and dev stuff, etc.


Anything about libc will apparently be handled by special "library" packages, or bundled with the "apps" themselves.

As for kernels and such, at least with Ubuntu Snappy this will be handles in a ChromeOS like fashion. Dump the updated base system into a separate partition, change the Grub config, reboot. If the system fails to boot up it will either instruct the user (i see no admins, nor "power-users" in this scenario) to pick the failsafe/recover option, or do so automatically.

Basically you can forget everything you learned about PC or server. The future is all containers and VMs. The computational equivalent of TV dinners or canned goods.


Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands...

This is exactly the same as the virtualization scenario, where you might have hundreds of possibly vulnerable virtual-machines running under the same virtualization platform (which maybe Linux). Or lots of Docker containers, some of which may have vulnerable software.

App-containerization is usually seen as having security benefits, as it promotes isolation.

Yes, package management tools are great. Containers are also great.

I can imagine a future world in which package management tools understood containers, and could choose how to apply updates (or not!) to nested containers.


> I can imagine a future world in which package management tools understood containers

Solaris has had this with zones since, IIRC, before Oracle bought Sun.


Oh god no! Zones are cool, but package management on Solaris is pretty bad. It has improved since they built something similar to Apt, but AFAIK it doesn't have the deep understanding of Zones that I'm suggesting is desirable.


On Solaris 10 package management was generally a pain, but there was a "sparse root" kind of zone that shares /usr with the global zone, so these get the updates automatically.

http://solaris.reys.net/zones-in-solaris-10-part-three-spars...

For OpenSolaris derived products with ipkg, the documentation says that "pkg update" in the global zone will update not only the global zone but all non-global zones as well.

https://docs.oracle.com/cd/E26502_01/html/E28984/gmhaa.html


I have the feeling that things will settle into a Microsoft-like "things mostly work, most of the time, because so much effort was put into it rather than good design" kind of world. Sort of like how PulseAudio is now.

Most people are cool with that kind of OS, so I don't think there will be much more than occasional grumbling. People like me who can't stand it will all have left.


Similar feelings here, this "it kinda works"-feeling was the reason why I switched to Linux in the first place. What are your plans? Where do you go when you 'leave'?


I switched all my servers and desktops to FreeBSD. It's like going back in time in many, many good ways (commandline/text-config focus, less magic, etc.), and one bad way (HW support).


One more for FreeBSD, and the hardware support issues are a lot less frustrating than for example what I remember of Linux in the early part of the last decade. I expect with the renewed interest in FreeBSD because of systemd, that we'll see things improve greatly overall (for example the million dollar donation to the FreeBSD Foundation).


I'm also planning on switching my two Linux boxes to FreeBSD.


To a distro that doesn't force things down the throats of its users in the same degree Ubuntu et al. do. e.g. Gentoo. (You can even run a FreeBSD kernel in Gentoo if you want.)

That isn't to say it's been all rosy in Gentoo-land. It was an effort to keep Gnome3 off my system, to keep the existing Gnome2 versions of everything until MATE (and the Gentoo community packaging) was ready enough to replace Gnome2. But my system is happily free of Gnome3, systemd, and pulseaudio. And because Gentoo doesn't really have release versions, I can keep my other packages up to date indefinitely.


I do wonder how much effort and forks will be required to keep Gentoo, well, Gentoo going forwards, as more and more stuff either is either lumped into Systemd or depends on/assumes its presence.

One can already see how you at least have to keep the libsystemd package installed on Debian's latest, even if you use something other than systemd as the init etc, or else apt throws a tantrum.

http://ewontfix.com/15/ may be the most interesting read in all this. Notice how everything but dbus and the systemd lib have various issues. And if kdbus hits the kernel, systemd is poised to position itself as the mediator between (legacy) dbus and kdbus.

All in all there is some serious "one true way"-ism coming out of the systemd camp.


Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?


Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.


Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk.

The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program.

So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.


If you end up with a giant ball of hidden complexity, that's a strong indication that you're dealing with that complexity at the wrong level.

Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.


PulseAudio supports network streaming, but it's certainly not the main selling point. Important features are:

* Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well)

* Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call

* Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency


Supposedly network transparency came later.

Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call).

Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage.

Also, i don't think Alsa had dmix (user-space software mixing) at that point in time.

As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.


Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.


Particularly that it doesn't work. I always hear about people for whom It Just Works, but that hasn't been the case for me over the course of a couple handfuls of machines. For what it's worth, LP and his gang seem like people for whom "it mostly works" is satisfactory, and that's not something I'm comfortable with in something like an init system, to be frank, because what about when it doesn't? The answer there unfortunately seems to be WONTFIX or outright hostility.


Your implementation doesn't work. My question is what part of the design is flawed?


> Over the course of a couple handfuls of machines

That's more than "your implementation" considering that it spans at least ten machines across about the same number of distros including Fedora (and one FreeBSD). But it's cute that you're so quick to say it's "implementation" when it's clearly broken across so many different environments.

Pulseaudio is a stinking pile of shit.


I really like that you can now use systemd-cat with logfiles because regular cat doesn't fit anymore.


Sorry, I don't get it - systemd-cat(1) only writes into the journal, it does not read from it, so it is more a replacement for logger(1) than for cat(1) - if you do cat foo >> /var/log/messages, how do you get timestamps on the log entries, and won't your syslog implementation just overwrite that? Does anybody actually do that?


really unix philosophy, isn't it?


I'm not sure the systemd guys want to build with the unix philosophy. I don't have a definitive source (maybe SE radio podcast?) but I seem to remember one of the authors saying as much. They're more interested in what Linux can become than what unix was.

Not that I agree, but I believe that's what they said.


Most of the systemd people arguing about the unix philosophy have no idea what that philosophy is[1]. A common argument is to insist that breaking up systemd into a separate binaries made "not monolithic", while ignoring that the design is still totally interdependent.

Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it.

Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3].

/Sigh/

"Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer)

[1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html

[2] Slackware was already on version 3.0!

[3] http://0pointer.de/public/gnomeasia2014.pdf


In all honesty, people who want a working Unix would have went to a BSD or Solaris variant a while ago.

GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier.

The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.


>The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.

This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...


Lennart Poettering has a different view on Unix philosophy, it's more 'make it interesting and do what you need to'. I think nobody is right or wrong. This is all growing pain and, as I often say, at the right time I'm sure there will be tinier systemd-like built to be more Unixy (as in 'small set of smaller composable tools').


Something like systemd except being ONLY an init system would be really great.



This looks surprisingly tempting. I agree with a lot of the ideas behind systemd, but at the rate it is growing, I'm going to type this in systemd-firefox in systemd-xmonad in six months. How stable is it in practice?


I can't see why most people would want that, with the exception of replacing journald. Why strip out device init, or even timers? Swap init is less useful, but I don't see the harm.

What is it that makes uselessd attractive? And why do you consider systemd to be bloated?


I like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.


You can turn these services off :-)

http://0pointer.de/blog/projects/three-levels-of-off


I know, but I still don't think they belong under the same umbrella.


That's just not their plan. They want to modernize and standardize (to reduce fragmentation) the whole userspace. Replacing init is a big, but far from the only part of the process.


I challenge you to show me what part of systemd isn't directly related to inititialization of services.


Maybe the parameters and interface will simplify over time. Patterns emerge with use.


Yeah, that doesn't answer my question. What isn't necessary?


I don't know all of systemd but :

  - journal
  - networkd
  - console
Are already far from generic system config/init parts. These components are very nice and cleaner than older alternatives but it feels like unnecessary coupling. Also every release added magic variables to handle corner cases. They're proficient but complexity is increasing.


journald, logind. chrooting (nspawn). tty-ask-password-agent.


nspawn inits. journald - fair point. logind inits. systemd-tty-ask-password-agent is a password agent that handles password requests of the system, for example for hard disk encryption passwords or SSL certificate passwords that need to be queried at boot-time or during runtime.


Sounds exactly like the Unix philosophy - cat is to concatenate files or standard input to standard output. If you took the binary format of systemd log files then it would output binary data to stdout.

Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Unix philosophy but rather the design decisions of systemd.


Doug McIlroy (the inventor of Unix pipes) included this in his description of "the Unix philosophy":

> Write programs to handle text streams, because that is a universal interface.

ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming:

> Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats.

> Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools.

(And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)


Well, I guess you are also against SQL databases, aren't you ;).

grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.


The tool being criticised outputs as a text stream. Which can then be used by every utility you have referenced. I'm still not following what the issue is here?


That's because cat is unixy. You can concatenate any file to any file with it. That doesn't mean those files are unixy, it means the program is unixy.


Not sure I understand your point. You just stated the purpose of cat, the tool being criticised isn't cat (so badly named) but does one job well - output binary logs into textual form onto standard output.


Surprising, what does `systemd-analyze blame` says ?


Oh neat, had no idea about that command. Looks like these two are the big time sinks:

6.340s systemd-udev-settle.service

6.232s NetworkManager-wait-online.service

Everything after that is under 250ms or so. Interesting that udev and network manager are taking so long during boot.


NetworkManager, and most other net daemons suck. I had almost lost hope till I found connman [1].

It's implemented by Intel and used in many mobiles. It has it's own _absurdly_ fast DHCP client. It manages many network interfaces flawlessly and it's really lightweight. Give it a try.

[1] https://01.org/connman


That same insanely fast DHCP client library now powers systemd-networkd[1]. We have been using it as the default on CoreOS for quite a number of releases now.

[1] https://coreos.com/blog/intro-to-systemd-networkd/


udevsettle is a hack that waits for the kevent queue to finish. I believe the justification for it was that certain volume and storage technologies on Linux act in a synchronous probing fashion that expect all devices to be up simultaneously before initializing. It's frequently mentioned as a bottleneck, including here: https://wiki.freedesktop.org/www/Software/systemd/Optimizati...

As for NetworkManager's wait online service, see what timeout has been set inside the unit file, and try lowering it. Though I suspect this might be yet another hack implemented as a synchronization point for network-dependent services to initialize properly, given just how finicky it is to define what a "network is up" state actually entails.


I'm still a systemd noob but I've heard there are ways to avoid blocking on network connectivity. Hopefully you'll forget about that part.

udev-settle seems to be a workaround LVM not being event driven enough http://freedesktop.org/wiki/Software/systemd/Optimizations/

https://bbs.archlinux.org/viewtopic.php?id=189369

Using arch, systemd boot time is now almost inexistant (but I have a tiny system with a SSD).


Voted down once, but most of the comments seem centered on desktop versus actual server installations.

"pulse audio", "gnome 3", etc.

How many people have experience with running systemd based servers in production and, if appropriate, at scale?

Thoughts?

Comparisons with tried and true components like syslog?


we run a ~70 node system, ~95% virtual/5% physical, almost fully converted from Scientific Linux 6 to CentOS 7 (only the NFS boxes left!), which is systemd based.

Concerning systemd as an init system, it's been extremely reliable and simple to use and manage. Writing unit files, even ones with complex requirements, is incredibly easy, because the FDO documentation is really terrific. For instance, we have a host running docker for services that are contingent on an NFS mount being present on the host: specifying a requirement on the mount-point for the docker service to boot-up is as simple as creating a docker.service.d directory and writing a 2-line drop-in unit file with RequiresMountsFor=/mount/path. Being able to add this functionality so easily, without having to assume total ownership of managing the rest of the service configuration really struck me as exemplary of the reasons systemd won the init wars. It really feels like it bends over backwards to help administrators get shit done, and done right.

Systemd also provides a lot more visibility into service behavior than other init systems i've worked with (logs tailed in status output, exit codes, real pid tracking, etc), which is very helpful in day-to-day work as an administrator. I'm also pretty regulary surprised by how fast our servers reboot, though that's a rather minor benefit. Mount units work just like it says on the tin, not much to report. We haven't started using any of the other systemd stuff like timers, but may do so as we encounter use-cases where it's preferable.

On the flip side, I'm not especially keen on journald. It makes it pretty rough to do system log aggregation out of the box. There's some plans to add the ability to forward logs to a remote server, but it's not there yet on CentOS. Rsyslog has nice integration on CentOS that can help make things resemble a more traditional log structure, but I can't speak to it's viability as we ended up using a more lightweight solution that uses journalds option to forward all message via syslog over a local socket (/run/systemd/journal/syslog) as an input for our log aggregator. It's irritating on occasion, but we've never not been able to work around it, and i'm confident that things will get better going forward, as journald gets more features and more log aggregators add support for polling the journal.

most importantly, i am really looking forward to Ubuntu 16.04 coming out with systemd, at which time Ubuntu, Debian, CentOS and more will all use the same init system in an LTS release. as a regular author of open-source chef cookbooks, it's exciting to think of a future where there's enough x-platform consistency that it's no longer necessary to special-case service management. along this same line, systemd unit aliases are also pretty awesome, and i hope package maintainers in both the rpm and deb world start working to add aliases for divergently named services (apache2 vs httpd, mysql vs mysqld, etc.).

ultimately, we're not dogmatic about the philosophy arguments, most of which at this point strike me as sour grapes. i just want a system that works reliably, is well documented, and makes it easy for me to get shit done. systemd fits that bill better than its predecessors, so we're happy using it until something better comes along :)


I may be showing my gray ear hairs, but I remember the early days of Gentoo where ZOMG boot 3ms faster by optimizing! The init portion of systemd reminds me of those days.

Your mention of requirements for service execution is certainly an interesting avenue for me to think about.

Honestly for my day to day "spin up VM, do some experiments/coding, fine tune" it doesn't matter. For some other work I am doing dealing with longer term system maintenance/administration, I've been slow to adapt.

Thanks for the insights.


> The init portion of systemd reminds me of those days.

There is quite a big difference in that systemd was never designed to boot fast - it was designed first and foremost to boot correctly, and the much increased performance was mostly a happy accident of the design they came up with.


This isn't backed up by Lennart's own blog post about the initial Systemd development:

> Unfortunately, the traditional SysV init system was not particularly fast.

> Another thing we can learn from the MacOS boot-up logic is that shell scripts are [...] slow in execution.

> it is also our plan to experiment with systemd not only for optimizing boot times

It seems like the real motivation was exactly reversed from your comment - speed first, and correctness as a happy accident.

He does put up a later post (biggest myths about systemd) some three years later which tries to change this impression, but that reads much more like an attempt to move the goalposts than an actual design goal.

http://0pointer.de/blog/projects/systemd.html


You have a point - clearly my comment over-stated it - let's say that both correctness and performance were design goals.

At the time Upstart was considered "the future" ... read the comment from Scott James Remnant on this post (unfortunately there doesn't seem to be a way to link to a G+ comment directly?):

https://plus.google.com/+KaySievers/posts/C3chC26khpq

The point is that Upstart's event model was found to be flawed, and the copyright assignment policy meant that fixing Upstart was undesirable.

This explains the filesystem problem (both relevant for reliability and performance) and claims that systemd solves it but Upstart cannot:

https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...


I've used distributions w/ systemd on a number of virtual machines, but those have mostly been non-critical machines.

I was slowly moving back to FreeBSD from Ubuntu/Debian. Systemd has moved that timing forward. Boot up time and monolithic systems don't do it for me -- managable sure -- but not my cup of tea.


Interesting that now distros can list this as a big feature: systemd-free.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: