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

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to