There's nothing stopping a Linux distro doing this.... but
It would be a step backwards: it is simpler, and does less stuff, so booting would be slower and some features are missing.
It would be a step backwards: it is simpler, and does less stuff, so booting would be slower and some features are missing.
My BSD systems (not front-facing and therefore on a lesser patch cycle) rarely get rebooted and neither do the processes so this is indeed moot for me.
Proof:
http://i.imgur.com/tZsM82Q.png
Yes that's a memcached uptime on a host that has had 10,185,367,932 cache hits...
OpenBSD however works wonderfully.
Also there are some peculiarities in the way the LSB init script compatibility is implemented in systemd: it tries to be 'smart' and remember their state. So you start an init script, and it failed for some reason / perhaps even exited with an error code, perhaps you are still developing that init script. Now fixing the problem and running the init script / systemctl start doesn't even try to run the script because it thinks it has run it yet. You first have to tell it to stop it (which fails), and only then you can run it again.
My BSD systems boot quickly enough for me.
It's pretty dumb, and not enough of a problem for me that I'd figure out how to work around it, but it's a pretty good example.
http://askubuntu.com/questions/63456/waiting-for-network-con...
My experience is that a substantial amount of time is wasted weeding out undesired timeouts in startup scripts, because they lead to increasing downtime.
defaultrouter="NO"