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.

It isn't a hard dependency now, but Gnome developers have warned for years, that if people doesn't develop and maintain an alternative to systemd's features, they will have problems supporting non-systemd distros.

The point is that Consolekit is basically bitrotting at the moment. Despite all the online huffing and puffing from people who doesn't like systemd, there simply isn't anybody developing an alternative to systemd's "logind" on Linux. There simply doesn't seem to be an interest from anybody to help upstream projects like Gnome/KDE/LXDE/XFCE support non-systemd Linux distros.

First, systemd's fast boot times were never a goal in itself; systemd is fast to boot because it is optimized to boot the right way. The speed is a secondary effect of this. (no arbitrary wait and checks whether another service is working or not, always boot in a predictable and reliable way in a known order etc).

Second, I don't understand the fetishism with slow boot times. Everything that reduces boot times without sacrificing reliability, is an improvement. Why wait minutes for a smartphone/router/SmartTV, server, laptop to boot, if it can be done in seconds? If you can cut the boot time of a server/OS container with 60 seconds, then you will gain +83 hours uptime when booting 5000 servers.

Time is money, efficiency is king. A booting system consumes resources but doesn't generate money while doing so.

Systemd is IMHO the best happing to Linux the +15 years I have been using it as my prime OS.

1. For the first time ever is there a coherent development of core Linux OS features. Take fx. "rootless X". It has been possible on Linux for a long time, but only by opening up massive security holes on multi-user systems. The solutions required cooperation between several kernel subsystem developers, X developers, and userland/systemd developers (session managing) to succeed. So secure rootless X is now possible on systemd Linux distros, simply because the systemd project could function as a developer nexus to coordinate and develop the needed features.

2. Since the entire commercial Linux segment and most other distros are becoming systemd driven, there now is a base compatibility layer on Linux for doing basic things like controlling networking, ntp, getting system information etc. Almost all new Desktop Environment development (KDE/GNOME/LXDE/XFCE) at the moment is based on systemd, simply because systemd offers powerful cross distro features that DE's can take advantage off.

3. It is now staggering easy for both distro maintainers, developers and end users to take advantage of advanced kernel features like CGROUP and Linux Capabilities. A simple edit in a standardized text config file can enable strong security features that prevent e.g., privilege escalation. The Linux kernel is full of advanced features that few take advantage of, simply because it often is hard to do with no basic framework outside the kernel to help the user. With systemd, it is now possible to expose many of these kernel features in an easy and consistent way.

4. systemd have actual end-to-end service supervision; systemd supervises all processes, and its watchdog can be made to supervise systemd itself, conditionally restarting it if it should hang.

5. Regarding "what people know"
Anybody being in the IT business for a decade or more have experienced how well known ways of doing things have disappeared. I knew how to optimize the DOS config.sys in order to have maximum available memory. Useful then, useless now. Overall a great improvement.

The reason why Linux is changing in the systemd direction, is simply because the way we do computing is changing; gone are the days with the OS running directly on metal with a few selected services, and the entire thing glued together with hand crafted scripts that were difficult for outsiders to understand.

These days it is all about virtualisation, OS containers, massive OS /node deployment with automatic processes, automatic zero config deployment, These days the SA's doesn't monitor a dozen processes on single server, but 10.000 or perhaps 100.000 processes on thousands of OS containers/servers etc.

systemd is simply brilliant at all this, and sysvinit is not.

Many reactionary retro grouches hates systemd because they now are forced to learn new stuff.

But this really is a wake up call for people; either they start learning systemd, or their Linux skills will not be in much demand in the future.

Re 1: Developers uncooperative?
Looking at the mailing list this doesn't appear to be the case. +500 developers have contributed to systemd, that points to excellent leadership where even small contributions are welcomed.

Re 2: Emacs syndrome.
It is popular but totally wrong meme that systemd just pile on features. Its scope have been quite narrow for years. Yes, it have gained new features, but almost all new systemd features are related to the original scope of stateless booting and light weight containers.
So people who hasn't bothered following systemd gets totally surprised when a new version of systemd has new features, but that is just because they don't really know systemd.

Re 5: Total disregard for everything outside of Linux,
All daemons made when sysvinit was king will work with systemd. It is backward compatible, even with sysvinit scripts (there are some few documented corner cases)

So daemon authors don't have to change a single line of code if they don't want to. The distribution managers can just add a service file instead of the sysvinit script. (probably remove some bugs that way too)

No other certified UNIX uses sysvinit scripts, they all have init systems more less like systemd. Does that mean they have a total disregard for anything e.g. not Solaris? (SMF).

I find the idea that all progress on Linux should be stopped if there is a danger that it progressed faster than other Unix'es (read BSD) a rather silly idea. Especially because those other Unix'es generally hate and despise Linux because it is a successful competitor.

systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.

I just discovered that my link was already included in the TFS. Oh, well...

There is a somewhat detailed review of Plasma 5 here:
http://www.themukt.com/2014/07...

The released videos seems very impressive.

I really love KDE. I sometimes work on Mac OSX or MS Windows 7, and I must say KDE beats every other environment I have tried when it comes to flexible workflow and productivity.

Whenever I work on other peoples computers, their personal files are always in a mess with their "Document" and "Download" folders loaded with hundreds of various files. I think this is simply because 1 panel file organizers like "Finder" or "Explorer" are really inefficient and hard to use for organizing and moving files. So I long for a twin panel file manager like Krusader, every time I work on other peoples machines.

The way KDE functions are integrated is also a joy: right click on files for useful things as packing and unpacking, or attaching the files to an email etc. A really smart GUI for mass file renaming (in Krusader by krename) is incredible useful too.

Looking forward to Plasma 5, probably included in Fedora 21.