Ive been runing Debian 12 (kde) since bookworm was released and am loving it.

I have recently discovered Devuan which seems to be Debian without systemd - what is the benefit of removing this init system?

  • Ew0@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 year ago

    Runit is brilliantly simple, and as the old granite maul examine text says, “simplicity is the best weapon”.

    I’m sorry, you won’t be able to convince me to use it, it doesn’t feel KISS (I left Arch when they swapped). Fuck binary logs too. The only place I use it is on my phone which is SailfishOS.

    Void to me is what Arch used to be – I tend to use minimal replacements where I can, e.g. Openntpd as ntp, socklog as logger, seatd as logind, zfsbootmenu instead of systemd-boot, no polkit et cetera.

    it’s the closest usable distro for me to cut most of the poetteringware out apart from messing around with Gentoo (which I can’t be arsed with any more). I am not a fan.

    Like or dislike systemd, be it convenient or not, you can’t deny it’s a behemoth.

    • Tobias Hunger@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.

      The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only… Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.

      You behemoth is my plumbing layer:-)

      I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.

      If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.

    • Tobias Hunger@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Fuck binary logs too.

      Text logs are binary, too… they just uses a pretty common binary encoding.

      Where do you actually use text logs? I did not use text logs outside of hobby machines ever during my career. Logs were either aggregated in databases or at least stored in temper-resistant formats (usually due to legal requirements).

      Do you actually use text logs in a professional setting? Just curious.

      • Ew0@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        If binary logs get corrupted they’re kaput; text logs are not (as far as I know?). Also you cannot grep binary logs? I wouldn’t know.

        No, I just have used Linux/BSDs for ~15 years in a non-professional setting.

        • Tobias Hunger@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          With textlogs you have a hard time noticing a couple of added/removed/changed characters or even entire log entries. Thats exactly why some industries may not use text logs in the first place as permanent records that are at least temper-evident are mandated.

          If binary logs go kaputt they tell you exactly which entries were effected and still display every bit of data they contain. Typically you do not grep in binary logs: Grep can not make sense of all the extra data in the logs (way more than in a typical syslog), so grep is just a poor tool for the job. You typically can use grep as binary logs so contain lots of text. This is ignoring compression, encryption and other extras of course.