4 ms·

systemd won because of politics, and absolutely nothing more. Debian, the root of the most used tree of Linux distros, only adopted systemd due to pressure fro

by b112 8mo ago

systemd won because of politics, and absolutely nothing more. Debian, the root of the most used tree of Linux distros, only adopted systemd due to pressure from Redhat/Gnome, and threats that if it didn't? Gnome would no longer work on Debian. Understand, that many of the issues "resolved" by systemd, were redhat issues. And further, not even init issues. For example, the most predominant being "predictable NIC names", which were already a thing with Debian. Or bootup times, of which Debian had excellent parallelization and boot times of a similar scope to how "fast" systemd was. There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size. It needs to be understood that the more code you have, the more bugs. It's just the way it is. There have been more security issues in core systemd yearly, than sysvinit in its entire lifespan. That's not even systemd's fault, it's just a simple fact, you have more code, you have more bugs. And when you say "systemd", you're likely referring to all the inane nonsense it does? How broken it is managing mounts, which really isn't an init's job anyhow? Or the absurd nature of having shutdown and startup identical, with automatic ordering, so you end up in all sorts of ridiculous edge cases? Why would anyone presume that start and stop MUST be mirror images of each other. The very logic is broken, and shows an immense lack of comprehension of how the real world works. And you speak of "it won" for superior this and that? At the start, it didn't even have an easy way to extend stop time. Hell, even now it just sends SIGTERM and a nanosecond later SIGKILL, as if shutting down a box FAST FAST NOW NOW is more important that data integrity or properly closed tcp connections or processes doing any form of proper cleanup. The number of mysql/database issues caused by this behaviour in the early days was insane. Look, I get you like systemd. But it's provided no real value, and certainly, even if there is some? The detractors outweigh it as the sun turns meat to leather.

tristan957 8mo ago
> There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size. The systemd repo is a mono repo for other tools in addition to the init system. I've heard from many sysadmins and distribution maintainers that systemd has been amazing. We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win.
- bayindirh 8mo ago
  > We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win. Current sysadmin and former distro maintainer here, who respectfully disagrees with you and your friends. Many, if not all software packages followed a well-defined SYS-V service file stub, esp. after so-called "Parallel SYS-V". We were able to order services, define dependencies and deterministically boot systems at the speed of light. Nothing broke, and the systems fully supported "pull the plug if you want, it won't break" promise. While I don't hate systemd, I don't like its many ways. It's something like X11 before auto-configuring support for me. The less I touch it, less grumpy I am. Technical parts aside, remembering the ugliness surrounding it (people, ecosystem and predatory aspects) makes me really angry sometimes. Tip: Research "Amutable" and what they are up to.
  - b112 8mo ago
    The only plus for Amutable, is that it may finally cause a sane systemd fork. My immense, strong suspicion here, is that they believe they can use their control over the systemd project, to add immense layers of code and change, to support Amutable's needs. When this happens, there will likely be pushback of some sort. I'm hoping a fork will happen at that time, and even better, hoping that maybe the project can go someplace saner. Getting rid of all tcp support (eg, systemd providing inetd functionality) from an init system would be an excellent start. The absurdity of pid 1 having networking hooks is absolutely madness. Splitting start/stop ordering would be an additional benefit. Removing all daemons, and all support code, and forking them (for legacy support) would be next. No horribly enacted timesyncd, or resolvd. Dropping the absurd journal and returning to a syslog solution would be next. Literal kiddie town, to have no centralized logging as a default when first created. There are now attempts to entirely re-skin the cat, with systemd-journal-gatewayd, yet every single appliance and piece of hardware supports... that's right, syslog protocol, not systemd's proprietary journalling protocol or formats. There is so much about systemd that is just about re-writing the entire universe, not for immense gain, not for immense improvement, but instead for the tiniest, smallest shred of edge-case betterment, and meanwhile, creating massive, overwhelming denigration of every other aspect of that same use case. Has the journal improved anything for anyone, anywhere, in any real, meaningful way? Absolutely not. All searching, etc is available on text files with | grep. Zero improvement. Has the journal improved performance? No. And the ridiculous and absurd and inane concept of the journal being removed at each reboot? It's as if the people writing systemd, had absolutely no real-world experience with servers, maintaining them, or working with them, and simply made design decisions predicated upon rumour, with no actual understanding of edge cases, or why things are, or were, as they are. -- An example would be some aspects of Hyundais. They are relatively new, in many ways, to much of the market they have entered. Yes, I know, decades may not seem like that, but it is so. And until they stole all of Toyota's QA methods by hiring engineers (which also took all documentation), they were of horrible quality. That said, I say in one of their newer SUVs, electric, the other day. Their dashboard, down at the bottom, ended in a sharp corner. When I sat in the car, I realised that should I be in an accident, or even brake aggressively, my kneecap would mash into this non-rounded, extremely square, sharp angle. I could literally see my kneecap being sliced/popped off. This sort of "it's silly to have round everywhere, let's do something new ascetically, and make it a sharp edge down there!", coupled with "There aren't many people 6'3" in S. Korea, so we'll never notice how dangerous this is", is a prime example of this. The authors had no idea of edge cases, and the litany of bug reports over the last decade has shown all their supposed improvements filed away, as they have basically had to conform to logical design standards, developed by people far wiser than they, over the last half century. No, someone-new-to-the-entire-unix-ecosystem, the phrase "but we can just" isn't a viable means to determine sensible design methodology. Go ahead, enact change, just make sure it makes some sense.

by b112 8mo ago

tristan957 8mo ago

> There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size. The systemd repo is a mono repo for other tools in addition to the init system. I've heard from many sysadmins and distribution maintainers that systemd has been amazing. We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win.

bayindirh 8mo ago
> We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win. Current sysadmin and former distro maintainer here, who respectfully disagrees with you and your friends. Many, if not all software packages followed a well-defined SYS-V service file stub, esp. after so-called "Parallel SYS-V". We were able to order services, define dependencies and deterministically boot systems at the speed of light. Nothing broke, and the systems fully supported "pull the plug if you want, it won't break" promise. While I don't hate systemd, I don't like its many ways. It's something like X11 before auto-configuring support for me. The less I touch it, less grumpy I am. Technical parts aside, remembering the ugliness surrounding it (people, ecosystem and predatory aspects) makes me really angry sometimes. Tip: Research "Amutable" and what they are up to.
- b112 8mo ago
  The only plus for Amutable, is that it may finally cause a sane systemd fork. My immense, strong suspicion here, is that they believe they can use their control over the systemd project, to add immense layers of code and change, to support Amutable's needs. When this happens, there will likely be pushback of some sort. I'm hoping a fork will happen at that time, and even better, hoping that maybe the project can go someplace saner. Getting rid of all tcp support (eg, systemd providing inetd functionality) from an init system would be an excellent start. The absurdity of pid 1 having networking hooks is absolutely madness. Splitting start/stop ordering would be an additional benefit. Removing all daemons, and all support code, and forking them (for legacy support) would be next. No horribly enacted timesyncd, or resolvd. Dropping the absurd journal and returning to a syslog solution would be next. Literal kiddie town, to have no centralized logging as a default when first created. There are now attempts to entirely re-skin the cat, with systemd-journal-gatewayd, yet every single appliance and piece of hardware supports... that's right, syslog protocol, not systemd's proprietary journalling protocol or formats. There is so much about systemd that is just about re-writing the entire universe, not for immense gain, not for immense improvement, but instead for the tiniest, smallest shred of edge-case betterment, and meanwhile, creating massive, overwhelming denigration of every other aspect of that same use case. Has the journal improved anything for anyone, anywhere, in any real, meaningful way? Absolutely not. All searching, etc is available on text files with | grep. Zero improvement. Has the journal improved performance? No. And the ridiculous and absurd and inane concept of the journal being removed at each reboot? It's as if the people writing systemd, had absolutely no real-world experience with servers, maintaining them, or working with them, and simply made design decisions predicated upon rumour, with no actual understanding of edge cases, or why things are, or were, as they are. -- An example would be some aspects of Hyundais. They are relatively new, in many ways, to much of the market they have entered. Yes, I know, decades may not seem like that, but it is so. And until they stole all of Toyota's QA methods by hiring engineers (which also took all documentation), they were of horrible quality. That said, I say in one of their newer SUVs, electric, the other day. Their dashboard, down at the bottom, ended in a sharp corner. When I sat in the car, I realised that should I be in an accident, or even brake aggressively, my kneecap would mash into this non-rounded, extremely square, sharp angle. I could literally see my kneecap being sliced/popped off. This sort of "it's silly to have round everywhere, let's do something new ascetically, and make it a sharp edge down there!", coupled with "There aren't many people 6'3" in S. Korea, so we'll never notice how dangerous this is", is a prime example of this. The authors had no idea of edge cases, and the litany of bug reports over the last decade has shown all their supposed improvements filed away, as they have basically had to conform to logical design standards, developed by people far wiser than they, over the last half century. No, someone-new-to-the-entire-unix-ecosystem, the phrase "but we can just" isn't a viable means to determine sensible design methodology. Go ahead, enact change, just make sure it makes some sense.