Re: Unfortunate dynamic linking for everything

Leo Bicknell wrote:
> To boot a machine into single user mode you need a kernel, init,
> and /bin/sh (minimally).  It would seem to me that alone is a good
> argument for those three things to be static.

You need a static shell, yes.  That does not have to be /bin/sh.
init does prompt, and /rescue/sh is (and always will be) static.

As I pointed out earlier, some of the heat here comes
from the fact that /bin/sh is currently overloaded:

  * It is the default system script interpreter, used
    by the rc scripts and many other things.  As such,
    it must start quickly.

  * It is the default user shell for many users.  As such,
    it must support NSS.

So far, I haven't seen anyone in this thread seriously
argue against either of these points.

Today, these two issues are somewhat contradictory.  Right now,
NSS requires dlopen() which requires dynamic linking which
negatively impacts startup.

There have been a lot of proposed solutions:

  * Rewrite NSS to not require dlopen().

    A lot of people have suggested this, but Jacques
    made an important point about long-term support.
    In short, this would probably just gaurantee that our NSS
    is perpetually out-of-date, since it would become a major
    headache to port existing NSS modules.

  * Rewrite dlopen() to not require dynamic linking.

    There were some patches for this submitted at one point.
    As I recall, the people who looked at them were not entirely
    comfortable with them.  (I'd be concerned about version
    conflict problems with this approach:  what happens when
    a dynamically-loaded NSS module refers to a libc function?
    Does that get resolved to the already statically-linked
    version?  Or does another copy of libc get dynamically linked
    with potential version conflicts?  Does anyone know?)

    I personally think this is worth researching, though I
    have my doubts.

  * Don't support NSS in /bin/sh.

    This essentially amounts to: Don't use /bin/sh as
    an end-user shell.  Given the number of commits to
    improve command-line usage of /bin/sh, I think it's clear
    that a lot of people do rely on /bin/sh as a user shell.

  * Change the default script interpreter for rc and such.

    (e.g., use a statically-linked, optimized /sbin/sh for
    that purpose.)  Again, not particularly attractive, and
    it certainly breaks a lot of administrator's assumptions.

  * Make dynamic linking faster.

    As many people have pointed out, FreeBSD's dynamic linking is
    slower than it should be.  Advances here would benefit Mozilla,
    OpenOffice, KDE, Gnome, Apache, Perl, bash, TCL, Python, PHP,
    etc.  (I believe these are all slower to start on FreeBSD
    than on Linux, for example.)  This is a major end-user
    experience issue that I find much more compelling than
    anything mentioned so far.  I personally find OpenOffice only
    barely usable on FreeBSD, in large part because it takes so
    long to open.

    I suspect that most of our users would gladly give up a few
    seconds booting (or a few minutes from portupgrade or buildworld)
    if they could have Mozilla and OpenOffice open a few seconds faster.
    Benchmarks do not necessarily reflect user experience.

As many people have pointed out, there are other advantages and
disadvantages to dynamic linking:  library upgrades are simplified, disk
requirements are reduced, memory usage is less efficient, system upgrade
and repair is more complicated, etc., but I think the above summarizes
the issues that people seem to really care about.

Tim