36 ms·

systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signa

• dcow 2y ago
  I love systemd.
  • andrewstuart 2y ago
    Me too. The best thing about Linux.
    • jbverschoor 2y ago
      It's a re-implementation of Apple's launchd. I've always liked it though
      • bryanlarsen 2y ago
        A much improved version of launchd, yes.
      • freedomben 2y ago
        It is much more than just a re-implementation of launchd. I can't grab a link right now, but Lenart wrote a long blog post about the philosophical decisions behind systemd, and he goes into detail about what he liked from launchd and what he did not like. It is called "rethinking PID 1"
• Faaak 2y ago
  Yeah, basically I've found that the people the more vocal against systemd are either not really knowing how it works behind the scenes, and just criticizing for the sake of it (or because other people do so), or criticizing from an ideological point of view (do one thing and do it well). They see systemd as an octopus, not following the unix ideology. Which I don't really agree tbh
  • hanselot 2y ago
    [flagged]
    • throwaway598 2y ago
      The root of the problem is sudo, and su more generally. This derives from *nix, or mainstream versions today, requiring a super user, a manifestation of the problem with monolithic kernals. A microkernal may be a stepping stone to improving this but even this is not a solution. The only solution is no kernal space, no privileged user(s), all processes negotiate independently with each other.
      • metalforever 2y ago
        No the root of the problem is the large attack surface systemd is creating by tightly coupling a ton of tools together, I agree about the microkernel idea completely though.
    • dale_glass 2y ago
      systemd isn't a single piece of software. It's a collection of software with an unified theme, like KDE or Gnome. Attack surface-wise, I don't think there's much difference between "sudo" being a part of the systemd package and not. Either way there's "sudo" code to be targeted, which package it's part of is just a technicality.
      • SAI_Peregrinus 2y ago
        I like to compare Systemd to GNU. Pretty similar scale, similar "take over the world" levels of adoption in Linux (GNU's libc is in nearly everything, all the other GNU tools are ridiculously common), adds lots of attack surface to what used to be single-purpose simple tools, etc. Just about every criticism of Systemd applies just as well to GNU.
• hxelk1 2y ago
  > you can actually declare startup dependencies and other useful relationships In theory, yes. In practice, I had a lot of trouble ordering things correctly in non-trivial cases. > it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back" I can only speak for myself, but I don't want the abysmal sysvinit scripts back. I just want a simple process supervision suite which is true to the UNIX way of doing things. The sysvinit/systemd dichotomy is false. Runit and s6 are both very real alternatives to systemd. They lack a ton of features, but they are a way to reliably run services. They do use shell scripts, but not for the reasons sysvinit did. They are extremely simple and have a very small attack surface as a result. Runit itself is a spiritual descendant of daemontools which predate systemd by great many years. The problem with systemd is that it's a mediocre solution to many problems. UNIX deserved better. [Edit: whitespace]
  • mid-kid 2y ago
    In a similar vein, systems like openrc use "shell scripts" as well, but can generally be written declaratively[1]. This provides greater flexibility when it comes to creating one-shot services or services that require a little setup before running, as you can just re-define the start() function, rather than requiring one to make a separate shell script for it, or dependency tree, like you'd have to in systemd land. "sysvinit" is an ill-defined concept, anyway, as every distribution had their own scripts and tooling around actual services, and sysvinit was generally only responsible for starting getty and launching the distribution's actual service system. How initscripts were created and how you managed them depended significantly on the distribution. [1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-vpn/tailscale/files/tailscaled.initd https://gitweb.gentoo.org/repo/gentoo.git/tree/net-vpn/tails...
    • declarethroway 2y ago
      Debian's sysvinit scripts can also be declarative. https://github.com/DanielAdolfsson/ndppd/blob/master/ndppd-init-debian-jessi https://github.com/DanielAdolfsson/ndppd/blob/master/ndppd-i... The full system also cares about dependencies and parallel running. And this is not recent, but the black legend will never die. Bonus: by having the shipped scripts under /etc, tools like etckeeper can show your changes as well as updates, all in one place.
• mid-kid 2y ago
  I'd agree with your message if systemd was just an init system.
  • bryanlarsen 2y ago
    It's not difficult to use some parts of systemd without using others. Is it any different than something like coreutils, another package of linux utilities that are synergistic but usable seperately? Nobody complains about coreutils being bundled. Even the rewrite in rust crowd bundle them.
    • CuriousCosmic 2y ago
      It really is not. This "sudo replacement" (which under the hood is systemd-run) will apparently require quite a bit of the systemd stack to operate. That is not something you have access to in many lightweight container distros or on other non-systemd distros. And coreutils is expected because most people use GNU/Linux. Coreutils is that GNU userland part. And either way, the majority of coreutils are GNU implementations of standard unix components. You can use most software that depends on coreutils on other *nix platforms like BSD for this reason.
      • bryanlarsen 2y ago
        I doubt you'll need to run systemd as pid 1 to use this.
        • navaati 2y ago
          Oh you do: this work completely differently from sudo, there is no suid binary involved, instead it does IPC to the systemd pid 1 and asks it to spawn you process, attached to your current terminal. So if you don't have systeme as pid 1, it'll have noone to talk to. Whether you like that or not is for you to decide.
          • bryanlarsen 2y ago
• xolve 2y ago
  Its refreshing to see that just hate systemd because "its not UNIX way" is not anymore. I see better discussions under this post and in other places around the web.
• SixDouble5321 2y ago
  Systemd isn't just one thing lol
• ranger_danger 2y ago
  > systemd has been a net positive for the linux ecosystem I guess that depends on whether or not you consider the great number of CVEs caused by it don't matter enough.
• deleted 2y ago
  [deleted]
• esoterae 2y ago
  No, it hasn't. You forget, the reason systemd was originally rationalized for its insertion into our trees was "boot times are too slow". Its chameleon-like nature and ability to solve the hastily described problem du jour seems to be its only consistently touted feature. Bash scripts that start processes are ephemeral. If it's signal handling you want, that was your program's problem. Either that or your program didn't fork itself, which is a fish of an entirely different feather. And now we have this sprawling mess of complexity and headache.
  • riddley 2y ago
    Same thing is happening with Wayland. It reduces features adds complexity and solves no new problems but here it comes.
    • themerone 2y ago
      How is Wayland more complex than X?
      • gmueckl 2y ago
        The resulting wayland environments are more complex because wayland itself refuses to define/include features that desktop systems are expected to have. This results in a sprawling mess of competing and incompatible interfaces for those gaps that other parts of the implementations (desktop environments) now have to compensate for by including multiple implementations of the same thing based on all these different interfaces.
        • imtringued 2y ago
          Stop using the wrong words. You're saying Wayland is too simple and feature incomplete.
      • j16sdiz 2y ago
        Wayland by itself is simplier -- it is done by "outsourcing" everything a window system should do to the window manager. There is where the complexity kicks in.
• deleted 2y ago
  [deleted]
• agilob 2y ago
  > remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. The init system was probably peak of systemd, after that they started reinveting things in a more complicated way. Do we really need journald, systemd-boot, machinectl, systemd-networkd, sd-bus, systemd-resolved, systemd-nspawn? Do people actually use it all? Are there any metrics to show how many systems have it installed and in use?
  • superb_dev 2y ago
    The follow argument is identical to tail `-f`. `sudo journalctl -f -u <service name>`
    • rangerelf 2y ago
      And what would be the equivalent to, "Oh, I don´t know the name of the log for this process I can see in 'ps aux', let me cd into /var/log and see what filenames I can find ... or grep everything until I can find a couple of words that make some sense so I can keep digging further"? The lack of explorability in journalctl, the "need" to keep everything locked behind their own flavor of tools and magic file types, is what makes the rest of us abhor them.
      • iforgotpassword 2y ago
        Huh, isn't grepping journalctl output pretty much the same? It even prefixes messages by the binary name.
        • mdaniel 2y ago
          Pedantically, they're the unit name which only sometimes matches the binary name
• paulddraper 2y ago
  100% Systemd unit files make Linux feel like a rational OS.
  • slackfan 2y ago
    Only if your marker for a rational OS is NT.
    • delta_p_delta_x 2y ago
      Not the parent commenter. Windows has a lot of rubbish user-level interaction which belie how good an OS NT really is. Anyone who blindly disses it because 'Windoze' and 'M$ bad' is not really worthy of any attention whatsoever.
      • slackfan 2y ago
        NT isn't terrible with some very well designed systems, that is quite true. It is however good for a completely different list of reasons that *nix is. Trying to conflate the two is a pottering's errand.
• deleted 2y ago
  [deleted]
• aftbit 2y ago
  Ah yes I remember back when you just put the system hostname in /etc/hostname. Now we have hostnamed!
  • egorfine 2y ago
    Which is now borderline impossible to tame. Google "change hostname ubuntu" and take a look at the results and comments.
    • pcthrowaway 2y ago
      I'm still trying to figure out whether I like nftables more than iptables. Both are pretty complex to manage IIRC (I've only touched nftables a couple of times though, and not recently)
      • aerique 2y ago
        Well, it has "NFT" in the name so it must be good!
• bitwize 2y ago
  I don't resent systemd for existing, but I don't want to be forced to accept Lennart's shitty design decisions and it's clear he wants me to be since he successfully agitated for other critical components to hard depend on it. I want the option of opting out, which Lennart would deny me if he could. At the end of the day, I just run Void (or MX Linux if I want something more Debian-flavored) and get on with my life.
  • aerique 2y ago
    Void Linux and now Guix have been a godsend.
• foresto 2y ago
  > systemd has been a net positive for the linux ecosystem. You're presuming to speak for an awful lot of people there, on a topic that would be difficult to measure. > since the beginning of systemd people have moaned > it's quite annoying that the armchair linux experts complain Now you're overgeneralizing, and doing so in a dismissive and patronizing way. Here are a few examples of problems I have with systemd: System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted. Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope --property=Delegate=yes <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable. At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back. There are more examples, but I'm tired of re-living them and don't really want to write a book. I hope these few are enough to convey my point: Systemd has been a net negative in my experience. It has made my life markedly worse, without bringing anything I needed. Based on conversations, comments, and bug reports I've seen over the years, I get the impression that many others have had a similar experience, but don't bother speaking up about it any more, because they're tired of being dismissed, ignored, or shouted down, just as I am. I would welcome a reliable, minimal, non-invasive, dependency-based init. Systemd is not it.
• nextaccountic 2y ago
  > systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? Systemd was meant to replace Ubuntu's upstart, not sysv init. And it indeed systemd was better designed than upstart. Sysv init is a horrendous hack. People should NOT use that. Upstart had limitations but is okay, and certainly much better than sysv init. Systemd is okay too (but has much more features). Also as an historical note, both upstart and system was inspired by Apple's launchd. NixOS was an early adopter of upstart but it later migrated to systemd (alongside Ubuntu itself)