Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Debian

Debian Begins Vote On Supporting Non-Systemd Init Options (phoronix.com) 225

Posted by EditorDavid from the canvas-the-community dept.
"It's been five years already since the vote to transition to systemd in Debian over Upstart," reports Phoronix, noting that the Debian developer community has now begun a 20-day ranked-choice vote on eight different proposals for "'init system diversity' and just how much Debian developers care (or not) in supporting alternatives to systemd."

The eight options they're voting on:
  • Choice 1: F: Focus on systemd
  • Choice 2: B: Systemd but we support exploring alternatives
  • Choice 3: A: Support for multiple init systems is Important
  • Choice 4: D: Support non-systemd systems, without blocking progress
  • Choice 5: H: Support portability, without blocking progress
  • Choice 6: E: Support for multiple init systems is Required
  • Choice 7: G: Support portability and multiple implementations
  • Choice 8: Further Discussion

There's detailed descriptions of each option on the Debian developers mailing list. "This is a non-secret vote," the post explains. "After the voting period is over the details on who voted what will be published."


This discussion has been archived. No new comments can be posted.

Debian Begins Vote On Supporting Non-Systemd Init Options More

Debian Begins Vote On Supporting Non-Systemd Init Options

Comments Filter:
  • Maybe they should have asked this question 5 years ago???

    • Re:Oh, Debian is a Democracy now? (Score:5, Informative)

      by jaklode ( 3930925 ) on Sunday December 08, 2019 @05:02PM (#59498786)
      You mean the vote we had 5 years ago? https://www.debian.org/vote/20... [debian.org]

      • Re: (Score:2, Informative)

        by nagora ( 177841 )

        I don't see any options about making everything dependant on systemd there.

        I'm not sure what the current vote is supposed to achieve other than to rubberstamp what has already been done.

        • Re: (Score:3)

          by godrik ( 1287354 )

          Well, after the tc (elected) changed the default init system to systemd. The winning (technical) choice in the GR was "support for other init system is recommended but not mandatory". The text is pretty clear that it means the package should be systemd compatible, and if possible be compatible with other things that's better.

          "packages may not require a specific init system" got the least vote.

          It seems, that it is exactly was done in the last release for instance.

          So I am not sure what you are talking about.

        • Re: (Score:3, Insightful)

          by AmiMoJo ( 196126 )

          The real problem is that the people doing the actual work of developing and maintaing Debian and all the many packages are happy with systemd dependency and don't want the extra work of supporting your favourite init system.

          • Re: (Score:3, Interesting)

            by gbjbaanb ( 229885 )

            are they happy, or are they in a position of having no realistic choice?

            So many big packages are systemd dependant, that the distro ends up being systemd dependant, and then the developers find that they have to depends on systemd no matter what.

            But here's the main thing - since when did userland programs even have to know about the init system? Its like Clash of Clans needing to develop specifically for the bootloader you use.

        • Re: (Score:3)

          by Kjella ( 173770 )

          I don't see any options about making everything dependant on systemd there.

          Of course not, Debian isn't issuing any marching orders. The opposite of "Packages may not (in general) require a specific init system" is that packages, like Gnome, may require a specific init system, like systemd, if they want. That didn't require a resolution because developers and packages are already free to do what they want by default. Basically, the project refused to have any official policy in the matter and let the chips fall where they may. Now you might say that certain key packages forced that

        • choice 1 (F) says:

          Debian can continue to provide and explore other init systems, but systemd is the only officially supported init system.

          That's effectively making everything systemd.

  • Gotta say it (Score:5, Funny)

    by 93 Escort Wagon ( 326346 ) on Sunday December 08, 2019 @04:43PM (#59498748)

    Begun, the Init Wars have.

    • Re: (Score:3, Funny)

      by Anonymous Coward

      Systemd is the JarJar Binks of linux.

      • Re: (Score:2, Interesting)

        by lgw ( 121541 )

        Systemd is the JarJar Binks of linux.

        Well put! After all, some people actually like Jar Jar (presumably they were very young at the time), but objectively he's bad software that spreads disaster, and may actually be a Sith Lord.

    • Re:Gotta say it (Score:4, Insightful)

      by PolygamousRanchKid ( 1290638 ) on Sunday December 08, 2019 @06:13PM (#59498944)

      Begun, the Init Wars have.

      Oh, but the end of this one is easy to predict:

      The Russians will win the vote.

    • Re: (Score:2)

      by jmccue ( 834797 )

      This is not the first 'init war', BSD rc vs SYSV makes this look like a sandbox fight. That morphed into the UN*X wars, which probably help create an opening for Linux.

      • Re: (Score:3)

        by thogard ( 43403 )

        The id, rstate and action fields in SysV inittab were intended to hold makefile type rules that would have ended all this nonsense had it been properly implemented and documented back in 1983.

  • Alternatives are required. (Score:5, Insightful)

    by rlwinm ( 6158720 ) on Sunday December 08, 2019 @04:44PM (#59498750)
    First off, I'm not a fan of systemd.

    However it does have its place. I do run Linux on my laptop and supporting suspend/resume and other modern features like that is important and in this case, while not ideal, systemd does seem to be working.

    Severs are another matter. Servers are very rarely rebooted and a speedy boot isn't usually that important. Furthermore it isn't something systemd can help with (things like database servers and custom application code tend to be the biggest consumers of boot time for servers). Ease of administration, reliability, and simplicity are the design goals for an init system for servers.

    Things like binary log files are a terrible idea for servers but livable for a desktop distribution. The two wildly different roles and different requirements to me are a clear reason why init system alternatives are a must. One size fits all usually is the worst of both worlds.

    • | Servers are very rarely rebooted and a speedy boot isn't usually that important.

      I don't run any servers but it seems to me if I have to reboot my server, I want it back online pretty quick.

      Old init mainly addresses service start and stop. Systemd allows for keeping those services running. I'd think that would be pretty important on a server too.

      • Re:Alternatives are required. (Score:5, Interesting)

        by raymorris ( 2726007 ) on Sunday December 08, 2019 @05:44PM (#59498876) Journal

        I've been managing Linux servers for most of the last 20 years, including periods where the regular day-to-day sysadmin would call me only when there were problems. I've seen a lot services down because of a full disk many times. I've seen them down because a TLS certificate expired. I've seem them down because they lost communication with the server running the database. I've seen them down because they can't read the file server. Several times I've seen them down because the password store got zeroed by a certain bug.

        I don't recall ever once seeing it down because the parent PID mysteriously dissappeared and the solution was to restart the service. Not in 20 years have I seen that once. So you're fooling yourself if you think systemd is usefully monitoring your service and going to do anything to fix it.

        It IS a good idea to monitor your services, of course. One of my companies offered a free service where we'd check your web site from three locations every few minutes and raise an alarm if the response didn't include the words you configured. (The configuration was to distinguish between the regular page and some kind of error page). That's useful monitoring - it ensures the service is up and accessible, providing the service it is supposed to provide. Sure is costly - free. :) Knowing that the PID exists doesn't tell you anything about whether it's providing the service properly. You'd only be fooling yourself rather than having proper monitoring.

      • Guess you haven't worked with much big iron. The OS booting is usually the quick part.

      • Re:Alternatives are required. (Score:4, Insightful)

        by MrKaos ( 858439 ) on Monday December 09, 2019 @10:46AM (#59501006) Journal

        Old init mainly addresses service start and stop. Systemd allows for keeping those services running. I'd think that would be pretty important on a server too.

        Everytime I see someone say this I'm reminded of how this whole situation began.

        /etc/inittab controls all of those functions of initd. It's easier and more obvious than you would expect so I think it because the solution is right under our noses that it remains unseen. Here is the manual page for /etc/initab [cyberciti.biz] the file that answers many of the points raised.

        Before I go into this though I *did* have criticisms of initd at the time. When systemd arrived I thought whooo hooo, someone has done something about that crappy rc.d system. The main issue was initd needed a complementary to deal with system events, that's what I thought systemd was at the time to finally perfect the general architecture of linux systems.

        So whilst initd wasn't perfect, the criticisms of it in the original systemd design document [0pointer.de] were flawed from day one. Second it was based on the premise that the crappy rc.d system was the *only* way to start up system services, when a read of the inittab manual shows that it isn't.

        Ok, back to the original design document of systemd. This is a broad critique I noted to myself:

        Process Identifier 1
        Agree.

        Hardware and Software Change Dynamically
        Agree. This is where a complementary eventd to talk to a system bus and alter initd state would help and drastically widen the scope of what is possible when events happen on the system.

        Parallelizing Socket Services
        misunderstanding of initd. This is achievable using inittab by configuring the runlevel initd is going to enter *OR* configuring the runlevel it is in and then signal initd to re-read inittab and maintain those processes also.

        Parallelizing Bus Services
        again inittab *already does this exactly as above *OR* entire process groups can be started in For lazy loading, the initd equivalent is 'ondemand' however this functionality needs a complementary eventd.

        Parallelizing File System Jobs
        Agree autofs is a system service like any other and this is exactly what a large company I worked for did. They did it as a background service (on solaris and we also had NFS mounts to deal with as home directories so it was a little more complicated than the use case presented here)

        Keeping the First User PID Small
        Considering the size and scope of systemd now compared to how miniscule initd is in comparison this argument is really reversed now.

        All of the arguments here a based on the assumption that the rc init scripts are the *ONLY* way to interact with initd when the core initd functionality is completely ignored. The rc scripts that are being used here are read hats idea, which were based on working around SCO holding onto some very simple pieces of code that interacted with initd, probably to drive this very wedge into the linux community so they could keep market share. They were "enable" and "disable" command which simply configured a system service or process group maintained by initd to be started and stopped in the background in parallel. So all I can guess is RH did what they could under the circumstances. (oh and btw fuck you SCO for that)

        You could the enable/disable commands inside a rc script to force initd to start/maintain the process in the background whilst the system start-up continued.

        Keeping Track of Processes
        Here we see the double fork argument. With a claim that an initd process should keep them around and manage the processes that crash which is exactly why crashed processes become owned by init. Essentially this part of the document criticizes sysVinitd for not do

    • Re:Alternatives are required. (Score:5, Insightful)

      by 0100010001010011 ( 652467 ) on Sunday December 08, 2019 @05:31PM (#59498836)

      SystemD is the WindowsNT kernel of Linux.

      It works, until it doesn't. I live with it on my laptop because it's more work to work around it because of how ingrained it is.

      But my servers are FreeBSD.

    • Re: (Score:2)

      by Sique ( 173459 )
      Another reason why systemd has its merits compared to SysV init or other script based systems is hardware changes on the fly. You usually don't have that with servers, but you have it with all the hot pluggable hardware of today's PCs and laptops. With changing hardware, you have to remove no longer used services and start new ones on the fly. With SysV init, you only have 5 different states. But you can literally have hundreds of different hardware configurations (with mouse A, without keyboard B, on the d

      • Re:Alternatives are required. (Score:4, Insightful)

        by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Sunday December 08, 2019 @08:58PM (#59499372) Homepage Journal

        With changing hardware, you have to remove no longer used services and start new ones on the fly.

        Most reconfiguration for hardware is handled by udev, not by the init system. We had udev before systemd.

        With changing hardware, you have to remove no longer used services and start new ones on the fly. With SysV init, you only have 5 different states.

        So what? You run an init script to stop a service, A file in /etc/default gets twiddled, and you run the init script again. If the service is disabled in its /etc/default file, it doesn't run. If it's enabled, it does.

        and you want to have them without the need of a reboot.

        They don't require a reboot with init scripts. It doesn't look like you know what you're talking about.

        The problem with SysV init and similar systems is that they don't really support flexibility.

        You have way more flexibility with init scripts than you do with systemd unit files.

        Every hardware change requires manual changes in the booting process.

        No, it only requires changes in files in /etc/default.

        You really don't understand how sysvinit works.

        • udev is another hunk of shit. I have a box with six ethernet interfaces. What order are they going pick this boot? Oh I manually have to stop them from changing? Great another problem in need of a solution.

        • Re: (Score:2)

          by Sique ( 173459 )
          If we already have udev, which is able to start and stop drivers and services at will, why do we need another system which starts and stops drivers and services?

          This is exactly the point. Why do we have to keep SysV init, if we have out of necessity, other systems there which do the same? Basicly, all we need in SysV init is /etc/init.d/udev, with Sudev and Kudev links in rc.0 to rc.5.

    • Re: (Score:2)

      by rastos1 ( 601318 )

      However it does have its place.

      Perhaps. But not on my machine.

    • Re: (Score:2)

      by Dog-Cow ( 21281 )

      I suppose the fact that systemd is more than happy to write to syslog is completely irrelevant to you. After all, facts have a way of upsetting bigots.

    • Re: (Score:2)

      by zixxt ( 1547061 )

      systemd is not faster than any other init system at booting.

      • Re: (Score:2)

        by sad_ ( 7868 )

        fast booting is pretty much a non issue these days, as all systems have much faster io then when systemd started development.
        anyway, the fast booting argument is not really the selling point anymore, but it keeps on being repeated over and over again.

    • I think there's room for "slimitd" - that is, a systemd-compatible thing that doesn't try to take over the world - just boots the system and gets out of the way.

      Systemd service units are quite good - you can get a shell script to be a daemon (safely) without really writing any code at all - and you get logging/rotation and restarts for free. That's pretty cool. FWIW, we probably need a "version 2" for the format of those service units, but even as they are, they're usable.

      I know you could write an init.d sc

  • Unless the maintainers can be expected to write scripts for them, they can hardly be said to be supported.

    So the poll option should include what init systems get mandatory support if not just the d. I'd say the realistic options are any combination of d/sysv/runit.

  • option C? Is it a reserved keyword?
  • Unix philosophy: Doing one thing well!

    Systemd is incompatible with the UNIX philosophy!
    • Really? Should the kernel just do one thing? You are confusing user space command line tool philosophy with the OS itself. Yo also don't seem to have any understanding of why that philosophy evolved or why it doesn't apply anymore.

      • Re: (Score:2, Troll)

        by iggymanz ( 596061 )

        Yes, the kernel is the core program that mediates interaction between the hardware and the running software processes. One job.

        No surprise a systemd tard wouldn't know that and be utterly ignorant of the Unix way.

        • You just described a driver. Not a kernel.

          • Absolutely false. I gave the textbook definition of a kernel which includes the management of all resources not just driver functions. What you're thinking of is too narrow minded.

      • Re: (Score:2)

        by PPH ( 736903 )

        What does systemd have to do with the kernel?

        • Once you learn to read go back and read this thread and you will have your answer.

          • Re: (Score:3)

            by PPH ( 736903 )

            I don't think you know the answer. Because I don't think you know what a kernel is.

            Hint: Linus officially took no position on systemd over other init systems. If you understand why, you will have taken the first step in your education regarding operating system kernels.

    • No shit. Apparently itâ(TM)s a feature that dns resolution now bypasses iptables.

  • Slackware 15 will be out very soon.

    • I'm a big fan of slackware , but its been 3.5 years since 14.2 and thats just not viable. I realise Patricks had money and health issues but if he can't do a release at least once a year he might as well not bother. My next distro will be Devuan - I'm simply not prepared to wait until 2023/4 until the following version of slackware.

  • systemd is like cane toads (Score:3, Informative)

    by Anonymous Coward on Sunday December 08, 2019 @08:10PM (#59499228)

    Its proponents brought it into Linux to solve some problems, but it's wiped out working ecologies. And it's primary author is *trying* to get rid of stable, functioning tools to fit his own personal model of how the world should work.

    * Binary system logs for no good reason except to break all existing log analysis tools
    * /etc/resolv.conf as a symlink
    * Killing the running processes of logged in users, which breaks "screen" and "tux" and tried to slip it in as a compile-time default with no notification ot suers
    * Forcing encryption of user home directories to be unlocked by systemd when a user logs in, proprietizing your home directory to require systemd to read your own files.

  • That ballot is rigged. Doesn't anyone notice? (Score:5, Interesting)

    by Nurgle909 ( 6444708 ) on Sunday December 08, 2019 @09:39PM (#59499480)

    Has anyone else noticed how completley rigged this ballot is?

    -Choice F - Systemd is placed first ( there is a known bias towards the first item in a list )
    -The "allow other init systems", choice is split into essentially 6 different choices. The six alternatives are all vaguely the same and so the people who want an alternative to systemd are not going to be able to co-ordinate to find the right choice.
    -The 'ranked choice' system is a mis-direction and will do nothing to offset these biases.
    -The systemd only option doesn't clearly say that.

    The result is that Debian is going to go systemd only unless 6x as many people vote to stop it

    • Re: (Score:2)

      by sgage ( 109086 )

      Just like it was 5 years ago...

    • Re: (Score:2)

      by green1 ( 322787 )

      Luckily several hundred times as many people would vote against it as for it. Unluckily 99% of those people aren't given ballots to start with.

    • Re: (Score:3)

      by olau ( 314197 )

      You can take a look at debian-vote to see how they came to be.

      Debian works the way that if you don't like the options, you can propose an alternative yourself, get a few backers, and it's in. That's why there are so many options, they started with a few.

  • I feel it is important for embedded systems with limited resources to be able to use sysv-init

  • They're missing an option (Score:5, Insightful)

    by drew_kime ( 303965 ) on Monday December 09, 2019 @12:06AM (#59499792) Journal
    Where's the option for "kill SystemD, bring back SysV init"? I guess they don't want to see how many people would put that as their top choice.

  • Does it have to be so obnoxious? (Score:3, Informative)

    by WaffleMonster ( 969671 ) on Monday December 09, 2019 @12:13AM (#59499802)

    Why does journald have to be so obnoxious? Out of all processes on the system it uses the most CPU time by far. Currently 3500 hours. Also I didn't ask for and don't want binary logs.

  • Amazing that all these people complain endlessly about systemd but what they are arguing for is going BACK in time to an even more inferior system. Systemd isn't the most amazing thing but it made strides and good decisions about a lot. It seems to me that the detractors would be better served making a NEW init system than using cludgy old init scripts, etc. like SysVinit, etc. But no, they'd rather howl and whine about systemd instead.

Slashdot Top Deals

May all your PUSHes be POPped.

Close