Debian To Seek A General Resolution Over Their Init System Policy

[dwagner]

If there is a such a substantial amount of other packages already dependent on what particular executable got assigned PID 1, that per se is a sign that the development turned into a wrong direction.
systemd has become the Jack of all trades, master of none, and pulls adjacent software into the same abyss.

[F.Ultra]

If there is a such a substantial amount of other packages already dependent on what particular executable got assigned PID 1, that per se is a sign that the development turned into a wrong direction.
systemd has become the Jack of all trades, master of none, and pulls adjacent software into the same abyss.

This is not about packages being dependent on systemd, this is about the maintenance burden of also supporting other init scripts. Not to mention that this _again_ is the "damn systemd for being so good that other devs find it useful" fallacy.

[F.Ultra]

When your choices are between the plague and cholera I guess you can't complain why people question why to even bother with the choice...

Oh and before the usual retorts based on the straw man that the complaints against systemD are just people who think init is better, I'm just going to point out that the argument against is more or less entirely around the implementation. Nothing wrong with copying the basic concepts of OSX's launchD and init definitely needed to be retired, but Pottering & Co undeniably botched the implementation.

I'm really not kidding about systemD starting out as copy/re-implementation of launchD (which is quite highly regarded). PulseAudio, another one of Pottering's projects, also started as a copy/re-implementation of CoreAudio (which is also quite highly regarded).

How was the implementation botched?

[dwagner]

This is not about packages being dependent on systemd, this is about the maintenance burden of also supporting other init scripts.

That is exactly what I mean: If your package has to "support" some particular init software, that is a sign of poor design decisions. If your executable requires some additional script to be started - that is bad enough already - but if that script then also has to take into consideration particularities of software A or B calling exec() on it - that is even worse.

[k1e0x]

Can we just fork already? Linux and Redhatix need to go their own ways..

[jacob]

If there is a such a substantial amount of other packages already dependent on what particular executable got assigned PID 1, that per se is a sign that the development turned into a wrong direction.
systemd has become the Jack of all trades, master of none, and pulls adjacent software into the same abyss.

Every single package is already dependent on what particular executable runs in kernel mode, namely vmlinux.
I don't get this obsession with no dependencies. It makes the OS brittle, inconsistent, unpredictable and essentially unusable as a development platform.
But if it helps you, consider systemd not as a package but as a collection of packages. It has been repeated ad nauseam: the purpose of systemd isn't to replace init, but to replace GNU (or FreeBSD-base etc.)

[oiaohm]

If there is a such a substantial amount of other packages already dependent on what particular executable got assigned PID 1, that per se is a sign that the development turned into a wrong direction.
systemd has become the Jack of all trades, master of none, and pulls adjacent software into the same abyss.

You point here is kind of right. But you miss the problem.

Lets start with elogind vs systemd logind.this is a on going conflict and a design error. Both have the same parent source being systemd logind. elogind has been modified to work without systemd. Please note without systemd as in your are running systemd you use elogind and things don't workout right.

Now this is only the start of the problem. elogind and systemd logind in debian and other distributions where both exist can both be based off different versions from the mainline systemd tree resulting in differences in configuration files.

Really what need to happen is different to what is happening. elogind in it current form need to disappear what need to replace it is the following one of the following.

1) full fork of systemd where logind has been modified to work with and without systemd init and service management from a single binary.
2) patch merged into mainline systemd where logind can work with and without systemd init and service management from a single binary.

Same really applies to eudev as well.

Its not really init diversity when you install elogind and eudev results in systemd init/service management not being able to work right.

Really we have like two different kids in the playground breaking each other toys because they are unwilling to share wondering why they end up with no toys that work.

Forking is a good way to prove that something is possible at some point a fork either need to replace what it forked or merge back in. Part forks like eudev and elogind cannot replace what they are forked from and are not designed to merge back in either.

If you are going to fork a project for long term sanity either fork it all or don't fork it at all. if you disobey this rule you create the elogind/eudev mess we have now.

[NotMine999]

To avoid needless dispersion of worldwide Linux developer resources, the world only needs 2 Linux distributions that use systemd:

1. A release that is "rolling", like Arch (for folks that like to walk near the bleeding edge of stuff)
2. A release that is "staged" (not a "rolling" release), like Debian (for folks that demand stability over bleeding edge)

As I have posted in the past, if all distributions are using systemd, then what unique features do they offer?

• kernel optimizations?
• package selection?
• packaging method?
• fancy skins on the desktop?
• multiple desktop environments?

How would any of those options actually sustain a distribution for long if they did not have access to "deep pockets", like Intel and Redhat?

As for non-systemd distributions, only 2 are needed:

• a release that supports SysV init
• a release designed for enbedded systems with a minimalist boot/init system

The SysV init release should satisfy the "never systemd" crowd and those implementations that want a Linux distribution but lack a systemd port. The embedded release addresses that crowd.

So there we go, the world really only needs 4 different Linux distributions.

[CommunityMember]

Really what need to happen is ....

Your actual code contributions are going to be welcome. Telling other people what to do, and how to do it, is likely not so well received in a volunteer organization.

Those that want init freedom (i.e. not depend on systemd) have mostly been primarily talk, and not contributing actual code with testing. Few packagers will not accept working and tested code, but being told how they must package rub many the wrong way with their limited volunteer time. Perhaps those packagers should leave the ecosystem, or perhaps those that desire init freedom need to step up and take ownership of all those packages.

[bregma]

systemd
pɯǝʇsʎs
ʂყʂƚҽɱԃ
s̡̜̗̲̠̯̰̥̬̲̠͍͆͢͝ͅy̢̨̢͙̩̯̰͓̘̱̲̺̟̪̟͢s̢̨͙̫̬̺͚̻͚̹̙̯͆͛͛ ͈t̢̨̘̝̙̫̪̠̙̰̠̜̰͢͜͜e̡̻̰̰̜̲̖͚̞̞̗͕̮̯͆͛m̰̻͇͙̹͓̬̞̣̠̺͛͢͝ ̩͆d̢̨̬̰̦̙̩̻̗̖͚͈̙̙͛͞