Dynamic Root Support For FreeBSD Now Available

Dan writes "FreeBSD's Gordon Tetlow has committed his enhancements to enable users to build /bin and /sbin dynamically linked on FreeBSD. His reason to do this is two-fold. One is to give better support for PAM and NSS in the base system. The second is to save some disk space. Currently (on his x86 box), /bin and /sbin are 32 MB. With a dynamically linked root (and some pruning of some binaries), the /bin, /lib, and /sbin come out to 6.1 MB. This should be great for people with 2.x and 3.x era root partitions that are only about 50 MB. Gordon says that there will be a performance hit associated with this. He did a quick measurement at boot and his boot time (from invocation of /etc/rc to the login prompt) went from 12 seconds with a static root to 15 seconds with a dynamic root."

Comments

bad bad bad

[Tirel]

not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,

there are less and less reasons to use seperate partitions for root directories, and this is *NOT GOOD*

Re:bad bad bad

[Fweeky]

Er, why? /bin, /sbin and /lib should all be on the same partition, and if you're really screwed, that's what /rescue is for.

Re:bad bad bad

[ctr2sprt]

It's not good as a default, but it's good as an option. So while I hope FreeBSD installs still come with a static bin+sbin, it's nice to have the option, on a make world, to change the behavior if I decide I need to. It's added flexibility without any added complexity. What more could you want?

Re:Linux distro's already do this.

[Anonymous Coward]

What utter nonsense. Linux developers and BSD developers are cut from the same cloth. Neither group has a monopoly on "research" or "getting things right". Your assertions are no more truthful than what I'd expect from a troll.

By the way, what are your credentials? I've never seen you contributing anything technical to any operating system project.

Re:What about independent of external libs?

[Piquan]

Because there's a lot of logic in, say, PAM or NSS, which are needed often in /bin and /sbin. You could write that into each program, but then you'd have to update them all each time you found a bug or needed to add a feature. You could share a .o file between them, and then it's the same thing as statically linking them in the first place.

Re:25%

[JDizzy]

It really depends if your a pesimist, or an optimist. Yes 3 units of 12 is indeed 25%, and since it is 3 units over 12 to 15 it could be seen as an additional 25% extra time. The more correct way to look at it is from the point of view for the number 15. aka the boot was an entire 1/5 faster without dynamic bins.

Besides, there have also been improvements in caching libs in conjunction with linking so that dynamic bin's always load faster. It could also be possible to make certain /bin and /sbin stuff static, but thats what /rescue is for with the crunched bins. Besides, this will only lead to a more optimised ld program and linking system there after. Not having the entire bulk of libc repliated allover the place in /bin and /sbin is entirly acceptible to me. Architecturally speaking that is a big faux pax to leave such a clutter. This is why elf was devised in the first place, and slow to implement Operating Environments is partly to blame for the hindering of cool features like dynamic linking tricks such as thosed used in pam and nss. This is, after all, the reason we have libraries.

Re:What about independent of external libs?

[josepha48]

You should look at the uClibc project which is trying to make a smaller libc for small floppy based distros. Also busybox, can be used to make a smaller system. Progamming in assembly is not pretty.