Debian Developer Resigns From The Systemd Maintainership Team

[gens]

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

to add:
simple process starting as done by all the daemons, for example, does exactly what socket activation does but simpler and without the 60 lines patch against dbus/systemd
result the same, complexity way lower
before you start: the diff is in the init waiting using waitpid vs waiting on a dbus socket, so the same from the init standpoint
and i know that it is for "starting processes before they can actually start working", but that is no gain time-wise (as explained elsewhere on this forum)

[TheBlackCat]

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

*sigh* Now we are back to writing shell scripts. You clearly have no interest in actually reading the posts you are responding to.

[gens]

*sigh* Now we are back to writing shell scripts. You clearly have no interest in actually reading the posts you are responding to.

...the point was that it is a powerful programming language
you *can* do it right now, if you know how
hint: it has variables, functions and stuff, so it can be done simply (source command is to import them in 1 line)


PS there was an example of a parallel starting init written in shell that would boot the computer in 5 sec

[mlauritsen]

Since SysV init and BSD init were designed lots of new things have happened in the world of computing - the modern Linux kernel, hot pluggable hardware, suspend/resume, mobile computing, networked storage etc. didn't exist back then.

All of these new features need some kind of support from the init system, and yes, you can get that by extending SysV init, using shell scripts or whatever. As I see it the point made several times above is that you can get that much easier by using systemd which gives you the needed bits in a neatly packaged, integrated, well tested, documented and supported package, instead of some hacked-up solution that you need to spend a lot of time putting together yourself.

[TheBlackCat]

...the point was that it is a powerful programming language
you *can* do it right now, if you know how
hint: it has variables, functions and stuff, so it can be done simply (source command is to import them in 1 line)

No, having to write a new program to do all that stuff means it can't do it right now, and won't be able to do it until someone writes a program to make it do so. It is no better than saying COBOL can do that stuff now because someone could, theoretically, write a program that does it using that language.

[doom_Oo7]

...the point was that it is a powerful programming language
you *can* do it right now, if you know how

The point is not that you could be able to do it, but to have somebody do it in an abstract, terse, and generic way because 99.9999% of the daemons just require to be launched on computer startup and killed when it's shutting down.
This way, everybody can reuse the same code (WITHOUT FUCKING COPY-PASTING IT).

[erendorn]

...the point was that it is a powerful programming language
you *can* do it right now, if you know how
hint: it has variables, functions and stuff, so it can be done simply (source command is to import them in 1 line)


PS there was an example of a parallel starting init written in shell that would boot the computer in 5 sec

Who needs applications or even an OS when you have assembly?

[nanonyme]

Who needs applications or even an OS when you have assembly?

Assembly sounds rather high-level. Why not just push executable binary code through punch cards?

[erendorn]

Assembly sounds rather high-level. Why not just push executable binary code through punch cards?

As long as it's turing complete, it can do as much as systemd, don't worry.

[gens]

The point is not that you could be able to do it, but to have somebody do it in an abstract, terse, and generic way because 99.9999% of the daemons just require to be launched on computer startup and killed when it's shutting down.
This way, everybody can reuse the same code (WITHOUT FUCKING COPY-PASTING IT).

YES, THATS IT
you understand now what an init should do

it's funny what you call abstract
a language designed to start and loosely control processes is abstract to you
but an INI stile file that describes a node in a FSM like system is completely down to earth, even though it also describes mount's and much more then just processes

and i said 2 times already
"source" shell command imports functions that can be used, avoiding c/p
not to mention that a shell script can parse a config file, removing even that

thus again you went to sysvinit and "scripts are bad therefore systemd is good" position
you don't remember when i said that a dependency resolving init is a good thing (even a process tracker)
and you totally forgot when i said that many inits already do it and some do it better, inits written in C (although it can be perl, python, go or anything really)

but the main thing is that systemd is teh best and sysvinit sucks
not to get personal but are you really so narrow minded ?