14 ms·

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slow

• GekkePrutser 5y ago
  I think it's also because those people that didn't want systemd have just moved on. I moved my servers to alpine and my desktop to FreeBSD. It's just not a thing in my thoughts anymore. I wouldn't write about it. So it seems the Linux community is more aligned now. However alpine is working on a similar thing based on s6 but with modularity and lightweightness as design goals. This sounds great to me. I'm not against the idea of a service manager, but I think systemd is overreaching.
  • genghizkhan 5y ago
    If anyone's interested here are the details: https://skarnet.com/projects/service-manager.html https://skarnet.com/projects/service-manager.html
  • iso1210 5y ago
    Indeed, they've either moved on or grudgingly accept it, even if they don't like it. Same thing happened with solaris, aix, hpux people who had to learn to accept linux as being the way of the world. I'm sure many people - especially developers who use OSX all the time - love systemd. That's fine, but people won't love systemd, just like solaris people learnt to accept linux. I'm also sure not everyone loves it. Some have moved on, some haven't but now tolerate it, they've spent the time to cope with it, maybe it's costing them more time every day than pre-systemd, but it's not big enough problem to move on. That's just life. I'm sure some people didn't like it when program manager was replaced by the start button in NT 4 either. It seems that systemd fanboys just can't acknowlege some people don't like their new world order, which is rather sad in itself.
• zozbot234 5y ago
  There's a lot of poorly-understood incidental complexity in the systemd codebase, and this can bite users even when doing basic service and runlevel management. The systemd approach is to try and make it 100% declarative based on simple .ini files, but the semantics of this seemingly "declarative" configuration was never properly specified. Even many systemd fans seem to be quite aware of this, and there seems to be a common understanding that some ground-up reimplementation of these ideas based on a clearer underlying "philosophy" will be needed at some point. Systemd has been a successful experiment in many ways, but relying on throwaway experimental code for one's basic production needs is not a good idea.
  • southerntofu 5y ago
    I hope you're right and we get a better, simpler declarative format in the future. systemd isn't bad but i've found when writing service files that some stuff is not as obvious as it should be.
  • kbumsik 5y ago
    The question is, was it better before systemd?
    • kaba0 5y ago
      No way in hell
  • tpush 5y ago
    > [...] but the semantics of this seemingly "declarative" configuration was never properly specified. What's missing from docs like [0] that makes you say that? [0] https://www.freedesktop.org/software/systemd/man/systemd.unit.html https://www.freedesktop.org/software/systemd/man/systemd.uni...
    • eesmith 5y ago
      I know so very little of systemd as it doesn't touch anything I do. I can pattern match that https://blog.darknedgy.net/technology/2015/10/11/0/ https://blog.darknedgy.net/technology/2015/10/11/0/ - "Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise" from six years ago (Discussion at https://news.ycombinator.com/item?id=10370348 https://news.ycombinator.com/item?id=10370348 ) might be relevant. Are those points reasonable? Dunno. If so, have they been addressed? No clue.
• midasuni 5y ago
  For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years of typing cat /etc/resolv.conf Even when you remember and type that in, you don’t get a simple list of nameserver and host, you get 100 lines of text you have to spend effort parsing to work out what’s going on. When it’s less mental effort to run tcpdump port 53 to see where your DNS is going, there’s a problem. For decades it was /etc/init.d/myserice restart Now is it systemctl restart myservice or systemctl myservice restart? I have no idea as I’m not at a computer. Or the restart fails it doesn’t tell you why, it gives you two locations to look for log files about why it might have broken. Init.d scripts didn’t do that. Even if there was something really wrong that log files don’t reveal, running init.d with bash -x allowed easy debugging Systemd came in and changed working processes and systems and gave very little benefit to people with working processes and systems from a operator point of view.
  • bonzini 5y ago
    > Now is it systemctl restart myservice or systemctl myservice restart Actually long before that it was service restart myservice, which still works.
    • morelisp 5y ago
      Unfortunately, it was `service myservice restart`, which is the wrong order if you want to be able to do multiple things at once (or even just align with any other `cmd subcmd args` program).
      • iso1210 5y ago
        service myserver restart /etc/init.d/myserver restart Seems the traditional order to me $ service myserver status $ service myserver reload $ service myserver restart makes perfect sense when tackling a single service
• baybal2 5y ago
  > Systemd is 10 years in making Systemd is 10 years in making, and still manages to brick production servers. The problem is not with SystemD or its coding as such, but the ideology it came with, and bad developers who push it. The last attempts to make it saner basically reverted it back to sysvinit. So, not much difference now.
  • bonzini 5y ago
    > The last attempts to make it saner basically reverted it back to sysvinit Uhm, how so?
  • throw-8462682 5y ago
    How likely is it that the prolific systemd team and tech decision makers in Linux distributions don’t have a design instinct and came up with this ball of mud full of accidental and unneeded complexity? Have you considered that there may be teams and requirements outside your current sphere of experience?
    • baybal2 5y ago
      For SystemD, I see none. Though, I see unfulfilled urge to give Linux "serious enterprise grade" twist, and bog everything in "serious enterprise frameworks of doom"
      • throw-8462682 5y ago
        If you think that systemd is an ‘enterprise framework of doom’ then you must not have worked in Java enterprise software development.
        • josephcsible 5y ago
          Having suffered under both, I'd totally spend the rest of my life developing enterprise Java if it meant systemd went away forever.
    • mjw1007 5y ago
• dagw 5y ago
  Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. They might not have been better or more robust, but they where easier to understand and reason about. You could explain the entire thing to the most junior of sysadmins in a few minuets, tell them to read the boot scripts, and they would basically understand how everything worked.
  • jbverschoor 5y ago
    Really? Have you ever written init scripts for a hand full of services for your typical saas application? It’s always been a mess, and I’m very happy systemd was copied from / inspired by Apple’s launchd.
    • drran 5y ago
      This mess is easy to solve with a library of functions to call, e.g. /etc/rc.d/init.d/functions, which can be imported and used. Unfortunately, there is no standard API for this.
    • dagw 5y ago
      I'm not saying it was necessarily easier to use, just easier to understand what was going on. Explaining step by step how a Unix systems started up used to be trivial and make sense. I don't hate systemd, I just don't understand it. But that could also be symptom of me being old.
      • delusional 5y ago
        Naa. I'm young and generally positive about systemd, but I'd happily admit that the complexity gap is huge. It's practically impossible to explain systemd to anyone not intimately familiar with linux and systems programming without a bunch of handwaving.
        • spindle 5y ago
          This. I can easily believe that systemd is an improvement in many ways for people who have time to understand it (especially in NixOS, as noted by another commenter). But I'm not happy that so many parts of Linux now have such a steep learning curve.
• egberts1 5y ago
  I’ve since moved away from systemd for all my Linux boxes, work and home. We still cannot block systemd from making a network socket connection so security model is shot right there by the virtue of systemd running as a root process. In the old days of systemd, no network sockets were made. Systemd has become a veritable octopus. Now, I use openrc and am evaluating S6.
  • viraptor 5y ago
    Selinux can block systemd from making network sockets. What do you mean by "security model" in this case? What model is that?
    • lloydatkinson 5y ago
      But the solution is for it to not try make the socket rather than needing another system to correct bad behaviour of the first system?
      • egberts1 5y ago
        There ye go. Make system process small as efficient, not to mention easily auditable.
    • josephcsible 5y ago
      By "cannot block systemd from making a network socket connection", I think GP meant that your system will break if you block systemd from making network socket connections, not that it's physically impossible to do so.
      • egberts1 5y ago
        Yes. If you borked your systemd config file, system-wide failure. Non-bootable, non-useable. Also if intransigent network connection occurs (fuZzing or not), untested errors occur … notably in PID 1 which isn’t easy to debug.
    • egberts1 5y ago
• throw0101a 5y ago
  > Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. Things would have been fine for a lot of people if they had stopped at SysV script replacing, and general start up. At this point, with all the additional functionality continuously being added, I'm waiting for systemd to fulfil Zawinski's Law: > Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. * http://www.catb.org/jargon/html/Z/Zawinskis-Law.html http://www.catb.org/jargon/html/Z/Zawinskis-Law.html * https://en.wikipedia.org/wiki/Jamie_Zawinski https://en.wikipedia.org/wiki/Jamie_Zawinski
• knorker 5y ago
  I don't think it's that people are warming to systemd. It's more that there are two kinds of people now: 1. People to young to remember stable software. 2. People who have given up, and just accepted that Linux too "just needs a reboot everynow and then to kinda fix whatever got broken". systemd has normalized the instability of shitty system software. And just like how you don't see front page news every day about 1.3M traffic deaths per year because it's not news, you don't see people up in arms about shitty Linux system software. It's normal now. It didn't use to be. Yes, ALSA is better than OSS, and then PulseAudio and now pipewire. It can do more. But when did it become acceptable to get shit, just because the shit could do more things? Pipewire is not bug free (I have a bug that's preventing me from an important use case), but it's sure more reliable than PulseAudio, while still being more capable. So maybe Pipewire is showing a trend towards coders actually giving a shit?
  • deleted 5y ago
    [deleted]
  • a1369209993 5y ago
    3. People who realized that the FOSS community they were originally so happy to have found - of people who actually care about writing software that works, rather than user-hostile malware designed around profit margins - effectively doesn't exist anymore, and refuse to update their software anymore at all because they know that recent versions are unusably broken, to the point of requiring "a reboot everynow and then to kinda fix whatever got broken".