• Tartas1995@discuss.tchncs.de
      link
      fedilink
      arrow-up
      2
      ·
      8 months ago

      The argument is basically that it does too much and as the motto of Unix was basically “make it do 1 thing and that very well”, systemd goes against that idea.

      You might think it is silly because what is the issue with it doing many things. Arguably, it harms customization and adaptability, as you can’t run only 2/3 of systemd with 1/3 being replaced with that super specific optimisation for your specific use case. Additional, again arguably, it apparently makes it harder to make it secure as it has a bigger attack surface.

      • fruitycoder@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        8 months ago

        Sustemd is modular though, you don’t have to use every subsystem. The base init system and service manager is very comprehensive for sure.

              • ozymandias117@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                ·
                edit-2
                8 months ago

                At a high level, microkernels push as much as possible into userspace, and monolithic kernels keep drivers in kernel space

                There are arguments for each e.g. a buggy driver can’t write into the memory space of another driver as easily in a micro kernel, however it’s running in the same security level as userspace code. People will make arguments for both sides of which is more secure

                Monolithic kernels also tended to be more performant at the time, as you didn’t have to context switch between ring 0 and ring 1 in the CPU to perform driver calls - we also regularly share memory directly between drivers

                These days pretty much all kernels have moved to a hybrid kernel, as neither a truly monolithic kernel nor a truly micro kernel works outside of theoretical debates

      • MonkderZweite@feddit.ch
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        8 months ago

        More like it’s bad because of architecturial decisions (integrated init system; system state managemt in the same package as init and supervision), creating lots of unneeded complexity, number of CVE’s, how the developers behave (or don’t), and that you can’t have other init systems in the same repo without a fuckton of shims and wrappers.

        Sounds like valid concerns to me.

        • EyesInTheBoat@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago

          That’s the problem with how most things Lennart designs are. They are typically 70-80 percent excellent ideas brilliantly architected, 10-20 percent decisions that we can agree to disagree on but well designed still, and ~10 percent horrifically bad ideas that he is unable to receive criticism on because of his standing, terrible attitude and ~90 percent good and acceptable ideas.

          Another problem is that they all seem to be designed in a way that they are the One True Way to do something and are designed to choke out any alternatives because Lennart Knows Best.

          I’m still ambivalent about having this much extra logic and complexity attached to my init system but the ship sailed long ago and I’m well into making lemonade at this point.

    • Unyieldingly@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      I been told it was to big, but if you look at the Linux Kernel, it is huge.

      People also love to say Unix, but Linux is not Unix.

        • FilterItOut@thelemmy.club
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago

          Fine then: “Linux is not Unix, Xerxes!”

          Imagine a very irate spartan shouting it as he hurls his spear across the room where the lawyers are having their discussion about the lawsuit pending between the linux loving spartans and the tyrannical unix using persians.