Linux development process

A typical linux distribution

Linux distributions aren’t just the Linux kernel. They all contain other critical software, like the Grub bootloader, Bash shell, GNU shell utilities, daemons, X.org graphical server, a desktop environment, and more.

Desktop programs

Not every desktop program is a part of a particular desktop environment. For example, Firefox and Icedove are not tied to a particular desktop environment. You can run any Linux desktop program in any desktop environment, but it can (and most likely will drag in other processes). For example, if you tried to install the Nautilus file manager on KDE, it will attempt to install a variety of GNOME libraries and probably start GNOME desktop processes in the background when you open it. It would work, you can use it, at a performance price.

Threading carefully concepts

Jessie installs systemd by default. This lack of choice is against point 4 of the Debian Social Contract https://www.debian.org/social_contract.en.html. And not only that: http://ewontfix.com/14/:

So how should init be done right?

The Unix way: with simple self-contained programs that do one thing and do it well. First, get everything out of PID 1:

• The systemd way: Take advantage of special properties of pid 1 to the maximum extent possible. This leads to ever-expanding scope creep and exacerbates all of the problems described in http://ewontfix.com/14/ (and probably many more yet to be discovered).
• The right way: Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies (see his script below)

Next, from the init script, run a process supervision system outside of PID 1 to manage daemons as immediate child processes (no backgrounding). As mentioned above are several existing choices here. It's not clear to me that any of them are sufficiently polished or robust to satisfy major distributions at this time. But neither is systemd; its backers are just better at sweeping that under the rug.

What the existing choices do have, though, is better design, mainly in the way of having clean, well-defined scope rather than Katamari Damacy http://en.wikipedia.org/wiki/Katamari_Damacy.

If none of them are ready for prime time, then the folks eager to replace legacy init in their favorite distributions need to step up and either polish one of the existing solutions or write a better implementation based on the same principles. Either of these options would be a lot less work than fixing what's wrong with systemd.

Whatever system is chosen, the most important criterion is that it be transparent to applications. For 30+ years, the choice of init system used has been completely irrelevant to everybody but system integrators and administrators. User applications have had no reason to know or care whether you use sysvinit with runlevels, upstart, my minimal init with a hard-coded rc script or a more elaborate process-supervision system, or even /bin/sh. Ironically, this sort of modularity and interchangibility is what made systemd possible; if we were starting from the kind of monolithic, API-lock-in-oriented product systemd aims to be, swapping out the init system for something new and innovative would not even be an option.

There has been some interest in having a proper free software license on the trivial init code included above. I originally considered it too trivial to even care about copyright or need a license on it, but I don't want this to keep anyone from using or reusing it, so I'm explicitly licensing it under the standard MIT license ~ Rich Felker

Thankies dear.

Init

#define _XOPEN_SOURCE 700
#include <signal.h>
#include <unistd.h>

int main()
{
    sigset_t set;
    int status;

    if (getpid() != 1) return 1;

    sigfillset(&set);
    sigprocmask(SIG_BLOCK, &set, 0);

    if (fork()) for (;;) wait(&status);

    sigprocmask(SIG_UNBLOCK, &set, 0);

    setsid();
    setpgid(0, 0);
    return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}

Yes, that's really all that belongs in PID 1. Then there's no way it can fail at runtime, and no need to upgrade it once it's successfully running.

Initialisation

Kill

Sending SIGTERM to processes

Sending SIGKILL to processes

Mounting real file systems

Mounting local file systems

Unmounting real file systems

Daemons

eudev is a fork of systemd-udev with the goal of obtaining better compatibility with existing software such as OpenRC and Upstart, older kernels, various toolchains and anything else required by users and various distributions.

In specific it tries to avoid glibc-specific functions and gcc-specific constructs by sticking to C99 while tracking closely the systemd-udev developments https://wiki.gentoo.org/wiki/Project:Eudev

Starting uedev daemon

Triggering uedev events

Waiting for uedev events to be processed

Shutting down uedev daemon

Resources

Kernel

• A Guide to the Kernel Development Process http://www.linuxfoundation.org/content/1-guide-kernel-development-process
• The Linux Kernel Archives https://www.kernel.org/
• The kernel guide http://www.linux.org/threads/linux-kernel-reading-guide.5384/

Init systems

• The Epoch Init System: A New Beginning http://universe2.us/epoch.html
• Daemontools: http://cr.yp.to/daemontools.html
• runit - a UNIX init scheme with service supervision http://smarden.org/runit/
• Supervisor: A Process Control System http://supervisord.org/

Related

• Captivating capital and copyfighting
• Installing linux
• Linux applications