Quote Originally Posted by stevenc View Post
That's right. I was suggesting that everyone, everywhere has to use my cron one-liner... or they will become *irrelevant*. Seriously, did you really think that was my point?

No, my point was that: if I merely wanted process supervision, it can be done extremely simply with the existing, familiar, commonplace components of GNU/Linux or BSD. The exact method can be based on individual circumstances or expertise.

I think the notion, that a modern OS shouldn't have inbuilt process supervision, but instead relying on its end users to program such a solution, is undefendable.

The OS should provide the framework and programs, just like systemd does, so that Linux Security Modules (LSM) and other kernel features can be used. The end-users should tweak declarative text config files, not be forced to program just to get a bare minimum functionality. Relying on declarative text config files like systemd does, also makes it much easier to machine parse the config files, which is necessary these days with automatic mass deployment of servers.

The non-systemd distros doesn't seem to have any standard process supervision system, in fact, most of them doesn't have anything at all in that regard. The solutions that exist, are really quite limited and doesn't increase security by hardening the process. What you learn in one distro, can't be used on another.

All systemd Linux distros now have automatic process and service supervision, that can utilise powerful kernel features that dramatically increases security and stability. The supervision chain is total, including the supervising process itself, and is configured with declarative text files, that are easy for both humans and machines to parse and edit. Once learned, the knowledge can be extended to all systemd distros.


Quote Originally Posted by stevenc View Post
I also tried to illustrate that systemd seeks to replace much that is familiar, and give us something complex that requires learning anew. Therefore I expect it to have many bugs and/or be more difficult to understand during times when it doesn't work as expected I consider these to be 'costs' of migrating to systemd, and I think it's too much to sacrifice.
Learning new stuff all the time just goes with the territory of computing. The main driving force behind the changes are that the problem domain keeps shifting, often increasing in both scope and complexity. The 1980-90 way of running a server is dying. These days it is all about virtualisation, OS containers, Big Data, Cloud Computing, mass deployment, extreme resource utilisation, massive scaling, and doing all this in a secure and easy manner. Any OS that can't compete in these domains will become irrelevant in a short time.

So while sysvinit (though always a hack) would work in well enough on a single server, running on metal, dishing out a few simple services like http, or ftp, while idling most of the time, it simply doesn't work well for modern computing problems.

There you have it; if you want work in IT, you just have to learn something new all the time, because they way we use computers change. People not making a living in IT can "stop the world" if they want to by using old software: WordPerfect 5.1 for DOS is still an excellent word processor and may fit the work flow of somebody perfectly well in this day and age. But it is not a general solution for the majority of end-users.

Like it or not, if you want to make a living using Linux, you just have to learn to use systemd. Systemd covers a lot of ground, so there is much to be learned. However, the documentation is there, and once you get the principle behind each systemd component it isn't hard to get to know.