Rethinking PID 1(0pointer.de)
0pointer.de
Rethinking PID 1
http://0pointer.de/blog/projects/systemd.html
5 comments
A good metric for measuring shell script infestation of the boot process is the PID number of the first process you can start after the system is fully booted up. Boot up, log in, open a terminal, and type echo $$. Try that on your Linux system, and then compare the result with MacOS! (Hint, it's something like this: Linux PID 1823; MacOS PID 154, measured on test systems we own.)
I think this is another instance of the transition of efficient serial computations opposed to runtime efficient parallel computations, at least the changes look very similar to the adaptions we did to algorithms in our parallel computation lectures.
Just compare this with pushing a computation through an operation-annotated DAG: A good serial program computes a topological order and annotates each node with the result so far. This is efficient, because each node is considered as little as possible (once for the computation, once for each successor), but requires pre-computations and allows only a single thread to compute things.
The program with the least possible parallel runtime just assigns a computation unit to each and every node and during each parallel step, each unit computes the value if it is possible. This requires syncronization and does unnecessary steps, but overall, this scales pretty good with more units.
I think that is a neat coincidence :)
Just compare this with pushing a computation through an operation-annotated DAG: A good serial program computes a topological order and annotates each node with the result so far. This is efficient, because each node is considered as little as possible (once for the computation, once for each successor), but requires pre-computations and allows only a single thread to compute things.
The program with the least possible parallel runtime just assigns a computation unit to each and every node and during each parallel step, each unit computes the value if it is possible. This requires syncronization and does unnecessary steps, but overall, this scales pretty good with more units.
I think that is a neat coincidence :)
I have to say I feel skeptical about this.
In some situations (servers) we just don't care about how long it takes to do this part of the boot: my SMTP/HTTP/SSH server in the basement has been up 155 days. I think it only goes down when I loose (residential) power.
I'd rather have a correct startup than a fast, subtly incorrect startup. I expect that this would introduce a lot of concurrency-related bugs, and make dinking with startup scripts into something of a Black Art.
In some situations (servers) we just don't care about how long it takes to do this part of the boot: my SMTP/HTTP/SSH server in the basement has been up 155 days. I think it only goes down when I loose (residential) power.
I'd rather have a correct startup than a fast, subtly incorrect startup. I expect that this would introduce a lot of concurrency-related bugs, and make dinking with startup scripts into something of a Black Art.
tldr: What if we could open a bunch of listening sockets and start services in parrallel instead of serializing them the way that sysvinit does? That'd be neat. And faster. Oh yeah, we're doing that.
Really? Downvoted for providing a summary of the (very long) post? I don't see the logic here.