Quoting Trent W. Buck (trentbuck@gmail.com):
(Sorry this post is so long; I didn't have time to make it shorter.)
You and your friend Blaise. ;->
Speaking as someone who had to jump through many hoops to support Upstart when it was first rolled out in Ubuntu 8.04 and Ubuntu 10.04, and systemd on Debian 8, and who also watched on the sidelines when pere rolled out insserv/starpar parallel booting by default in Debian 7, I strongly believe it's *not* trivial.
Maybe it's only enough work for one full-time person, but it's more than I could easily cope with alongside my other regular responsibilities.
To be clear about what I meant, I am not being critical of DDs' refusal to commit to making sure that a whole flock of init systems have full-citizen support. What I was saying is that, if (say) I wanted to use OpenRC on Debian 8 and there weren't packages with the necessary plumbing for the 7 or 8 services I desire to run (init scripts or whatever), I'd just create that plumbing locally for the 7-8 services. It wouldn't be a big deal for a local admin to do that for local needs, IMO.
(Oh, I also tested cinit/minit back in the day, but I gave up on those before production rollout, because NO WAY was I going to write job descriptions for every system component.)
Well, honestly, how many system components require init plumbing on a typical system? In my experience, not many.
PPS: systemd really wants to be in charge of the initrd, too.
I have no problem with it wanting. ;-> (With luck, my next server build won't need an initrd. I'm going to see if I can just compile in what the machine needs.)
Personally, I think Debian's Policy Manual is its killer feature.
I absolutely concur -- and certainly hope Devuan doesn't bollix that. (Aptosid carefully complied with Debian Policy, in its day, FWIW. I hope I'll find that its rival live-CD sibling Siduction does likewise, but haven't caught up with it, yet.)
If I was prepared to give up on that, and was building my own distro, it'd be built on top of musl and busybox (inc. busybox mdev).
Yes, I'm looking into that -- though I'd aspire to follow Debian Policy to every extent possible, in so doing.
NB: mdev doesn't do the whole blkid thing, but linux-utils mount uses libblkid internally, so *ALLEGEDLY* you can do "mount LABEL=porn" even though no symlink /dev/disk/by-name/porn exists. I haven't verified this myself.
For server deployment, I would expect to have no reliance blkid(8) nor UUIDs. I'm glad they meet the needs of people with relevant use-cases.
I'm not familiar with vdev, it appears to be this:
https://git.devuan.org/unsystemd/vdev https://github.com/jcnelson/vdev
the latter explicitly says
This system is mothballed. It's usable if you know what you're doing [...] Expect to get your hands dirty.
Outdated links. There's a guy who took over maintenance. Honestly, though for my own uses on servers, it looks _way_ overengineered. What I'll be using on my upcoming server rebuild will depend on testing, but the first thing I'll be trying is just plain static /dev . If there turn out to be problems with that, I'd have a go with mdev -- and I strongly doubt that there'll be any need whatsoever for anything more complicated than that. For my _own_ use-cases, on servers and on my preferred sparsely built, no-DE laptops, I cannot presently anticipate needing anything as complex as vdev (or for that matter udev), either. But again, that will be determined by testing.
PS: OpenWRT also have their own in-house replacements for systemd, logind, and udev. They're not really set up (yet?) for use by anyone else, but they're certainly interesting for study.
http://wiki.openwrt.org/doc/techref/procd (& other pages)
Interesting. For my own Linux uses, what I seek, though, is (being admittedly a little vague, here) to avoid dealing with the characteristic objectives of systemd, logind, and udev at all -- if possible: Specifically, to the best of my present understanding, there's literally nothing I do where I need or want hotplugging. Back a number of years ago on Don Marti's linux-elitists mailing list, I remember politely questioning whether then-new udev was actually necessary, especially on servers, and Greg K-H rather hotly responded with a well-practiced tale of how it was needed so that his daughter could connect and disconnect USB printers without needing to wield root authority. I was impressed by the passion in his defence of his daughter's interests, so much so that I was very gentle when I told Greg that his daughter would not be permitted to connect her USB printer to my server. I've been more than a little skeptical of the entire farrago, ever since.