Several parts are written as libraries, so you can just rip them out and use them on your own. Almost everything in systemd can be removed at compile time. There is also documentation for removing even those things that doesn't have compile time configure switches (really tiny embedded systems may have special needs):
http://freedesktop.org/wiki/So...

You can't rip out random parts of the systemd package and expect them to work as intended (probably rare to do in any Linux project). That doesn't mean systemd is monolithic, but rather that it is modular, in the same sense that lego bricks are modular; you can't rip out random parts or bricks from a lego project, and effortless combine them with eg. Playmobil, or another brick system that isn't designed to be lego compatible. Systemd have well defined interfaces, just like lego bricks, so you can use the systemd API's, or even make you own tool variants or replacements if you want too.

The same command on systemd is "journalctl -f" . Notice how you don't need to give a path. Notice that in both instances you need a executable (tail vs journalctl) to view the logs.

How about "journalctl _EXE=/usr/sbin/smartd -f" ? Now you are "tailing" the output from a single executable.
Don't worry that the command line seems long: there is tab-comppletion for everything. That is the power of an index log file: every process, daemon, commandline, kernel subsystem etc. that have ever written to the log file are indexed so they are tab'able. The journal have total knowledge of all entries; they can all be traced back to whatever wrote them. Notice the underscore in the field value _EXE, that means that there is kernel guarantee the entry isn't faked.

Spend some hours playing around with journalctl. You will never want to go back to unstructured text log files again.

That is a perfect description of the tools in systemd.

OS containers are a big thing (tm). Because systemd is running as PID1 and have total control and supervision of all processes in the system and can control them with e.g. cgroups, it is possible to have OS containers that runs _unmodified_ from the host system. That is beyond a humongously big thing (tm). No need to "Dockerize" your OS/app.

"Dumb" init systems like Sysvinit, who just throws some processes up in the air and then promptly forgets all about them, are unable to so.

Systemd is seriously the most cool technology that have come to Linux for years. It really saddens me that the joy of hacking new Linux technology seem to have disappeared.

Totally wrong. I mere point to the fact that almost none of the ranting systemd detractors have a clue what they talk about, for the very simple reason they haven't read the systemd documentation (which is quite large), looked at the source code, or even glanced the 'man' pages.

The amount of straight up factual nonsense you hear from systemd detractors is simply staggering, they just repeat memes spouted on some blog by a swivel eyed loony, instead of simply starting to read the systemd documentation:

Like or not, systemd is the future of Linux, the vast majority of all Linux distros will use systemd, so every Linux user should cram up on systemd, the sooner the better.

So is Hammer FS portable to Linux without major reworking? I don't think so. All BSD kernel functionality from init rc, to hardware detection etc. are made only with BSD in mind. Of course they are.

systemd doesn't run on non-Linux systems, simply because those systems doesn't offer the kernel services systemd requires. It is a moot point anyway; no BSD could have a GPL program controlling boot and services, it is simply not their business model, so they would never use it, even if the systemd developer limited its functionality to work on BSD too.

BSD is of course welcome to clone systemd. OpenBSD is already trying to do that to some extent.
And some day BSD will get a modern init system like systemd too. It is only a matter of time.

It is you who are the propaganda victim of what other people rant about systemd, I have actually read some of the systemd documentation and used some of is functions.

I have read Brooks, and unlike you I can distinguish between contributors and lead developers. I think that there are around 12 people with commit access to the systemd tree, working on various aspect of systemd. There are however hundreds of people who have contributed to project by submitting patches to the mailing list. The systemd project is organized pretty much like the Linux kernel in that respect. (Oh, you must just hate the Linux kernel because of all the people contributing patches to it).

That is just crazy talk. Of course booting is central to any OS; it during booting all devices are discovered, configured, and this information relayed to other parts of the OS, and the kernel is told where the rest of the OS is on the disk etc. This is exactly what systemd does, and e.g. because it can be initiated in initramfs, and then jump back to the root FS, it can obtain early boot logging info, and securely control and supervise system processes from the very beginning.

This is a major fallacy among systemd detractors. Your lack of factual knowledge about systemd, and your irrational, emotional hate against systemd makes it impossible for you to conduct a levelheaded analysis of the situation.

All future work on DE's like Gnome, KDE, LXDE, XFCE is based on systemd. Without an alternative to systemd's "logind" there will be no secure rootless X, probably no Wayland, no fully functional desktop on multiuser systems (suspend, powersave etc.).

Systemd detractors are simply ignoring any request from upstream projects about helping them out to support non-systemd distros because of attitudes like yours, which is exactly the reason why upstream projects will eventually stop supporting non-systemd platforms.

And how do you make a distro agnostic GUI to control networking, time and locale setting on non-systemd platforms? The answer is you don't! Piece of cake to do on systemd distros, so this is why upstream projects target it. The systemd detractors offers no help to upstream projects to support their choices however.

That attitude is exactly why systemd detractors have lost the discussion on all major Linux distros; you favor negative campaigning against systemd and named open source developers instead of arguing about technical aspects based on factual knowledge.

"systemd" is a tool and daemon collection. Each of those tools, like "systemctl" or "hostnamectl" or daemons, like "journald" does one thing only, and can therefore easily described with a single line.

some examples:
"localectl" - control the system locale and keyboard layout settings
"hostnamectl" - control the system hostname
"journalctl" - query the systemd journal

So, yes systemd as a project is capable of many things, but it does so in simple, modular way.

Regarding binary logs; they are totally optional. You can just forward everything to rsyslog if that is what you want. The distro maintainers can even make it the default, though it is unlikely on mainstream distros considering how good and convenient the systemd journal is.

grep, tee, sed etc. all work with systemd's binary journal through the well known concept of piping,
in fact the default pager for "journalctl" is good old "less" that just display what journalctl pipes to it. systemd's journal simply enhances the standard Linux text tools.

The systemd logging system is an incredible advance over plain syslog; central collection and display of all log files, including ".xsession-errors" and "utmp" etc. No more hunting around for log files dumped in various places, no need to use "last" to read the binary "wtmp" log files.
The most powerful but easy to use log file filter ever; Want to find all "foo" and "bar" log entries from the second last boot, and display the interleaved result using monotonic timevalues? A simple one-liner with journalctl. There is a consistent straightforward syntax and bash-completion help for everything.

I could go on for pages on how much better systemd's logging facilities are; integrated help database (-X), multi-language support, multi-user support, early boot log info, kernel guarantee that entries aren't faked, integrated consistency check, rate limitation, total knowledge of every single daemon, process or command line that have ever generated a log entry, super powerful log filtering, a consistent API to read the log entries (meaning the daemon can changes its output wording without breaking the log watch scripts)...

Re the KISS principle; This is exactly the principle behind systemd; instead of complex executable config files, you have separation between code and and daemon config files. systemd may be able to do many things, but it does in a simple straightforward way: want to prevent a daemon from forking? a single entry into a text config file, want to limit a daemon to max 50% cpu time? a single entry into a text config file, etc. etc.
systemd makes it simple to use advanced kernel features, using a simple, consistent and coherent framework for doing so. Most of its features are activated by simple keywords in the service configuration (text).

Re obsolete skills;
I do think that the threat of ones skill set rapidly becoming obsolete is a justified reason for change, otherwise you get firmly ejected out of the IT business. All major Linux distros are changing to systemd. In the future you either know systemd well, or you don't work with Linux.

I have seen many people over the decades who got ejected out of IT because they refused to improve their skill sets. They were all very angry at the technology they couldn't or wouldn't master; they would rant endless about how GUI's, OO-programming, tcp/ip, httpd services, java, C++, twisted pair ethernet, etc. was the work of the devil.

In the end, most of them just lost their jobs and couldn't get a new one because they now lacked the skill set needed.

Again, the scope of the systemd project isn't only to be init system; the scope is to provide a coherent base OS layer that controls all processes from boot to shutdown, enabling a stateless zero config boot if needed, including any OS containers booted from the main OS.

You can't have good service management without good logging, and you can't have good logging without an integrated logging systemd like systemd's "journald" that provides early boot logging info; syslog can't receive logging info until fairly late into the boot.

syslog has been outdated for decades; it doesn't provide really structured log files, anybody process writing to syslog can pretend to any other programs (journald gives kernel guarantee that the named services in the log files, are actually those that wrote the log entry), it works badly with multi language logging info, the logfiles are scattered all over the place (with systemd all logs, including utmp and xsession logs are stored in one central logfile). The worst part is, that since the logfiles have no real structure, the actually text output have become an API: change the daemon's output from "failure" to "error", and thousands of log watching scripts will break. systemd's logging facilities are a huge improvement over the old legacy syslog system.

Systemd is all about starting processes and services, including controlling whatever is needed for the system to boot, to ensure those processes are started correctly, at the right time, supervised and logged, and that everything needed is provided in the correct order and as automatically and fast as possible. Basic things like network and ntp control are part of this too. Mind you, you don't have to use the systemd version of sntp, or dhcpd, just use your own sntp or full ntp daemon.

That systemd provides such daemons is simply because, that when launching eg. 5000 OS containers at the same time, then it really matter whether it takes 50 or 5 seconds to get a dhcpd lease. And the systemd daemons are designed to be really lightweight, and really fast.

Again, most work systemd for a long time have been about OS containers; the long time goal is to launch any unmodified Linux OS as an OS container in a secure, sandboxed manner.
There is still a lot of work to be done (with safety), stuff like kdbus and cgroup is part of that effort.

You are obviously demonstrating that you have no personal experience with systemd; systemd is a collection of tools that does one thing a does it well. "hostnamectl" sets and displays hostname information, systemctl stops and starts services, "localectl" control the system locale and keyboard layout settings, etc.

All the systemd tools (*ctl) are just totally normal Linux tools; yes, you can use pipes, direct output, and combine them with all the standard tools like grep, tee, sed...

The systemd tools doesn't break any of those rules you listed.

Sure, some of the systemd daemons (not tools) are specifically designed to talk to each other, in order to have logging info from eg. early boot, or in order to prevent a daemon from forking if the kernel capabilities forbid it, but this behavior is quite common on all unix'es.

Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
This is a good place to start, together with a Linux distro that uses systemd:
http://www.freedesktop.org/wik...

Despite what people claim, systemd is a perfect example of one tool does one job and does it well. Systemd is an umbrella project where a collection of tools are developed in the same place, and with the specific aim of making the tools work together in a modular integrated fashion. There is nothing monolithic about systemd and the way it works.

So "systemctl" controls stopping and starting services, "journalctl" filters log files and displays the output via a pager ("less" is standard, but it is easily changed), "hostnamectl" sets and display hostnames etc.

All the tools can be chained together with standard pipes, so they are just like any other Linux tool, though remarkable well made (tiny and fast) and well documented. bash-completion is also well integrated, so "hostnamectl " will show all possible keywords.

Regarding network engineers disliking ethernet; I heard plenty of that in those days. Remember, ATM was once king in telecom, and Token ring in the LAN world. Believe me, at lot of those network guys really looked down on ethernet in the beginning; they saw it as primitive and that it did everything the wrong way. The "happy-go-lucky" ethernet attitude to network collision grated on their nerves.

I think you are imagining that systemd has a primitive auto restart feature. This isn't the case. It has a very granular and intelligent system of handling restarts, depending of exit code, signal, timeout, or a combination of these.
Look at the man page under "Restart=" here;
http://www.freedesktop.org/sof...

Also look at "StartLimitInterval=, StartLimitBurst=" As their names imply, they can abort restart attempts if the service is restarted too many times in a certain time period.

Furthermore, if you have a really fragile setup where a certain service never must be restarted unless the whole machine reboots, you can let systemd prevent all manual restarts of the service with a single keyword (or make it reboot the system etc).

It is of course the choice of the SA whether any services should be restarted at all. Systemd doesn't force anything.

You can also control coredumps and where to place them in a very granular way.

All in all, systemd allows for some really advanced service maintenance and supervising of services that far surpasses anything else on Linux with its combination of power and coherent ease of use.

First, most Unixen, except OSX and BSD are dying ;-).
Second, these days the new SA's comes from Linux to Solaris etc, not the other way around.
Third, in exchange for a dangerously superficial similarity between Linux and some obscure Unixen, you gain a really strong, shared interface among all major Linux'es. It is an end to needless fragmentation among Linux distros; in the future major core maintenance like service management, logging, controlling network and ntp, and starting OS containers, etc., will all be done the same way on all Linux distros. You start a Fedora OS container with the exact same command line whether it is from a Fedora, OpenSUSE, CentOS, Debian, or Arch Linux.

For the vast majority of Linux users it is of much more interest that systemd harmonizes differences between Linux distros, than it retain a dubious similarity to other Unix variants. And what is exactly left of this similarity these days besides the GNU tools? Solaris uses SMF and OSX uses Launchd, neither is similar to sysvinit at all.

There are more than 500 developers who have contributed to systemd, all major Linux distros have chosen systemd as their new core. There are essentially nobody that works on Linux alternatives to systemd, so apparently the entire Linux developer community is "broken in a highly dangerous fashion" (what drama!).

Anyway, Linux isn't Unix. GNU's Not Unix! (look it up). Unix have been stagnating and dying for the last many decades. The only really successful certified Unix is Apple's OSX, and Appple have basically left the server market.

Linux is Linux, and the community should develop technologies that advances Linux, exactly like *BSD forks develops BSD technology without thinking a moment on how it would work on Linux.

So true. For some reason even knowledgeable people sometimes "fossilize" in their way of thinking. I guess staying in ones comfort zone is comfortable, and it certainly is hard to relearn all the time. Still, constant change (to the better) has been _the_ premise since the first day of computing. Mental fossilization isn't an age thing, it is a mental attitude thing that even young people can get.

I have seen a lot people basically ejecting themselves from the IT industry because they couldn't/wouldn't learn a new way of doing things. As you have experienced too, they would often attack all the new stuff with quite an amount of angry emotion and verbiage.

The angry systemd detractors you find in any such discussion have all the hallmarks of people fossilizing before they eject them self out of the Linux industry. They relentless attack systemd for being "new" with lots of anger, they are usually clueless about how the new technology work, so it is clear that they won't read and learn anything before getting a strong opinion on what systemd is. In short, all the danger signs of mental fossilization.

As it is now, there probably won't be any significant Linux distro in 5 years that doesn't support systemd. In the future, there will only be a tiny legacy niche for non-systemd Linux distros, so by not learning systemd, they are basically saying farewell to work with Linux in a professional way.

sysvinit script files were a simple solution for when the needs were simple. Every other Unix system have dropped sysvinit since, only Linux remained, solely because their wasn't any central core OS linux group, unlike *BSD or Solaris.

Come one, _executable config files_? People would laugh their butts of if Microsoft introduced such a silly concept. systemd is doing the right thing by separating the executable code from the config files.

systemd really is a massive improvement on how things are done in Linux. You should consider actually studying in all seriousness, instead of dpending on what other ignorant people rant about it online.

This is a good starting point;
http://www.freedesktop.org/wik...

The entire commercial and most of the non-commercial Linux industry is converting to systemd at the moment. In the near future, you either know systemd well, or your Linux skills will be in rapidly diminishing demand. Like it or not, systemd is the future of Linux.