Slashdot Mirror
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."
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*
Mostly because very, very few people think that this is a good idea.
Programming can be fun again. Film at 11.
This is just an option. The default way is still via static binaries.
This won't change for some time (wheather it will change at all still has to be discussed).
I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other. Just look at the realpath vulnerability that they all were affected by.
Only 'flamers' flame!
Does slashdot hate my posts?
"Because Linux does it" is not always a good reason to do something. Linux developers tend to throw anything and everything they can into the mix. BSD developers tend to watch what others do, research the pros/cons, then develop a plan on how to do it right ... before tackling the coding.
:)
Hence, while Linux distros tend to get things first, BSD tends to get things right.
...was that, in earlier *nixes, sbin programs were always statically linked, to avoid problems with requiring
Not necessarily FreeBSD, but just some flavor of Unix. The versions of Digital Unix (under different names) which I teethed on were designed like this.
It's always annoyed me that Linux's [/usr]/sbin was dynamically linked.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
It's good that they are trying to save disk space, but why don't they just rewrite them so they don't use libc? Linux assembly.org is working on such a project, though it doesn't have to be in assembly. I've done some work using direct syscalls in Linux with C (look at /usr/include/asm--start with unistd.h). I haven't looked at FreeBSD in this way yet, but I think it can be done. At the very least, simple utilities like cp and ln could be written this way. Save disk space and be staticly linked--good all the way around.
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.
/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.
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
It isn't a lie if you belive it.
How about some utils which are written in assembly and are not dependent upon other libs? They're faster and smaller. You may want to look at LinuxAssembly.org's asm utils. They say it works for FreeBSD and other BSDs, though I haven't tested this myself (yet). When I tried them in Linux a few years ago, they weren't quite complete, but being small and independent has its advantages. When it's complete (maybe it is now?), I imagine these programs will be the choice for those who want to save disk space or speed up their system. Such a project would work in C. If it was in C, it would probably get more developers on board too...
Hence, while Linux distros tend to get things first, BSD tends to get things right.
:-). More recently, first to implement IP6, Serial ATA, Hyperthreading, etc. I would have to check, but I think they got USB and Firewire first as well.
Actually, BSD gets a lot things first. First to have a commercial support, first to have a free and complete operating system, and first to get sued by obnoxious companies
A Government Is a Body of People, Usually Notably Ungoverned
enable users to build /bin and /sbin dynamically linked on FreeBSD
/bin or /sbin; for some executable library $L in /lib; there exists some subroutine $p in $P and some object $l in $L such that $p uses $l.
/bin or /sbin. The new behavior is achieved by removing the arbitrary, stupid prohibition.
I am having difficulty parsing this, and neither the article nor the comments here help me. This is my best guess. Someone please correct me.
SITUATION: For some executable program $P in
OLD BEHAVIOR: When building $P, static-linker resolves name "$l", yielding an address or the desired data.
NEW BEHAVIOR: When executing $P, dynamic-linker resolves name "$l", yielding an address or the desired data.
DETAILS OF CHANGE: The kernel enforced the old behavior by examining every request sent to the generic 'dynamic-link' facility and blocked any requests which involved programs which happened to be in
ALTERNATIVE DETAILS OF CHANGE: The old behavior was enforced by the build scripts for $P and $L; we didn't want our super-important $P to be disturbed if something as lame as the dynamic linker crapped out on us. The new behavior is achieved by changing some compiler flags. We will all die when the dynamic linker craps out.