Slashdot Mirror

If you're interested, have a look at how NetBSD does init with rc.d.

Why do you think a numeric priority system gives "freedom" to the end user? To me, having to manually mess around with numbers is an annoyance, and it means that the init system is getting in the way.

Having numbers means that some dependency info gets lost. If you have an S10 and S20 script, is there any dependency between them, or were they just arbitrarily numbered? It's impossible to tell unless you go and read through the script and figure out for yourself. This makes it hard to debug when things go wrong. You also just end up with a bunch of scripts that all start with S99 or K99.

The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output. "Runlevels" were implemented with dummy scripts (i.e. scripts that just had dependency information in them, and didn't perform any actions).

Other than that, it's as simple as the traditional sysvinit, but without meaningless numbers everywhere. You can read more about it here: http://www.mewburn.net/luke/pa...

It's 2015, we should be naming things not numbering them.

Personally, I am a little surprised that Launch.d is being ported to FreeBSD, as Luke Mewburn's rc.d is a very nice startup system. You can read more about rc.d here.

NetBSD's setup does not actually make sure everything works, it makes sure it compiles under fake hardware.

That's how NetBSD's support for some platforms got so bad.

That last sentence is wrong!

Native compiling on a [slow] platform doesn't test that "everything works" for that platform, just that the native compiler generates some code on a given model. This is especially relevant for platforms with a diverse range of hardware, including Alpha.

Cross-compiling on a fast platform reduces the turn-around time for providing software to test on slower platforms. (Why wait a week for a build to compile when you cross-compile in an hour?). The NetBSD cross-build framework offers other benefits such as allowing build an entire OS release (including install media) without requiring root privileges or fancy OS support such as loopback disk drivers. More details in my BSDCon 03 talk and build.sh paper.

Either build method does not remove the need for actually testing the resulting build on the variety of hardware available for a given platform. That is a separate and more important issue.

(Why do [AC] fanboys of some operating systems belittle functionality that their OS doesn't currently have, only to about-face and shout to the rooftops when they finally get it?)

NetBSD's setup does not actually make sure everything works, it makes sure it compiles under fake hardware.

That's how NetBSD's support for some platforms got so bad.

That last sentence is wrong!

Native compiling on a [slow] platform doesn't test that "everything works" for that platform, just that the native compiler generates some code on a given model. This is especially relevant for platforms with a diverse range of hardware, including Alpha.

Cross-compiling on a fast platform reduces the turn-around time for providing software to test on slower platforms. (Why wait a week for a build to compile when you cross-compile in an hour?). The NetBSD cross-build framework offers other benefits such as allowing build an entire OS release (including install media) without requiring root privileges or fancy OS support such as loopback disk drivers. More details in my BSDCon 03 talk and build.sh paper.

Either build method does not remove the need for actually testing the resulting build on the variety of hardware available for a given platform. That is a separate and more important issue.

(Why do [AC] fanboys of some operating systems belittle functionality that their OS doesn't currently have, only to about-face and shout to the rooftops when they finally get it?)

The FreeBSD system is based on the NetBSD RCng system. The RCng paper is available here.

And your system won't work anymore, either. The order is important, and if you just add a "&" to the end of the commands, you lose control of that. Conventional init satisfies dependencies by prefixing the scripts with numbers indicating when they are to be launched - S10network, S12syslog, etc - and doing so sequentially. But this is overly conservative; the whole system doesn't start until a single service does, even if nothing depends on it. It also means you have to maintain a total order instead of a DAG, which sucks.

NetBSD 1.5 replaced init, too. See The Design and Implementation of the NetBSD rc.d system for details.

There was also an IBM article called Boot Linux faster on replacing initscripts with make. (This is less weird than it seems. Correctly resolving parallel dependencies is what make was designed to do.)

So Apple's not the only one to see a problem here and replace it. I don't know why the major Linux distributions haven't yet; the init system really sucks. Hopefully they'll take a look at launchd, which I believe is open source.

Au contraire, NetBSD-style init scripts are much more logical than sys V. With sys V you have a mess of symlinks. On NetBSD (and FreeBSD 5.x) you tell the rcorder program what dependencies your script has and what does it provide, the system figures our the execution order on it's own. To turn a service on you just put in your /etc/rc.conf file. Want to run bind? Just put named_enable="YES" in your /etc/rc.conf and there you go. Check Luke Mewburn's rc.d paper for more info.

There are many similarities between FreeBSD and NetBSD thanks to their mutual heritage, but FreeBSD's documentation doesn't usually apply equally to NetBSD. The differences are well covered in NetBSD's own online documentation, though.

• nsswitch.conf(5)
• rc.d(8) (which FreeBSD incorrectly refers to as "rcNG"). I have a paper about this.
• dynamically linked world
• /rescue
• the enhanced ftp(1)

• dynamic module support in nsswitch
• PAM ("soon")

Luke Mewburn wrote the new rc.d system for NetBSD.

I always fantasize about hacking a Debian SysV init into OpenBSD, then reality re-schedules my free time.

NetBSD's got a very nice rc (startup) system; as opposed to the monolithic (Open|Free)BSD approach, NetBSD's is a highly modular dependancy based model; no more giving scripts esoteric names like "000.wibble" to try to get it executed before "001.wobble"; just add a dependency in wobble on wibble and the rc system will make sure wibble is executed first.

There's an interesting PDF paper on the design and implimentation, some conciderably more terse and less interesting official documentation and a Daemon News article, and for those uber geeks, the CVS repository where you can compare with the other BSD's.

You'll note FreeBSD -CURRENT is looking at adopting it, while Open sticks with the tried and tested BSD4.4-type setup