Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Debian

Debian May Need To Re-Evaluate Its Interest In 'Init System Diversity' (phoronix.com) 135

"Debian Project Leader Sam Hartman has shared his August 2019 notes where he outlines the frustrations and issues that have come up as a result of init system diversity with some developers still aiming to viably support systemd alternatives within Debian," reports Phoronix: Stemming from elogind being blocked from transitioning to testing and the lack of clarity into that, Hartman was pulled in to try to help mediate the matter and get to the bottom of the situation with a lack of cooperation between the elogind and systemd maintainers for Debian as well as the release team. Elogind is used by some distributions as an implementation of systemd's logind, well, outside of systemd as a standalone daemon. Elogind is one of the pieces to the puzzle for trying to maintain a modern, systemd-free Linux distribution.

Various issues were raised that are trying to be worked through albeit many Debian developers face time limitations and other factors like emotional exhaustion. Hartman noted in his August notes, "I think we may be approaching a point where we need to poll the project -- to have a GR and ask ourselves how committed we are to the different parts of this init diversity discussion. Reaffirming our support for sysvinit and elogind would be one of the options in any such GR. If that option passed, we'd expect all the maintainers involved to work together or to appoint and empower people who could work on this issue. It would be fine for maintainers not to be involved so long as they did not block progress. And of course we would hold the discussions to the highest standards of respect."

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

Debian May Need To Re-Evaluate Its Interest In 'Init System Diversity'

Comments Filter:
  • some history (Score:5, Informative)

    by KiloByte ( 825081 ) on Sunday September 22, 2019 @08:45AM (#59223306)

    The main problem is fixes being ignored. Emulation of systemd's APIs other than unlamented systemd-shim was and tested in January 2018, revisited in June 2018, redone and resubmitted in Nov 2018 -- all without any positive response. But our work was heeded, oh yes -- the existence of this work was used to rip away systemd-shim. The result was Buster being released with no working non-systemd GUI. And just before freeze, policykit's maintainer requested a completely different approach, which required a substantial rework -- implemented shortly after freeze, and then predictably rejected. Joy.

    So it's not a case of no one willing to do the work, it's about fixes being intentionally turned down.

    • by Anonymous Coward

      Is it really so awful to make a less monolithic system. Separate flat config files. They let individuals improve separate components separately without trying to drink from the whole spitoon. Lets' novices visualize this better. less interdependencies. less like "the registry". More like unix.

      • by iggymanz ( 596061 ) on Sunday September 22, 2019 @09:54AM (#59223488)

        and while we're at it why not text logs instead of a format that needs special tools to read

        • It seems to me that a pretty small patch is needed to do this. You just have to find where in the code the binary log is written and instead write text in whatever format is needed. Have you done it? Has someone? I would happily test it!
        • by vadim_t ( 324782 )

          There are a few advantages to it. See here: https://www.freedesktop.org/wi... [freedesktop.org]

        • Wierd. I read logs in actual text and I use several systems that use systemd. I wonder what is different about yours?
          • The difference is I have to work on systems set up by others, and those non-default settings of the stupidity that is systemd are not set, because systemd was designed by someone who knows nothing of the Unix way of doing things nor anything about systems administration. It panders to idiots.

        • and while we're at it why not text logs instead of a format that needs special tools to read

          Why not both? That is how all by Debian machines log, I haven't had to configure anything, just installed the right package

      • The problem seems to be that for all of these init systems to be plug-and-play, there *needs* to be an abstraction layer. SystemD is a monster and most things these days make it easier for themselves to just assume it is there, so things like sysvinit have to fit systemd's interface, or they both have to share a common one that doesn't exist yet... and then you'd need to change all of the software that interfaces with them.

        Isolating and maintaining little bits is the answer to the wrong question
        • by mysidia ( 191772 ) on Sunday September 22, 2019 @03:36PM (#59224584)

          The problem seems to be that for all of these init systems to be plug-and-play, there *needs* to be an abstraction layer.

          Yeah... its called a standard. There should be a standard for the filesystem and program interface to the init system -- just like other System APIs have a standard; just like there was something called the Linux Standard Base --- The standard should not say "use systemd" The standard should specify the format of configuration files/scripts and/or the interface for registering services.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      You're wasting your breath trying to prop up the fall of the Roman Empire.

      Move to OpenBSD. The code is clean and small, and community still believes in Unix. We want your help.

      • Those of us who love(d) Debian since close to the beginning and were pissed when systemd was shoved down our throat, in many cases, have dumped Debian and moved to Devuan.. Debian withOUT the bullshit that IS systemd....

        • Re: (Score:2, Insightful)

          by Cyberax ( 705495 )
          The greatest advantage of Devuan: idiot crazies have moved there from Debian. The greatest disadvantage of Devuan: not ALL crazies have moved there from Debian.
    • Window Maker knows nothing of systemd
  • Why bother? (Score:3, Insightful)

    by sgage ( 109086 ) on Sunday September 22, 2019 @09:33AM (#59223396)

    " Hartman noted in his August notes, "I think we may be approaching a point where we need to poll the project -- to have a GR and ask ourselves how committed we are to the different parts of this init diversity discussion. "

    Why bother. If they paid any attention to the results, we wouldn't have systemd in Debian. They'll just do what they feel like.

    • by ljw1004 ( 764174 )

      Why bother? If they paid any attention to the results, we wouldn't have systemd in Debian. They'll just do what they feel like.

      Could you expand on that a bit? I didn't follow all the ins and outs. From what I saw, the TC voted by a slight majority in favor of systemd. Ian Jackson's GR about loose init coupling didn't make it.

      Which results are you talking about? Who are the "they"?

    • by green1 ( 322787 )
      Because this way, they can claim to have asked (even though the poll will only be of people who agree with them) and then have a clear path to strike down the non-systemd heathens.

      This is all coming about because someone dared question systemd, and even managed to somehow install a system without it, that is completely unacceptable and must be stopped!
    • Re:Why bother? (Score:5, Insightful)

      by KiloByte ( 825081 ) on Sunday September 22, 2019 @10:39AM (#59223616)

      Uhm no -- a GR is voted upon by developers, not users. Systemd is a big non-modular blob, the lack of modularity meaning it's pre-integrated and thus requires less work from maintainers. For sysadmins, though, it's a nightmare as you can't adapt it to your needs or debug problems you could do with basic shell knowledge with sysv-rc.

      • Re:Why bother? (Score:5, Insightful)

        by jythie ( 914043 ) on Sunday September 22, 2019 @10:51AM (#59223656)
        I think this is something a lot of people miss when talking about systemd. It makes the lives of distribution and package maintainers easier, and they are the ones deciding if it is in or not. It also makes certain types of user's lives easier, and they tend to be the type of users that the distro maintainers work closest with like companies that maintain large amounts of VMs for 'cloud' tasks.
        • Re:Why bother? (Score:5, Insightful)

          by Calydor ( 739835 ) on Sunday September 22, 2019 @11:32AM (#59223800)

          I have no experience with systemd or even Linux since playing a bit with Mandrake in early 2000s, so please believe me when I say I have no horse in this race whatsoever.

          With that said, take a look at what you just posted and replace 'systemd' with 'Windows'. Wasn't Linux supposed to do things differently from Windows because being unable to modify Windows however you want is seen as The Problem(tm)?

          • Re:Why bother? (Score:5, Informative)

            by jythie ( 914043 ) on Sunday September 22, 2019 @01:22PM (#59224190)
            You hit a nail on the head. In many ways, the problem with Windows isn't Windows, it is the economics of windows, which applies to any OS. Linux changed because its use in the market changed, and is following the same pattern as windows did because advocates spent decades trying to get it into markets that Windows (or various Unix systems) dominated. It became them because form and function flow from use and power.
          • With that said, take a look at what you just posted and replace 'systemd' with 'Windows'. Wasn't Linux supposed to do things differently from Windows

            With modification and customisation comes problems and complexity, often providing more than enough rope for users to hang themselves. Doing things differently from Windows does not make something automatically better. It's always important to focus very carefully on the exact thing and way something is being done and what purpose it was originally trying to achieve.

    • Why bother. If they paid any attention to the results, we wouldn't have systemd in Debian.

      What makes you say that? A tiny number of vocal users bitching is not the same as conducting a referendum on the issue.

  • by BAReFO0t ( 6240524 ) on Sunday September 22, 2019 @09:41AM (#59223428)

    GNU/Linux, a system whose entire point is that you (the user) can adapt it however you want, to suit your needs, because everything can interoperate, thanks to everything being a file, plain text config and script files, and small tools that do one thing and do it right. Developed by a distributed community.

    Or systemd/Linux. A monolithic OS with central control and only one tool and king to rule them all. Like Windows or macOS.

    Of couse you are free to inflict upon yourself whatever you want. But if you choose the latter, you can't go around, acting like you are the former.

    And for the sake of sanity, "Linux" shall continue to mean "GNU/Linux". Otherwise Android/Linux could call itself that too, and it wouls become a big mess.
    How about PoetteringOS? Since he already tried to have the kernel his way anyway, even if it meant losing compatibility with everything else. (As reported here on /..)

    • by tepples ( 727027 ) <tepples AT gmail DOT com> on Sunday September 22, 2019 @09:50AM (#59223460) Homepage Journal

      How about PoetteringOS?

      I've seen "Poetterix" used in discussions about the expanding scope of systemd. From this IRC log [qdb.us]:

      <thebug> systemd and docker -- THE FUTURE
      <jbenedetto> hahaha
      <thebug> it sounds a lot like SMF+Zones, except those actually worked and were secure
      <thebug> LXC ... wat
      <jbenedetto> welcome to Poetterix
      <thebug> can we have beatrix potterix instead?
      <thebug> I feel like that'd suck a whole lot less

      • Re: (Score:3, Funny)

        by sgage ( 109086 )

        Lennax

      • by green1 ( 322787 ) on Sunday September 22, 2019 @10:37AM (#59223604)
        Poettering Operating System: POS for short.
        • by Lucky_Strikez ( 5037283 ) on Sunday September 22, 2019 @01:01PM (#59224126)
          I bet at some point in the future Poettering will turn out to be CIA/FBI agent, and made SystemD as crazy as it is so that backdoors could be implemented among the chaos. I mean how did he even weasel into the scene in the first place? Suddenly big Linux supports a guy with a crazy init system out of nowhere and then it was everywhere. The hatred for it is pretty universal among the community and yet it persist.
          • by AmiMoJo ( 196126 )

            He solved a problem that the distro maintainers had. All the other init systems seem to be focused on the user and flexibility, which makes them a pain for the people putting the distros together.

        • That's coming.
    • GNU/Linux, a system whose entire point is that you (the user) can adapt it however you want, to suit your needs, because everything can interoperate, thanks to everything being a file, plain text config and script files, and small tools that do one thing and do it right. Developed by a distributed community.

      An this is a good example of the limits of that approach. Making everything interoperate with everything is O(N^2) complexity, testing and conflicts. It means maintainers having to adopt awkward shims an

      • by raymorris ( 2726007 ) on Sunday September 22, 2019 @11:56AM (#59223894) Journal

        More than once I've run grep on a partition or on a disk.
        Did you know send, grep, awk, cut, etc support disk drives, partitions, LVM volumes, keyboards, modems, and a thousand other things they can operate on?

        They don't have to support any of those, it happens "magically" because a drive is a file. A partition is a file. A volume is a file. A modem is a file. A keyboard is file. Ed, sed, grep, awk and Perl operate on files. Cut and all the other tools operate on files. It's O(1) for everything to work together when each software package doesn't invest its own weird interface.

        • Indeed. And while you are absolutely right, this is an example of what I would call the "sysadmin mindset" -- which comes from the rich history of sysadmins that were the journeymen of computing. Everything is a file that can be grepped and sedded on the fly, configuration is flat text, the sysadmin know what is configured where and expertly watches over everything.

          By contrast, there is another view of computing which is the "developer mindset". This comes from the point of view of those that write software

          • by raymorris ( 2726007 ) on Sunday September 22, 2019 @01:15PM (#59224166) Journal

            I've been writing software on Linux for 20 years.
            Guess what? Your example of crontab as an interface for people, not software - well if you can't write code to parse /etc/crontab, it might be time to refer back to that "For Dummies" book.

            If you don't WANT to write 8 lines of code to handle /etc/crontab, perhaps you'd like to use the appropriate module for your language of choice, to have an OO interface:
            https://pypi.org/project/pytho... [pypi.org]

            https://metacpan.org/pod/Confi... [metacpan.org]

            If you've been programming for at least a few months, I bet you can pretty well imagine in your head the code for these modules. It's pretty simple, splitting a tab-separated line.

            Oh btw, /etc/crontab actually *is* a file. One field in each line refers to a job, and each job is a - you guessed it, a file.

            • by amorsen ( 7485 )

              Dealing with a monolithic crontab file is a pain when you maintain software. It is difficult to reliably remove crontab rules, you cannot be 100% sure that what you remove is what you put in. Hence /etc/cron.d and similar solutions.

              However, cron does not currently know about "invoke this when the system is woken up from standby" or "invoke this whenever removable media is inserted". Cron could be taught about removable media and standby, of course, but it is unlikely that such a small enhancement with so mu

    • by Cyberax ( 705495 )

      GNU/Linux, a system whose entire point is that you (the user) can adapt it however you want

      What "GNU"? My Linux doesn't have any of these stinking GNU hippies.

      Or systemd/Linux. A monolithic OS with central control and only one tool and king to rule them all.

      Is systemd controlled by a single entity like FSF that controls all of the GNU? Or maybe like the kernel that is effectively controlled by a single individual?

      Like Windows or macOS.

      Or FreeBSD.

    • GNU/Linux, a system whose entire point is that you (the user) can adapt it however you want

      Unless you're building Linux From Scratch your comment is woefully ignorant of just how many customisations are *not* possible by and end user in every distribution, and just how much gets dictated to you in the first place. This specialised and locked in approach is precisely the reason we have such a large variety of distributions to thank, being someone who doesn't like a package manager, or someone who prefers a DE that wasn't available to them, or someone who wanted to adopt a fork that isn't upstreame

  • by 0100010001010011 ( 652467 ) on Sunday September 22, 2019 @09:41AM (#59223432)

    I'm not arguing for one system over the other, but software diversity has always lead to improvements to all projects.

    clang and gcc complement each other. FreeBSD and Linux have both refactored their code to compile on both.

    Initsystems are not a 'one size fits all'. What works on a desktop might not be the best solution for a car's infotainment system.

    FreeBSD had the forked FutureBSD project that tried out launchd. [Personally launchd was pretty cool, I hated the xml config]. Sun's SMF was interesting as was Upstart.

    As long as the tool was completely FOSS, Debian used to embrace it as making its platform. The kFreeBSD project still is a really interesting idea.

    • clang and gcc complement each other. FreeBSD and Linux have both refactored their code to compile on both.

      Which is fantastic. But note that you can't just start saying you want gcc's lever but clang's AST representation passed to gcc's optimizer and then compiled to LLVM-IR.

      There's competition and users can chose either, but the two toolsets are completely disjoint and their components entirely non-interoperable. The intermediate products of compilation (PCHs, object files, ASTs, IR) are in binary formats,

  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Sunday September 22, 2019 @09:56AM (#59223496)
    Comment removed based on user account deletion
    • by RedK ( 112790 )

      That's how many problems we've had on RHEL 7 with SystemD doing things like "so I see you trying to authenticate that user with Kerberos... yeah, not on my watch..."

      Took us all of about 30 minutes to get our RHEL7 image to authenticate users with Kerberos. We know have hundreds of servers happilly all authenticating against the KDC. I don't get what issues you are having nor what systemd has to do with it since the only part of systemd we used is the default SSSD unit file to start the service.

      Only thing I could see would be the SELinux label problem on /var/cache/krb5ucache, since RedHat decided to only label /var/cache/krb5rcache in their default policy. We simply

  • Easy. Drop SystemD (Score:4, Insightful)

    by nagora ( 177841 ) on Sunday September 22, 2019 @09:59AM (#59223514)

    It is after all a load of shit.

    • by HiThere ( 15173 )

      You overstate the case. It doesn't benefit individual users. It has reportedly benefited system admins dealing with multiple systems.

      I wish systemd would go away, but I haven't yet taken any direct action to cause that to happen. That will occur when I replace my current computer.

  • I tried multiple times, asked for help, tried good ideas, also stupid ideas, gave up and resolved the errors in systemd by installing sysvinit. Why does it work for everyone else?
    • systemd works for me where the system is simple. But when I want to change things or when the system is weird and hackish then it doesn't want to allow me to succeed. So if I'm just installing a vm for some task I don't care if it's systemd or not but if it's my actual system and I might have to do something weird to solve a problem someday it's a hard no.

  • by QuietLagoon ( 813062 ) on Sunday September 22, 2019 @10:38AM (#59223606)
    ... realized. Remove any competition to the monolithic, single-point-of-control and -failure takeover of Debian. I have looked, and tried to understand, the man pages for systemd, its config files, and its control programs. If nothing else, those man pages are the best illustration of the complex, over-reaching disaster that is systemd.

    .
    But go ahead, eliminate any possibility of another system providing any manner of escape from that snowball rolling down the mountain.

    • by HiThere ( 15173 ) <charleshixsn@@@earthlink...net> on Sunday September 22, 2019 @11:39AM (#59223830)

      It's not that simple. Compare the configuration files of grub with grub2. Gurb was relatively easy to deal with. Grub2 is unintelligible. The people writing the systems have gotten divorced from the individual users. (This has always been a problem. Back in the days of Debian Potato the install manuals were gibberish, if you didn't already know what they were saying, and just needed a reminder. A lot of the time they obviously expected you to "just ask your local expert".)

      • Or they expected you to "read the source".

        • by HiThere ( 15173 )

          Ahhh....read the source to a computer operating system before you've installed the operating system?

          I get that you were being humorous, but that just isn't a plausible answer. (Unfortunately, it may be correct. Often I got the idea that they thought I had a couple of spare systems to experiment on.)

      • I have given up on figuring out where grub2 keeps its stuff. I only interact with it through the tools, and every time I touch it I need to Google.

        There is a file called grub.cfg in /boot/efi/EFI/fedora. Despite the name it is only a config file in the sense that sendmail.cf is a config file.

        The second line is "# DO NOT EDIT THIS FILE". To whoever wrote that: "Fuck you too". Do not presume to tell me what I can do or do not do on my system.

        • by MrKaos ( 858439 )

          To whoever wrote that: "Fuck you too". Do not presume to tell me what I can do or do not do on my system.

          Which implies that the entire grub configuration is duplicated...somewhere....

  • by FudRucker ( 866063 ) on Sunday September 22, 2019 @10:48AM (#59223640)
    i said Debian should build an init agnostic distro so during the install of the OS it has a screenie offering a choice of init systems to choose from like the old trational sysV or systemd or runit or whatever else is available
    • Re: (Score:2, Interesting)

      by green1 ( 322787 )
      Systemd proponents do not want choice. They know they would never win if people actually had choice. Choice therefore cannot be permitted.
      • Systemd proponents do not want choice. They know they would never win if people actually had choice. Choice therefore cannot be permitted.

        Is that why they bend over backwards giving you things you bitch about like being able to execute init files, or being able to produce text logs, or offering you the choice of doing things the old way at every bloody step of the way?

        • by troff ( 529250 )

          Translation: "Is that why they bend over backwards giving you everything you had previously, now with 1.2+M LOC that you don't want, doing things that make your life harder, require extra work to give you everything you had previously; and now Debian are considering whether they are at all committed to having anything other than the broken new stuff, because the systemd maintainers are too exhausted to even explain why they're exhausted, in the face of everybody else trying to make their stuff work?"

    • i said Debian should build an init agnostic distro so during the install of the OS it has a screenie offering a choice of init systems to choose from like the old trational sysV or systemd or runit or whatever else is available

      Not going to happen. You don't seem to realise the insane amount of work that maintainers would need to do to make something like this happen. For you it's a choice between A and B, for a maintainer it's making available A and B, and system C to select between A and B, and now they maintain 3 systems, except software D, E, and F, now needs to be tested and made compatible with 2 system, configuration changes to the system need to be made available in 2 systems... this isn't a doubling of work, it is a major

      • by rl117 ( 110595 )

        > You don't seem to realise the insane amount of work that maintainers would need to do to make something like this happen.

        Err, we already had multiple init systems supported and working in Debian prior to the systemd takeover. Including systemd.

        Somehow, it was entirely possible for many years to support this. But today it's "insane". I wonder why that might be...

  • systemd sucks (Score:5, Interesting)

    by fluffernutter ( 1411889 ) on Sunday September 22, 2019 @11:15AM (#59223736)
    If you start a long process on a server, generally you want it to run for a lomg time. Systemd goes way too far in killing processes it doesn't know about. It's not just a mechanism to control services, it tries to be a system cop. That behavior should be optional.
    • Systemd doesn't kill any processes it doesn't know about, other than child processes run by a user in a user session at user log-out and that behavior IS entirely optional.

  • by Anonymous Coward on Sunday September 22, 2019 @12:49PM (#59224076)

    Dan J. Bernstein wrote a very good init tool, "daemontols", available at http://cr.yp.to/daemontools.ht... [cr.yp.to] . It's bog stable and did the *important* thing that systemd did" replaced the often fragile init system with a much more stable and reliable one. But djb wanted a license where no one but him could build and publish the software with any patches applied. It meant that no Linux distribution would use it, because much like systemd, he widdled all over the top of the / filesystem in violation of the File System Hierarchy.

    Systemd has basically blown 15 years getting back to a stable such point because it insists on redesigning *everything else* along the way. Do not get me *started* on the replacement dhcp network stack, the automount replacements, and the insistence on killing all your jobs after you log out to kill nohup and tux and screen use, without recording anywhere that it killed your process. And oh, yes, replacing /etc/resolv.conf with a symlink that it then refuses to re-establish.

To thine own self be true. (If not that, at least make some money.)

Working...