> Back to the keyboard, I just discovered, that every (GUI) program I
> run, is spawned from PID 1. Honestly, I would have expected those to be
> child processes of e.g. the display manager or the session manager...

That isn't how it starts off, chances are that when you run a program
it is spawned (well, forked, err, cloned) by a process that you
own (so *not* pid 1).

Important is to know that unix requires *almost every* process to have
a parent process. You can get this information with getppid (man getppid), and
ps will show it to you. One of the reasons for this is to report
the exit code to somebody (man wait ; less /usr/include/sysexits.h) to
somebody. A process which hasn't had its exit code collected will hang
around in a zombie state (Z in the ps listing) - zombie because it is
dead, but still occupies a process table entry, which is a finite resource.

So: What happens if a parent process goes away ? Well, the kernel
reparents the children so that they are now direct children of
pid 1, aka init.

And that is what thing that makes pid 1 special[1]. It can't
crash/exit/hang because then you'd run out of process table entries
which means the whole system hangs. Actually linux will move that forward,
and have the kernel panic on init exiting - where would it's status code
go, anyway ?

So pid 1 - init's main job is to wait for all processes which have lost
their parent. Init adopts orphan processes.

And if you know that you are almost ready to write your own init. It
also happens to be why this mailing list exists: init processes
can't crash and so should be simple.

regards

marc

[1] There is some fine print - modern linux allows you to delegate
this function to other processes, but just because you can does not
mean you should.