By n-amount do you mean parallel startup or disparate init systems? The latter would not happen since there's one FreeBSD. At least one FBSD-based distribution (TrueOS) used OpenRC IIRC, but TrueOS is history now.
GhostBSD uses OpenRC.
Your point was "if an
alternative init system is done right, it would neither hurt nor restrict you, but enable less skilled people to govern it ", to which I replied as I did. My reply was the history behind GNU/Linux changing their init system was because of diversity of systems, maintainability and the NIH syndrome they suffer from.
See above: I'm not promoting systemd... In contrast, my concern is: it's reasonable to evalute runit vs. OpenRC as a replacement for the
Ok, so there's a language issue here. There's
alternative, proposing FreeBSD have more than one choice for an init system or
replacement, proposing FreeBSD has a new init system.
This is obviously where the confusion comes in. Ok, so replacement it is.
current
BSD init, like e.g.
is done here for Linux. Both allow for parallel services start, and they might be easier to manage for newbies (that's to be evaluated). Additionally, they supply service monitoring/supervision, which seems to be a demand of professional server plants.
It should easily be possible to switch off parallel startup, I you want that. Likewise, it should be possible to not monitor a service. Both are reported to be fairly slim & KISS. Thus, you'll loose
nothing, while others could benefit.
As I wrote in another message, I have anecdotes galore of the failure of service monitoring OSs like Solaris's. Only a lazy administrator would trust them. If, for example, postgres crashes, we DO NOT want it to restart and possibly hide the issue.
Now, for sure, there's probably a service that can be restarted automatically, however, that's not a new phenomena, and shell scripts monitoring services have been around since the first UNIX rolled out.
It does not, because the current
BSD init does not have a feature that is demanded by many desktop users: parallel service startup. The only arguments against this so far were 1. added complexity, which I doubt; at least the added complexity will not be overly much IMHO; and 2. race conditions, i.o.w.: in most cases, it works well. There are race conditions in
any system beyond a certain complexity, e.g. currently my
wpa_supplicant(8) does not start automagically, but it does start w/o errors & warnings manually. If I want parallel startup, I would probably run into many issues right now. If it comes by default, I'd be happy.
There's a lot of supposition in there.
First, let's address you major issue: parallelism.
What makes you think this is something demanded of desktop users? Was it not you who said FreeBSD does not hibernate, so, by implication, it must be shut down and started up again, rendering an init system that has parallelisation, a must?
My reply is to fix the problem of non-hibernation, not adjust the init system to fix this one use-case. Should it be fixed? Yes, of course.
Is there a workaround?
Second, the issues of another, replacement init system:
1. Legacy change of all ports to the new init system, where those ports use daemons.
2. Scope creep. As changes to the init system require parallel processes to run, these need to be "aware" of other processes and interact accordingly. If we take systemd as a model (eek!) then the use of sockets for parallel start ups means a significant change to ALL daemons.
3. Parallelizations cause race conditions. Race conditions are bad, more so in a program that between programs. Mitigating them takes work. It's not a real problem with separate processes of course, compared to one process, but it's nonetheless a potential issue. In the case of an init it requires a strict adherence to rules about what can run before/after/required/desired etc.
In the case of something like runit, I tinkered around with this a while back on (ahem) NetBSD. It's parallel, sort of. It just starts as many as possible and keeps retrying until they stick. Not what I call a great system.
Again: please stop complaining about
systemd and using it's deficencies as contra argument. We are 100% d'accord that this mess is broken by design. Come up with arguments against
runit (
sysutils/runit) and/or
OpenRC instead.
Why? It's pertinent because the fast startup that systemd apparently gives you was driven by the points you raised. It's extrememly germane because to have a "proper" parallel start up init service you need something like systemd's init or launchd or even svc.
Yes, it is possible to employ an alternative init system for FreeBSD, but then you will lose compatibility with (almost 100%) NetBSD and to a lesser degree OpenBSD. I think that should be a consideration as well. (At the risk of mentioning systemd again, this is the contrarian view held by systemd - ignore compatibility, we're going it alone).