Debian Developer Resigns From The Systemd Maintainership Team

[gens]

Sure, you'd need DBUS and the process tracker. But since dbus is now even part of the kernel, I wouldn't count that as a huge dependency.

I'd doubt, that it's only 10 lines of C code. You'd need to handle a few cases here to get it right. Maybe it would make sence to put process restarting into a shared library, I guess. As it really wouldn't make sense to repeat mostly the same code over and over again in every daemon out there. But then, you can put this code into a process hypervisor, if you have it anyway.

I'd love to see the code as I find this topic interesting.

I'm all for simple solutions. If somebody comes up with a simpler solution than systemd, that solves the same problems, I'm all for it.

dbus means libdbus, as writing using the dbus protocol yourself is brain damaging (at least for me)
and it's not in the kernel yet and it needs a user space helper

open local socket, fork, exec, read/write to socket (plus gettimeofday and maybe sleep, for timeout)
can also be over a file instead of socket

the process tracker will use proc events (notably fork and exit) + a client-server model over a local socket
the actual "tracking" will be just maintaining a list of PID's spawned from the starting process
so just an array of PID's where fork() will add a pid and exit() event will remove one
i got the client-server model in a couple of functions, the proc events netlink code from above and the rest on paper
one advantage over cgroups will be in that it can protect against fork bombs (by limiting max PID's that come from a program)
and another, more complicated to do, one will be that it can, in theory, make a genealogy tree of a process (in contrast to pstree)

i don't know of a problem that only systemd solves...
even more so as systemd uses the kernel to do almost all of the actual work

[erendorn]

i don't know of a problem that only systemd solves...
even more so as systemd uses the kernel to do almost all of the actual work

There is no problem that only systemd can solve. There are some that currently only systemd does solve (ie, that are done simply by adding a configuration flag, as opposed to coding a script to do the same functionality).
And for most of the problems, one solution can be found that is simpler than systemd as a whole, but all these solution together are not really simpler than systemd as a whole, especially in terms of configuration.

[gens]

There is no problem that only systemd can solve. There are some that currently only systemd does solve (ie, that are done simply by adding a configuration flag, as opposed to coding a script to do the same functionality).
And for most of the problems, one solution can be found that is simpler than systemd as a whole, but all these solution together are not really simpler than systemd as a whole, especially in terms of configuration.

and many other inits can do the same
and some do
(even shell can, by importing common functions using the "source" command (it is a programming language..))

in all this time i am still to find something that is either hard to do under linux or impossible without systemd

PS for some things there are no configuration flags...

edit: to add, making a special API to do common things is something that is done on android, not on a proper computer/os

[profoundWHALE]

I'm all for simple solutions. If somebody comes up with a simpler solution than systemd, that solves the same problems, I'm all for it.

That's going to be hard to find.

[gens]

That's going to be hard to find.

yes, since it solves no problems

[doom_Oo7]

edit: to add, making a special API to do common things is something that is done on android, not on a proper computer/os

Yes, go tell Google to install Slackware on their phones, they will certainly make more money with it.
(because in case you did not yet understood, this is ALL about making money since we live in a capital-led world...)

[profoundWHALE]

yes, since it solves no problems

Nothing makes me laugh more than a joke, and I just find you hilarious.

[Bm33on]

I won't be allocating my company's time to contributing to anything to do with it or anything to do with anything GNU or Linux.

[TheBlackCat]

There is no problem that only systemd can solve. There are some that currently only systemd does solve (ie, that are done simply by adding a configuration flag, as opposed to coding a script to do the same functionality).

even shell can, by importing common functions using the "source" command (it is a programming language..)

I am still not sure whether you legitimately don't understand the difference between "you could theoretically program something that does that" and "it can do that right now" or you are just being obstinate at this point. Your insistence on ignoring the distinction even in reply to people explicitly pointing it out suggests to me the latter.

[gens]

I am still not sure whether you legitimately don't understand the difference between "you could theoretically program something that does that" and "it can do that right now" or you are just being obstinate at this point. Your insistence on ignoring the distinction even in reply to people explicitly pointing it out suggests to me the latter.

you would be better reading the ~600 C standard book
these thing were possible (and done) in the days of the intel 80386 (and even before)

many programs do these things
it's not something new and unknown

so it's not theoretical, its something you would know is easy if you just did it a couple times
it seems hard because nobody is talking about it, and that is because you never usually have to do things like this

if you want to learn, read the man (2) pages from fork, execve, waitpid, socket and... idk
i know it seems complicated if you never did it, but these are really simple things

if you want something actually hard but rewarding, read this 1988 document about the synthesis kernel
maybe that will make you a bit curious of what is actually possible in computing, instead of having a philosophical opinion on someone elses motivations


but idk, it's hard to explain programming decisions to philosophers