8 ms·

I still don't understand why systemd sucks

JdeBP 10y ago
static linux isn't really a reaction to systemd. What it is a reaction to is exemplified both by what the blurb on its WWW spends most of its time on, and indeed by its very name: dynamic linking. "Executing statically linked executables is much faster" ... "Statically linked executables are portable" ... "Statically linked executables use less disk space" ... "Statically linked executables consume less memory" -- http://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/ http://wayback.archive.org/web/20090525150626/http://blog.ga...
- arjun1296 10y ago
  I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck.
  - modifieddog 10y ago
    > I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. If I remember correctly, the argument goes someting like this: modern compilers, i.e. something as recent as the Plan 9 toolchain or a GCC version from this millenium, usually compile in only the necessary code with static linking, and not whole libraries. With dynamic linking, you always have to load the whole library into memory, which supposedly pays off only with heavily used libraries such as libc (e.g. think about how many libraries used by Firefox/Chromium are used by other programs). So the hope is (combined with a general strive for small programs), since text pages are shared between processes and statically linked programs only include the absolute necessary code you end up with a smaller memory footprint. (I'm not sure whether you save disk space, but I don't think that would be a problem nowadays. Heck, look at go binaries.) And I guess, the linker could do more whole-program-optimization on a statically linked program, since all the coude is available. > For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck. Generally you would want to have a proper build system. In case of StaLi, they have one global git repository (/.git). An update is simply "git pull && make install". I don't know if this process is slower or faster than binary updates, but if they strive for small programs/binaries, then I guess it doesn't matter as much. Source-based distributions, such as Gentoo, have the advantage that you don't have to wait for someone to publish an upgraded binary, you can compile it yourself, instead. This might give you a slight edge for security vulnerabilities.
    - pjmlp 10y ago
      Modern compilers?! Static linking was already like that in MS-DOS compilers.
      - modifieddog 10y ago
        > Modern compilers? I was being partially ironic. It seems that the common assumption is still that you (statically) link in the whole library. Then, of course, binaries get really huge. But when you link in only what's necessary, the overhead is probably relatively small (when was the last time you used all of libc?). The other thing is (which you can see in this thread, as well), people seem to think that you can do things only the way we are doing them now without ever questioning whether these things are still apropriate and how they originally came into existence. ("There has to be dynamic linking", "we have to use virutal memory", "there have to be at least 5 levels of caches", etc.) To my knowledge, all the reasons regarding saving space, security, and maintenance were all made up after the fact (and aren't necessarily true, even (or especially) with modern implementations). Originally, dynamic linking was intended for swapping in code at runtime (was it Multics or OS/360?), which you can't do anymore today. Furthermore, dynamic linking (as it is done today) is really complex. In contrast, static linking is much simpler (=> fewer bugs/security holes). I think we should reconsider if the overhead is worth it or not (do you really care whether your binaries make up 100MB or 200MB on your 1TB HDD?). For embedded devices: yes, space does matter, but you probably don't run a full fledged Ubuntu desktop on you IoT device, anyway. You use different approaches (e.g. busybox, buildroot, etc.).
    - 0xcde4c3db 10y ago
      > you always have to load the whole library into memory Not really. You do have to mmap it, but it can be demand-paged (executables are handled this way on most modern systems, which is why compressed executables are usually a bad idea). IIRC, what saves time is mostly not having to do the actual linking part where the references are resolved. This can be precomputed and stashed in the binary (an optimization well-known to Gentoo+KDE users), but that confuses some package managers, breaks some uses of dlopen()/dlsym(), and has issues with ASLR.
striking 10y ago
Here are a pair of links that you may have missed under the "Don’t use systemd (read more about why it sucks)" line item. http://suckless.org/sucks/systemd http://suckless.org/sucks/systemd http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ The first link reads like a sort of 99 Theses, while the second is a dissertation on why people will never get along on the subject of systemd.
- anon4711 10y ago
  I take the attribution in the first link (references to "Führerbunker" and "Führer") to mean that the author is comparing Lennart Poettering to Hitler. That's not funny, it's just very, very inappropriate.
  - striking 10y ago
    I didn't write the linked content, nor did I choose the links. If you feel strongly about this, consider contacting the authors of the story.
    - anon4711 10y ago
      I didn't mean to imply that you did; sorry if that came out wrong.
justinsaccount 10y ago
Because people like to complain more than they like to actually build a usable alternative. Edit: here's a great example from one of the links in the other comment: suckless complaining about "sysv removed" in systemd. Link takes you to this changelog entry: "The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native systemd units from these scripts when needed. This enables us to remove a substantial amount of legacy code from PID 1, following the fact that many distributions only ship a very small number of LSB/SysV init scripts nowadays." So, code was removed from the init daemon itself and moved into a standalone utility that does one specific job. Systemd is now both being blamed for bloating init, and for splitting functionality out into a separate tool that does one thing.
- bnolsen 10y ago
  runit on void linux runs great. it's tiny, easy to understand and very fast. and it doesn't try to take everything over.
- clarry 10y ago
  > Because people like to complain more than they like to actually build a usable alternative. More like people have had perfectly usable alternatives but now the hivemind is more or less forcing something else onto them. I don't need to build a new init system, I have one that works, thank you. Please don't give me systemd.
  - justinsaccount 10y ago
    The one I had did not work so I am happy to have systemd now.
- qwertyuiop924 10y ago
  They built many. runit, s6, nosh, bsdinit, openrc. But yeah, it is being blamed for bloating init, because for one thing, cron isn't init's job. And that's just the start.
bitwize 10y ago
Hating systemd is like hating Hillary Clinton at this point. It's well past time to suck it up and make peace with your next init system/President because the only viable alternative(s) are far worse.
- DigitalCannon 10y ago
  Maybe they're far worse to you.. You also have the option of creating something yourself if everyting sucks so much.
- thescribe 10y ago
  As someone who has found runit to meet my needs I don't think I have any reason to make peace with systemd. I feel like part of what people object to about systemd is the 'one true way to linux' thing.
  - vacri 10y ago
    Right now what I'm objecting to with systemd is that this system replaces syslog, has been created and driven by the enterprise linux distro, with full-time experienced linux devs, and has been released and used in production for years... ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache.
    - vidarh 10y ago
      That is "replaces" syslog (you can still have it forward to syslog if you insist) is one of the best parts. After getting used to journald I have no desire to ever go back to dealing with syslog. > ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache. What are those "dirty hacks"? You can trivially use logstash or similar or you can forward log entries to a remote syslog-compatible endpoint. Incidentally the same that people usually do with syslog.
- striking 10y ago
  I cannot even begin to describe how silly your comment is. Since when were politicians even comparable to programs? Do we "elect" a init system, as one nation united under Torvalds? I'm hoping I was just trolled by an HN-flavored Markov Chain.
morganvachon 10y ago
That's a loaded question, and I'm only qualified to answer from my perspective and experience. My biggest gripe with it has always been that it is alpha-quality software, even today, that has a central role in an otherwise mature OS ecosystem. It has been widely adopted (some would say forced or tricked into adoption by a few distros) and therefore all the major Linux distributions are now running at an alpha level while its creators try to figure out exactly what they want it to be. That was the state of Linux in the late 90s, a state that it overcame during the 2000s, but now it's regressing again. First it was "just an init to replace SysV", something I could get behind, and back in 2012 or so I was actually excited about it. Then it started growing, replacing individual components of GNU/Linux with a monolithic mega-app that has more in common with Windows NT based OSes than with anything UNIX-like. Gone is the philosophy of "do one thing and do it well", replaced with "do everything no matter the quality of the results". I've always been a Slackware user since I started messing with Linux in the late 90s, and these days I find it getting faster and better while mainstream Linux distros slow down and grow more and more bugs. One of my benchmark systems for observing the growing bloat of modern OSes is an Atom based netbook from around 2010. It shipped with Windows 7 Starter, which it ran acceptably but not great. Recently I tested Windows 10, Slackware 14.2, Ubuntu 14.04, Ubuntu 16.04, Debian unstable, OpenBSD, and Elementary OS Loki on it. Slackware was the fastest OS on it by a wide margin, followed by OpenBSD, then Debian, Ubuntu 14.04, Elementary, Windows, and Ubuntu 16.04 dead last. Guess which of those (not counting Windows) do not have systemd? Yep, Slackware and OpenBSD. Maybe it's a coincidence, but given how Ubuntu 16.04 on my modern workstation gets progressively slower with each systemd update, whereas Slackware on the same machine continues to chug along with no issues, that's telling. All of that said, systemd was and maybe still is a good idea, if only they can stop trying to reinvent the wheel and instead fix the spokes they broke along the way. I can't say I'm happy about eroding the UNIX philosophy from Linux, but if systemd is the future of Linux then it damn well needs to be a stable future.
- billforsternz 10y ago
  I am puzzled that you had an Atom based netbook from around 2010 that shipped with any kind of Windows 10.
Annatar 10y ago
Because it's a Windows monolithic approach to startup, shutdown and dependency management, as well as being a poor copy of Solaris' service management facility, smf(5).

JdeBP 10y ago

static linux isn't really a reaction to systemd. What it is a reaction to is exemplified both by what the blurb on its WWW spends most of its time on, and indeed by its very name: dynamic linking. "Executing statically linked executables is much faster" ... "Statically linked executables are portable" ... "Statically linked executables use less disk space" ... "Statically linked executables consume less memory" -- http://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/ http://wayback.archive.org/web/20090525150626/http://blog.ga...

arjun1296 10y ago
I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck.
- modifieddog 10y ago
  > I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. If I remember correctly, the argument goes someting like this: modern compilers, i.e. something as recent as the Plan 9 toolchain or a GCC version from this millenium, usually compile in only the necessary code with static linking, and not whole libraries. With dynamic linking, you always have to load the whole library into memory, which supposedly pays off only with heavily used libraries such as libc (e.g. think about how many libraries used by Firefox/Chromium are used by other programs). So the hope is (combined with a general strive for small programs), since text pages are shared between processes and statically linked programs only include the absolute necessary code you end up with a smaller memory footprint. (I'm not sure whether you save disk space, but I don't think that would be a problem nowadays. Heck, look at go binaries.) And I guess, the linker could do more whole-program-optimization on a statically linked program, since all the coude is available. > For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck. Generally you would want to have a proper build system. In case of StaLi, they have one global git repository (/.git). An update is simply "git pull && make install". I don't know if this process is slower or faster than binary updates, but if they strive for small programs/binaries, then I guess it doesn't matter as much. Source-based distributions, such as Gentoo, have the advantage that you don't have to wait for someone to publish an upgraded binary, you can compile it yourself, instead. This might give you a slight edge for security vulnerabilities.
  - pjmlp 10y ago
    Modern compilers?! Static linking was already like that in MS-DOS compilers.
    - modifieddog 10y ago
      > Modern compilers? I was being partially ironic. It seems that the common assumption is still that you (statically) link in the whole library. Then, of course, binaries get really huge. But when you link in only what's necessary, the overhead is probably relatively small (when was the last time you used all of libc?). The other thing is (which you can see in this thread, as well), people seem to think that you can do things only the way we are doing them now without ever questioning whether these things are still apropriate and how they originally came into existence. ("There has to be dynamic linking", "we have to use virutal memory", "there have to be at least 5 levels of caches", etc.) To my knowledge, all the reasons regarding saving space, security, and maintenance were all made up after the fact (and aren't necessarily true, even (or especially) with modern implementations). Originally, dynamic linking was intended for swapping in code at runtime (was it Multics or OS/360?), which you can't do anymore today. Furthermore, dynamic linking (as it is done today) is really complex. In contrast, static linking is much simpler (=> fewer bugs/security holes). I think we should reconsider if the overhead is worth it or not (do you really care whether your binaries make up 100MB or 200MB on your 1TB HDD?). For embedded devices: yes, space does matter, but you probably don't run a full fledged Ubuntu desktop on you IoT device, anyway. You use different approaches (e.g. busybox, buildroot, etc.).
  - 0xcde4c3db 10y ago
    > you always have to load the whole library into memory Not really. You do have to mmap it, but it can be demand-paged (executables are handled this way on most modern systems, which is why compressed executables are usually a bad idea). IIRC, what saves time is mostly not having to do the actual linking part where the references are resolved. This can be precomputed and stashed in the binary (an optimization well-known to Gentoo+KDE users), but that confuses some package managers, breaks some uses of dlopen()/dlsym(), and has issues with ASLR.

striking 10y ago

Here are a pair of links that you may have missed under the "Don’t use systemd (read more about why it sucks)" line item. http://suckless.org/sucks/systemd http://suckless.org/sucks/systemd http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ The first link reads like a sort of 99 Theses, while the second is a dissertation on why people will never get along on the subject of systemd.

anon4711 10y ago
I take the attribution in the first link (references to "Führerbunker" and "Führer") to mean that the author is comparing Lennart Poettering to Hitler. That's not funny, it's just very, very inappropriate.
- striking 10y ago
  I didn't write the linked content, nor did I choose the links. If you feel strongly about this, consider contacting the authors of the story.
  - anon4711 10y ago
    I didn't mean to imply that you did; sorry if that came out wrong.

justinsaccount 10y ago

Because people like to complain more than they like to actually build a usable alternative. Edit: here's a great example from one of the links in the other comment: suckless complaining about "sysv removed" in systemd. Link takes you to this changelog entry: "The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native systemd units from these scripts when needed. This enables us to remove a substantial amount of legacy code from PID 1, following the fact that many distributions only ship a very small number of LSB/SysV init scripts nowadays." So, code was removed from the init daemon itself and moved into a standalone utility that does one specific job. Systemd is now both being blamed for bloating init, and for splitting functionality out into a separate tool that does one thing.

bnolsen 10y ago
runit on void linux runs great. it's tiny, easy to understand and very fast. and it doesn't try to take everything over.
clarry 10y ago
> Because people like to complain more than they like to actually build a usable alternative. More like people have had perfectly usable alternatives but now the hivemind is more or less forcing something else onto them. I don't need to build a new init system, I have one that works, thank you. Please don't give me systemd.
- justinsaccount 10y ago
  The one I had did not work so I am happy to have systemd now.
qwertyuiop924 10y ago
They built many. runit, s6, nosh, bsdinit, openrc. But yeah, it is being blamed for bloating init, because for one thing, cron isn't init's job. And that's just the start.

bitwize 10y ago

Hating systemd is like hating Hillary Clinton at this point. It's well past time to suck it up and make peace with your next init system/President because the only viable alternative(s) are far worse.

DigitalCannon 10y ago
Maybe they're far worse to you.. You also have the option of creating something yourself if everyting sucks so much.
thescribe 10y ago
As someone who has found runit to meet my needs I don't think I have any reason to make peace with systemd. I feel like part of what people object to about systemd is the 'one true way to linux' thing.
- vacri 10y ago
  Right now what I'm objecting to with systemd is that this system replaces syslog, has been created and driven by the enterprise linux distro, with full-time experienced linux devs, and has been released and used in production for years... ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache.
  - vidarh 10y ago
    That is "replaces" syslog (you can still have it forward to syslog if you insist) is one of the best parts. After getting used to journald I have no desire to ever go back to dealing with syslog. > ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache. What are those "dirty hacks"? You can trivially use logstash or similar or you can forward log entries to a remote syslog-compatible endpoint. Incidentally the same that people usually do with syslog.
striking 10y ago
I cannot even begin to describe how silly your comment is. Since when were politicians even comparable to programs? Do we "elect" a init system, as one nation united under Torvalds? I'm hoping I was just trolled by an HN-flavored Markov Chain.

morganvachon 10y ago

That's a loaded question, and I'm only qualified to answer from my perspective and experience. My biggest gripe with it has always been that it is alpha-quality software, even today, that has a central role in an otherwise mature OS ecosystem. It has been widely adopted (some would say forced or tricked into adoption by a few distros) and therefore all the major Linux distributions are now running at an alpha level while its creators try to figure out exactly what they want it to be. That was the state of Linux in the late 90s, a state that it overcame during the 2000s, but now it's regressing again. First it was "just an init to replace SysV", something I could get behind, and back in 2012 or so I was actually excited about it. Then it started growing, replacing individual components of GNU/Linux with a monolithic mega-app that has more in common with Windows NT based OSes than with anything UNIX-like. Gone is the philosophy of "do one thing and do it well", replaced with "do everything no matter the quality of the results". I've always been a Slackware user since I started messing with Linux in the late 90s, and these days I find it getting faster and better while mainstream Linux distros slow down and grow more and more bugs. One of my benchmark systems for observing the growing bloat of modern OSes is an Atom based netbook from around 2010. It shipped with Windows 7 Starter, which it ran acceptably but not great. Recently I tested Windows 10, Slackware 14.2, Ubuntu 14.04, Ubuntu 16.04, Debian unstable, OpenBSD, and Elementary OS Loki on it. Slackware was the fastest OS on it by a wide margin, followed by OpenBSD, then Debian, Ubuntu 14.04, Elementary, Windows, and Ubuntu 16.04 dead last. Guess which of those (not counting Windows) do not have systemd? Yep, Slackware and OpenBSD. Maybe it's a coincidence, but given how Ubuntu 16.04 on my modern workstation gets progressively slower with each systemd update, whereas Slackware on the same machine continues to chug along with no issues, that's telling. All of that said, systemd was and maybe still is a good idea, if only they can stop trying to reinvent the wheel and instead fix the spokes they broke along the way. I can't say I'm happy about eroding the UNIX philosophy from Linux, but if systemd is the future of Linux then it damn well needs to be a stable future.

billforsternz 10y ago
I am puzzled that you had an Atom based netbook from around 2010 that shipped with any kind of Windows 10.

Annatar 10y ago

Because it's a Windows monolithic approach to startup, shutdown and dependency management, as well as being a poor copy of Solaris' service management facility, smf(5).