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. http://www.freedesktop.org/wik...
> 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. http://www.freedesktop.org/wik...
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: 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.
...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. http://www.freedesktop.org/wik...
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.
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.
Like SELinux, I'm afraid that it's complex, incomprehensible and unusable to the average developer, and is immediately thrown away or never even usable to most 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.
The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.
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.
Instead of helping KDE and Gnome supporting non-systemd systems,
KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any criticisms. Perhaps appropriately electing to focus on bringing their vision to life to serve those who would follow the vision and letting the rest go on to KDE or xfce or MATE or whatever. I personally don't care about gnome shell as it doesn't serve my needs anymore either, but I can accept that they are caring after their user experience. I also wouldn't mind systemd so much except for the fact it is becoming unavoidable whilst retaining compatilibity with ongoing projects in linux.
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.
Systemd is not "that good." As an opponent myself, I am an admin, not a developer. And as an admin, I fail to see what was wrong with the BSD Init system. It works. It's simple. It's good.
And as far as Mr. Poettering goes, I much prefer to trash talk his work. Attacking him, no matter what you may think of him, doesn't get the point across.
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.
Systemd is not nice because it does all that stuff. Init is not supposed to do all that stuff, because it makes it bulky, gives additional avenues of attack, and is just all around a pain. What would have been better would have been to make systemd a modular system so that if you want it to handle all that, it can, but if you dont, it just does the parallel start up.
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.
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.
Systemd is the new future toolbox for maintaining and running Linux: All major enterprise Linux distros are using or are about to use systemd. Sure, a few companies will delay their transition to systemd if they have a lot of custom stuff they need to change, but systemd just have so many new awesome features that most will embrace it with joy; systemd simply means faster and better maintenance, and being able to pack more services in each hardware unit.
Those who dislike systemd are just a tiny but vocal minority; they have also spend the last couple of years smearing named open source developers like Lennart Poettering and trash-talking systemd, instead of developing an alternative to systemd. As a group they accept how the most extreme voices against systemd are unopposed, meaning that all the swivel eyed loonies with their paranoid ranting have become spokespersons for them, resulting in that nobody wants to work with them. So not only are the systemd detractors a small group, but they alienate most of the potential developers they could have had.
The end result is that almost nobody works on alternatives to systemd. Critical software like "ConsoleKit" is bit-rotting, nobody tries to help upstream projects supporting anything else but logind, despite that eg. Gnome developers have warned about this for years.
Instead of helping KDE and Gnome supporting non-systemd systems, the systemd detractors just rant on how NSA/The Greys/Poettering are controlling Gnome and KDE, and that everybody should boycot them and use CDE instead.
Like it or not, systemd will be in any Linux distro of importance in the future. Sysvinit (and X) are on life support and will be killed off at first opportunity people get. Even OpenBSD are starting to clone certain parts of systemd, and there is no doubt that all BSD's will have their init-system upgraded to a modern version inspired/cloned from systemd in the upcoming years. It is simply that good.
I have always admired RH for it's feature set and pursuit of enterprise-related features. I do however have one gripe: All the config files are in the wrong place! This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros. Does anybody know why there is such a difference in file locations?/etc/network/interfaces vs/etc/sysconfig/network/networking/where/are/the/damn/config/files
I think the differences are just the normal fragmentation between different distros, with everyone having their own idea of the "correct" place to put the config files. The systemd project is trying to establish a cross distro standard for some of the important config files, making it easier for upstream projects to know where e.g./etc/os-release is (on non-systemd distros it can be "hidden" almost everywhere).
Systemd is the most important new feature of RHEL 7, since the core of the OS now have been making a huge leap forward in security and reliability regarding processes and deamons. It is now a piece of cake to utilize advanced kernel features like "capabilities" http://man7.org/linux/man-page... and "cgroup" https://www.kernel.org/doc/Doc...
All major distros are about to change to "systemd"; Red Hat, Suse, Ubuntu, Debian. Their derivatives like CentOS, Sci-Linux, Fedora etc. are also changing to systemd, so in a few years, systemd will simply be the new standard toolbox to maintain and run Linux distros, and part of the new future Linux development stack; systemd, Wayland, cgroups and kdbus.
So every Linux System Administrator who have been to procrastinating regarding learning systemd, better start reading up on the subject. A good place to start is : http://www.freedesktop.org/wik...
I've heard reports of people laying on the ground and "hearing" meteors. What baffled scientist about this was people were hearing them realtime and not delayed due to the speed of sound. They finally realized that it was radio waves emitted by the meteors causing the grass to vibrate and they were hearing the vibrations.
Maybe I dreamed it...
I have heard meteors making real time sounds as they streaked across the sky. It was during the 2001 Leonids meteor storm. It was in a city with not a blade of grass in sight. This particular meteor storm was widely reported as emitting crackling and hissing sounds: http://www.spaceweather.com/me...
There has been some speculation about what could cause such sounds. Some have suggested that “electrophonic meteors” can cause secondary lower frequency vibrations to be heard simultaneously, but it is just a suggestion since good quality data is missing.
The RTFA discovery is just a part of a new series of discoveries that shows we know a lot less about meteors and comets than we thought we did.
What? The ZX Spectrum keyboard was years ahead of the competition with its square, flat, chiclet keys. It took decades before the PC industry realized its potential instead of emulating old typewriter keys. These days even Apple's Macbook Pro has flat and square keys, a clear tribute to the ZX "Speccy" chiclet keyboard.
On a more serious note, while the ZX Spectrum keyboard wasn't for touch typists, it had its advantages too: all the BASIC commands was printed on or above or below the keys, so it worked as a BASIC "cheat sheet". You only had to press "G" to print the command "GOTO" so it saved key presses and removed typos in the commands and functions etc.
The ZX Spectrum worked very well as an entry level PC with an emphasis on learning BASIC programming. I know several people who made a career in the IT business because of what they learned from programming the ZX Spectrum.
Slashdot Mirror
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.
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.
http://www.freedesktop.org/wik...
> 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.
http://www.freedesktop.org/wik...
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 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:
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.
...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.
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.
http://www.freedesktop.org/wik...
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;
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.
Like SELinux, I'm afraid that it's complex, incomprehensible and unusable to the average developer, and is immediately thrown away or never even usable to most 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.
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.
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.
instead of developing an alternative to systemd
The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.
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.
Instead of helping KDE and Gnome supporting non-systemd systems,
KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any criticisms. Perhaps appropriately electing to focus on bringing their vision to life to serve those who would follow the vision and letting the rest go on to KDE or xfce or MATE or whatever. I personally don't care about gnome shell as it doesn't serve my needs anymore either, but I can accept that they are caring after their user experience. I also wouldn't mind systemd so much except for the fact it is becoming unavoidable whilst retaining compatilibity with ongoing projects in linux.
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.
Systemd is not "that good." As an opponent myself, I am an admin, not a developer. And as an admin, I fail to see what was wrong with the BSD Init system. It works. It's simple. It's good.
And as far as Mr. Poettering goes, I much prefer to trash talk his work. Attacking him, no matter what you may think of him, doesn't get the point across.
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.
Systemd is not nice because it does all that stuff. Init is not supposed to do all that stuff, because it makes it bulky, gives additional avenues of attack, and is just all around a pain. What would have been better would have been to make systemd a modular system so that if you want it to handle all that, it can, but if you dont, it just does the parallel start up.
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.
How much did Lennart pay you? 8)
Hey, lets look at your sig:
--
When you cant win, ad hominem.
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.
I bet they'll have to support RHEL6 for many and many years as a lot of companies won't upgrade to RHEL7.
http://boycottsystemd.org/
Systemd is the new future toolbox for maintaining and running Linux: All major enterprise Linux distros are using or are about to use systemd. Sure, a few companies will delay their transition to systemd if they have a lot of custom stuff they need to change, but systemd just have so many new awesome features that most will embrace it with joy; systemd simply means faster and better maintenance, and being able to pack more services in each hardware unit.
Those who dislike systemd are just a tiny but vocal minority; they have also spend the last couple of years smearing named open source developers like Lennart Poettering and trash-talking systemd, instead of developing an alternative to systemd. As a group they accept how the most extreme voices against systemd are unopposed, meaning that all the swivel eyed loonies with their paranoid ranting have become spokespersons for them, resulting in that nobody wants to work with them. So not only are the systemd detractors a small group, but they alienate most of the potential developers they could have had.
The end result is that almost nobody works on alternatives to systemd. Critical software like "ConsoleKit" is bit-rotting, nobody tries to help upstream projects supporting anything else but logind, despite that eg. Gnome developers have warned about this for years.
Instead of helping KDE and Gnome supporting non-systemd systems, the systemd detractors just rant on how NSA/The Greys/Poettering are controlling Gnome and KDE, and that everybody should boycot them and use CDE instead.
Like it or not, systemd will be in any Linux distro of importance in the future. Sysvinit (and X) are on life support and will be killed off at first opportunity people get. Even OpenBSD are starting to clone certain parts of systemd, and there is no doubt that all BSD's will have their init-system upgraded to a modern version inspired/cloned from systemd in the upcoming years. It is simply that good.
I have always admired RH for it's feature set and pursuit of enterprise-related features. /etc/network/interfaces /etc/sysconfig/network/networking/where/are/the/damn/config/files
I do however have one gripe: All the config files are in the wrong place!
This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros.
Does anybody know why there is such a difference in file locations?
vs
I think the differences are just the normal fragmentation between different distros, with everyone having their own idea of the "correct" place to put the config files. The systemd project is trying to establish a cross distro standard for some of the important config files, making it easier for upstream projects to know where e.g. /etc/os-release is (on non-systemd distros it can be "hidden" almost everywhere).
Systemd is the most important new feature of RHEL 7, since the core of the OS now have been making a huge leap forward in security and reliability regarding processes and deamons. It is now a piece of cake to utilize advanced kernel features like "capabilities" http://man7.org/linux/man-page... and "cgroup" https://www.kernel.org/doc/Doc...
All major distros are about to change to "systemd"; Red Hat, Suse, Ubuntu, Debian. Their derivatives like CentOS, Sci-Linux, Fedora etc. are also changing to systemd, so in a few years, systemd will simply be the new standard toolbox to maintain and run Linux distros, and part of the new future Linux development stack; systemd, Wayland, cgroups and kdbus.
So every Linux System Administrator who have been to procrastinating regarding learning systemd, better start reading up on the subject. A good place to start is : http://www.freedesktop.org/wik...
I've heard reports of people laying on the ground and "hearing" meteors. What baffled scientist about this was people were hearing them realtime and not delayed due to the speed of sound. They finally realized that it was radio waves emitted by the meteors causing the grass to vibrate and they were hearing the vibrations.
Maybe I dreamed it...
I have heard meteors making real time sounds as they streaked across the sky. It was during the 2001 Leonids meteor storm. It was in a city with not a blade of grass in sight. This particular meteor storm was widely reported as emitting crackling and hissing sounds:
http://www.spaceweather.com/me...
There has been some speculation about what could cause such sounds. Some have suggested that “electrophonic meteors” can cause secondary lower frequency vibrations to be heard simultaneously, but it is just a suggestion since good quality data is missing.
The RTFA discovery is just a part of a new series of discoveries that shows we know a lot less about meteors and comets than we thought we did.
What? The ZX Spectrum keyboard was years ahead of the competition with its square, flat, chiclet keys. It took decades before the PC industry realized its potential instead of emulating old typewriter keys. These days even Apple's Macbook Pro has flat and square keys, a clear tribute to the ZX "Speccy" chiclet keyboard.
On a more serious note, while the ZX Spectrum keyboard wasn't for touch typists, it had its advantages too: all the BASIC commands was printed on or above or below the keys, so it worked as a BASIC "cheat sheet". You only had to press "G" to print the command "GOTO" so it saved key presses and removed typos in the commands and functions etc.
The ZX Spectrum worked very well as an entry level PC with an emphasis on learning BASIC programming. I know several people who made a career in the IT business because of what they learned from programming the ZX Spectrum.