Debian Init System Discussion Is Still Unsettled

[erendorn]

As you have said, process tracking is still experimental, however that said it is still being further developed and there is experimental support for restarting a service, however it works by killing all processes spawned by the one in question, including some important ones e.g. SSL so for that fact it's still labelled as experimental.

As far as feature parity with systemd, it has a lot of catching up to do, however the pace of development is picking up and in time it should hopefully provide a suitable permissive licensed init service with process tracking.

Will it also have declarative configuration of services? This is the one thing I like about systemd, as a non serious admin. Long init scripts are hard to change, and harder to maintain diffs, while service files are much easier to understand. And I trust init system developers much more than I trust myself with a shell script

[Akka]

Will it also have declarative configuration of services? This is the one thing I like about systemd, as a non serious admin. Long init scripts are hard to change, and harder to maintain diffs, while service files are much easier to understand. And I trust init system developers much more than I trust myself with a shell script

I think they already have that at least for the more common cases. I think this was one of the original goal with openrc?

[TheBlackCat]

restarting services is easy

It doesn't track the children of services.
It doesn't prevent services from hogging system resources.

that is what cgroups do

It doesn't handle dependencies.

writing a parser for existing dependency based systems is not that hard
maybe some logic or tracing or whatever

It doesn't provide the additional tools.

a cgroups gui actually sounds fun to me
it could be extended to track the memory/cpu/network usage of processes and derive per user, disk and similar charts
it could even blink bright red when it gets something weird or the processes tree doesn't look like it should
(like a rogue process or maybe from something like ptrace, or a full auditing system like audit)
it could even compress and encrypt the data and send it over the network to an admin gui
thx for the ideas

If it's so easy, what are you waiting for? Come back to us when it is implemented. In the meantime, your tool is simply not a replacement for systemD.

[intellivision]

If it's so easy, what are you waiting for? Come back to us when it is implemented. In the meantime, your tool is simply not a replacement for systemD.

It has surpassed Upstart in terms of cgroup support and with the current rate of development, it will catch up to systemd's early feature list and it will provide a permissively licensed alternative to that init system.
It was also a dick move for Freedesktop.org (which is a cross platform project) to abandon non-Linux platforms by adopting a Linux only framework (logind) with absolutely no attempt to make a solution that worked on other platforms.

[interested]

It has surpassed Upstart in terms of cgroup support and with the current rate of development, it will catch up to systemd's early feature list and it will provide a permissively licensed alternative to that init system.
It was also a dick move for Freedesktop.org (which is a cross platform project) to abandon non-Linux platforms by adopting a Linux only framework (logind) with absolutely no attempt to make a solution that worked on other platforms.

Where did you get that idea about logind? freedesktop.org is just a file hosting site and an informal meeting place. It doesn't chooses anything at all.

Regarding some of the projects like KDE and Gnome, then they are using logind because it works and is actively maintained, unlike the bit rotting, unmaintained ConsoleKit. There are precious few desktop developers, so please understand why it is hard for them to personally use or support abandonware.

I would say that the obligation was entirely the opposite; it is a dick move, that the non-linux systems can't be bothered to develop infrastructure that helps upstream Desktop Projects, or at least, just maintain those bits of infrastructure that already exist.

Non-Linux systems just aren't pulling their own weight when it comes to supporting DE's.

[MartinN]

Where did you get that idea about logind? freedesktop.org is just a file hosting site and an informal meeting place. It doesn't chooses anything at all.

Regarding some of the projects like KDE and Gnome, then they are using logind because it works and is actively maintained, unlike the bit rotting, unmaintained ConsoleKit. There are precious few desktop developers, so please understand why it is hard for them to personally use or support abandonware.

I would say that the obligation was entirely the opposite; it is a dick move, that the non-linux systems can't be bothered to develop infrastructure that helps upstream Desktop Projects, or at least, just maintain those bits of infrastructure that already exist.

Non-Linux systems just aren't pulling their own weight when it comes to supporting DE's.

that's a crying shame if you ask me (pulling the weight on DE's)... FreeBSD and Linux as the two main OS stalwarts for the last 2 decades or better should be shamelessly ripping each other's off ideas and code for just about everything, to the extent such 'ripping' works for either of course. I have healthy respect for FreeBSD (not so much the other *BSDs as I never really ran those...) and it's nice to have -some- competition and a bunch of committed geeks coding to both OSs... as much as I love Linux that is...

I don't see why the app landscape on Linux and/or FreeBSD oughta differ that much... theoretically, all open source apps should port either without or with some effort to both platforms (at least that's the idea .)

[intellivision]

Where did you get that idea about logind? freedesktop.org is just a file hosting site and an informal meeting place. It doesn't chooses anything at all.

Regarding some of the projects like KDE and Gnome, then they are using logind because it works and is actively maintained, unlike the bit rotting, unmaintained ConsoleKit. There are precious few desktop developers, so please understand why it is hard for them to personally use or support abandonware.

I would say that the obligation was entirely the opposite; it is a dick move, that the non-linux systems can't be bothered to develop infrastructure that helps upstream Desktop Projects, or at least, just maintain those bits of infrastructure that already exist.

Non-Linux systems just aren't pulling their own weight when it comes to supporting DE's.

This is exactly what I was talking about. Consolekit was active while logind was being developed, with the full knowledge that logind would be a Linux only affair. The Consolekit guys abandoned their work to focus on logind, leaving no non-Linux alternative. The freedesktop.org crew then decided that logind was the only way forward, this was also because the Consolekit developers have ACTIVELY been avoiding correspondence on documentation and maintaining Consolekit, so forking it isn't an option

[interested]

This is exactly what I was talking about. Consolekit was active while logind was being developed, with the full knowledge that logind would be a Linux only affair. The Consolekit guys abandoned their work to focus on logind, leaving no non-Linux alternative. The freedesktop.org crew then decided that logind was the only way forward, this was also because the Consolekit developers have ACTIVELY been avoiding correspondence on documentation and maintaining Consolekit, so forking it isn't an option

Again, what you are saying is, that Linux developers should do the work of maintaining essential stuff for non-Linux systems. Why can't the non-Linux developrs themselves maintain CK or develop an alternative that upstream DE's can use?

It was clear from the beginning, that when the original authors had abandoned CK, that CK was on essential life-support only. The problem being, that CK allegedly is a rather nasty codepile that was never very well documented.

There have been numerous "warnings" about this for years, also on the Debian developer lists, but those few that allegedly tried to look into CK, found it difficult and beyond their ability to maintain. Well, no wonder. That the CK code base is byzantine has been stated by anyone involved in it. Don't blame the unfortunate temporary maintainers that they won't bother holding hands for anybody trying to maintain a difficult code base they themselves left a year ago, they may have other things to do in their life. And they are not withholding any documentation; there never was any.

So now CK have been bit rotting for +1? years. Don't blame the systemd guys for actually develop an well documented functional alternative to CK. If they can, why can't the non-linux guys?

The bit rotting is now so bad, that upstreams DE's have problems supporting it, and upstream DE's certainly aren't getting help for this from anybody.

The right solution isn't ranting against Poettering, freedesktop.org or anybody else, but to get of the couch and start coding.