On May 11,  4:15am, Greywolf wrote:
} [Thus spake Jason Thorpe ("JT: ") Yesterday...]
} JT: On Jan 22, 2005, at 3:37 PM, Greywolf wrote:
} JT:
} JT: > You can do that on your box.  I happen to like systems that don't
} JT: > have quite so many single points of failure.  If you wish to address
} JT: > things and call them "nonsense", I point you to /lib, a dynamically
} JT: > linked
} JT: > /sbin/init, and the whole notion of /rescue even being necessary.
} JT:
} JT: Of course, I don't consider /rescue to be necessary (on production
} JT: systems; on development systems that one expects to break when testing
} JT: new code, sure, it can be useful there...).
} 
} Wrong-o.  /rescue -- or a rescuesque CD -- is mandatory at this point for
} anything running with a dynamically linked root fs.

     Technically, it isn't required.  Of course, you do need to have
some way of recovering from a catastrophic failure.

} JT: And, if you want to talk about single points of failure, I'll refer you
} JT: to /netbsd.
} 
} Yes, but if the (presumably new) kernel dies, you can reboot from an
} older version (you DO have an older version, also presumably) by

     Fine, if you don't like that one then how about losing/corrupting
/sbin/init or /bin/sh (regardless of whether they are statically or
dynamically linked).  The point being that there are many possible
single points of failure.  Although dynamically linking the root does
add to the number of possible single points of failure it does not make
the problem significantly worse.

} specifying at boot time.  You cannot do this with the libraries, and
} certainly not one-by-one.  Hence the redundancy provided by /rescue
} which is not always necessary.

     /rescue is a convenience feature, nothing more.

} JT: If you want to prevent your shared libraries from accidentally being
} JT: deleted on a production system, then for goodness sake, chflags them
} JT: (and all other critical "read-only" files) to be immutable (it would be
} JT: pretty cool to have a "harden" option in the install for this, and
} JT: appropriate optional clauses in the system mtree spec).
} 
} Indeed, it would, but you're sidestepping the original problem, which is
} that in addition to the fact that I don't like the multiple points of
} catastrophic failure in this scheme (please take into account that the
} more places which are exposed to hardware error, for example, the greater
} the likelihood you will get nailed), there is really absolutely nothing
} wrong with having one's root utilities statically linked, ready to go,
} without all the other overhead associated with the current state of
} events.

     Maybe people would like to see messages from their shell in their
native language.  Apparently doing proper and complete
internationalisation will require dynamic linking.

} JT: > I'm not against what you want to do for yourself, but please don't cut
} JT: > my rope for me.
} JT:
} JT: As soon as you step up and offer (and follow through) to maintain all
} JT: aspects of statically linking the NetBSD universe, then maybe I could
} JT: take this argument seriously.
} 
} Our goals are to run as efficiently as possible on multiple platforms,
} last I looked.  What did I miss?  What is the problem with maintaining

     This is only one goal.  You missed goals about interoperability,
completeness, and conforming to open systems standards (PAM is a
standard put out by the same people that put out the Single UNIX
Specification, not to mention being the current holders of the UNIX
trademark; whereas, BSD Auth is a proprietary scheme).

} a statically linkable universe?  To my eyes, it's another pass on building
} the libraries so that most versions are present.  All I'm getting here is
} "Well, most modern machines are fast enough, so what does it matter?"

     It's called flexibility and of course, supplying the services
expected in a modern OS.  Just about every other UNIX variant already
has PAM and third party apps rely on this so that they don't have to
deal with figuring out a myriad authentication schemes.  Even basic
UNIX authentication can be complicated on some systems since you might
have to use getspnam() to get a shadow password entry in order to get
the encrypted password, or you might have to use a special variant of
the crypt() function (i.e. on Ultrix).

} I'm not asking you to build a static anything _for me_.  I am asking
} that you do not hinder or prevent _me_ from doing so _for myself_.

     I doubt that people are going to go out of their way to hinder
you; however, they're not going to go out of their way to make it easy
for you either.

} And the community I joined here nigh 10 years ago was once one that
} would truly weigh progress and not just push things "because it is
} in vogue".  (That didn't happen until a whole four years later).

     Things aren't pushed simply because they are in vogue, they are
pushed because they are needed.

} JT: But until then, all I'm hearing from you
} JT: (and all the other people who irrationally fear an all-dynamic
} JT: universe) is an unreasonable demand to increase software maintenance
} JT: and development costs in a way that impedes the progress that the
} JT: NetBSD Project needs to make in order to stay relevant in the OS world.
} 
} NetBSD has already lost the race to "stay relevant", long ago. In the
} eyes of a few people it is sufficiently stable for operations, but its
} progress is totally impeded by the legions that flock to flood the
} niche that Linux/RHEL began to dig out a LONG time ago.

     By this token, so has every other UNIX variant including all the
commercial ones.  So why does Sun bother to continue to improve Solaris
(which by the way beats the crap out of Linux)?  Personally, I just
don't buy the above.  However, if NetBSD were to ignore the services
expected of a modern OS, then it would become irrelevant.

} What we are doing right now with the way things are going amounts to
} nothing more than technological masturbation.  If we want to provide
} ANYTHING worth noting, we need to do some serious innovation.  But,

     You mean like being the first open source OS to have USB support;
you mean like our VM; you mean like bus_dma; you mean like being able
to use the same device driver on any platform that has a given piece
of hardware regardless of bus type, processor endianness, word length,
etc., ...?

} of course, this being a volunteer project, all we can seem to do is
} follow and pray we don't get steamrolled.  Yet.

     The rest of this paragraph is such crap that it really doesn't
deserve a response.

}-- End of excerpt from Greywolf