I come from a decade of using Linux and spent a couple of those years building my own variant, attempting to get a system that was capable of building itself up from sources in a bare chroot, and for which the “options” provided by the source code (e.g. the option to support NLS or openSSL, or not) were all exposed to the user and were actually options in the system (i.e. to actually take advantage of having “open source”). In Linux that is a difficult problem. In the Linux ecosystem each “distro” is dependent on almost the totality of itself: you can build new versions of packages only within a running system that has the whole system. The smallest starting point is a pre-existing binary image that contains hundreds or even more than a thousand packages. Even Gentoo now can only be developed by starting with a “Stage 3 tarball” that installs about 500 MB of executables and libraries. In a Linux distro it is difficult to cross-compile the system, and creation of static binaries is not supported. Updating the toolchain can be hazardous. A modern Linux system is like the American electrical grid, the system depends upon _itself_. If it were to “go down” completely no one knows how to bring it back up.

This really came home to me when I tried to develop tools and a process for building a rather standard Linux distro (Archlinux) starting with just a basic toolchain (a libc, binutils, a compiler). It was very difficult because the core of a Linux distro is rife with cyclic dependencies. They don't bother to address those cyclic dependencies as layering violations nor do they develop a build process for working around them. So even though a LInux distro is Just a Pile of Packages and a Kernel, thousands of independently developed packages cobbled together by the “distro”, the user/developer can't treat them as independent. (For example, you can't build and install packages without a package manager but the package manager generally depends on much higher levels than just the toolchain. In Gentoo portage depends on python, amongst other high level things, and in Arch pacman depends on gpgme/gnupg etc.. It's hard to bootstrap such a system. It's hard to make fundamental changes.)

When I threw systemd into the mix the layering violations became much worse (e.g. systemd pulls in dbus, which depends on systemd). Actually I hit a brick wall in trying to build a modern Linux system, with a package manager, starting from the toolchain and c library. Of course it is possible to build a small specialized or even embedded linux system that does build static toolchains and can be built from the ground up, e.g. Sabotage Linux that uses a homebrew package manager that requires only the toolchain, and can build static binaries. Such Linux projects are very marginal, generally die after a short time, and are not where Linux is heading.

After a decade I came back to BSD. As I did a decade ago, I was able to “svn checkout” the latest FreeBSD src and ports and build my complete system from source code with options needed for my goal, only this time with a very nice ZFS mirror filesystem. Here I have the advantage that the system, even if distributed as a complete graphical system by PCBSD folks, is always built from the toolchain up, the build process automatically builds the intermediate cross-tools (in /src/obj) and allows complete freedom to take advantage of the source code, and without layering violations. Here it is a natural result of the process that options in the source code can be given “knobs” so that the optional features are exposed and the “lego” nature of the architecture makes evolution always possible. In other words, it still seems to have the advantage of being Unix and I hope that evolution of FreeBSD will continue to have that building block nature. It seems to me that systemd is NOT a building block; it is intent on being The System, as if it were invented by a corporation whose main source of income were the U.S. Navy and the NSA.

Source: insightfull post from gary on FreeBSD - Forums - systemd is obsolete