I'd take systemd over sysv init, atd, crond, three or four watcher daemons, syslog, various other semi-maintained tools that replicate each other's functionality, and around 30x 50-line shell scripts.
It's pretty obvious you're not actually acquainted with the problem domain. Keep using whatever makes you feel comfortable, though.
These are all flaws in systemd with just one of those daemons you mentioned. Were I to get into init, I'd ask you about BSD-style rc files, which are tiny and very readable, as well as being shell scripts, so you can run more pre-execution tests to ensure your job will run correctly. With BSD atd and crond, I'd discuss how atd functionality has been merged in as a cron job. There are a lot of other solutions to sysv init than systemd. Unfortunately, the Linux monoculture sees bash as the only shell, sysv init as the only pre-systemd init, and the poorly configured rsyslogd distros ship with as the only syslog.
People like to make fun of Gentoo, but it does many things right. ;) OpenRC and netifrc are sane and flexible. syslog-ng is the "default" syslog and comes with a reasonable default config file. Use of logrotate is strongly recommended, etc, etc, etc.
As someone who has an on-going project to replace 157 rc.d scripts from FreeBSD 9/10, I can report that the generalizations about the Mewburn rc.d system that are often made, in order to contrast it with the egregious mess that one can find in the System V rc clone on Linux operating systems, are not in fact strictly accurate.
Yes, most of the rc.d scripts are small. Yes, the Mewburn rc.d system did almost 16 years ago what people are erroneously characterizing as novel to systemd: namely taking all of the common management code out of the individual service definitions, leaving just a few parameterizations in some cases. Yes, there is a definite common coding style that is a breath of fresh air when coming from the Linux world.
But no, the scripts are not universally tiny. One problematic example currently of interest is /etc/rc.d/bluetooth, weighing in at over 360 lines. Others include the subsystems that are split across multiple scripts, such as /etc/rc.d/atm1, /etc/rc.d/atm2, and /etc/rc.d/atm3.
Nor are they universally consistent, /etc/rc.d/serial being an example of one with quite different configuration semantics to the key=value-in-rc.conf{,.local} norm.
And whilst one might rail against the problems of having a common script for SuSE Linux, Debian Linux, and RedHat Linux, all of which have different sets of init.d script helper tools (resulting in "portable" init.d scripts ending up being a case "$distribution" in...esac statement for pretty much every step), one can equally point to the fact that OpenBSD's rc.d system (https://news.ycombinator.com/item?id=8506460) has entirely different function and parameter names to the NetBSD one (as adopted by FreeBSD/PC-BSD and DragonFly BSD) as well as different rules about rc.conf and different variable naming conventions.
Be very careful about attempting to claim some kind of moral high ground on interoperability and standards. (-:
Also be very careful about notions that the Linux world sees the Bourne Again shell as the only shell, some rather silly statements by some people who should know better notwithstanding. The adoption of the (Debian-modified) Almquist shell as /bin/sh by Debian and Ubuntu, and its significant effect on bootstrap speed, is quite famous. And my experience is that the Z Shell is quite popular, for starters.
Really though, the primary reason to cite rc.d is to debunk the pants-on-head claim of shell script-based rc being intrinsically spaghetti and voodoo.
Have you taken the time to examine how a Linux system that uses a replacement for sysvrc written in the last ten years actually handles startup? Or what services people who aren't running a RedHat distro actually run on their Linux servers?
Or have you simply either taken the systemd folks at their word about the "sorry state" of sysvrc replacements, or -perhaps- glanced at a >10 line startup script and recoiled in horror?
2. Yes. Folks who aren't running 'RedHat' (sic) use systemd, sysvinit, or pretend to use upstart but as a thin wrapper to sysvinit.
3. No, I don't generally listen to Linux advocates as a way of evaluating something.
Good. Far too many people in these conversations have poorly-informed opinions.
> Folks who aren't running 'RedHat' (sic) use systemd, sysvinit, or ... upstart [sic] ...
These are init and RC systems, not services. :)
> ...or pretend to use upstart but as a thin wrapper to sysvinit.
I dunno. The Upstart project page says:
"Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.
It was originally developed for the Ubuntu distribution, but is intended to be suitable for deployment in all Linux distributions as a replacement for the venerable System-V init."
If I look at the file list for the upstart package, [1] I see that upstart provides its own /sbin/init, /sbin/halt, and -it seems- just about everything that's provided by the sys-apps/sysvinit package on my Gentoo system.
Also, sysvinit and sysvrc aren't the same thing. OpenRC -the default Gentoo RC system- is a sysvrc replacement. [2] It relies on sysvinit (or similar) to get its work done, and is an obvious improvement over sysvrc.
If you were aware of the distinction, and have the time, would you be so kind as to mention the top N worst things about sysvinit? If you weren't aware, and have the time, would you care to learn the distinction, and then bounce on back and answer the query?
Thanks in advance. :)
[0] http://upstart.ubuntu.com/
[1] https://packages.debian.org/jessie/amd64/upstart/filelist
[2] If I'm reading this right, Debian even maintains a sysvrc package: https://packages.debian.org/jessie/sysv-rc
Re further requests for info, I don't really want to continue the conversation, because you should have apologised by this point and haven't. Don't presume to know things about other people, it's rude and looks poor when you're wrong.
That would be why I started my initial comment with questions, rather than presuming that I knew your background and knowledge and launching into poorly-formed and ill-founded accusation and/or assertion. :)
I'm trying to have a serious, level-headed discussion about a topic that is -inexplicably- sensitive for a few groups of people. In order to do so, I need to discover the pertinent information about the background and knowledge of my conversation partners.
> If you actually meant services, then what's your point?
I did. That would be why I asked about services rather than RC systems. :) I know that many people don't work this way, but if you can try to keep in mind [0] that I try hard to say what I mean, and leave nothing but white noise in between the lines of my statements.
Anyway, my point is this. You said:
> I'd take systemd over sysv init, atd, crond, three or four watcher daemons, syslog, various other semi-maintained tools that replicate each other's functionality...
which I took to be a little strange. It seems like this is your understanding of the typical set of services a Linux system runs, but it doesn't jive with how either I or my handful of professional sysadmin friends run our systems. We generally don't run atd, leave any FS watching up to the software package that actually needs it, avoid using tools that duplicate each other's functionality like the plague, and tend to not use unmaintained software... unless it's clear that that software is "done".
I've known several friends and acquaintances who have gone off to work for Red Hat. They've -to a man- come back with some really strange, very hard-line positions about how Linux systems are "supposed" to work. One of them vehemently insisted that -because of the complexity of dependency management and testing- a highly-flexible, rolling-release distro like Gentoo Linux was impossible. [1] Because of my personal experience with how Red Hat seems to have enweirdened some of my friends and acquaintances, and because I knew next to nothing about your background, I wanted to ensure that you had indeed stepped out of the Red Hat bubble and seriously looked at what other companies and distros consider a typical set of services and the features provided by and operation of their sysvrc replacements.
[0] I won't fault you if you can't. I have quite a difficult time remembering what I had for breakfast, let alone the rhetorical styles of the couple-dozen one-off Internet conversation partners that I've had over the past several months. :)
[1] Note that his position was not "Only a fool would attempt to provide guaranteed enterprise support for any and all arbitrary Gentoo Linux configurations because of $COMPLEXITY."! I can't argue with that position. I asked him if perhaps he misspoke and that maybe this or something similar was closer to his actual position. He vehemently denied that it was, and doubled-down on his original statement.
I ask basic questions because I often have conversation partners who have not done their basic research. In the past, I've wasted a lot of time having mid-to-advanced level discussions about topics with people who -as it turns out- didn't have even the most rudimentary grasp of the fundamentals of the topic. I ask brief clarifying questions of this sort out of respect for the busy schedules of myself and my conversation partners.
More than that, I've found that presuming to know something about other people often leads to hurt feelings and wildly incorrect assumptions. :)
From the start, I've been behaving in exactly the way you claim that you want me to behave. I even explained -at length- the reasoning behind my first and second comments and my conversational MO.
After your reply to my first comment, you've failed to meaningfully engage in any further discussion, citing my failure to behave in the way that you want me to behave as the reason for your non-participation.
We're getting really far afield here, but do you make it a policy to apologise to people (who aren't paying you) who continue to fail to understand something long after you've made that thing clear to everyone else in the room?