20 ms·

Systemd: The Biggest Myths

131 points by janerik 14y ago

mhurron 14y ago
> systemd being Linux-only is not nice to the BSDs. >Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it systemd is not portable, it wasn't made to be portable, it relies on far too many linuxisms. Therefore the BSD's don't care about it. It is not 'the BSD's don't care about it so we didn't make it portable.'
- mseepgood 14y ago
  They would never use a new GPL licensed project for their core OS.
- diegocg 14y ago
  I disagree, I think that Lennart is right. Nobody really cares if systemd is not portable. Upstart was not portable to BSDs, and nobody cared. The traditional sysvinit system was, AFAIK, not portable until the debian/freebsd people bothered about it. Heck, the init scripts in Linux used to be not portable even between different Linux distros. launchd (OS X) and SMF (solaris) weren't portable, either. By the way, when was the last time a BSD operating system cared about making their init system portable to Linux? I'm not sure why systemd not being portable to other operating systems is suddenly a big deal.
  - 4ad 14y ago
    You can write software ignoring how it will be started and you (or others) can write init scripts for various traditional systems. This is way harder if you use systemd; suddenly you need to care about the init system, and you might sacrifice init independence for pragmatic reasons (I want to support systemd, but I don't want to write this yet-another-abstract-wrapper-layer so that someone else might use it with other type of init system).
    - jeltz 14y ago
      Why would systemd suddenly change this? It is one of the init systems with best backwards compatibility with sysvinit. And writing a systemd init configuration for your daemon is trivial and it is also easy to maintain.
    - cnvogel 14y ago
      You always had to care about the init-system: There are some differences between e.g. debian and redhat (start-stop-daemon only on debian, tools for creating the symlinks to install a service), then there's upstart with a different shell-script-esque syntax. To support systemd, the number of configs you provide will go from maybe 4 to 5, not from 1 to 2! And, looking at the examples provided by ArchLinux, the systemd services look as if they are a lot less boiler-plate than the typical debian init-script. https://wiki.archlinux.org/index.php/Systemd/Services https://wiki.archlinux.org/index.php/Systemd/Services (e.g. dropbear is very simple)
      - X-Istence 14y ago
        No, generally you didn't have to care about the init-system unless you wanted to provide an init script. But it didn't matter how your daemon was/is started. With systemd that is no longer the case, you can use certain systemd only features thereby locking out people that want to use your service/daemon without systemd.
  - mhurron 14y ago
    > I'm not sure why systemd not being portable to other operating systems is suddenly a big deal. Because software being written that has systemd as a dependency will be Linux only software.
    - diegocg 14y ago
      > Because software being written that has systemd as a dependency will be Linux only software. And this is news, and suddenly it's systemd's fault? If you hate Linux-only software, software that depends on systemd is the last of your problems. Software that depends on glibc and the Linux kernel are probable the main offenders.
      - 4ad 14y ago
        There are currently 23946[1] FreeBSD ports. Nothing I ever needed in the last 15 years of using FreeBSD was missing. Yes, dependency on glibc and the Linux kernel is sometimes annoying, but in practice it is not an insurmountable problem. Dependency on the Linux kernel is rare and dependency on glibc can usually be easily fixed and upstream is usually happy to accept patches. Systemd is different because there is a lot of software that might decide to use it and you can't just work around it. [1] http://www.freebsd.org/ports/ http://www.freebsd.org/ports/
      - X-Istence 14y ago
        Generally when software relies on glibc or the Linux kernel it can be patched so that it works on the BSD's. In my time of porting to OS X for example I haven't had anyone not take my patch to fix a problem an upstream it with a "thanks!". This becomes more problematic with systemd, whereby we can't port systemd, and since the software depends on systemd (most likely for some reason or another the software developer thought it was a good idea) we can't easily replace/rip out those parts of the code and make it run on the BSD's.
      - deleted 14y ago
        [deleted]
  - jeltz 14y ago
    The only one greatly affected by systemd not being portable is Debian. Their BSD distribution uses the Debian version of sysvinit.
- stox 14y ago
  Pretty much a self fulfilling prophecy.
- X-Istence 14y ago
  The BSD folks may not be interested in systemd itself, we are still interested in running various bits and pieces of software on top of the platform. When software starts requiring systemd just to run we have no chance what so ever at porting that software. The same is true for a lot of Linuxisms. I have spent an awful lot of time getting software that states on the tin it is written for POSIX to run on BSD because its source code uses all kinds of Linuxisms. The same holds true for people assuming that /bin/sh is bash, which may be true on certain Linux distributions but isn't so most other systems. I've started noticing the same issues with other things as well, such as the symlink from /bin to /usr/bin, /sbin to /usr/bin ... whereby software believes all software lives in /usr/bin when in reality that isn't the case for the BSD's.
curlypaul924 14y ago
I don't want systemd because I don't trust Lennart Poettering to be able to write reliable code.
- chris_wot 14y ago
  Why the heck do people whale on him so much?
  - betterunix 14y ago
    Well, consider his response here: https://bugzilla.redhat.com/show_bug.cgi?id=461546 https://bugzilla.redhat.com/show_bug.cgi?id=461546 First, he denies that this is something people need. Then, when he is told that people need it, he says that they are just doing things the wrong way. Then, when people point out that this is neither unusual nor the wrong thing to want to do, he just repeats that this is not what was intended so too bad. He offers no advice on how to do things the right way despite being the only person who seems to think that everyone else is wrong.
    - glogla 14y ago
      Yes, that bug discussion show very well what's wrong with Lennart and his software.
      - mverwijs 14y ago
        I also find it telling how he closes the ticket asking everyone to go upstream and use PulseAudio's ticket system (http://www.pulseaudio.org/ticket/606 http://www.pulseaudio.org/ticket/606), which gives me this error: ------------------------------- Internal Server Error TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION' -------------------------------- That kind of sums up.
        chris_wot 14y ago
        He doesn't run a bug tracker any more?
betterunix 14y ago
Will they have the same attitude as the ConsoleKit/PolicyKit/_Kit people have when someone says, "I need to do something different, but this service is preventing me from doing it?" As an example, I want to set up my system so that one user can play audio even when a different user is "active," yet after hours reading through bug reports about that and mailing list archives, all I could find where these responses: * "Not our fault, it's that other service." * "We are never going to support that. You don't want it anyway." * "Well that will be fixed with systemd" * "You can add the user to the audio group, but that's wrong and you should not do it. You should instead do that thing that the other guys are telling you not to do and that they will never support." * "This will be fixed with systemd!" So, I guess now the question is, when someone comes along and says, "I need to do X, I used to be able to do X before systemd was in use and now systemd is stopping me, how can I fixed that?" will systemd maintainers respond with things like the above? Will there be useful and thorough documentation, so that users can fix things without having to bug the maintainers?
mseepgood 14y ago
Most "arguments" I read are are either ad-hominem or ad-pulseaudionem attacks.
- fosap 14y ago
  I don't see a single ad-hominem. And ad-pulseaudionem is just like a ad-networkmanagerem or a ad-dbusiem: If your software design sucks and it does not work good enough that you don't have to care about this you will be told it sucks. And to me it seems that systemd is written in the spirit of dbus and nm.
zdw 14y ago
Given the title, I'll allow that most of these points are defensive and brusque. Unfortunately, this tends to be par for the course for the developer, and I think that turns people off. Fundamentally, systemd tried solving too many problems at once, in a ways that inadvertently annoyed people. It replaced so much of the core infrastructure that upgrading systems resulted in an admin experience that feels alien. Giving people new tools to deal with things like binary logging != instantly changing every admin's CLI muscle memory. I'm not saying that systemd doesn't solve valid problems (the issues it addresses are truly quite important) - it just goes about it in a dramatically jarring way.
- diegocg 14y ago
  >Given the title, I'll allow that most of these points are defensive and brusque Not really...
- mseepgood 14y ago
  > most of these points are defensive and brusque I prefer reading "This is wrong, because ..." over "This is right, but ...", since it's more honest.
  - jeltz 14y ago
    The myths are a mix of those that are correct but often misunderstood and those who just are plain wrong. Those which are plain wrong cannot be responded to with "This is right, but ...".
thaumaturgy 14y ago
3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also replaced syslog, and did so with its own custom binary log format. To quote from a forum thread I started shortly after updating my old system to systemd, "Getting smbd/nmbd to work again was a real adventure. Like other users reported, it would just silently fail when starting it from systemd. No error message when issuing the start command, and only a vague "failed" in status. I ended up having to track down Lennart's blog post on "systemd for administrators" to figure out how in blazes to extract anything useful from that cussed binary log system he invented. My first half-dozen or so attempts to get anything useful out of the log journal got exactly zero results; I finally got lucky on another approach..." (I ended up abandoning that distribution altogether after that and a number of other frustrations, and the response from the forums.) 13. The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to require systemd, making that software difficult (or impossible) to port to BSD. 14. It seems weird to me to hear someone else decide for other people what is or isn't a "negligible" amount of work. 15. So ... systemd is in fact Linux-only by design. How does that jive with 13 again? 19. systemd may not "force" you to do anything, up until your distribution adopts it, pushes it as an update, and then you find yourself spending hours trying to figure out how to troubleshoot a problem that didn't exist before the update. Then it certainly is forcing you to do something. Here's the problem in a nut shell as I see it: if systemd had been the default in Linux for the last ten years, probably the tool chain around it would be mature enough to meet everyone's needs, we would all be accustomed to the specific commands needed to control and interact with and debug systemd stuff, and if someone came along and proposed replacing everything with a syslog daemon and a pile of init scripts, there'd be rage and outcry. That is to say, I don't see anything inherently bad about systemd. But, what is enormously frustrating is to have something that works, and be well adapted to it, so that if something breaks I know exactly where to look, and then have all of that be replaced by a foreign system that breaks old things in new ways and requires hours spent trying to figure out what the hell happened. If the replacement system offers serious benefits over the old system, that offsets the pain slightly. In this case, I've yet to see what the actual benefits are; I have no idea what problems systemd is attempting to solve which are so severe, so immediate, so intractable that they require a jarring change to some of the fundamental parts of the operating system.
deleted 14y ago
[deleted]
lucian1900 14y ago
The intensity of people's hate for this guy is mind-boggling. Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues. Even without such an impressive track-record, people should at least give him the benefit of the doubt. Even a cursory look into systemd design debunks most of the "criticism" people have against it.
- betterunix 14y ago
  "Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues." Without issues? PulseAudio is loaded with issues. The only time PA works correctly is when you are doing things the way Lennart thinks you should do them -- which is basically the way desktop Windows and Mac OS X users are expected to do things. Another way to put things is this: Lennart's software designs dictate how users should use their computer, to the exclusion of all other use-cases. Doing something cool or unusual with PulseAudio is like pulling teeth.
  - the_mitsuhiko 14y ago
    Pulse Audio is not perfect but what before was. People were bitching about PA and wanted OSS back. I seriously doubt that many of those actually do anything reasonable with audio.
    - gnosis 14y ago
      "I seriously doubt that many of those actually do anything reasonable with audio." Actually, serious audio work on Linux is done with JACK. PulseAudio is completely inadequate for serious audio work.
      - andor 14y ago
        You're stating it as if it were a shortcoming of PulseAudio. PA is inadequate for most audio work, because the latency is too high -- which is a feature. Latency vs. CPU usage is always a compromise. To achieve low latency, you need very small buffers for "rendered" audio, and lots of well-timed copy operations to the audio hardware. To just play some audio files efficiently, you want large buffers, because then fewer copy operations are necessary. Here's a better explanation by Lennart Poettering: http://0pointer.de/blog/projects/when-pa-and-when-not.html http://0pointer.de/blog/projects/when-pa-and-when-not.html
ragenz 14y ago
Myth 31: "I heard it was written by web developers."
- sparkie 14y ago
  No, that's Gnome-shell.
howeyc 14y ago
> 13. Myth: systemd being Linux-only is not nice to the BSDs. > Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. > 15. Myth: systemd could be ported to other kernels if its maintainers just wanted to. > That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. So what happens to software written for Linux that can be (and currently is) ported to BSD when it starts to require systemd?
- nona 14y ago
  If it starts to rely on systemd, the question you should be asking, is: why does this program want to depend on systemd? It's to interact with the lower plumbing - ie. set up hostname, locale, timedate, multi-seat etc. If these interfaces are missing, the software should still work minus a few missing features. Applications could still #ifdef all they want to make things work on BSDs, no change there either. Or the BSDs could make their own implementation of the plumbing interfaces. Lennart even provided a handy chart: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... Honestly, it's about time we standardize and stop wasting time on these low-level things. I'd rather work on software higher up in the stack, than wasting my time working around trivial differences between the Linux distros (bonus points if they get adopted on other the BSDs too). But that's just me.
ElliotH 14y ago
Benefits to me as a desktop and laptop user of systemd. 1) Speed does matter. Fast boots are good. 2) The new journal is just better. Finding something in the logs is easier. 3) Service files are easier to write than init scripts and one can have more confidence they will work as intended as you need write very little configuration oneself. 4) Knowledge of dependencies means I never have to worry about starting dbus before gdm. It just does what is necessary to do the correct thing. I personally want all of those things. I am really happy they came to Arch and Fedora. They both feel much more modern for it. Working on systems that use older init systems now feels archaic. Let's move with the times. I remember the same set of complaints when we got NetworkManager. I remember the same complaints with PulseAudio. Guess what? I now have systems with excellent networking and excellent sound.
- thaumaturgy 14y ago
  NetworkManager is still popularly referred to as "NetworkMangler", and for good reason. I had serious problems with NetworkMangler on two completely different distributions over a period of two years. I finally solved the NetworkMangler issues by switching to Wicd; its interface is crude and ugly, but it damn well works. I haven't had to restart my laptop to get a working network connection since. If NetworkManager is an example of how great systemd can be, then I just became vehemently opposed to it.
- fosap 14y ago
  >I remember the same complaints with PulseAudio. And this is perfectly the reason number two why i won't switch to systemd (reason number one is there is no need for it). PulseAudio does not work. It sucks. The irc channel is full of clueless (but trying to be helpfull) people. And nobody cares. I want my Alsa back. But now it's too late, i hope systemd will either be better (doubt it) or never be this popular. And, I cannot lie, I don't want it because I don't want another dbus. freedesktop, stop turning my linux into a single user os. Next thing is they want to abolish x11. Sure it's about time for x12, but wayland? I just don't understand the community that surrounds Linux anymore.
  - bkor 14y ago
delinka 14y ago
6. Myth: systemd is not modular. Not true at all. At compile time you have a number of ... So it's only modular at compile time. This seems like a negative to me.
- bkor 14y ago
  You can also disable various things during runtime. A->B does not imply B->A.
  - delinka 14y ago
    It's not assumption by implication, it's due to omission. I cannot assume a feature exists in your software, you must tell me it exists. As a contrived example, why would I expect your To Do List app to manage recipes?
Niten 14y ago
This article from last August hits the nail on the head with regard to systemd: http://www.pappp.net/?p=969 http://www.pappp.net/?p=969 "I’m not sure that this is a bad design, but it is most definitely not UNIX or anything like it."
- bkor 14y ago
  The blogpost already addresses everything that above article gets wrong.

131 points by janerik 14y ago

> systemd being Linux-only is not nice to the BSDs. >Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it systemd is not portable, it wasn't made to be portable, it relies on far too many linuxisms. Therefore the BSD's don't care about it. It is not 'the BSD's don't care about it so we didn't make it portable.'

mseepgood 14y ago
They would never use a new GPL licensed project for their core OS.
diegocg 14y ago
I disagree, I think that Lennart is right. Nobody really cares if systemd is not portable. Upstart was not portable to BSDs, and nobody cared. The traditional sysvinit system was, AFAIK, not portable until the debian/freebsd people bothered about it. Heck, the init scripts in Linux used to be not portable even between different Linux distros. launchd (OS X) and SMF (solaris) weren't portable, either. By the way, when was the last time a BSD operating system cared about making their init system portable to Linux? I'm not sure why systemd not being portable to other operating systems is suddenly a big deal.
- 4ad 14y ago
  You can write software ignoring how it will be started and you (or others) can write init scripts for various traditional systems. This is way harder if you use systemd; suddenly you need to care about the init system, and you might sacrifice init independence for pragmatic reasons (I want to support systemd, but I don't want to write this yet-another-abstract-wrapper-layer so that someone else might use it with other type of init system).
  - jeltz 14y ago
    Why would systemd suddenly change this? It is one of the init systems with best backwards compatibility with sysvinit. And writing a systemd init configuration for your daemon is trivial and it is also easy to maintain.
  - cnvogel 14y ago
    You always had to care about the init-system: There are some differences between e.g. debian and redhat (start-stop-daemon only on debian, tools for creating the symlinks to install a service), then there's upstart with a different shell-script-esque syntax. To support systemd, the number of configs you provide will go from maybe 4 to 5, not from 1 to 2! And, looking at the examples provided by ArchLinux, the systemd services look as if they are a lot less boiler-plate than the typical debian init-script. https://wiki.archlinux.org/index.php/Systemd/Services https://wiki.archlinux.org/index.php/Systemd/Services (e.g. dropbear is very simple)
    - X-Istence 14y ago
      No, generally you didn't have to care about the init-system unless you wanted to provide an init script. But it didn't matter how your daemon was/is started. With systemd that is no longer the case, you can use certain systemd only features thereby locking out people that want to use your service/daemon without systemd.
- mhurron 14y ago
  > I'm not sure why systemd not being portable to other operating systems is suddenly a big deal. Because software being written that has systemd as a dependency will be Linux only software.
  - diegocg 14y ago
    > Because software being written that has systemd as a dependency will be Linux only software. And this is news, and suddenly it's systemd's fault? If you hate Linux-only software, software that depends on systemd is the last of your problems. Software that depends on glibc and the Linux kernel are probable the main offenders.
    - 4ad 14y ago
      There are currently 23946[1] FreeBSD ports. Nothing I ever needed in the last 15 years of using FreeBSD was missing. Yes, dependency on glibc and the Linux kernel is sometimes annoying, but in practice it is not an insurmountable problem. Dependency on the Linux kernel is rare and dependency on glibc can usually be easily fixed and upstream is usually happy to accept patches. Systemd is different because there is a lot of software that might decide to use it and you can't just work around it. [1] http://www.freebsd.org/ports/ http://www.freebsd.org/ports/
    - X-Istence 14y ago
      Generally when software relies on glibc or the Linux kernel it can be patched so that it works on the BSD's. In my time of porting to OS X for example I haven't had anyone not take my patch to fix a problem an upstream it with a "thanks!". This becomes more problematic with systemd, whereby we can't port systemd, and since the software depends on systemd (most likely for some reason or another the software developer thought it was a good idea) we can't easily replace/rip out those parts of the code and make it run on the BSD's.
    - deleted 14y ago
      [deleted]
- jeltz 14y ago
  The only one greatly affected by systemd not being portable is Debian. Their BSD distribution uses the Debian version of sysvinit.
stox 14y ago
Pretty much a self fulfilling prophecy.
X-Istence 14y ago
The BSD folks may not be interested in systemd itself, we are still interested in running various bits and pieces of software on top of the platform. When software starts requiring systemd just to run we have no chance what so ever at porting that software. The same is true for a lot of Linuxisms. I have spent an awful lot of time getting software that states on the tin it is written for POSIX to run on BSD because its source code uses all kinds of Linuxisms. The same holds true for people assuming that /bin/sh is bash, which may be true on certain Linux distributions but isn't so most other systems. I've started noticing the same issues with other things as well, such as the symlink from /bin to /usr/bin, /sbin to /usr/bin ... whereby software believes all software lives in /usr/bin when in reality that isn't the case for the BSD's.

curlypaul924 14y ago

I don't want systemd because I don't trust Lennart Poettering to be able to write reliable code.

chris_wot 14y ago
Why the heck do people whale on him so much?
- betterunix 14y ago
  Well, consider his response here: https://bugzilla.redhat.com/show_bug.cgi?id=461546 https://bugzilla.redhat.com/show_bug.cgi?id=461546 First, he denies that this is something people need. Then, when he is told that people need it, he says that they are just doing things the wrong way. Then, when people point out that this is neither unusual nor the wrong thing to want to do, he just repeats that this is not what was intended so too bad. He offers no advice on how to do things the right way despite being the only person who seems to think that everyone else is wrong.
  - glogla 14y ago
    Yes, that bug discussion show very well what's wrong with Lennart and his software.
    - mverwijs 14y ago
      I also find it telling how he closes the ticket asking everyone to go upstream and use PulseAudio's ticket system (http://www.pulseaudio.org/ticket/606 http://www.pulseaudio.org/ticket/606), which gives me this error: ------------------------------- Internal Server Error TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION' -------------------------------- That kind of sums up.
      - chris_wot 14y ago
        He doesn't run a bug tracker any more?

betterunix 14y ago

Will they have the same attitude as the ConsoleKit/PolicyKit/_Kit people have when someone says, "I need to do something different, but this service is preventing me from doing it?" As an example, I want to set up my system so that one user can play audio even when a different user is "active," yet after hours reading through bug reports about that and mailing list archives, all I could find where these responses: * "Not our fault, it's that other service." * "We are never going to support that. You don't want it anyway." * "Well that will be fixed with systemd" * "You can add the user to the audio group, but that's wrong and you should not do it. You should instead do that thing that the other guys are telling you not to do and that they will never support." * "This will be fixed with systemd!" So, I guess now the question is, when someone comes along and says, "I need to do X, I used to be able to do X before systemd was in use and now systemd is stopping me, how can I fixed that?" will systemd maintainers respond with things like the above? Will there be useful and thorough documentation, so that users can fix things without having to bug the maintainers?

mseepgood 14y ago

Most "arguments" I read are are either ad-hominem or ad-pulseaudionem attacks.

fosap 14y ago
I don't see a single ad-hominem. And ad-pulseaudionem is just like a ad-networkmanagerem or a ad-dbusiem: If your software design sucks and it does not work good enough that you don't have to care about this you will be told it sucks. And to me it seems that systemd is written in the spirit of dbus and nm.

zdw 14y ago

Given the title, I'll allow that most of these points are defensive and brusque. Unfortunately, this tends to be par for the course for the developer, and I think that turns people off. Fundamentally, systemd tried solving too many problems at once, in a ways that inadvertently annoyed people. It replaced so much of the core infrastructure that upgrading systems resulted in an admin experience that feels alien. Giving people new tools to deal with things like binary logging != instantly changing every admin's CLI muscle memory. I'm not saying that systemd doesn't solve valid problems (the issues it addresses are truly quite important) - it just goes about it in a dramatically jarring way.

diegocg 14y ago
>Given the title, I'll allow that most of these points are defensive and brusque Not really...
mseepgood 14y ago
> most of these points are defensive and brusque I prefer reading "This is wrong, because ..." over "This is right, but ...", since it's more honest.
- jeltz 14y ago
  The myths are a mix of those that are correct but often misunderstood and those who just are plain wrong. Those which are plain wrong cannot be responded to with "This is right, but ...".

thaumaturgy 14y ago

3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also replaced syslog, and did so with its own custom binary log format. To quote from a forum thread I started shortly after updating my old system to systemd, "Getting smbd/nmbd to work again was a real adventure. Like other users reported, it would just silently fail when starting it from systemd. No error message when issuing the start command, and only a vague "failed" in status. I ended up having to track down Lennart's blog post on "systemd for administrators" to figure out how in blazes to extract anything useful from that cussed binary log system he invented. My first half-dozen or so attempts to get anything useful out of the log journal got exactly zero results; I finally got lucky on another approach..." (I ended up abandoning that distribution altogether after that and a number of other frustrations, and the response from the forums.) 13. The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to require systemd, making that software difficult (or impossible) to port to BSD. 14. It seems weird to me to hear someone else decide for other people what is or isn't a "negligible" amount of work. 15. So ... systemd is in fact Linux-only by design. How does that jive with 13 again? 19. systemd may not "force" you to do anything, up until your distribution adopts it, pushes it as an update, and then you find yourself spending hours trying to figure out how to troubleshoot a problem that didn't exist before the update. Then it certainly is forcing you to do something. Here's the problem in a nut shell as I see it: if systemd had been the default in Linux for the last ten years, probably the tool chain around it would be mature enough to meet everyone's needs, we would all be accustomed to the specific commands needed to control and interact with and debug systemd stuff, and if someone came along and proposed replacing everything with a syslog daemon and a pile of init scripts, there'd be rage and outcry. That is to say, I don't see anything inherently bad about systemd. But, what is enormously frustrating is to have something that works, and be well adapted to it, so that if something breaks I know exactly where to look, and then have all of that be replaced by a foreign system that breaks old things in new ways and requires hours spent trying to figure out what the hell happened. If the replacement system offers serious benefits over the old system, that offsets the pain slightly. In this case, I've yet to see what the actual benefits are; I have no idea what problems systemd is attempting to solve which are so severe, so immediate, so intractable that they require a jarring change to some of the fundamental parts of the operating system.

deleted 14y ago

[deleted]

lucian1900 14y ago

The intensity of people's hate for this guy is mind-boggling. Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues. Even without such an impressive track-record, people should at least give him the benefit of the doubt. Even a cursory look into systemd design debunks most of the "criticism" people have against it.

betterunix 14y ago
"Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues." Without issues? PulseAudio is loaded with issues. The only time PA works correctly is when you are doing things the way Lennart thinks you should do them -- which is basically the way desktop Windows and Mac OS X users are expected to do things. Another way to put things is this: Lennart's software designs dictate how users should use their computer, to the exclusion of all other use-cases. Doing something cool or unusual with PulseAudio is like pulling teeth.
- the_mitsuhiko 14y ago
  Pulse Audio is not perfect but what before was. People were bitching about PA and wanted OSS back. I seriously doubt that many of those actually do anything reasonable with audio.
  - gnosis 14y ago
    "I seriously doubt that many of those actually do anything reasonable with audio." Actually, serious audio work on Linux is done with JACK. PulseAudio is completely inadequate for serious audio work.
    - andor 14y ago
      You're stating it as if it were a shortcoming of PulseAudio. PA is inadequate for most audio work, because the latency is too high -- which is a feature. Latency vs. CPU usage is always a compromise. To achieve low latency, you need very small buffers for "rendered" audio, and lots of well-timed copy operations to the audio hardware. To just play some audio files efficiently, you want large buffers, because then fewer copy operations are necessary. Here's a better explanation by Lennart Poettering: http://0pointer.de/blog/projects/when-pa-and-when-not.html http://0pointer.de/blog/projects/when-pa-and-when-not.html

ragenz 14y ago

Myth 31: "I heard it was written by web developers."

sparkie 14y ago
No, that's Gnome-shell.

howeyc 14y ago

> 13. Myth: systemd being Linux-only is not nice to the BSDs. > Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. > 15. Myth: systemd could be ported to other kernels if its maintainers just wanted to. > That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. So what happens to software written for Linux that can be (and currently is) ported to BSD when it starts to require systemd?

nona 14y ago
If it starts to rely on systemd, the question you should be asking, is: why does this program want to depend on systemd? It's to interact with the lower plumbing - ie. set up hostname, locale, timedate, multi-seat etc. If these interfaces are missing, the software should still work minus a few missing features. Applications could still #ifdef all they want to make things work on BSDs, no change there either. Or the BSDs could make their own implementation of the plumbing interfaces. Lennart even provided a handy chart: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... Honestly, it's about time we standardize and stop wasting time on these low-level things. I'd rather work on software higher up in the stack, than wasting my time working around trivial differences between the Linux distros (bonus points if they get adopted on other the BSDs too). But that's just me.

ElliotH 14y ago

Benefits to me as a desktop and laptop user of systemd. 1) Speed does matter. Fast boots are good. 2) The new journal is just better. Finding something in the logs is easier. 3) Service files are easier to write than init scripts and one can have more confidence they will work as intended as you need write very little configuration oneself. 4) Knowledge of dependencies means I never have to worry about starting dbus before gdm. It just does what is necessary to do the correct thing. I personally want all of those things. I am really happy they came to Arch and Fedora. They both feel much more modern for it. Working on systems that use older init systems now feels archaic. Let's move with the times. I remember the same set of complaints when we got NetworkManager. I remember the same complaints with PulseAudio. Guess what? I now have systems with excellent networking and excellent sound.

thaumaturgy 14y ago
NetworkManager is still popularly referred to as "NetworkMangler", and for good reason. I had serious problems with NetworkMangler on two completely different distributions over a period of two years. I finally solved the NetworkMangler issues by switching to Wicd; its interface is crude and ugly, but it damn well works. I haven't had to restart my laptop to get a working network connection since. If NetworkManager is an example of how great systemd can be, then I just became vehemently opposed to it.
fosap 14y ago
>I remember the same complaints with PulseAudio. And this is perfectly the reason number two why i won't switch to systemd (reason number one is there is no need for it). PulseAudio does not work. It sucks. The irc channel is full of clueless (but trying to be helpfull) people. And nobody cares. I want my Alsa back. But now it's too late, i hope systemd will either be better (doubt it) or never be this popular. And, I cannot lie, I don't want it because I don't want another dbus. freedesktop, stop turning my linux into a single user os. Next thing is they want to abolish x11. Sure it's about time for x12, but wayland? I just don't understand the community that surrounds Linux anymore.
- bkor 14y ago

delinka 14y ago

6. Myth: systemd is not modular. Not true at all. At compile time you have a number of ... So it's only modular at compile time. This seems like a negative to me.

bkor 14y ago
You can also disable various things during runtime. A->B does not imply B->A.
- delinka 14y ago
  It's not assumption by implication, it's due to omission. I cannot assume a feature exists in your software, you must tell me it exists. As a contrived example, why would I expect your To Do List app to manage recipes?

Niten 14y ago

This article from last August hits the nail on the head with regard to systemd: http://www.pappp.net/?p=969 http://www.pappp.net/?p=969 "I’m not sure that this is a bad design, but it is most definitely not UNIX or anything like it."

bkor 14y ago
The blogpost already addresses everything that above article gets wrong.