I just discovered that my link was already included in the TFS. Oh, well...
There is a somewhat detailed review of Plasma 5 here:
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.
Can I safely assume that you never used Dan Bernsteiin's "daemontools", which stayed of the complexities of logging and worked very well for daemon management.? If SysV init was due for replacement, then there are much lighter tools that could have done just _that_ task.
Oh I know Dan Bernsteins "Daemontools" like "supervise". With all due respect for the man, those tools are an ugly hack that tries to make up for the almost non-existing functionality of SysVinit. Systemd are so much better in any respect compared to "Daemontools" that has no rate-limiting, no intelligent restarting, no total supervising chain (who monitors "svok"?), no resource control etc. etc.
SysVinit has been on the official UNIX kill list for decades with every Unix OS getting something else. Only Linux kept on using it long after it should have been killed off, only because there where no central Linux development outside the kernel. It wasn't because SysVinit was good it lasted so long, it was lack of development.
Come on, if anyone said: lets mix config statements and executable code in a free form, unstructured executable config file, people would laugh at them. Nevertheless, this is exactly what Linux has done with script based init systems like SysVinit and OpenRC and the rest of the lot.
With systemd we finally have separated code and config statements. You configure the init-system (systemd) handling of services by adding simple keywords in a structured text file that can easily be parsed by both humans and machines.
With systemd there finally is a central, coherent development of the "system glue" outside the kernel. It is exactly what the "Linux Plumber Initiative is all about. Systemd allows end users, SA's, developers and Distro maintainers, to enable powerful Linux kernel features in userland (like cgroup, Capabilities and soon, IPC's like kdbus) with simple keywords added to config files.
SysVinit and all those script based init-systems are effectively dead.
The discussion is over what the new Linux default init-system and plumbing system is; systemd won by a landslide because of its technical superiority.
You will doing yourself a disfavor if you keep on listening to all the systemd haters; they don't know what they are talking about, and their religious hatred against Linux changing will mean they will get left behind. Don't fall for that trap, stay sharp and hone your skills on systemd.
I do not "want to configure systemd". I want to not replace several decades of daemon and log management integration in dozens if not hundreds of distinct environments with an entirely distinct, complex, and poorly integrated system.
Those old and crusty daemon and log management integration tools are simply crap compared to systemd's integrated approach. You obviously don't have any real experience with systemd if you think otherwise. Everything is at least 100 times better than compared to SysVinit/Upstart (and Syslog etc).
The idea that "in a few years, all Linux distros will use it" is completely irrelevant to the upfront cost of switching now.
No it is not. The point is that if you will continue to use Linux, you have to switch to systemd. The development of components needed to run non-systemd systems have been stagnated and bit rotted for years.
So you have to switch to systemd at some time or another, so you better get started as soon as possible with learning systemd. Yes, there will be a cost for doing so, namely that you will have to learn something new. But that really goes with the territory when working in IT. Staying in the comfort zone instead learning new stuff (which is getting harder the older you get) is a surefire way to become obsolete on the job market.
Systemd has really good backwards compatibility with old daemon init-scripts and is it possible to use it with syslog if you have many logwatch scripts. It is quite possible to have a gentle upgrade of the environment by keeping backwards compatibility with legacy programs while slowly out-phasing them.
The existing compilation settings are, of course, in the SRPM's published by Red Hat. Manipulating them and replacing core utilities means maintaining an internal fork: it would no longer be part of, nor supported by, Red Hat's distribution. I'm afraid that it would also be like removing a car's battery. One can jumpstart the car, but it will cause a host of other problems because the rest of the operating system is now integrated with such a core component.
Either you have an actual user case for not using eg. RHEL's setup and version of systemd, and then you act upon that, or you don't have an actual user case, and there the problem just disappears.
You seem to try to make a problem out of nothing, what exactly is the precise problem you have since you want to configure systemd differently from RHEL?
The problem with discussing with systemd opponents like you is that you are hopelessly uninformed about systemd. That is why the critique seems so vague and imprecise.
Stop getting your information from ignorant systemd haters, and study the project itself. I can recommend the video talks on the systemd page if you want to understand the design of systemd. In a few years, all Linux distros will use it, so it is worth investigating.
> This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities"
Just like SELinux, which I'm afraid most developers and many admins turn off as their first step in setting up new systems. Using internal security structures requires extra development time: it may be well invested, but it's extra work that is already discouraging people form upgrading or activating such security features. Please do not assume that simply because a security structure is available that it will be welcomed, or used, by most developers.
I am aware that some turn of SELinux, because it is "easier" and they don't understand how it works, and they don't want to learn anything new. Yes, there a many SA's that lack both the technical skills and the ability to learn new skills.
But frankly, uneducated people with lack of skills, shouldn't hold back the development of Linux, just because they can't be bothered learn anything new even though they as SA's are paid to keep up with technologies (let's use SysVinit the next 30 years too, hooray!). They will be punished by life and left at the wayside. I have seen this happening to a lot of people in the IT business since the 1980's; they stagnated and stayed in their comfort zone and was later ejected out of the IT business because of outdated and obsolete skills.
Systemd is now the new defacto Linux plumbing system, and SA's either learn it, including its security features, or they will have to stop being Linux SA's.
Besides that, using "Kernel Capabilities" are very simple. Just put a single keyword into a text file and restart the service. Most end users will never have to edit anything since the services will come with some standard "kernel capabilities" features turned on, like "ReadOnlySystem=" and "ProtectedHome="
So yes, people will use systemd's many new security options, since they will be turned on by default in their distro, and it will increase security dramatically compared to old legacy Sysvinit systems, that are hard to protect. And yes, in the future there will be more kernel security features that systemd can utilize like kdbus, making services ever more hard to exploit, and making the defense ever deeper, practically sandboxing exposed services.
Systemd will make Linux more secure, it is a simple fact.
> You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options.
"Compile switch options" are entirely irrelevant to published binary system components, such as systemd in RHEL 7. It's certainly possible to compile many system tools without specific features: this does not make them "separate" from the systemd monolith.
No, "Compile switch options" are entirely relevant for every distro. The distro has full control over which part of of systemd they want to include and with which options switched on as default. Systemd can be tailored in many different ways to fit both super computers and clusters, servers and VM's and OS containers, and desktops and tiny embedded systems. It is extremely flexible.
Just look at the documentation and the source code; it is all there for everyone to see.
If you don't want how RHEL are distributing systemd, just get another distro, or talk to Red Hat and explain you particular user case.
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.
As an example: systemd removes the ability to run a grep on the plain text log file. And replaces it with something else. Metro also takes away the ability to do some stuff and replaces it with something that the marketing department claims to be just as capable or even more. And perhaps it's all fine when you are within the boundaries that the marketing department envisions. But Linux was never about keeping yourself within some borders. We want tweak and poke, replace X with Y and customize to no end. You can't beat flexibility of a shell script combined with textutils/binutils/fileutils.
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:
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.
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.
...But I remain skeptical that a server "needs" systemd - witness that BSD servers work fine and none of them have systemd.
"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.
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.
Strangely it reminds me of Metro UI on Windows that may be nice/useful on tablet/phone but was pushed by MS also to places where it does not belong: desktop or even server.
Similarly systemd may have it's uses for some specific systems and for all I care go ahead. But if systemd is going to take over my workstation and turn the boot process into something that is difficult to read/modify/log/... then I'm not going to be happy.
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.
You are using the developer view of "modular", rather than the admin view of "a bunch of small programs each doing only one thing (the Unix model).
If systemd had followed the Unix model, people would be able to take good old init, the rc-replacement from systemd, and syslog, and hook it all together. As it is, if you want one thing systemd, you get all of it.
If not for the Gentoo people who forked udev, "if you want one thing from systemd" would have included systemd.
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.
"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."
Why on earth is that a job for init?
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.
Thus speaks someone who has never seen a crash/restart loop. Large apps like databases can take several minutes to start up and recover, and then immediately die again. The next morning you have several terabytes of core dumps, and a corrupt database, and have to restore the latest backup.
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;