First, KDE like all other main DE's are officially committed to supporting non-systemd distros and BSD. The only ones believing otherwise are alarmist systemd-detractors.

Second, the KDE component mentioned in the rather whining blog, isn't a central component, but just a login/display manager. There are other options to use.

Third, the reason why SDDM hasn't got CK support is quite understandable; KDE doesn't have big corporate sponsors, they are volunteers and are stretched to the limit regarding developers. Investing costly developer resources in using a dead and deprecated module like CK is simply insane.

But here is what KDE/Gnome developers and many others have said for years: it is up to the non-systemd distros to support upstream projects, just like the systemd distros does. Don't like systemd software, fine, but develop your own software stack so that upstream projects work on your distro.

Yes it will suck for small non-systemd distros that they just can't leech software development from the big commercial distros anymore. But the answer to that isn't trolling every systemd thread about how bad systemd allegedly is (not so credible to hear from non-users you know), but to get organized! Why is it that you only hear from systemd-dislikers in systemd threads? Why don't you create your own _positive_ community that is about creating cross distro non-systemd software? Why no "New SysVinit alliance created" threads?

The small non-systemd distros will have to cooperate for the first time in Linux history; if they play "every distro for itself", they will sink.

No, things won't be easy for the non-systemd distros. Some of the development needed in order to have even some feature parity with systemd isn't trivial either (cgroups etc). But there is a freedom of choice, the point is that the non-systemd distros and their users are solely responsible for creating such choices.

It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.

It is almost tragic so badly the non-systemd users like you are analyzing the situation. I really like systemd, but have no problems with people not using it, and in fact wished that systemd had even a tiny bit of competition.

If the non-systemd crowd don't understand that systemd actually both work, is good, and have compelling features, you will never be able to make an alternative to it. You won't even be able to have status quo. Know your enemy and all that.

systemd had hundreds of contributors before it was used in any long term stable Linux distro like RHEL7. So many developers started to drool when they saw the systemd feature list; it presented much of what many people have longed for in a Linux init system. So yes, systemd was quick to gather a community and is now probably one of the largest Open Source projects when it comes to developers.

systemd is simply superior to SysVinit in every way which is why all the major distros adopted so quickly. It simply solve a lot of real world problems and makes life easier for both upstream developers, distro makers and end users.

For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional.
So nobody is forced to use systemd if they don't want to.

That there can only be one cgroup manager at the time is caused by the cgroups developers decision to make a unified hierarchy tree with only one canonical manager instead of exposing cgroups fs directly to end users. systemd is just an example of such a manager. If you don't use systemd, you can just use another cgroups manager instead.

Regarding SLURM, they are of course starting to integrate systemd in their project. I assume most other cgroups projects are doing the same.

That LWN article is 3 years old and very outdated. The systemd developers was still developing the journald in those days, so they didn't want to freeze the API etc. it until they thought it was ready.

The journald log file format have been stable for a very long time now. Here is the developer info and documentation:
http://www.freedesktop.org/wik...

There are already independent journald readers and several log watch programs that query the journald directly.
Most tellingly; rsyslog can now read systemd journals directly. No need to forward syslog messages to it anymore if you use it as a log sink. It can read and write journald log files directly.

Here is a list over stable API's in systemd:
http://www.freedesktop.org/wik...

They are not "options", but field names in the systemd journal.
So journalctl is querying the "database" directly for the values in the "_KERNEL_SUBSYSTEM" field that again contains fields like usb, pci, etc., that again have log entries.

"journalctl -F (tab)" will show you all possible main field names. Selecting eg. "journalctl -F _KERNEL_SUBSYSTEM (tab)" will show the the possible values:
sound
hid
pci_bus
acpi
watchdog
usb
pci
pnp
scsi
vc
clockevents
(snip)

You can basically "tab" your way to every log entry since they are indexed, and every log entry can be selected and shown by exactly which part of the system that generated them. It is an incredible powerful feature. It also allow you to generate on-thefly log entry lists of every PID/GID/Hostname/executable/service name/etc. that have ever written to the log file. Just press tab and all the values appear instantly.

The field names starting with _underscores have Kernel guarantee of not being faked.

Of course you can have text only log files. Just tell journald not to make any journal files, and forward log messages to rsyslog. It is trivial to do.

Btw, did you know that rsyslog was started because of the inherent limitations of flat text files. These limitations is why all Unix/Linux Enteprise central logging solutions involve some kind of database (Splunk, rsyslog with db-driver modules etc).

Really, systemd's logging solution is seriously cool. It is worth a serious try out.

You got it all backwards; systemd provides outstanding early boot support, including VT's, especially because it starts from initramfs even before the root-filesystem is mounted.

The systemd journal is an open standard with a stable API and many language bindings, so there already exist alternative readers.
There are no realistic scenarios where a systemd log file can't be read. They can be copied just like files to another machine one way or another, or the machine can be booted with a rescue disc

The systemctl syntax is extremely easy to both use and understand. Yes, you will have to read a man page before using it, but then again, the only intuitive interface is the nipple, everything else is learned. It is trivial in comparison to learning regex, but much more efficient.

I see you find "--boot" and "short-monotonic" cryptic. That is probably because they are features that doesn't exist in traditional flat file log files (and more or less impossible to implement). But with systemd, every boot is marked in the journal with an unique ID, so it is trivial to select certain boot sequences. Really hard to do reliable with a regex.
Monotonic timestamps is a meta-data time stamp in every log entry. The monotonic time counter starts from zero at every boot, so that every hardware, kernel and service initialization can be followed with an easy time delta. Here is a short monotonic log snippet; notice how time is incrementing.

[ 1.586450] lhost kernel: hidraw: raw HID events driver (C) Jiri Kosina
[ 1.586648] lhost kernel: usbcore: registered new interface driver usbhid
[ 1.586747] lhost kernel: usbhid: USB HID core driver
[ 1.586867] lhost kernel: drop_monitor: Initializing network drop monitor service
[ 1.587025] lhost kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
[ 1.587148] lhost kernel: TCP: cubic registered
[ 1.587253] lhost kernel: Initializing XFRM netlink socket
[ 1.587456] lhost kernel: NET: Registered protocol family 10
[ 1.587714] lhost kernel: mip6: Mobile IPv6
[ 1.587807] lhost kernel: NET: Registered protocol family 17
[ 1.588196] lhost kernel: Loading compiled-in X.509 certificates

You can still use "grep" and all the other standard Linux tools in conjunction with "systemctl". "systemctl" just act as a powerful log filter so often grep isn't needed.

I like your example for grep'ping for the word "error". That way you would miss both "Error" (no "i" switch") and "Warning" "Critical" "Failure" and what not. For systemd you could just use "systemctl -p err" and you would have found all critical log entries.

Service vs. daemon=bike shedding

You may imagine that systemd is a "toy", it doesn't make it so. It is developed by top notch developers from many distros, including leading kernel developers like Greg KH. In fact, since all major Linux commercial distros are converting to systemd, it is _the_ init system to know for the future professional Linux admin.

Red Hat have always been a corner stone of Linux. If it wasn't for Red Hat, Linux wouldn't exist today. They have fueled money and developer time into almost all aspects of Linux over the decades, and their lawyers have fought off so many patent trolls and entities trying to harm Linux. AFAIK, Red Hat have been one of the biggest kernel contributors for decades too, so they have had a huge influence on both its design and features.

So I think the "let's hate Red Hat" fad among systemd haters is puerile, stupid and anti-Linux.

And I think even less about the tin foil hat conspiracy theories about mysterious Red Hat forces, working behind the scenes hell bent on taking over Linux.

The accusation of Red Hat's intention of "hostile takeover of Linux" is always vague. How exactly are RH controlling Linux by being a contributor among many when developing systemd? Is there some kind of mind control in the source code, or is it done by chem trails?
Why is RH Kernel and glibc contributions not a problem, while their systemd contributions are?

All the major distros have changed to systemd simply because it is superior in every way to the existing alternatives. systemd simply solves real world problems for both distro makers, upstream developers and end users in a much better way than anything else.

What a rose tinted look at the past. I was there too, but I don't remember the way you do at all.
The main reason why Linux took of was that it solved real world problems in an efficient way.
So many OS's have been made in order to follow some dogmatic doctrine about microkernels/"everything is a file" etc., instead of focusing on how to solve problems for its users, but not Linux.

So Linux made things possible for admins, developers and ISP's that was otherwise difficult or expensive. In short, Linux made money and increased productivity. That is also why its users fueled developer hours and money back into the Linux community. The LAMP stack wasn't made by a lone hero hacker, but a collective of business' and developers that saw an opportunity for making money or increase efficiency and getting a competitive edge.

The LAMP stack was never designed by the cartoonish Unix design interpretation of "only do one thing", in fact almost no program of any complexity is, yet this was what was driving Linux forward.

systemd is just yet another change in Linux that follows the old Linux philosophy on focusing on solving real world problems for its users instead of riding a "Unix/Posix" hobby horse.

If you are beginning to have problems with how Linux have always evolved, then it is you who are beginning to act old, not Linux.

Keeping Linux in an eternal 1990's time freeze where nothing must be changed will simply kill of Linux just like all the other OS's that forgot both their users and how to adapt to the times.

Yes, for file systems. Notice this is for a single running daemon. Think of it like a kind of sand boxing that prevents the service and all processes it spawns to e.g. read/write /boot /home /root etc.

Since it is build on "capabilities", those directories will be inaccessible even if the process is exploited. It is seriously cool stuff that systemd makes it easy to use.

systemd makes it easy for both end users, upstream developers and distro makers to take advantage of those advanced kernel features; no low level hacking needed, no home made bash scripts, no endless hacking needed to make three dissimilar sub-systems talk together by fragile scripts.

With systemd strong hardening features comes ready to use out of the box. Just add a simple "keyword=value" in a text config files, and everything works.

The reason why kernel features like "capabilities" and "cgroups" have existed with very little or no use on general purpose distros, is exactly because they are very hard to use on systems that aren't designed like systemd.
It is the same with the new Kernel IPC system "kdbus". Systemd will make it easy for upstream projects to use kernel IPC, while SysVinit and similar won't.

You don't have any knowledge about how systemd restarts services. You haven't read the systemd documentation, but instead seem to rely on some random systemd haters wrong info about how systemd restarts services. Think about that.

systemd doesn't restart services unless told so. And it can be quite intelligent about restarts, distinguishing between several different ways the service was terminated and making conditionally restarts depending on the service's exit signal and combining it with rate limiters.

Try reading the "Restart=" section here to get a glimpse of the many options:
http://www.freedesktop.org/sof...

But it will be. The "systemBSD" and "Uselessd" projects are just a warm up.
Of course all the BSD's will get modern init systems like systemd before this decade is over.

I like the fact that systemd's wholesale acceptance by all major Linux distros means much less fragmentation in both the way the Linux OS is managed and the easy that upstream projects are now able to support advanced features in a distro agnostic way.

I also like the fact that it exposes advanced kernel features like "cgroups" and "Capabilities" and make them easy to use; just add a keyword in a text config file and restart the service.

Add ProtectSystem=full in a service config file, and the service and all processes it makes can only "read" /usr and /etc enforced by capabilities. So even if the service is compromised, the hacker can't modify these directories, even if the hacker are able to execute code with root privileges.
http://www.freedesktop.org/sof...

Also "ProtectHome=" makes the service unable to read /home, so that no information stealing can take place.

Perhaps the best thing about these features and the many other systemd features like those, are that they can be enabled by either upstream or the distro makers, so that the end user doesn't have to anything in order to improve the system security. It will simply mean improved security and "defense-in-depth" as deafault on systemd distros.

systemd's logging system is a huge improvement over old legacy style text logs. It has more early boot logs since it can log while still in initramsfs, and with kdbus it will probably get even earlier and late logging; the goal is "metal-to-metal" logging.

Having structured and indexed logfile (called journal) is a huge improvement in many ways; it allows for rich meta-data like monotonic timestamps, high precision time stamps, UUID's, exe file names and paths, and incredible easy and powerful sorting and filtering with tools like "systemctl".

If you try to add meta-data like monotonic timestamps in flat text files, they become very long and cluttered, making them hard to read for humans.

Another problem with flat text files are the fact that watch scripts depends on the exact wording of the daemon output strings; if the developers changes the wording, third party scripts will fail. In a perverted sense, the exact wording have become a API that cannot easily be changed or extended.
Not so with systemd; it has a stable API and lots of language bindings. It is easy to make a watch script that targets the stable field's.

Some CLI examples: I have used full length options for readability and since systemd have excellent bash completion for everything, it doesn't involve much more typing.

journalctl --boot -1 --priority err

Show all log entries from previous boot only, that have log level "error".

journalctl --since -5m

Show log entries generated the last 5 minutes.

journalctl --follow --unit smartd.service

Follow (tail) the smartd daemons log output.

journalctl _KERNEL_SUBSYSTEM=usb --priority warning

Show only messages generated by the kernel USB subsystem that have log level "warning"

journalctl --field _PID

The "--field" option makes systemctl show all values of the following journal field. In this case it will show a list of all PID's that have ever written to the journal. Want to see every executable that have ever generated log output, substitute _PID with _EXE. Notice the underscore. Field values with underscores have kernel guarantee for being correct.

It is also easy to track two services that you suspect are causing each other problems:

journalctl --output short-monotonic --boot -u NetworkManager.service -u chronyd.service

This will show the log entries for NetworkManager and a sNTP client from the current boot, and show the output with monotonic timestamps. Nice.