• m4
    link
    fedilink
    25
    edit-2
    1 year ago

    Gentoo comes with OpenRC as default so I roll with it. And it’s simple and it works.

    Plus the idea of having to randomly wait for some obscure stuff to block for a minute the boot/shutdown is not my thing.

    • @[email protected]
      link
      fedilink
      81 year ago

      The cool thing with Gentoo is that you can just decide one day to switch to systemd and it’s about as easy as changing your profile and updating your system (and maybe recompiling your kernel)

    • @[email protected]
      link
      fedilink
      English
      51 year ago

      You have to compile everything though, even from a stage 2 installation. I haven’t attempted one for like 15 years, but I imagine it’s still not quick.

      • @[email protected]
        link
        fedilink
        3
        edit-2
        1 year ago

        It’s not too bad. I very rarely recompile everything from scratch and after I do that I just create a snapshot with btrfs. Are usually then chroot into that snapshot and compile everything natively overnight for that 5% Theoretical performance boost.

        Most recently I took that snapshot and then used btrfs send to adapt it to a laptop as well and that worked quite well actually.

        Everything I install is typically through flatpack or distro box just like silver blue. This means install times are pretty much okay but I have a huge amount of flexibility in the way the system works

        Also heaps of binary packages as well, so that’s not too bad. The binary packages much slower than both arch and Alpine but not a lot slower than for example Fedora.

  • @[email protected]
    link
    fedilink
    English
    21 year ago

    Because I left Windows precisely to avoid the kind of shittery that systemd is doing.

    It’s absolutely no coincidence that the people who have developed the stuff that’s brought the most degradation to Linux - systemd, PulseAudio, Gnome’s “user has no right to themes” attitude - all come from a Microsoft background or explicitly work for Microsoft.

    I’d have far less of a problem if systemd was split into more practical, actually independent things that actually worked and distros didn’t buy their snake oil so easily. But for the time being, to me, the systemd experience is pretty much like the PulseAudio experience, what with the whole “waiting 120 seconds for a network interface to activate that it’s not going to because it’s the damn ethernet port and I’m on the road so the cable is not connected, stupid letter-potter dipshit”.

  • @[email protected]
    link
    fedilink
    161 year ago

    Most of them think that they’re making a point about an argument their side lost almost a decade ago.

    • @[email protected]
      link
      fedilink
      91 year ago

      To which the other side replies with points outdated since the first other init/service manager aside from SysV and Systemd was invented.

  • @[email protected]
    link
    fedilink
    English
    71 year ago

    Its just easier for me to dualboot windows. Im too dumb to find how to do it with systemd :p

  • @[email protected]
    link
    fedilink
    241 year ago

    SysV init works more reliably, is smaller, does just one job and is much, much better architected.

    SystemD tends to fail if you do anything out of the ordinary, is massively bloated, has it’s claws into far too many parts of the system, is IMHO poorly architected, the many of the individual components are poorly designed and the whole thing is a huge, and utterly unnecessary, attack surface.

    SystemD is probably adaquate if you just want to use your machine in the most basic way, but as soon as you try to do anything beyond that you start running into the rough edges and bad design decisions that it’s plagued with.

    • -> @[email protected]
      link
      fedilink
      131 year ago

      Could you elaborate on this? As someone who uses SystemD extensively on workstations and servers for spawning and managing both system-level and user-level services, I do find minimal issues overall with SystemD minus some certain functionalities such as socket spawning/respawning.

      Of course some of default SystemD’s housekeeping services do suck and I replace them with others. I would like to see the ability to just remove those services outright from my systems as separate packages since they do remain useless, but it isn’t that big of an issue.

      • @[email protected]
        link
        fedilink
        51 year ago

        SysV init does one job, it runs a set of scripts in an admin defined order, the init portion of SystemD attempts to solve a dependency graph at boot time and execute the startup scripts (units) in the order it devines from that. The big problems I’ve had around that have been services silently failing to start because it failed to resolve the ordering, and the difficulty of inserting a new unit into the ordering in a specific place. It’s doable if there happens to be a target at the point you want, but if not you can’t really do it as the existing, and any new, services all sequenced on the existing target. With SysV, of course, setting the service start order is trivial.

        The thing is, if SystemD was just an init system it wouldn’t be as bad, and has some useful ideas, but it tries to replace huge swathes of the system. As you say, some, and I’d say most, of the default housekeeping services suck, and you need to replace them. Unfortunately this then breaks the much vaunted integration of those services. Leaving them on the system isn’t a great plan as it just leaves the extra attack surface. So now you need to contemplate repackaging it to exclude the stuff you don’t need, which is a huge pain, and makes keeping up-to-date a big job. You’ve also got to worry about breaking dependencies from other packages.

        Probably the biggest issue though is the huge attack surface SystemD exposes on your system. We’ve just seen an example of how that can be taken advantage of, with malware in a library way down the dependency chain from the system library that gets jammed into all sorts of things. I understand there is an effort underway to reduce those dependencies, but it’ll always be worse than simply not doing that in the first place.

        The architectural and design issues are to do with the way the different parts are so tightly linked when they have no rational reason for being, the level of complexity introduced to core services and the incoherence of some of the choices around behavior. A recent bugbear was the automounter. It works most of the time, but if a mount unit fails it just gives access to the mountpoint, when by definition you obviously and explicitly didn’t want that. It also has a nasty habit of marking the unit failed, so future attempts also get bypassed until you reset it or have a recovery unit to do that.

        Anyway this turned into a wall of text, and its late, so I’m going to stop there, I hope it’s reasonable coherent.

      • @[email protected]
        link
        fedilink
        English
        21 year ago

        Systemd has a larger attack surface area since it touches more things, even though you can assign user accounts and such. Just the simple fact that it does more things than simply executing a shell script (like everything before systemd does) makes it more vulnerable.

        • @[email protected]
          link
          fedilink
          2
          edit-2
          1 year ago

          Systemd has a larger attack surface area since it touches more things

          That’s what the critics always say but are the things it manages unnecessary? If not, you’d use other tools for that but the overall attack surface would be the same.

      • Max-P
        link
        fedilink
        131 year ago

        I also use systemd a lot and it baffles me people can claim sysvinit was more reliable with a straight face.

        Half the time I restarted MySQL in the sysvinit days (pre-upstart as well), it would fail to stop it then try to start a new instance of it with the old one still running and the only way to fix it was to manually stop the other instance.

        Process management is like the one thing systemd really does well thanks to cgroups, it’s impossible for it to lose track of processes because the process lied about its pidfile.

  • @[email protected]
    link
    fedilink
    111 year ago

    My initial experience with Linux was without systemD and I didn’t like it when Debian switched to it. Void is comfy enough.

  • SeekPie
    link
    fedilink
    2
    edit-2
    1 year ago

    I’ve been using linux for ~2 years now and only know one of these (GUI installer), anyone smarter than me can explain what they are?

  • @[email protected]
    link
    fedilink
    71 year ago

    I like being able to see my logs without waiting 20 minutes, knowing who started what without playing cat and mouse with random processes and being able to change something without going through multiple levels of merged configurations files from three different sources.

    I also enjoy tools that were developed over decades and not rewritten from scratch reintroducing long-solved issues.

  • @[email protected]
    link
    fedilink
    English
    12
    edit-2
    1 year ago

    Does Alpine Linux count as “running”?

    SystemD just isn’t necessary for every Linux install.

    Linux has thousands of uses that aren’t “running on bare metal on my customized gaming rig at my computer desk to play steam games and pretend to look like Mr. Robot”

    • @[email protected]
      link
      fedilink
      English
      61 year ago

      Not having to go on an hour-long googling adventure to figure out how to write a simple init script. If you know bash, that’s all you need if you’re running (for instance) OpenRC. Systemd services are a mishmash of obscure setting names.

    • @[email protected]
      link
      fedilink
      English
      51 year ago

      It’s easier to manage/secure since it’s essentially just shell scripts. Systemd touches a lot of things and makes the initialization process more complex, which introduces more security vectors.

      • @[email protected]
        link
        fedilink
        41 year ago

        It’s easier to manage/secure since it’s essentially just shell scripts

        I love the fact that I can’t tell whether this is irony or not.

  • @[email protected]
    link
    fedilink
    261 year ago

    I use distros with systemd but damn, pretty soon it’s not gnu/linux anymore, it’ll be systemd/linux. systemd already manages services, bootloader, dns and networking. Maybe they’ll replace coreutils next and the transition is completed.