Boycott Systemd

Finally people are beginning to wake up and understand that systemd and Lennart Poettering, who works for Red Hat, is a cancer that will destroy and splinter the Linux ecosystem. According to a new movement, It represents a monumental increase in complexity, an abhorrent and violent slap in the face to the Unix philosophy, and its inherent domineering and viral nature turns it into something akin to a “second kernel” that is spreading all across the Linux ecosystem. I could not agree more. systemd flies in the face of the Unix philosophy: “do one thing and do it well,”

Systemd the Operating System?

It appears that Lennard Poettering is a student of Adolf Hitler plan to invade the Sudetenland. Just let me do this and all will be well! Systemd was sold to the adoring masses on the basis that it would significantly speed up system startup and shutdown. That was a complete lie from the start. Systemd has not significantly improved system startup or shutdown times. Instead it has seriously complicated things for ordinary system administrators and integrators. Instead of a small number of initialization scripts, there are hundreds of configuration files and executables. Since then, systemd has spread like a cancer

Systemd: The Cancer That Could Kill Linux As We Know It

Originally systemd was positioned by Lennart Poettering as a drop-in replacement for the System V init subsystem with the goal of speeding up system startup by parallelizing service startup where possible. An admirable objective! However, the scope of systemd has slowly increased to encompass the Linux kernel, system logging and lots more. This is craziness. It is now serious blotware with numerous binaries. Like a cancer, systemd is now spreading to more and more Linux subsystems. Worse, we now have apologists for systemd claiming that the old SysV init shell scripts were too complex to understand (actually they were easy

Systemd and /etc/fstab

Once again Lennart Poettering and Kay Sievers have managed to complicate things and broken the simple model that served the Unix and Linux communities well for over 30 years, i.e. that details of filesystem mounts that should persist across a reboot are listed in /etc/(v)fstab. With systemd, mount units may either be configured via unit files, or via /etc/fstab. Mounts listed in /etc/fstab are converted into native units dynamically using systemd-fstab-generator at boot time or when the system manager configuration is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach. A systemd unit configuration file whose name

Mask V Disable a Systemd Service Unit

In the systemd world, you should be aware of the difference between disabling and masking a service unit. To prevent a service unit that corresponds to a system service from being automatically started at boot time: # systemctl disable name.service When invoked systemd reads the [Install] section of the selected service unit and removes the appropriate symbolic link. In RHEL7, for example, the symbolic link would be to the /usr/lib/systemd/system/name.service file from the /usr/lib/systemd/system/ directory. Every service unit that is known to systemd may be started if it is needed – even if it is disabled. To explicitly tell systemd