Debian Init System Discussion Is Still Unsettled

[GreatEmerald]

Although not a whole lot of people will probably read this due to the bot deciding to move the topic on the last second, but the TC had an IRC session where they more or less decided on the ballot text. If everything goes well, another voting session should start soon (Monday or even sooner): https://lists.debian.org/debian-ctte.../msg00603.html

Though I'm still a bit confused about the whole tight/loose thing. What does "require a specific init system to be PID1" even mean? For instance, last I checked, GNOME requires logind, not anything to be PID1, so they should be unaffected, as far as I understand that. But helper tools like bootchart really do need specific PID1s for the operation...

[droste]

yes
most of it is done by cgroups [...]

Yeah "most of it". What about the missing pieces?

[...] so all you need to do is to know when something is started and set it's cgroup.. policy i guess to whatever is defined somewhere
if you need to set something after the fact or dynamic or whatever, make a GUI or a daemon that does it [...]

You mean like systemd?

[...] point is you do not need a special init system, nor patch every thing to do it

or is there something wrong with that ?

Since you seem to have a solution to replace everything systemd does with a simple and elegant solution, why don't you implement this and we can replace systemd with this as soon as you're done?

http://0pointer.de/blog/projects/why.html

[liam]

Call me old fashioned, but when you mention sockets being opened and a service being spawned on-demand, I think of:

http://man.freebsd.org/inetd

"The inetd utility appeared in 4.3BSD"
"4.3BSD was released in June 1986"

But systemd can add cron and syslog to its list obnoxiously reinvented services, which developers will be told to now learn and then rewrite their software to accommodate. The same thing all over again in another couple of years no doubt.

None of those things are claimed to be an invention of systemd.
I've refrained from taking part in this thread because: 1. most of the people against it either don't really understand the issues or will not be swayed by any conceivable technical argument, protestations notwithstanding, 2. the people who are actually developing Linux want the features that systemd offers so what debian decides doesn't really matter. More and more of userspace is going to assume the presence of systemd APIs. As a result the distros will become more stable, more functional, and Linux will attract more users. The people that are either bring graybeards or chicken Little's will either move to alternative platforms or adjust.

[TheBlackCat]

then you have an init system that for whatever reason you must have to do that socket activation

You didn't actually read his post, did you? He was quite clear that he doesn't care about systemD per-se, it is just that systemD is the only system available (and maintained) right now that offers the specific socket activiation features he needs.

[TheBlackCat]

would you mind posting the startkde script, i don't have kde installed
would be grateful

You know KDE has a public git repository, right?

http://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=53d1bc6a2098f634c5f386f95e1a1c504b554303&hb=8a9917b02f7bdf25453f7e2c2223ee06552be0b2&f=startkde.cmake

[gens]

Yeah "most of it". What about the missing pieces?



You mean like systemd?



Since you seem to have a solution to replace everything systemd does with a simple and elegant solution, why don't you implement this and we can replace systemd with this as soon as you're done?

http://0pointer.de/blog/projects/why.html

yes, most of it
you need a "hook" for events like launching some processes and a bit of common sense
i read Lennart put a public post about how hard it is, too hard for the KDE guys (and thus mostly anybody)

yes like systemd, and like openrc and like... idk

'cuz i don't need all this crap
i wont limit my computer session...
i wont... in fact lets go over that list

i wont interface my init with dbus, its desktop bus
i wont have a shell free bootup, i think shell is a great programming language
i wont have modular coded early boot services (what ever the f that is)
i wont... hmm actually read ahead is good in some circumstances, but i hear my hard drive working for ~80% of the boot (and there are programs that do that already)
i wont have socket based activation on any daemon, its just useless
bus based and device based... what is that udev ?
i wont use "Configuration of device dependencies with udev rules", if they are udev rules then udev ? whatever that means (i guess its about not liking /usr on a diff disk)
i wont use path based activation, wtf, not for an init system
i use timer based activation, its called cron
i handle mounts...
i handle fsck...
i dont care about quota, but can handle it easy
i dont automount, i click on things or use fstab (not that i cant)
i dont even have swap, but if i did.. fstab and swapon/off, its easy
i wont snapshot, but if i wanted btrfs is good at it
XDG_RUNTIME_DIR Support... rly ? "export XDG_RUNTIME_DIR=/somewhere/over/the/rainbow" i wonder
i wont kill other users processes, i dont have other users (but if i did... you know how it goes)

this list treats sysvinit as the init program itself, not the scripts
what is hypocritical since on the first page of he's propaganda he talks for a while about how "bash" is bad (bash, not shell... bash... debian uses dash by default so they safe)

also cgroups are made for containers
it's just the way they are made (good) that makes them suitable for multi-seat and limiting daemons/users/whatever resources

[gens]

You know KDE has a public git repository, right?

http://quickgit.kde.org/?p=kde-works...startkde.cmake

is that an insult or you being helpful ?

anyway i see most of that script is to handle X
systemd would save some... idk 30 lines ?


i give up
for all the systemD fanboys
dig that hole and have fun doing it
no hard feelings

here's a song http://www.youtube.com/watch?v=ttzwW7pIVIw

[TheBlackCat]

anyway i see most of that script is to handle X
systemd would save some... idk 30 lines ?

Now I know for a fact you never read what he actually wrote. startkde is going to be kept for X11, socket activation is only going to be used for Wayland. Rather than rewriting most of startkde from scratch to work with wayland, he thought it was more efficient to use a pre-existing, commonly-used, well-tested system instead.

[smorovic]

To me it's: use systemd for linux, and something else for BSD and Hurd variant. That's up to mantainers to vote on what they want.

For the latter:
Upstart might support non-Linux, but that's still not there. While they could opt to support it (in addition to systemd) so they don't diverge too much from Ubuntu (which is in some way connected to Debian in both directions), right now it isn't an option for non-Linux (only long term when porting is done). Also, Ubuntu employees shouldn't have a vote in this because of conflict of interest.

For Launchd, there is some *BSD work to port it, but it's probably going to be a fork (Apple might be unwilling to integrate support for non-OSX port). Hurd is probably even more behind with it. So it's a no for launchd.

Sysvinit is the obvious currently working choice for non-Linux. The only possible solution is OpenRC, but AFAIK there is no Hurd support.

So now I don't see other sane choice but systemd for Linux, sysvinit for kFreeBSD and Hurd. And also mandatory to have support for components that are available not only for Linux.
Maybe Upstart boot support should be there, but package support should be optional, so Ubuntu people can work on it if they want. Although in practice this might end up unrealistic to support (if people will do their software in a way that's incompatible with upstart, what to do then? maintain forks?)

[nanonyme]

To me it's: use systemd for linux, and something else for BSD and Hurd variant.

Hurd port of systemd might actually make even a tad of sense. (Hurd not being anti-GPL like eg FreeBSD)