Unfortunate dynamic linking for everything

[Matthew Dillon]

:Our rationale for encouraging Gordon is as follows:
:
:1.  4.x upgrade path:  As we approach 5-STABLE, a lot of users might want
:    to upgrade from 4-STABLE.  Historically in 4.x, the / partition has
:    been very modest in size.  One just simply cannot cram the bloat that
:    has grown in 5.x into a 4.x partition scheme.  Of course there is the
:    venerable 'dump - clean install - restore' scheme, but we were looking
:    for something a little more user-friendly.

    This argument would apply to very old 4.x users but not to anyone who
    installed it as of March 2001.  I bumped the nominal size of the
    root partition to 128MB in 1.98.2.7 of sysinstall/label.c.

    Prior to that Jordan had bumped the root partition size to 100MB
    in 1.98.2.3 in March 2001.  It was 50MB before then, which is too small
    even for 4.x.

:2.  NSS support out-of-the-box:  Again, this is a user-experience issue
:    in that forcing NSS users to recompile world was seen as a potential
:    roadblock to them.

    Users have to recompile the world anyway, I don't think NSS is an issue.

    Or to put it another way:  Nobody in their right mind should be 
    contemplating upgrading a 4.x system to 5.x for production purposes.
    There will simply be too much 4.x cruft left over.  Upgrading
    really requires a wipe and reinstall in this instance.

    I seem to recall that the main reason 5.x went to a dynamic /bin was
    to work around a terribly broken PAM design.  The other issues were
    just eye candy compared to the PAM problems.  Personally speaking, I
    think the solution is to fix PAM instead :-)

:3.  Binary security updates: there is a lot of interest in providing a
:    binary update mechanism for doing security updates.  Having a dynamic
:    root means that vulnerable libraries can be updated without having to
:    update all of the static binaries that might use them.

    Non-issue if you have an automatic security update mechanism or script
    to do the work for the user, which we don't.  Even so, /bin and /sbin are
    sufficiently self-contained in the source hierarchy that recompiling and
    reinstalling them is not a big deal.

    I think the security argument is a red-herring because, frankly,
    security problems are far more prevalient with ports and larger services
    (Apache, sendmail, sshd, etc... mostly in /usr/bin and /usr/local),
    and not as big an issue for /bin and /sbin.

:As for performance, we felt that the typical use of FreeBSD did not fall
:into the category of doing forkbomb performance tests.  While there might
:certainly be users that do continuously create lots of short-lived
:processes, we felt that the above benefits outweighed this, but left the
:door open for tailoring to this need (recompiling world with
:NO_DYNAMICROOT).

    fork() is a non-issue (forking overhead for a dynamic executable imposes
    a slight time penalty but does not really impose any resource penalty).

    However, I personally believe that anything run by a shell script is
    an issue in regards to performance, and anything you exec multiple
    separate copies of is an issue in regards to memory overhead.  A system
    running a large number of JAIL'd environments will wind up with a larger
    number of swap-managed dirty pages.

    But, all this aside, the reason I am decidedly against a dynamic /bin is
    simply one of system recovery and safety.  I've blown up /usr so many 
    times over the years that had /bin and /sbin been dynamic I would have 
    been in real trouble on many occassions.

    If I recall correctly, some people have proposed and/or implemented some
    sort of emergency fall back or safety bin in 5.x to make up for this
    issue.  I would humbly submit that this simply acknowledges that a dynamic
    /bin and /sbin is a bad idea in the first place.

    I do not intend to make /bin or /sbin dynamic in DragonFly by default.
    I don't mind adding support for those people who want it, but I am not
    going to make it the default.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>