4 ms·

Within all the noise about systemd I think posts like this are quite beneficial. Instead of discussing politics or throwing out buzzwords, it presents a specif

Within all the noise about systemd I think posts like this are quite beneficial. Instead of discussing politics or throwing out buzzwords, it presents a specific technical shortcoming. Positive or negative, these are the types of things that people should be reading about in relation to systemd. The problem is that people are deciding whether or not they like systemd based on "do you like Lennart" or "do you like The UNIX Philosophy", because that's what people are making noise about.

Mister_Snuggles 12y ago
As I said in another comment, I really wish it went into more detail on the actual problem. The problems with journalctl are usability ones, which doesn't make them any less of a problem, but doesn't point to an underlying technical failure either. The problems with systemd are basically stated as "a Fedora upgrade causes systemd to go bad." Is this a systemd problem or a Fedora problem?
- tankenmate 12y ago
  Some anti-fragility on the part of both Fedora and systemd would help here. Maybe a statically compiled init would be a start?
  - vezzy-fnord 12y ago
    systemd does not support static linking due to its use of NSS. See: http://lists.freedesktop.org/archives/systemd-devel/2014-March/017493.html http://lists.freedesktop.org/archives/systemd-devel/2014-Mar...
    - ultramancool 12y ago
      > Only the most trivial libraries actually support it. ... what kind of nonsense is that? Almost every library supports static linking to a basic degree at least. Heck, I statically link giant things like Qt and Boost every day at work.
      - vodik 12y ago
        Well the core of the issue here is you can't really staticly link against a library that depends on dlopen/dlsym (nss system is built around this). I mean, you could, but now your staticly linked binary still depends on other dlsym'd code. So whats the point? (Not trying to make an argument that this is good or bad behaviour)
        ultramancool 12y ago
        I understand, but the question then becomes why your library depends on dlopen and why you don't offer an alternative static method as Qt's "plugins" do. Doesn't seem like good design on the part of the NSS devs to me, and probably a poor choice of library on the part of the systemd devs to me. But maybe I'm missing something.
        the_why_of_y 12y ago
        The library that depends on dlopen is glibc.
        ultramancool 12y ago
        You can statically link glibc, so I'm pretty sure that's not right...
    - ansible 12y ago
      systemd does not support static linking due to its use of NSS. Well, that is a surprise to me. And something of a concern.
    - Mister_Snuggles 12y ago
      I can see systemd as a whole not supporting static linking. But systemd is a collection of many different binaries that each do their thing, so would it be possible for systemd (the pid 1 executable) to be statically linked while the other supporting executables are dynamically linked?
      - cesarb 12y ago
        The systemd developers try to avoid using NSS on PID 1 (for very good reasons), so NSS wouldn't be a problem for static linking PID 1. * See for instance https://bugzilla.redhat.com/show_bug.cgi?id=915912#c18 https://bugzilla.redhat.com/show_bug.cgi?id=915912#c18
        Mister_Snuggles 12y ago
        Sounds like it would just need some changes to their build setup to allow the PID 1 piece to be compiled statically, which doesn't seem too bad. Of course, this may not even solve the root cause of the problem this article talks about. It would make PID 1 a little more resillient though.
  - cma 12y ago
    Anti-fragility isn't the same as robustness. It should rarely be used as a term.
    - bkeroack 12y ago
      I'm not even sure how any software could be described (accurately) as anti-fragile. Robust, yes. But anti-fragility indicates that performance improves with stressors or catastrophic/unexpected events.
- digi_owl 12y ago
  Given that Fedora and systemd has been developing in lockstep over the last few years, one would think they worked well together...
  - Mister_Snuggles 12y ago
    I'd hope that any distribution would be packaged to work well with it's init system, regardless of which init system that is. After all, the whole point of a distribution is to have a core set of software[0] that works together reasonably well. [0] With the number of different packages in a modern Linux, I don't expect everything in a distributions repository to work perfectly, but core stuff (like the stuff that gets you from a cold boot to a login prompt, etc) should be rock solid.
felixgallo 12y ago
those are completely valid criteria. What's wrong with wanting your system to follow the closest thing to a known axiom in operational computer science that has ever existed?
noselasd 12y ago
I don't really have a good or bad opinion about systemd, to me the init system and things around it are just pieces that needs to work. The points discussed here are serious, should be filed as bug reports, and should be acted on by the developers. But the article also just sounds like systemd bashing, software has bugs and poor thought out solutions - which can be fixed or improved - it's just code. I could probably have written a similar article about many, many Fedora (and Debian) upgrades over the course of a decade or so about core components such as distro upgrades making the init system crashing, failing to start services, glibc upgrades screwing up servers, grub upgrades calling for a 2 hour car drive to fix and so on. But I didn't, I either filed a bug report, fixed the code, or was just too plain busy getting things back to working.

Mister_Snuggles 12y ago

As I said in another comment, I really wish it went into more detail on the actual problem. The problems with journalctl are usability ones, which doesn't make them any less of a problem, but doesn't point to an underlying technical failure either. The problems with systemd are basically stated as "a Fedora upgrade causes systemd to go bad." Is this a systemd problem or a Fedora problem?

tankenmate 12y ago
Some anti-fragility on the part of both Fedora and systemd would help here. Maybe a statically compiled init would be a start?
- vezzy-fnord 12y ago
  systemd does not support static linking due to its use of NSS. See: http://lists.freedesktop.org/archives/systemd-devel/2014-March/017493.html http://lists.freedesktop.org/archives/systemd-devel/2014-Mar...
  - ultramancool 12y ago
    > Only the most trivial libraries actually support it. ... what kind of nonsense is that? Almost every library supports static linking to a basic degree at least. Heck, I statically link giant things like Qt and Boost every day at work.
    - vodik 12y ago
      Well the core of the issue here is you can't really staticly link against a library that depends on dlopen/dlsym (nss system is built around this). I mean, you could, but now your staticly linked binary still depends on other dlsym'd code. So whats the point? (Not trying to make an argument that this is good or bad behaviour)
      - ultramancool 12y ago
        I understand, but the question then becomes why your library depends on dlopen and why you don't offer an alternative static method as Qt's "plugins" do. Doesn't seem like good design on the part of the NSS devs to me, and probably a poor choice of library on the part of the systemd devs to me. But maybe I'm missing something.
        the_why_of_y 12y ago
        The library that depends on dlopen is glibc.
        ultramancool 12y ago
        You can statically link glibc, so I'm pretty sure that's not right...
  - ansible 12y ago
    systemd does not support static linking due to its use of NSS. Well, that is a surprise to me. And something of a concern.
  - Mister_Snuggles 12y ago
    I can see systemd as a whole not supporting static linking. But systemd is a collection of many different binaries that each do their thing, so would it be possible for systemd (the pid 1 executable) to be statically linked while the other supporting executables are dynamically linked?
    - cesarb 12y ago
      The systemd developers try to avoid using NSS on PID 1 (for very good reasons), so NSS wouldn't be a problem for static linking PID 1. * See for instance https://bugzilla.redhat.com/show_bug.cgi?id=915912#c18 https://bugzilla.redhat.com/show_bug.cgi?id=915912#c18
      - Mister_Snuggles 12y ago
        Sounds like it would just need some changes to their build setup to allow the PID 1 piece to be compiled statically, which doesn't seem too bad. Of course, this may not even solve the root cause of the problem this article talks about. It would make PID 1 a little more resillient though.
- cma 12y ago
  Anti-fragility isn't the same as robustness. It should rarely be used as a term.
  - bkeroack 12y ago
    I'm not even sure how any software could be described (accurately) as anti-fragile. Robust, yes. But anti-fragility indicates that performance improves with stressors or catastrophic/unexpected events.
digi_owl 12y ago
Given that Fedora and systemd has been developing in lockstep over the last few years, one would think they worked well together...
- Mister_Snuggles 12y ago
  I'd hope that any distribution would be packaged to work well with it's init system, regardless of which init system that is. After all, the whole point of a distribution is to have a core set of software[0] that works together reasonably well. [0] With the number of different packages in a modern Linux, I don't expect everything in a distributions repository to work perfectly, but core stuff (like the stuff that gets you from a cold boot to a login prompt, etc) should be rock solid.

felixgallo 12y ago

those are completely valid criteria. What's wrong with wanting your system to follow the closest thing to a known axiom in operational computer science that has ever existed?

noselasd 12y ago

I don't really have a good or bad opinion about systemd, to me the init system and things around it are just pieces that needs to work. The points discussed here are serious, should be filed as bug reports, and should be acted on by the developers. But the article also just sounds like systemd bashing, software has bugs and poor thought out solutions - which can be fixed or improved - it's just code. I could probably have written a similar article about many, many Fedora (and Debian) upgrades over the course of a decade or so about core components such as distro upgrades making the init system crashing, failing to start services, glibc upgrades screwing up servers, grub upgrades calling for a 2 hour car drive to fix and so on. But I didn't, I either filed a bug report, fixed the code, or was just too plain busy getting things back to working.