5 ms·

I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source: >Sometimes ParticleOS adopts systemd featu

• palata 2y ago
  > I’m somewhat a fan of systemd As in: "you've tried alternatives and you really think that systemd is superior", or as in "you don't see why people complain about systemd and its philosophy"? Genuinely interested, because usually people I hear say that they don't see the problem with systemd don't really have experience with the alternatives. Which makes sense: people who like being able to use alternatives tend to get screwed by systemd :-). Edit: for those downvoting, this is a genuine question. I mostly hear opinions from people who hate systemd, and those who don't generally just don't really care: "I've always used systemd and I haven't had issues". But the latter group wouldn't call themselves "fans of systemd".
  • miladyincontrol 2y ago
    Blatantly not the person you're asking, but once you go past basic service management trying to do it just about anywhere else is an absolute and total nightmare. People who have major problems with systemd more than anything just ever seem confused, often vastly overestimating systemd's actual scope. The reality to many is its the simplest simple way to handle some very complex tasks, and the vast majority of it is still all so very very much optional even in the most 'systemd heavy' distros.
  • TheDong 2y ago
    Not the person you're asking, but I'm curious what you mean when you say "the alternatives". I've used runit, openrc, briefly upstart (what a trashfire that was), and I don't miss a single thing about them while writing systemd unit files. I've used GNU Shepherd on Guix, and honestly, meh, systemd feels way more pragmatic. I've also used systemd-networkd as well as NetworkManager, and feel like they both still have a few warts, but overall prefer systemd-networked on servers. I've used grub, refit, and systemd-boot, and gotta say systemd-boot is my preference there too. I haven't really used systemd portable services, but I've used docker and don't like it, and my overall impression is I'll probably like portable services more. Are there other alternatives I have to use before I'm allowed to have an opinion? What alternatives have you used which made you feel so enlightened?
    • palata 2y ago
      > What alternatives have you used which made you feel so enlightened? I didn't mean to seem like I feel so enlightened. My experience is that when not using systemd, I regularly get screwed by what I would call the "imperialist culture" of systemd, for lack of better words: it doesn't feel like you can relatively easily extract subcomponents of systemd and use it standalone. And more and more projects depend on a particular subcomponent of systemd, meaning that they require systemd. So it's not so much that I believe systemd is technically worse than the alternatives. It's more the philosophy that I don't like.
    • feitingen 2y ago
      Personally, it's not that the alternatives are so awesome. It's when i meet against some awful design choices in systemd, like how it decides to wait forever rather than hard fail, and by wait forever, i mean wait for 30 seconds, no, 1 minute 30 seconds, no 5 minutes... you get it. Or you can easily lock yourself out when there's a typo in /etc/fstab. Or the hardcoded 5 minute timeout for sysv-generator: https://github.com/systemd/systemd/blob/main/src/sysv-generator/sysv-generator.c#L165 https://github.com/systemd/systemd/blob/main/src/sysv-genera... God forbid you used cgroupsv1 for anything when poettering unilaterally decided to punish everyone with a 30 second delay for using it. If you stray off of the intended opinionated path, be prepared for the least user-friendly experience linux has to offer. You might even get some abuse from the developers if you try to ask for help, but they've probably toned it down since CoC became a thing (I hope).
      • SubjectToChange 2y ago
        God forbid you used cgroupsv1 for anything when poettering unilaterally decided to punish everyone with a 30 second delay for using it. Intentional time-delays are a nice middle ground. Yes, it is annoying to the users who've ignored all prior deprecation warnings, but it's better than those same users being "surprised" when support is removed entirely. Maybe you'd consider it less of a "punishment" if systemd dropped support for cgroupsv1 outright instead of inserting a time delay, I believe the opposite.
  • spookie 2y ago
    From my own experience the alternatives are fine as long as the distro maintainers put on the effort to make them work. I've used Devuan and others with runit, sysV, s6 and openrc. And honestly, openrc is the better alternative from an user perspective. Nevertheless, it is hard to argue against systemd when the critical mass is there, and you run into eventual problems. Still, I find alternatives such as runit and openrc easier to reason about than systemd. Perhaps this is due to the need to fully grok them, so you're able to fix issues yourself. Contrast that with systemd, where there are plenty of drag and drop solutions out there, so that requirement is lessened. You could also argue the real reason is systemd's complexity, but personally that doesn't feel like the core reason. Either way, it's good that there are alternatives. I like how heterogenous the whole Linux ecosystem can be, it helps mitigate large scale security issues.
    • rollcat 2y ago
      > Either way, it's good that there are alternatives. I like how heterogenous the whole Linux ecosystem can be, it helps mitigate large scale security issues. IMHO all it does is drive fragmentation and marginalisation. Either your alternative is successful enough that third parties are compelled to care about it (making the integration work on their part more painful, which is often "solved" by using Electron); or it isn't, so you have to bring in your own integration (aka glue). Sorry but Ballmer was right: developers, developers, developers. Users add value, developers multiply it.
      • spookie 2y ago
        I see your point, fair if you prefer it. But I don't see it as fragmentation, but as competition. The better idea tends to prevail, and it's nice that the environment allowed alternatives to even try :) hell, systemd itself happened as a esult of this environment :)
        • rollcat 2y ago
          Some competition is OK. For example, similar programming languages (e.g. Rust and Zig) - they inspire each other, fit slightly different niches, and there's plenty of space for both. Experimentation is OK. DNF started as a yum fork, with a different solver algorithm. IMHO yum should've just adopted the algorithm, but Fedora/CentOS ended up switching. That's mostly fine (people had to update docs, retrain their muscle memory). The level of "competition" we see in package managers, desktop environments, initrd builders (!), resolv.conf managers (!!!), is just wasted effort. There's no "pick the winner", it's "everyone is a loser". <https://tailscale.com/blog/sisyphean-dns-client-linux https://tailscale.com/blog/sisyphean-dns-client-linux>
  • thyristan 2y ago
    I've used Solaris SMF back in the day, which is what systemd largely copied, but badly. The major difference is, in SMF you specify services, their dependencies and whatever else you need. Then SMF looks at the whole desired system, computes the dependency tree and boot order, validates everything and writes a boot plan that can be executed in a static and deterministic fashion. You can look at the plan, execute that exact same plan each boot. You therefore know that if the system came up once using that plan it will again. Whereas systemd does everything on the fly, the boot order is computed anew with each boot, all the services on the same tree level are started at the same time and just have to fight it out. Thus the actual boot order varies greatly with each boot and will fail randomly, wait randomly (hands up: who wasn't annoyed by the systemd-rememberance-minute-and-a-half popping up like an inopportune windows update?) and will be hard to debug because you just cannot reproduce anything that lead to that. Your boot will be littered with 'wait-for-something' units, 'sleep-for-10s-because-that-magically-makes-it-work' and additional dependencies to maybe clean up the tree which the maintainers forgot about. Sometimes intentionally because "systemd is about making it boot fast, and it works on my laptop". It isn't all bad, but for systems that I need to boot and shutdown reliably, systemd is a step back even over init scripts because of the nondeterminism. You can "fix" things by just watchdog-rebooting when the system doesn't come up, and the downtime will just be a little longer. But it is annoying. And it is a design bug that will never be fixed.
    • StopDisinfo910 2y ago
      Systemd has more in common with launchd than SMF to be fair. SMF very much is a product of another time. Completely fine when we were dealing with workstations whose configuration was mostly static and not expected to change but very much unfit to the environment systemd operates nowadays. Systemd uses a dependency graph by the way. There is little magic. Provided you have properly setup what depends on what, everything will boot just fine and it’s somehow resilient enough than even if you messed up somewhere there is a good chance it manages to bring everything up after some hiccups.
      • ahartmetz 2y ago
        Regarding "there is little magic", Poettering repeatedly praises socket activation in his blog. It's not a new idea, but an old one that fell out of favor because it kinda sucked (remember xinetd?). It's about pretending that a service is running when by providing its listening socket, then starting it when the first client connects. It has some problems: it's more complicated, it can actually slow things down compared to starting a service as soon as possible, and it has new error cases because of course "pretending that a service is running" doesn't have exactly the same effect as actually having the service running.
  • PhilipRoman 2y ago
    Systemd makes me sad because 99% of what I like about it could have been implemented in a modular fashion, but instead it's mostly all-or-nothing. I still use OpenRC on servers, but I have to implement or integrate a lot of the missing features, like all the cgroup/namespace stuff, logging, etc.
    • palata 2y ago
      This. I don't like that it's not modular, and that more and more projects simply depend on on it. It feels like it makes it harder to not have systemd. Which makes sense for systemd if their goal is to kill the "competition". But that's not my vision of how open source should work.
      • bayindirh 2y ago
        > But that's not my vision of how open source should work. Exactly. I expect a modular fork of systemd when people get annoyed enough. I still don't understand why people treat systemd as the second coming of the Christ. Disclosure: I'm managing large number of servers for the last 20 years. Don't tell me that init scripts were bad. I won't buy it. Don't tell me systemd is fast, again, I won't buy it.
        • rollcat 2y ago
          > Exactly. I expect a modular fork of systemd when people get annoyed enough. That's exactly the case with elogind, used by e.g. Alpine, Void, and Gentoo. > I still don't understand why people treat systemd as the second coming of the Christ. FWIW it managed to pull most distros in a single direction, decreasing ecosystem fragmentation. The outliers are well, outliers. Just to be clear: it's not an endorsement from my side; there's enough criticism of systemd which I will not repeat. But the fragmentation aspect is what kills so much momentum, and it just runs too deep: Gnome was started because KDE's dependency on Qt wasn't kosher; Qt later got relicensed, but both projects kept pulling in different directions. It feels like any compatibility between anything is coincidental.
  • cedws 2y ago
    We made heavy use of systemd and its related components on a fleet of a few thousand edge devices and it worked great for us. Occasionally, we would run into bugs or confusing behaviour and have to dig through GitHub issues, but that was far outweighed by the problems it took care of for us. systemd does a lot more than just init. You can preach about whatever alternative inits all you like, but they don't do even 10% of what systemd does.
    • palata 2y ago
      > systemd does a lot more than just init. You can preach about whatever alternative inits all you like, but they don't do even 10% of what systemd does. I didn't mean to preach about alternative inits. My personal criticism of systemd is that it tries to take over everything, limiting the choice. I want to have a choice, that's all. And systemd doesn't do anything to help there.
      • cedws 2y ago
        Can you give concrete examples? systemd-resolved: can be disabled and replaced with your DNS resolver of choice systemd-timesyncd: can be disabled and replaced with your NTP daemon of choice systemd-networkd: can be disabled and replaced with your own networking scripts
        • palata 2y ago
          I am telling you that it is difficult to use systemd subcomponents without running all of systemd, and you give me example of running most of systemd and replacing a few subcomponents. Can you run those 3 standalone?
          • cedws 2y ago
            >I am telling you that it is difficult to use systemd subcomponents without running all of systemd Actually it's the first time you have stated that, but I'll bite. How do you propose that would work, and why would you even want to do that? The entire point of having these modules is for them to plug in to core systemd, which enables a lot of magic that would otherwise require an amalgam of shitty shell scripts. If you don't want to use systemd, why not just use chronyd for NTP, dnsmasq for DNS, and so on? Your problem is completely imaginary.
• blucaz 2y ago
  > I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source: You don't have to, we build packages and publish repositories from latest main, and the particle configs can use those by enabling the 'obs' build profile