No it doesn't. If you need text files logs for some legacy reason, just direct all logging output from journald to syslogd. It enhances the logging info while keeping standard syslog text logs. It is a simple one liner in the systemd config file to enable that behavior.

Furthermore, the journal viewer, "journalctl" can easily be combined with any standard unix tool like grep; that way you can have all the advantages of having an indexed logfile while using standard GNU text utilities.

In fact, the standard pager for viewing log files is good old "less". You can easily disable the pager, or use another one of you like.

All the systemd tools are just normal Linux tools, just better implemented than average. So all the text utils and find utils etc. works absolutely fine with systemd tools. I really don't know where you got that idea that this wasn't the case.

Sure, you can't grep the structured journal directly, but that is what piping was invented for. "journalctl -b1 -p err | grep -i rpcbind" shows all instances of "rpcbind" in the previous boot log only, and only at error level "critical".
It is that easy.

Oh, and the structured journal is well documented with a interface stability promise, and many language bindings to read and write into it. Even rsyslog can read systemd journal files directly.
Here is how it is designed:
http://www.freedesktop.org/wik...

I don't think there are any aspect where shell scripting can't be used together systemd and its tools. In fact, systemd enhances the admins ability to gain secure knowledge about the system and executing programs depending on the state of the system.

No offense meant, but systemd opponents are usually badly informed about even basic points about systemd. They seem to get their opinions about systemd, not from the systemd documentation, but from other users on the net, and quite frankly, some of those users are just spewing random lies and made up stories about systemd because they are blinded by their hatred.

Do yourself a favor, and don't rely in random anonymous systemd haters for your information, but get it from the source instead.
http://www.freedesktop.org/wik...

It is worth getting a proper knowledge about systemd since this is the future of Linux, especially if one intends to poke around and make custom stuff.

"Need" is an elastic term. Sure, sysvinit worked on Linux servers for many years despite its many shortcomings, but it was always a very resource intensive endeavor to make it work and support it (think; all distros have different init scripts for each service and everybody of them hard to debug and prone to bugs). All the missing functionality of sysvinit had to be made up with complex scripting at each and every service.

But the old sysvinit model relied heavily on a certain way of doing computing, basically running servers directly on the metal with a few selected services and often with lots of "scripting" glue hand crafted for each server. They where individual servers, maintained by admins that needed a rather thorough knowledge about how a particular server worked.
But that model have changed considerably over the years and that is the main reason why old style script based systems no longer is working as well as it used to do.

Massive and rapid deployment of servers, virtualization, OS-containers, instantiated services etc. are becoming important. OS's needs to be automatically configured, or mass configured by machines. It is all about speed and hardware density in order to stay competetive. Take for example a hosting provider that has 10.000 Linux instances hosted. It used to be that they would have to run 10.000 instances of sshd or similar, even though only 1000 users where active at the time. With systemd they only need to run exactly the amount of services as there are current users, since services can be "on-demand socket activated". (no, it isn't like inetd, read here: http://0pointer.de/blog/projec... )

In short, the provider can pack more users into each hardware unit, that saves money.

systemd also makes it possible to upgrade a service and restarting it without breaking any end user connections (it buffers the client requests).

There are many systemd enhancements for servers because it isn't just simple init systems. I think that in order to stay relevant, BSD will have to start cloning a considerable amount of systemd features. It will be different on BSD because they don't suffer the same fragmentation chaos as Linux, but the main points of systemd, like (k)dbus service communication, intelligent PID1 that utilizes kernel features like security modules making them available to services without reprogramming, a total service and process superviser chain, early "metal-to-metal" logging etc. will be cloned by BSD. It is only a matter of time.

I don't think it is similar to the GUI formerly known as Metro. As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.
Also, systemd enhances both tiny embedded systems, servers and desktop systems. It doesn't have any weak points in that regard.

You shouldn't worry about "read/modify/log.." when it comes to systemd. It enhances early boot logging considerably since it is active from initramfs. All the config files are well documented text files with declarative statements that are easy to parse for both humans and programs. Systemd has a lot of really nice helper programs like "systemd-delta" that instantly tells which of the hundreds of service config files (unit files) that have been changed, and it is also smart enough to see whether it is a functional change, or just an added comment.

It is however a new way running and maintaining Linux. You can't avoid reading up on the subject if you want to modify or understand things. What many discussions on systemd makes clear is that many people are quite ignorant of its features and its design. They simply haven't studied it.

If you want to admin Linux in the future, it is simply mandatory to read up on systemd. The official systemd site isn't a bad place to start.
http://www.freedesktop.org/wik...

First of all, let me say that "Unix model" and all similar references to Unix philosophy etc, are totally content free platitudes in my opinion. There is no canonical "Unix" book where a Unix-pope have decreed ex catedra what "Unix" is. Heck, Unix was even born without support for "piping" between programs. The "Unix model" end up as 1990's time freeze because that keeps some old sysadmins happy that they don't need to learn anything new.

So it is easy to argue that systemd actually follows the "Unix model" in every way, and is modular, even in the "admin" sense of the word as you describe it.

Systemd is an umbrella project with many small programs collected in one utility box, just like "busybox" or "kernel-utils". It consist of many small binaries, like "systemctl" "localed" "timedated" etc. All these binaries behaves exactly like any other Linux/Unix binary tools; they tend to do one thing only (and do it very well), and can easily be combined with any other standard GNU tools like grep, sed, tee, ed, less and so on, by utilizing piping (eg. "systemctl | grep -i foobar") . They are in fact indistinguishable from any other Unix tool in the way they behave.

You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options. There is even an official page about how to reduce systemd even further http://freedesktop.org/wiki/So...
One of the key drivers behind systemd is the embedded market, and they want minimal systems. On desktop and servers, it doesn't make much sense removing systemd options, since they are basically zero-overhead and provides options that nobody else does.

And yes, systemd works fine with together syslogd, in fact it enhances it considerably because systemd is able to get early and late boot log info since it is active from early boot in initramfs.

What you can't do is ripping random elements out of the systemd toolkit and expect it to work unmodified together with any other random system.

One reason why systemd simply routs any opposition is, that when people actually study it, they find that is has awesome new features and solve so many of the sysvinit shortcomings. From terminating services correctly http://0pointer.de/blog/projec...
to actually tracking and supervising all running processes http://0pointer.de/blog/projec...

And because of its design, it also offer superior security features, because as PID1 it can hook into advanced kernel features like "kernel capabilities" http://man7.org/linux/man-page... and "cgroup", and soon, also kdbus. Systemd works as a Linux plumbing layer, making all these features available for end users and distro maintainers, and making them easy to use by just adding simple keywords into a text config file.

Systemd is also a cross distro comparability layer; that means upstream projects can develop against systemd, and be sure it works across many different distros. It is easy to develop DE developers to make a GUI for setting networks or NTP/time or keyboard layout etc, on a systemd OS. On non-systemd distros, everything is scattered and fragmented, making it impossible to do.

The end result is, that all new development will be done with systemd. And because people like you think that nothing needs to be changed, the non-system distros will remain utterly fragmented and unsupported from upstream projects.

The bottom line is, that if people want to use non-systemd distros in the future, they better start getting off their couches and start develop an alternative. Not only do they need to maintain sysvinit infrastructure now that the "big boys" like Red Hat and Debian and Suse and Ubuntu are converting to systemd and therefore drops sysvinit/upstart development, but also extend the present infrastructure to deal with eg. safely using rootless X. They also ought to organize to help upstream projects like KDE and Gnome, by making a similar compatibility layer that work across the few remaining non-systemd distros.

Because it can't be done safely in any other way. This is why certified Unix'es like Solaris and Mac OSX have dropped old style init scripts; sysvinit and its brethren doesn't belong in the modern world. They are outdated and unsafe.

That situation is easily handled by systemd since it has total knowledge and supervision of all running processes and services, and has extensive capabilities for various ways of restarting crashed services. This included ways to limit restarts, so as if a services crashes more than eg. two times within eg. 10 minutes it wont restart that service again (or reboot the entire system, or many other actions). This is controlled by simple keywords added to the config files like "StartLimitInterval=, StartLimitBurst="

You can even make systemd clean up core dumps after a failure if that is what you want.

Here is a overview of the many fine grained service control mechanisms that systemd supports;
http://www.freedesktop.org/sof...

The problem is, that on a multi user system, something have to track user sessions, or else suspend, sleep and shutdown (and many more things) doesn't know when it is safe to operate. On Linux this used to be done by ConsoleKit, ("logind" is the systemd solution), but CK have been abandoned for almost 2 years now. It is bit-rotting and starting to break, and upstreams projects like KDE and Gnome are finding it increasingly hard to support.

So in order to run a multi-user or multi-seat Linux system in a way people expect, you have to use systemd.

There is also root-less X.org. It can't be done safely on Linux without systemd's "logind" because of eg. raw input devices needs to be tracked by a session manager. ConsoleKit could probably be extended to do the same, but nobody seems to try.

At the moment it also look like that Wayland Desktop Environments will be a systemd thing only. Eg. KDE KF 5 will support non-systemd systems running X.org, but only systemd systems with Wayland. Again, they don't do it because they are remote controlled by Poettering, but because all new development outside KDE is happening around systemd. There are no alternative developers actively supporting other solutions than systemd, so KDE simply have no other choice.

There are many more problems for non-systemd systems that will crop up, once all the major Linux distros and their developers shift their focus to systemd.

I have no problem with people preferring other init systems than systemd, in fact, some competition to systemd would be nice. But in order for people using eg. sysvinit in the future, they better start making a clear, technical analysis of what maintenance problems they have to deal with, and start working on them.

As it is now, even distros like Slackware that isn't so hot on systemd, will probably become systemd distros, simply because they have no real alternative, and are too small to pick up all the maintenance burden themselves.

At the moment, http://www.freedesktop.org/wik... is the best site for systemd information. It could have a better organization, but there is an awful lot of information about systemd, even the nitty gritty details needed for developers.

You are absolutely right, that advanced kernel features like "capabilities" and "cgroup" are hard to use for developers. That is the exact reason for why "systemd" was made as a "Linux plumbing layer" that makes advanced and powerful new kernel features easy to use for everybody.

With systemd, it is a one liner in a text config file to turn on really powerful service sand-boxing features like preventing the service, even if exploited, to gain new privileges.

Or use the "ReadOnlySystem=" to make "/boot" and "/usr" read-only for the service; even if the service is exploited to run code with root-privileges, the /boot and /usr directories will be read-only for that root executable (and all other instances/processes that stems from that).

This is great stuff; even the distro maintainers can turn on powerful "Kernel capabilities" as default. There is no need to patch code, or ask the service developers to understand anything about it, or develop against it.

Same with "cgroup". It is a one-liner to enable powerful system usage limits, or giving a certain service net/cpu/IO priority.

"Capabilities" are meant to be used together with a MAC like SElinux, and normal ACL's, but thanks to systemd, it is extremely easy to use. No need for compiling custom kernels, hand crafting scripts that are distro specific, or similar barriers; just adding simple keywords to a text config file, and systemd will take care of all the behind the scene magic.

Attacking Lennart Poettering is a bit like pouring water on a duck. I think the ability to consider the opinions and experience of others is completely missing. Input is only accepted if it's praise or furthering the direction he's already staked out (and even then he's thrown ego tantrums).

Around 500 different developers have contributed to the systemd project. It just shows that the project have excellent leadership with Lennart Poettering since he can attract so many developers across so many different distros. It also shows that their are open to new ideas and code from outsiders.

So maybe your assessment of Lennart Poettering is wrong and based on the countless made up stories about the man circulated by the systemd detractors.

The point that gets across to Red Hat is our money. Money that can go elsewhere.

And Suse, and Debian, and Ubunty, and CentOS, and Arch Linux etc. etc. All major Linux distros are going to use systemd as their default init system and the vast majority of the smaller distros will follow suit too.

Systemd have won over all major distros because of its superior advantages, and because any opposition to it seems to consist of people in denial, claiming that sysvinit is perfect and should be used for the next 40 years so they don't have to learn anything new. With that attitude it isn't a wonder why no-one seems to develop any alternatives to systemd, or even maintaining critical non-systemd components.

Of course you need to develop alternatives to systemd in order to decay into non-functionality. AFAIK, running a multi-user non-systemd OS these days, depends on a old bit-rotting version of ConsoleKit. There are many more features that will break and bit rot in the future for lack of maintenance; Red Hat, Suse, Debian, Ubuntu, etc. won't put resources into developing for non-systemd systems.

KDE will support running on non-systemd distros, but it will be with reduced functionality. Not because the KDE developers are evil, but because they are offered no alternatives to systemd. Take fx. the new KDE login manager; KDE simply couldn't afford spending developers so that it also supported the rather broken and bit-rotting ConsoleKit. And nobody else has stepped up and offered help.

Sure you can use another login manager, but it is just an example on how bit by bit, non-systemd distro will have to step up and start doing their own development in order to have functional software. Networking and ntp DE modules, and log viewers, etc. will all be systemd based, with no common alternative in sight.

Gnome developers have warned for years about current problems; systemd offers really good and compelling features that can enhance their DE, while non-systemd distros doesn't. And because non-systemd distros seems to be sticking their head in ground and denying the reality that status quo can't be maintained, they don't offer any help at all. In fact, snarky remarks and vague conspiracy insults are all they are getting.

There are many not so nice things about old style init scripts. Come on, executable config files where code and declarative statements are mixed? Who thought that was a good idea? Many people also find that debugging such scripts are hard etc. But the main thing isn't so much that old style script init systems are inherently bad, but that they don't work well with modern day computing.

The days of running a handful of services on a single server, directly on the metal, while hand crafting scripts, are basically over.

These days it is all about packing maximum of services on each hardware unit, with virtualization, OS containers, services on demand, plugging services into LSM's (Linux Security Modules). It is all about massive and fast deployment, cloud computing, and getting the most from the hardware you got, for the least amount of effort. Automatic supervising chains of all processes and services are simply a must, rate limiting and service hardening with minimal effort are required.

Old style script init systems simply aren't a good solution for present and future systems. Even BSD will eventually upgrade their init systems to something modern like systemd. OpenBSD already have a GSoC project for cloning part of it.

This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities", sand-boxing deamons so that privilege escalation is impossible, or forking etc. It also makes it a breeze to use cgroup, making it easy to control system resources to keep the system up and stable in case of DoS'ing, it has rate limiting, and a total supervising chain of all processes and deamons, including itself, etc. etc.

It is also very modular. For some reason systemd-detractors keep on saying that systemd isn't modular, even though a simple look at the source files could have told them otherwise. At the same time they also accuse systemd for being too modular, in that since systemd runs as PID1, it can utilize advanced kernel features like cgroup and let other modular parts of systemd (like logind), or third party deamons take advantage of that.

Hey, lets look at your sig:

Had you forgotten all about your own sig?

This is exactly why systemd detractors have lost every technical argument and lost out on all major Linux distros; you are wasting time on negative campaigning against systemd instead of getting off your asses and start coding alternatives.

You have lost wholesale to systemd because you wasted time smearing open source developers like Poettering behind your anonymous handles instead of working.