• Pasta Dental@sh.itjust.works
    link
    fedilink
    arrow-up
    48
    arrow-down
    6
    ·
    1 year ago

    Quit your bullshit, nothing was ever forced on you. This is Linux, free software and all that, if you’re not happy then use a systemd-less distro and stop complaining about meaningless points. SystemD works very well for me (and the vast majority of the Linux community) and is very easy to use and understand

    • taj@lemmy.ml
      link
      fedilink
      arrow-up
      28
      arrow-down
      6
      ·
      1 year ago

      This. If you want to go back to the days without systemd and writing invit scripts manually, knock yourselves out. The rest of us will continue to live in the modern world of systemd, pulse audio (and now pipe wire).

    • gens@programming.dev
      link
      fedilink
      arrow-up
      9
      arrow-down
      25
      ·
      edit-2
      1 year ago

      Udev was changed to depend on systemd. No good reason for it. So it practically was forced. You can lie all you want, it won’t change reality. SystemD was hyped up by comparing it with the worst implementation of sysV, at a time when no major distro other then fedora even used sysV. And that is not even the tip of the pile of dishonesty.

      Just by saying that it is no better then alternatives of the time will get ignorant people like you to yell. That is how strong the hype was around it. How can you even talk about free software when RH can take a core component and make it hard dependant on whatever they want. Just like bluetooth has a hard dependency on PA. I’m also free to say something sucks, just like you are free to lick their balls.

        • gens@programming.dev
          link
          fedilink
          arrow-up
          4
          arrow-down
          15
          ·
          edit-2
          1 year ago

          It always was about feelings with you fanboys. Pathetic.

          PS I wouldn’t mind using systemD, it’s the same as every other. Functionally absolutely the same.

          • ozymandias117@lemmy.world
            link
            fedilink
            English
            arrow-up
            4
            arrow-down
            1
            ·
            1 year ago

            As someone currently actively supporting two commercial products, one using OpenRC and one using systemd to meet different requirements for different projects

            Functionally absolutely the same

            Makes it blatantly obvious you have no idea what you’re saying

            • gens@programming.dev
              link
              fedilink
              arrow-up
              1
              arrow-down
              1
              ·
              edit-2
              1 year ago

              As someone who wrote an init system for fun and knows how udev and practically everything else associated with bringing a modern computer to a fully functional state (including network mounts, if that is your nitpick) works, i can not know what you are nitpicking about without you saying it. Not that someone who is actively supporting two commercial products to meet different requirements would have any idea what i am saying.

              PS It’s all simple really, just that it seems magic to people without curiosity.

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

                Sure - it’s primarily the way systemd uses cgroups

                For example, systemd’s use of cgroups for process monitoring makes it trivial to support setting resource limits for us

                One of the major issues we’re having with systemd, and the reason we’re using OpenRC on a different project, is the way Before and After with targets still cause all the services to start at the same time, causing resource contention

                An alternative we’ve used once is to create a special target for the services that had to start early, even if the entire boot took longer, and use a process to then request new targets be started by systemd

                This project we found it simpler to use OpenRC, though

                Calling them “functionally the same” without taking into account how process monitoring works on different init systems is disingenuous

                • gens@programming.dev
                  link
                  fedilink
                  arrow-up
                  1
                  arrow-down
                  1
                  ·
                  edit-2
                  1 year ago

                  Process monitoring, in the basic sense, is seeing if a process is running. You mean how they handle dependency trees/graphs ? From what i just read sysD targets are groups that can have other groups in them (aka inherit, aka “services”, aka compose). I wonder if that is the core of the problem. Not that i care, that’s the hole they dug for themselves when they insisted only pid EINS can orchestrate cgroups (didn’t use to be).

                  Either way, in the overwhelming majority of use cases they are practically the same.

                  Bdw, i didn’t downvote you. I reserve it only for the most irrational fans, aka parroting fanboys.

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

                    One of the big issues with process monitoring, in the general sense, is how PID 1 checks on processes

                    The cgroups usage lets them make use of a very powerful Linux-specific feature. Some competitors such as Upstart tried to use ptrace for this, but that causes services to run slower

                    “Is a process running” I think is a harder question than you realize. systemd also offers the ability to ask “is a process running correctly” through watchdogs, and “is a process using too much memory” or “is a process using too much CPU” and offer corrective action if they are

                    The systemd.target issues I mention are related to different design goals. Systemd tries to start as many services as possible at once, but we need some services up within 1 second, and the rest can take longer

                    One option I offered was a modification to systemd so that targets could handle Before/After during our design, but the maintenance of porting it over for each update versus using OpenRC was decided to be too much effort