Announcement

Collapse
No announcement yet.

Debian Developers Take To Voting Over Init System Diversity

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Debian Developers Take To Voting Over Init System Diversity

    Phoronix: Debian Developers Take To Voting Over Init System Diversity

    It's been five years already since the vote to transition to systemd in Debian over Upstart while now there is the new vote that has just commenced for judging the interest in "init system diversity" and just how much Debian developers care (or not) in supporting alternatives to systemd...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Choice 9: Focus on systemd and leave the rest to Devuan

    Comment


    • #3
      Typo:

      Originally posted by phoronix View Post
      and the interest/commiment to supporting systemd alternatives

      Comment


      • #4
        This is just sad. I had no idea there would still be people taking this ridiculous prejudice seriously so many years later. I used systemd on Debian since well before it was even part of the distribution, it was really quite good then, and now it enables like... half the important infrastructure for a decent workstation or desktop, including many things that didn't work well or at all when systemd was birthed. It isn't more memory-intensive than other init systems, it is generally faster, it is dead simple to configure, it is the default on every major distribution, it is maintained well by a dedicated team of developers.

        There is no good reason to impose the cost of maintaining non-systemd init scripts on every Debian package maintainer, to satisfy a group of people who appear to have few or no valid practical concerns. If your init system is so great, go ahead and write the missing units/scripts for it yourself, like I did many years ago with systemd; if it's too hard for an intermediate user to accomplish that, is your init system even worth considering?
        Last edited by microcode; 06 December 2019, 08:42 PM.

        Comment


        • #5
          Let's be real. Even if there is a resolution, it doesn't mean an end to "further discussion" as we've seen. And if someone loses, they're still going to be pushing for another vote down the line. And trolling in the forums hoping that people believe their FUD.

          Might as well press FD to pay respects.

          Comment


          • #6
            Originally posted by microcode View Post
            There is no good reason to impose the cost of maintaining non-systemd init scripts on every Debian package maintainer, to satisfy a group of people who appear to have few or no valid practical concerns. If your init system is so great, go ahead and write the missing units/scripts for it yourself, like I did many years ago with systemd; if it's too hard for an intermediate user to accomplish that, is your init system even worth considering?
            Do you think systemd should be the only init available for containers? Do you want to see people stop using Debian-based images to build containers?

            Comment


            • #7
              Originally posted by monraaf
              removed post
              Could you speak a little louder, please? I don't think we could hear you over the sound of you shuffling your punch cards.

              Originally posted by monraaf
              you never reboot a linux box period
              If you're giving out this kind of advice, your opinion isn't worth the papyrus it was written on. Anyone who claims to have as much network admin experience as you should have hit their fair share of 0-day exploits by now (including kernel issues) or just got "lucky" enough to be overlooked and never bothered to learn enough infosec to be anything other than a liability in most companies. Nobody sane chases uptime scores on a machine that connects to the internet. And nobody competent gives out career advice that requires winning the lottery.

              Live kernel patching is a relatively new thing and it's rather hard to find outside of paid distro subscriptions. Which would mean that with your ancient advice, you've most likely been leaving unpatched boxes on the network for hackers and script kiddies to add to their botnets for years. Thanks for that. We probably have you to blame for some of the daily spam we get.

              It's sad because I know people in their 70s (likely older than you) who work hard to keep up with technology. Bitrot isn't constrained to digital mediums. Please try to make yourself relevant instead of holding the rest of us back with your Flintstone-era knowledge.
              Last edited by tildearrow; 07 December 2019, 01:55 PM.

              Comment


              • #8
                Originally posted by phoronix_anon View Post

                Do you think systemd should be the only init available for containers? Do you want to see people stop using Debian-based images to build containers?
                Docker-style containers do not use an init system in the traditional sense.

                LXC-style containers are not different from a normal system.

                Therefore, yes: whenever an init system is used at all, it should be systemd.

                Comment


                • #9
                  Originally posted by monraaf
                  removed post
                  No that not the case. I am a old school hard core unix admin.

                  Originally posted by monraaf
                  Every old timers know that systemD does everything wrong on all possible way, it should've never been invented, it solves nothing. Linux is not windows98 that it require constant rebooting, you never reboot a linux box period, removed post
                  Ok this nobrianer must never used Solaris OS with SMF at some point. Because you would know that the way systemd is doing things is SMF like not Windows like. Systemd does not doing everything wrong. Does everything kind of different to what us hard core unix admins were kind of use. Please note I said kind of different if you had SMF experience and a few other Unix OS experiences what systemd is doing is not that odd.

                  So this paragraph proves you are not a hardcore unix admin because you got this wrong. With systemd you really should not be talking about windows if you are you really don't know the topic.

                  Originally posted by monraaf
                  roll back to the original sysVinit
                  No its a no brainer that sysvinit need to die. To be truthful the sysvinit Linux is using is a person idea of clone of the sysv real init not designed to work with the Linux kernel. So sysvinit on Linux not designed to deal with the fact Linux kernel recycles PID numbers same thing exists in most of the init systems before openrc or systemd. . There are many CVE numbers linked to the fact Linux kernel recycles PID numbers this has lead to the development of pidfd. So sysvinit is a disaster zone and all other init systems on Linux that do service management that have not been designed to deal with the pid recycling.

                  sysvinit the old one is no longer maintained. Its not picking up the new features like cgroups and pidfd. Freebsd has something like pidfd and its why freebsd service management is many times better than Linux with sysvinit.

                  If you wanted to back something like sysvinit that long term stands a chance of working it would be openrc. Openrc has optional cgroup support and will have pidfd usage support so at least this option will work without having CVE numbers issued against it for creating security flaws.
                  Last edited by tildearrow; 07 December 2019, 01:55 PM.

                  Comment


                  • #10
                    Originally posted by intelfx View Post

                    Docker-style containers do not use an init system in the traditional sense.

                    LXC-style containers are not different from a normal system.

                    Therefore, yes: whenever an init system is used at all, it should be systemd.
                    Isn't it needlessly costly to increase the size of containers by many megabytes when a simple init like init.d or supervisord provide identical functionality with smaller attack surface and footprint? Every byte should be audited in a container especially during development when pushing and pulling remote repos.

                    Comment

                    Working...
                    X