I've also read Gentoo is similar in that everything is built from source

Well, Slackware is essentially a binary distribution (sources included), but everything not in Slackware generally has to be compiled, or you have to find a binary that runs on Slackware (this is how I use VirtualBox: Oracle offers an AMD64 binary that just runs on Slackware).

Gentoo has a tiny bootstrap system that is a binary distribution, and then compiles everything from there on, with aggressive compiler optimization for the target machine. Gentoo has a lot of "ebuilds" that are essentially build instructions like slackbuild scripts, but already included with the distribution. Technically, you should be able to build Gentoo even without that bootstrap system on any other Linux.

FreeBSD has a similar concept, somewhere in between Slackware and Gentoo. The basic system comes as binaries + source, and it has "ports" built into the distruibution, again a set of build instructions for 3rd party software. The main difference - except for the obious Linux vs. BSD - is that FreeBSD does not try to micro-optimize for the target machine. Other BSDs have copied the ports idea.

T2 and Linux From Scratch are examples for distributions that are essentially only build instructions for a distribution. You can customize virtually everything, and build your own Linux to match your very special needs - e.g. for embedded systems or high performance computing.

Alexander

Hi Alexander,

Thanks, that's very interesting, and the differences are good to know. I played around with things like busybox a few years back, but have to admit that now that embedded systems like the RPi can run full Linux distros, I've obviously found those easier to develop for. In a message, hippo pointed me to the controversy surrounding systemd, it seems the only two distros that haven't adopted it as the default yet are Slackware and Gentoo. I guess I should start keeping an eye on those and other distros as well.

Regards,
-- Hauke D

It seems the only two distros that haven't adopted it as the default yet are Slackware and Gentoo.

At work, we use a third-party, ARM-based embedded computer featuring a touch screen for one of our products. It runs Yocto Linux, customized by the hardware vendor, further customized by us. It is just a really big pain to change anything in the distributed code. There are literally thousands of different configuration files, all depend on another, include, extend or override each other. The build process starts by building a big database of all that junk, then builds gcc, binutils, bash and friends a few times (LFS and T2 have to do that, too), builds qemu, one or two kernels, and finally builds native binaries inside qemu. And yes, you may have guessed it, a complete compile cycle takes about a day.

I've burned a few days trying to customize really tiny things, like getting rid of audio or bluetooth drivers and applications that won't ever be able run on the hardware we use, because it lacks both audio and bluetooth hardware. Or trying to simply disable a service run from the init scripts. I didn't even try to integrate our own programs. In the end, I just used the vendor-supplied tar file and added, deleted and changed files during the installation from a shell script. Our programs are build using Makefiles, shell and perl scripts, and the vendor's "SDK", a toolchain hacked out of the Yocto build process, with lots of references to directories that only exist on the vendor's build server.

It's not pretty, neither the toolchain nor my hack to get the system running, but it works and runs absolutely stable. And it does not use systemd.

Yocto is not a distribution in the classic sense, its a distribution building kit like T2 or LFS, or buildroot. But it's the most complex one I've ever seen, and I think it takes a few weeks or months to learn how to use it. In https://xkcd.com/1343/, Yocto is about 1 m outside the screen, on the right-hand side.

---

It is still possible to get rid of systemd. Systemd is nothing new, it's just a tons of more or less useful utilities stuffed into one ultra-fat binary nightmare that runs as the most privileged userspace process that absolutely must not die. The idea of starting several services in parallel, with automatic dependency resolving is years older, and has been implemented at least three times. All three times, the init process is reduced to nearly the bare minimum, as the name promises. In all of the three implementations, init just starts a monitoring process. The monitoring process starts one supervisor per service, and the supervisors start the services. System logging, filesystem mounting and almost all other tasks are handled as services.

How?

• djb's daemontools, I've written serveral posts about them. The djb way is the inofficial manual, longer than djb's spec-like documentation. Running svscan as process 1 replaces the classic init with djb's svscan.
• runit follows the spirit of daemontools, can be combined with them, and is explicitly designed to run as process 1 aka init.
• http://www.fefe.de/minit/ is yet another tiny init.
• Busybox contains a lot of clones of those tools, including its own small init.
• need, provide, simpleinit provide automatic dependencies at runtime.

Why init should be small and have as few features as possible, in one four-word sentence: init must not die. If init dies, the kernel will panic. All unsaved data is lost, the machine is down. Paul Jarc has explained init's main jobs in Running svscan as process 1:

• Start up other processes (services, logging) - svscan, svscanboot from daemontools is an ideal candidate to be started by init.
• wait() for children not reaped by other processes. It's really just that. Call wait(), over and over again. Discard the results.
• Handle signals, mainly as interface to the kernel. Well, that's nearly handled by wait(), just set up a few signal handlers before.

Everything else can and should be handled in different processes, started by init or one of the processes started by init. This way, init needs only very little code, and it can (ideally) completely be audited.

Systemd puts inetd, syslog, and tons of other services into process 1. Do you want a system where a malformed network package or a malformed log message kills init (not in the sense of sending a signal, but in the sense of terminating the process)? Well, some people accept that risk for a system that boots in 10 instead of 20 seconds. Imagine that. Half of the boot time, you can reboot your shiny new machine twice as often as with a traditional init.

---

I don't really care about boot times, anything less than five minutes is ok. Servers and firewalls run 24/7, so boot time is absolutely irrelevant. Workstations are started when I enter the office, and shut down several hours later. During system boot, I walk around the office, greet the co-workers, fetch a new bootle of water, find out what needs to be done that day, perhaps try to guess a solution for a bizarre problem at a customer site that may have a hardware or a software cause. That takes from 3 min to hours, depending on what has happened since the last work day. So again, boot time is irrelevant.

What if I really need instant access to a computer? I use an always-on machine, like an X terminal running on my main server, or my smartphone, or I simply use a computer of a co-worker to get a browser or a PDF viewer.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

it seems the only two distros that haven't adopted it as the default yet are Slackware and Gentoo

There is a debian fork called Devuan. The reason for the fork was the decision to use systemd instead of a sane init. (via heise.de)

While searching that, I found http://without-systemd.org/. You may guess what content is hosted there. ;.-)

---

Update:

From there, I followed a link to A history of modern init systems featuring a really compact init implementation in less than 100 lines:

# MIT license.

#include <sys/types.h>
#include <sys/wait.h>

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define LEN(x) (sizeof (x) / sizeof *(x))

static void sigpoweroff(void);
static void sigreap(void);
static void sigreboot(void);
static void spawn(char *const []);

static struct {
    int sig;
    void (*handler)(void);
} sigmap[] = {
    { SIGUSR1, sigpoweroff },
    { SIGCHLD, sigreap     },
    { SIGINT,  sigreboot   },
};

static char *const rcinitcmd[]     = { "/bin/rc.init", NULL };
static char *const rcrebootcmd[]   = { "/bin/rc.shutdown", "reboot", N
+ULL };
static char *const rcpoweroffcmd[] = { "/bin/rc.shutdown", "poweroff",
+ NULL };

static sigset_t set;

int
main(void)
{
    int sig;
    size_t i;

    if (getpid() != 1)
        return 1;
    chdir("/");
    sigfillset(&set);
    sigprocmask(SIG_BLOCK, &set, NULL);
    spawn(rcinitcmd);
    while (1) {
        sigwait(&set, &sig);
        for (i = 0; i < LEN(sigmap); i++) {
            if (sigmap[i].sig == sig) {
                sigmap[i].handler();
                break;
            }
        }
    }
    /* not reachable */
    return 0;
}

static void
sigpoweroff(void)
{
    spawn(rcpoweroffcmd);
}

static void
sigreap(void)
{
    while (waitpid(-1, NULL, WNOHANG) > 0)
        ;
}

static void
sigreboot(void)
{
    spawn(rcrebootcmd);
}

static void
spawn(char *const argv[])
{
    pid_t pid;

    pid = fork();
    if (pid < 0) {
        perror("fork");
    } else if (pid == 0) {
        sigprocmask(SIG_UNBLOCK, &set, NULL);
        setsid();
        execvp(argv[0], argv);
        perror("execvp");
        _exit(1);
    }
}
[download]

I think it looks quite good, there are only two things I'm missing here:

• Sanitising of the output: This init relies on the kernel to provide a sane set of stdin, stdout, stderr. Technically, setting up the standard handles could be done in rc.init and rc.shutdown, but errors this init wants to report via perror() are written to whatever the kernel has set up as handle 2. Compare with busybox init: It calls console_init() and set_sane_term() as first actions.
• Handling for all kernel signals. Keyboard request (usually mapped to Alt+UpArrow) results in a SIGWINCH signal sent to init. Easy to add to the sigmap[] variable, add a new handler that starts yet another program.

rc.shutdown is started by two signals, you have to look at the command line parameters to get the difference. I would have prefered one program per signal. For the reboot and shutdown signals, I could either use two different tiny scripts that would execute the same shutdown script with the two command lines, or I could just symlink one to the other and use argv[0] to decide what to do.

Everything else could be done by other programs, as explained in the second part of Re^14: CPAN failed install.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I want to explicitly note that most of software in The FreeBSD Ports is also available in already compiled form (binary), with default options for the related ports. pkg (https://www.freebsd.org/cgi/man.cgi?query=pkg&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html ; "Tough Beans" if you cannot click the link since the site blocked my effort to give you that) is the command to manage the (to be) installed software.

The software which is not available in binary -- see "lame" -- is due to license restrictions: no binary distribution; explicit user consent; restricted commercial use; etc.