What I understand from various contributions on this forum is that the concern is with VM instances at cloud operators, not with bare metal, nor embedded systems.
As far as an init system is concerned?
As I stated speed isn't everything. If cloud operators are rebooting their servers every day to prevent OS memory leaks then they should be seeking a new OS or becoming competent in discovering those said leaks.
What I don't really understand is why people posting here focus on systemd, whereas it is NOT the only init system out there.
(Apart from it's the subject of this topic?
)
And the fact is it's not an init system either. It's more than that. That's its problem. Forgetting all the extra parts it has engulfed as it meanders into userland and subsumes GNU, its init system is a horrible design hanging everything off PID 1.
Void Linux uses runit and it boots impressively fast, faster than the other distributions I've tried.
GhostBSD uses OpenRC.
The de-facto monopoly of systemd in the Linux world has political roots, not technical.
And that's just great. Let them keep it there. It would seem almost incomprehensible that any BSD would consider any aspect of systemd to be a worthwhile thing to copy. As I stated earlier, it's deliberately designed to be non-portable and Linux-centric. That was a great decision by its designers because it makes it less likely some poor sod would attempt to port it. Look at a previous committer, Beno Rice's love affair with it. If he had his way it would be under development in FreeBSD. Oh, the inhumanity!
Redhat obviously wants to control the narrative of Linux userland. It can't control the kernel, so systemd is its chance to dictate how things work. It's perfectly understandable from their business perspective. It just amazes me how dumb the average Linux fan of systemd is because they can't see this as being a negative. The average fan spouts about the pre-systemd init systems being full of shell scripts etc and yet most of them would have never written an init shell script in their lives. They'd support systemd even if it was a front for the Taliban.
FreeBSD not being a Linux distribution, there is no reason to invite Linux politics in our technical choices.
Furthermore, the problem with systemd is not with its init system functionality, but with the fact that it controls everything else, often in unexpected and undesired ways, impacting the source code of applications and making them less portable - if still portable at all.
I freely admit I know less and less about it as I have no interest in it (apart from not wanting it in BSDs). However, I did try it early on and was aghast at its demands for you to change how you program daemons. How it handles system logging. How it handles core dumps. How it handles init services and just waits for minutes for a problem to resolve. How it defaults to not allowing users to leave a process running after logout. It's basically the mantra of "we know best, so change your ways or get out!" (For Star Trek fans: I AM BORG!)
If FreeBSD really needed to change its init system, choosing or developing another one would require to clearly state the strengths and weaknesses of the current solution so as to improve it in a consistent way.
This is why I've asked my question in the post above. I'm interested in the light experienced people could shed on the strengths and weaknesses of FreeBSD's current init system.
Apparently, as mark_j outlined, parallel startup is one of its weaknesses. From what I've seen browsing rc.d, it could be solved with some refactoring.
Are there any other problems besides this one?
Of course you would have to illustrate the current pitfalls of the rc system and how to design around it. But, there's ports and other utilities to give you things like parallel startup. Why complicate something just to "modernize" it? Manpower is obviously an important issue. I'm not sure some Google Summer of Code project could solve it...
Do you want to monitor an init service to re-start it should it fail? There's a port for that (or write a shell script if you're able). Sun wrote all this back 20 years ago in their SMF. They weren't trying to be compatible with other OS's. Same goes for systemd.
Then, as can been seen by observing systemd developers, scope creep engulfs the process as you try and solve more and more problems you've just created with your last great 'enhancement'. It's why systemd will never stop expanding into userland and kernel. Who knows, in ten years time, the linux fraternity might be asking how they can unwind themselves from this systemd mess.
