Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Debian Linux

Debian Project Drafts General Resolution on Init-System Diversity (lwn.net) 212

Debian "is heading toward a new general resolution to decide at what level init systems other than systemd should be supported," reports LWN.net.

"I'm absolutely convinced we've reached a point where in order to respect the people trying to get work done, we need to figure out where we are as a project," writes Debian project leader Sam Hartman. "We can either decide that this is work we want to facilitate, or work that we as a project decide is not important."

LWN.net reports: The immediate motivation for a reconsideration would appear to be the proposed addition of elogind, a standalone fork of the systemd-logind daemon, to Debian. Elogind would provide support for systemd's D-Bus-based login mechanism -- needed to support small projects like the GNOME desktop -- without the need for systemd itself. The addition of elogind has been controversial; it is a difficult package to integrate for a number of reasons. Much of the discussion has evidently been carried out away from the mailing lists, but some context on the problem can be found in this bug report. In short: merging elogind appears to be complex enough that it would be hard to justify in the absence of a strong commitment to the support of non-systemd init systems. It seems possible that this commitment no longer exists across the distribution as a whole; the purpose of a general resolution would be to determine whether that is the case or not.

Unsurprisingly, Debian developers have a variety of opinions on this issue. This response from Russ Allbery is worth reading in its entirety. He argues that the 2014 decision (of which he was a part) never really nailed down the project's position toward other init systems. That was a necessary compromise at the time, he said, but it is causing stress now: "while I feel somewhat vindicated by the fact that this didn't immediately fall apart and has sort of worked, I think it's becoming increasingly untenable".... Josh Triplett zeroed in on one of the issues that is testing the init-system peace now. There is, he said, an increasingly long list of features that are only available with systemd, and application developers want to use those features... The responses to this argument took a couple of different approaches. Ted Ts'o described those features as "the 'embrace, extend, and extinguish' phenomenon of systemd which caused so much fear and loathing."

There's much more information in LWN.net's 1,600-word article -- but where do things stand now? Hartman posted a draft general resolution last week with three choices.

"It should be noted, though, that this is explicitly a draft," concludes LWN.net. "It is likely to evolve considerably before it reaches the point where the project will vote on it."


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

Debian Project Drafts General Resolution on Init-System Diversity

Comments Filter:
  • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Saturday November 16, 2019 @10:46AM (#59420054) Homepage Journal

    I'd rather ditch GNOME if that's what's making it hard to implement another init system. If they can't be arsed to support normal Unix login, they can take a hike.

    • by opkool ( 231966 ) on Saturday November 16, 2019 @10:59AM (#59420090) Homepage

      My thoughts exactly. Why does a UI need to depend on SystemD?

    • Re: (Score:2, Interesting)

      by thegarbz ( 1787294 )

      If they can't be arsed to support normal Unix login, they can take a hike.

      If normal Unix login can't support the kernel features which were implemented many years ago, maybe it should be the one hiking. Or better still, why not embrace that wonderful diversity Linux has to offer and actually use a distribution that meets *your* use case.

  • This is a step in the right direction (since the previous stance was "Fuck you. Use Systemd"). However, I fear too many people are simply indifferent to the desires of other for this to get any real traction.

    • This is a step in the right direction (since the previous stance was "Fuck you. Use Systemd"). However, I fear too many people are simply indifferent to the desires of other for this to get any real traction.

      Given the direction that Debian has taken with systemd, I would be shocked if the result is anything but making the "fuck you, use systemd" stance official.

    • by green1 ( 322787 ) on Saturday November 16, 2019 @02:09PM (#59420650)

      I suspect you are mistaken, this reeks strongly of a desire to formalize that exact previous stance so they can once and for all toss out any heretics who dare question the systemd gods. Right now they have no official policy, so some people still manage to question systemd. That won't do, and they're determined to fix that.

      Say what you will about Systemd, but it has political connections like no other project short of the kernel itself (and possibly even better than those!)

      • Say what you will about Systemd, but it has political connections like no other project short of the kernel itself (and possibly even better than those!)

        systemd has profit motives these days. IBM make money selling their services to their customers to fix the stuff they broke. (See also DOORS, ClearCase, DOORS NG, Jazz SCM).

        If everything worked perfectly you couldn't sell "systemd" experts to clients that are locked in to RedHat. (And no, just because it's FOSS doesn't mean that clients aren't locked in without substantial cost that management will never pay for).

  • gentoo (Score:2, Interesting)

    by Anonymous Coward

    has maintained openrc along side systemd from the beginning.
    A lot fewer headaches when you don't jump in with both feet and abandon previously-working solutions only to decide later that you want to go back to them...

    • has maintained openrc along side systemd from the beginning.

      Now if only I didn't have to build the system with no USE flags, and then build it again with one USE flag, and then build it again with two USE flags... Even setting just five or six of them at install time causes the build to fail.

  • The question is just how easy/difficult would it be to replace Systemd and still not break applications. THe answer being next to impossible. Applications written to integrate with systemd don't work very well, or at all, with other init systems. Which I suspect is one of its primary features.

    Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server? A system logger? Something that uses QR codes?’ ref [freedesktop.org]

    The singular aim of systemd is to get other projects to depend on it. T
  • From one of TFAs:

    Systemd user sessions, socket activation, sysusers, dynamic users, systemd-homed, temporary directory setup, transient units, anything talking to the slice or control group APIs, containerization, firstboot, systemd's whole "preset" system-wide configuration and policy mechanism for admins to say "what services do I want launched when installed and what services do I want to leave stopped until I configure them", "stateless system" capabilities, and I'm probably forgetting another dozen.

    I think we need to move past the framing of "people don't want to write init scripts"; this is also about being unable to use a decade of additional capabilities that go far beyond sysvinit.

    Granted, some of those things are appropriate for an init system role, but doesn't systems also have some support for things like DNS, NFS and NTP? Feel free to add other things systemd does that it really doesn't need to (shouldn't?) be doing.]

    In any case, maybe systemd is doing too much, after all, it's suppose to be an init system, not the general OS toolbox. Perhaps I'm preaching to the choir, but just adding my $0.02.

    • by mvdwege ( 243851 )

      but doesn't systems [sic] also have some support for things like DNS, NFS and NTP?

      No.

      Here's a cracker, Polly

  • So why should we let Lennart drop a trojan horse and do an embrace, extend, and extinguish internally in Linux? Lennart and systems is a cancer in the world and needs to be extinguished.
  • by allquixotic ( 1659805 ) on Sunday November 17, 2019 @01:43PM (#59423352)

    The best way to deal with this is to build bona fide standards -- APIs, wire protocols and such-like -- for all the features that systemd is trying to expand into. Do this for anything where the "de facto" way of doing it is really poor for various reasons, and a new design is needed to simplify and clean up the system. Introduce these userland standards at places like the Linux Plumbers Conference, and invite other implementations than systemd to pick them up. Specifically design the standards so individual pieces of the stack can be slotted in, rather than requiring by design that the entire thing be a monolithic project/daemon.

    Once you accomplish that, it would be easy for application developers to target these APIs and wire protocols in a way that's easily swappable between systemd and other implementations, and users could either use systemd or alternative implementations of any subset of the features.

    This would require a slight change in direction from systemd, towards more of a standards-based implementation and perhaps slow down the velocity, but it would make it much easier for folks to support new features -- things that the old standards like POSIX, X11-related standards couldn't support -- without having to track an arbitrarily-changing systemd design. Then, it would be easy for projects like Debian to decide to support init system diversity as long as they can implement these standards, and systemd would no longer be the only way to get these features. In turn, downstream projects like GNOME would target the standards instead of targeting systemd directly.

    There's value to be had in making a standard so general that you basically HAVE to have multiple implementations of it before it gets standardized. That's how the web works -- with a few exceptions like proprietary codecs, by and large the web standards work pretty efficiently at introducing new JavaScript versions and suchlike, but you almost never see websites these days "designed only for Chrome" or something. You can use the latest Firefox, Safari, or Edge to get the same functionality. Sadly, Edge is going away -- I liked it in the sense that it increased browser engine diversity -- but at least there are still the big three.

    Having multiple implementations of the standards all but prevents private extensions and arbitrary incompatible changes, because users will complain if a significant market share belongs to a competing product and they can't take advantage of what your site demands. We could do something analogous with the login, networking, logging, hardware management and init systems built on top of Linux, with systemd being kind of the Firefox (the grandfather) and something else being the Chrome (the newcomer).

  • by Seven Spirals ( 4924941 ) on Wednesday November 20, 2019 @02:04PM (#59436092)
    Devuan already made the right choice (ie.. giving people init-freedom at this time only between openrc and SysV-init). Debian already made the wrong one and lost plenty of mindshare in the process (witness the health and vitality of the Devuan project and others now three years old). Just keep all those systemd lamers in one place running the mainstream garbage, I say. Let Debian share Linux's increasing estrangement from it's Unix roots while Linus is off writing codes-of-conduct and going on an apology tour an PTA booster tour. In short: fuck this shit. The clueful already went elsewhere long ago. Too little too late Debian assholes. You should have grown these sensibilities back in 2015 when people still cared that you were about to turn "suck" to 11 with systemd in the first place.
  • by slashdotjunker ( 761391 ) on Wednesday November 20, 2019 @11:57PM (#59437994)

    I can save you a lot of time. If you feel the need to discuss whether or not you want to support diversity then the answer is clearly no.

    There are only two meaningful answers to a question like this: yes or no.

    If your answer is yes then it won't change anything. A discussion like this can only occur after support for diversity has already been lost. People will not change their opinion because you release a press statement. Trust is regained through action.

    If your answer is no then it will not change anything because you have already stopped supporting diversity. The only effect is to act as a psychological barrier to any future attempts to support diversity.

    Given the outcomes above there is no reason for anyone who supports diversity to want to have a discussion about diversity. At best there will be no effect. At worst, the opportunity for institutional change will be lost forever. On the other hand, if you are against diversity then these outcomes are very good for you.

    My advice is to abandon this high-level discussion and return to the concrete problem. Do you want to merge this package or not?

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...