Systemd-free Devuan announces its first stable release candidate 'Jessie' 1.0.0

* https://github.com/MariaDB/server/blob/10.1/support-files/my...

I recommend actually learning about the reality of MongoDB. For starters, the systemd service units supplied in the likes of Ubuntu and Debian do not set any of the settings recommended for MongoDB by its authors, so here (as in so many cases with systemd service units in the wild, alas) shortness actually equates to not doing things properly.

* http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/mo...

* https://sources.debian.net/src/mongodb/1:3.2.11-2/debian/mon...

* https://docs.mongodb.com/manual/reference/ulimit/#linux-dist...

Another example of such is WSO2 Carbon, with a 14-line system service unit from one source that gets things grossly wrong.

* http://jdebp.eu./FGA/systemd-house-of-horror/wso2.html

I recommend actually learning about Caddy, too. Ironically, the subject of its service unit came up here on Hacker News only a day ago. It is 43 lines long, some 6 times the length of the supposed 7-line systemd service unit being bandied about here, and not as far different from those for MySQL and Percona as you imply; and it does not attempt to be "more modern" as you claim, as it entirely lacks the socket unit that would make it more in line with the systemd way of doing things.

* https://news.ycombinator.com/item?id=14167704

The idea that this is "modern service design" is borne of not knowing the subject, too. The sort of design changes recommended by the systemd people are in fact pretty much the same sort of design changes recommended by IBM in 1992 for services managed by the System Resource Controller and recommended by quite a lot of other people since, including Apple and ... well ... me for many years. Whilst this is good service design, it is not "modern", and not in any way unique or original to systemd. To further alleviate the ignorance of MySQL as well as demonstrate how this is far from "modern" and not something that one gets to claim for systemd service units, I point out that people were running mysqld without mysql_safe, in the very way that the systemd people are by all appearances just learning about in their mailing list discussion, under daemontools in 2002. I strongly suspect that that wasn't even the earliest occasion of that.

* http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Promp...

You can't say the same of systemd. It has to be whatever systemd has compiled in. (Which, by default, is terse status, followed possibly by journal data, or just system status if no units are available) Sysctl status also loads a unit at run time, and then may unload it afterward, meaning it is not useful to see if a unit was already loaded. It also uses a UTF colored dot, combined with different lines that can be interpreted different ways. In other words: it is a complex arrangement of information. And for machine output, you need the 'show' command, and more options.

With sysv, you ask it for status and it tells you if it's running, if the script supports status. Clearly a complicated mess.

Your last comments don't make sense. Sysv init scripts don't have to "find" a program any more than any other method of executing a program. And all init scripts I can think of are fire-and-forget, as much as systemd or any other init program is. The only thing they don't do is continue to try the same operation over time or wait around for a dependency, if that's what you meant (which Sysv scripts aren't really supposed to do, but inittab supports it anyway)

I'll do you one better on your first comment: ALL Sysv init scripts are a different "structure" internally. Even in the way they are used! The reason is, they're just scripts. Outside of inittab, there is no real standard for how they work, so each system makes them work however they wish. They can write them so they're all the same, or all different, and make them called the same or different, and give them different features, or no features. This is why some people love Sysv - it is totally flexible. You can make it do anything you want, and all you need to know is csh.

With other apps (not just systemd, but lots of things) complicated custom domain-specific languages are invented to do little things, like change configuration files' permissions, or send a file somewhere. Csh/Bash allows you to do the same, except it's a lingua franca that is compatible with every Unix-like operating system. It's interpreted, it's flexible, it's portable, it's backwards compatible, it's composable, it's extendable.... I mean, this is really an amazing thing that no other language or tool can claim (other than web browsers). Any problem you have with Sysv you can fix it within Sysv, without requiring compiling code, or even rebooting. I know i'm beating a dead horse here, but I just can't see how anyone would want to throw all this amazing power away or see it as limiting.

If you wanted, you could write a systemd clone in bash, and make service/unit files out of bash. I don't know why nobody has done this yet, but probably because it would be self-defeating.

Fair enough. And to be fair to me, I've been thinking seriously about moving my workstation over to a BSD. But even if I do that, I'd still have to deal with Linux for work at times.

It's my understanding that notwithstanding the current accomodations, systemd is the future for Gentoo, is that incorrect? I'm not a Gentoo user, just what I've heard from people who are.