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."

6 of 112 comments (clear)

  1. Re:Linux distro's already do this. by phoenix_rizzen · · Score: 5, Interesting

    "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. :)

  2. My understanding... by devphil · · Score: 3, Interesting


    ...was that, in earlier *nixes, sbin programs were always statically linked, to avoid problems with requiring /usr, or accidentally damaging the dynamic loader, or still functioning while restoring dynamic libs from tape, etc, etc.

    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)
  3. What about independent of external libs? by moncyb · · Score: 2, Interesting

    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.

  4. Re:25% by moncyb · · Score: 2, Interesting

    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...

  5. Re:Linux distro's already do this. by Arandir · · Score: 4, Interesting

    Hence, while Linux distros tend to get things first, BSD tends to get things right.

    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 :-). 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.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  6. Blink by timotten · · Score: 2, Interesting

    enable users to build /bin and /sbin dynamically linked on FreeBSD

    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 /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.

    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 /bin or /sbin. The new behavior is achieved by removing the arbitrary, stupid prohibition.

    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.