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

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

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.

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

Well, if most modern machines are fast enough, what's another pass
on the libs to make it work?  Besides, they're my damn cycles I'm
burning anyway, and if it works, I'm SO okay with that, considering
I'm not just building the world for one architecture, but I'm also
building for a slower one in addition.  One that benefits from statically-
linked binaries.  So I posit that equating "statically linked" with
"nonsense" is an assertion botch.

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

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

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.

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,
of course, this being a volunteer project, all we can seem to do is
follow and pray we don't get steamrolled.  Yet.

				--*greywolf;
--
Are you being infected by a UNIX virus?  If you're receiving OS shipments
from your vendor, you may be subjecting your computer to the worst virus
in history: SVR4.  There is a cure for this virus:  upgrade to NetBSD
(now running on a platform near you).