Debian Init System Discussion Is Still Unsettled

[bkor]

Also, I recall someone mentioning that if there was a program ported from OS X to Linux and it depended on OS X functionality, the developer would have to make the program free of those API dependencies rather than require Debian to implement them (making it as a parallel to the GNOME situation). Which I find hilarious, because that's not true even in such a parallel ? the developer has full rights to have the program depend on an OS X emulation layer (I forget how it's called) and require Debian to include the layer, or otherwise the program wouldn't be able to run. It's a perfectly valid dependency. Not ideal to have it, but it's not dependency for the sake of dependency, either.

That dude is trying to push OpenRC. As none of the init systems other than systemd is intending to provide things at the Linux plumbing layer, he is facing difficulties trying to promote it. Every time I push back at him, he replies with: "you do not need this" or "this should not be needed". E.g. with logind functionality, etc.

Quite sad, I've asked him privately to stop. Now had to resort on the bug to tell him STFU.

[Akka]

Well, KDE now uses the startkde shell script to, well, start the KDE environment, and startkde is a complicated, old, unreliable minefield of a script, and something that systemd could do much better with its user sessions in a reliable, consistent and easily debuggable manner. Similar thing with KDM, it's a huge piece of old code that is extremely difficult to debug and change, and it seems that there aren't any people left who actually know how the thing works to begin with (those who try to figure it out seem to get a headache). So KDE plans to get rid of both as soon as they can, and replace them with superior alternatives (for KDM, they were thinking of SDDM or LightDM, probably the former). Probably in time for KF5 launch.

Yes but I think systemd user session is another thing. They are already supporting logind. Systemd user session is something they discuss for the future.

[Delgarde]

Yea. The GNOME upstream by far has no such obligation, since it's their project and they can do with it what they wish (especially sine systemd integration is the logical thing to do in their case, other options are simply inadequate). Debian could remove GNOME from the archive, but that would most likely cause major fallout, and I don't think Debian developers want that. Then the only way out would be to force Debian GNOME maintainers to do the job, but they aren't very enthused about it, either (and why would they; they have stated their opinion on the list, and they are wholly supportive of GNOME's general direction, and don't feel like maintaining legacy code that nobody else cares about).

It's also a mistake for people to think of this exclusively as a GNOME problem. GNOME is the most immediate example of upstream developers depending on a specific PID1, but it should be seen not as an isolated case but as the possible start of a trend. They need to stop fixating on GNOME, and take a look at what other upstream desktop developers are thinking. Both KDE and XFCE have support for logind, and KDE at least is contemplating further systemd use - even if it's optional to start with, it's unlikely to stay that way.

Mind you, I don't see most of the TC participating in this discussion in particular. The general sentiment seems to be "if someone provides a patch that makes it work under non-default inits, accept the patch", but it doesn't force the maintainers to write the patch in question. Also, forcing the maintainers to do anything is unimplementable to begin with, unless there is a 3:1 majority vote to change the rules.

Yes, that's the major sticking point at the moment... Ian in particular is very keen that whatever the committee decides as to the default init, they need some sort of official statement discouraging packages from depending on a specific PID1 (default or otherwise). Others (particularly Russ) are strongly against such a statement, seeing it as unnecessarily proscriptive, and somewhat overstepping the committee's mandate.

[Delgarde]

Systemd user session is something they discuss for the future.

That's correct. Nobody, including GNOME, is using systemd user session already. But GNOME is actively moving in that direction, with current discussions on their mailing lists being focused on the technical issues, rather than over whether it should be done at all. And while KDE aren't quite so far along, it's definitely something they're talking about. Also interestingly, there was talk on the GNOME lists about reaching out to those KDE guys, getting some collaboration over how they implemented things... good to see.

[mrugiero]

It's also a mistake for people to think of this exclusively as a GNOME problem. GNOME is the most immediate example of upstream developers depending on a specific PID1, but it should be seen not as an isolated case but as the possible start of a trend. They need to stop fixating on GNOME, and take a look at what other upstream desktop developers are thinking. Both KDE and XFCE have support for logind, and KDE at least is contemplating further systemd use - even if it's optional to start with, it's unlikely to stay that way.

Still, they don't have any obligation to support other things. I'd be pissed only if they rejected patches to offer support for alternatives just because it's not the one they chose, but because they don't implement all of the alternatives? They are in their right to choose what to work on. Again, is there anybody volunteering to maintain or pay for maintainance of both ConsoleKit and the ConsoleKit backend for those projects? For sysvinit/upstart support in the case they start depending on systemd as PID1? Otherwise, you are free to complain, to suggest, to express your frustration or concerns, but you have no right to dictate what others do. You always have the option to do the work, and I'll personally support your position if your patches get rejected with no technical basis other than "we prefer systemd, neener neener", and my guess is that you'll count with the support of a big share of the community. You also have the option to fork a project in that case.

[Vim_User]

Apparently OpenRC is so bad, they rather continue to use Upstart.

I guess you can tell us that because you were part of the team that has made the decision which init system to use on ChromeOS?
Or are you just another troll that foesn't understand the meaning of "fits better for our purpose"?

[profoundWHALE]

Okay so this may sound crazy, but what if:
SystemD with support for other inits.

But before you try hang me, hear me out. For Linux, specifically Linux, systemd is the clear choice, for cross platform Upstart is the clear choice, and for licensing and more of an evolutionary step for people who don't like sudden change, OpenRC is the clear choice.

Simply use systemd how it is, integrated with the Linux system, but add functionality to the other 3 inits to work with it. That way Debian Linux will still get it's systemd and the others will still get their new cross platform inits with legacy support if they want to keep the old one.

[GreatEmerald]

Yes, that's the major sticking point at the moment... Ian in particular is very keen that whatever the committee decides as to the default init, they need some sort of official statement discouraging packages from depending on a specific PID1 (default or otherwise). Others (particularly Russ) are strongly against such a statement, seeing it as unnecessarily proscriptive, and somewhat overstepping the committee's mandate.

Indeed. Ian Jackson seems to be doing everything in his power to make sure Upstart gets maintained in some way, and given that currently there is nothing that depends on Upstart being PID1, anything that restricts that is currently in favour of Upstart, whether or not it becomes the default.

Still, they don't have any obligation to support other things. I'd be pissed only if they rejected patches to offer support for alternatives just because it's not the one they chose, but because they don't implement all of the alternatives? They are in their right to choose what to work on. Again, is there anybody volunteering to maintain or pay for maintainance of both ConsoleKit and the ConsoleKit backend for those projects? For sysvinit/upstart support in the case they start depending on systemd as PID1? Otherwise, you are free to complain, to suggest, to express your frustration or concerns, but you have no right to dictate what others do. You always have the option to do the work, and I'll personally support your position if your patches get rejected with no technical basis other than "we prefer systemd, neener neener", and my guess is that you'll count with the support of a big share of the community. You also have the option to fork a project in that case.

Nobody is willing to touch ConsoleKit with a 10-foot pole. To the point where Canonical rather ripped out logind than maintain ConsoleKit. So yes, nobody has a right to demand anyone else to maintain ConsoleKit. As for rejecting compatibility patches just because, I agree that it wouldn't be a nice thing to do, and it seems to be the general sentiment of the TC as well. (Although still, when implemented, the maintenance for the patch should fall on whoever submitted the patch, not on those that pulled it in and otherwise work on another init system.)

Okay so this may sound crazy, but what if:
systemd with support for other inits.

But before you try hang me, hear me out. For Linux, specifically Linux, systemd is the clear choice, for cross platform Upstart is the clear choice, and for licensing and more of an evolutionary step for people who don't like sudden change, OpenRC is the clear choice.

Simply use systemd how it is, integrated with the Linux system, but add functionality to the other 3 inits to work with it. That way Debian Linux will still get it's systemd and the others will still get their new cross platform inits with legacy support if they want to keep the old one.

That's pretty much the general sentiment of the TC at the moment, it seems like. Except that Upstart is no clear choice for the others; kFreeBSD will have it as an option, but that's an option they might not want at all, given that Upstart on BSDs is an extremely new thing and probably still has bugs to be ironed out before it's production quality. And on Hurd, Upstart isn't even an option, and nobody can force Hurd maintainers to port Upstart to Hurd. So it feels like OpenRC is the clearer choice for non-Linux systems at the moment.

[GreatEmerald]

Oh dear, looks like ChaosEsque Team has found its way to this thread. Thankfully, ignore lists to the rescue!

[gens]

For now, yes. But give it a year or so, and things might look different... several KDE developers have expressed interest in what Gnome is doing with systemd, because as a desktop, they have exactly the same problems. I believe they already have some support for logind, and at least one of them was speculating on the systemd user-session aspect recently (can't remember where I saw it... possibly a G+ post linked off this Debian discussion?)

Edit: Here was one of the discussions I was thinking of...

https://plus.google.com/+MartinGr%C3...ts/GMtZrNCeaLD

yes, in 5 years we might have an operating system as powerful as windows XP
logind is a replacement for console-kit
check a bit about the history of console-kit
i agree something like that might be needed for idk .5% of GNOME/KDE users (or less) and ye its a cool feature, but check console-kit history again and tell me it couldn't have been done properly


id guess Martin is about as young as me, and thus finds things like socket activation to be new, exiting and needed
but socket activation, same as almost all that systemd does, is not new and does not bring any real benefit

think about it
you have a 1MB daemon that starts idk an hour after boot instead of on boot
well... useless, but ok its fun

then you have an init system that for whatever reason you must have to do that socket activation
it uses 20MB and runs from the start