[ On Wednesday, August 28, 2002 at 15:39:14 (-0400), David Maxwell wrote: ]
> Subject: Re: HEADS UP: migration to fully dynamic linked "base" system
>
> On Wed, Aug 28, 2002 at 02:50:05PM -0400, Greg A. Woods wrote:
> > 
> > [ On Tuesday, August 27, 2002 at 23:47:10 (-0400), David Maxwell wrote: ]
> > > 
> > > Currently, /sbin and /bin programs have to be 'special', and have to be
> > > maintained that way. After this change, everything that the system runs
> > > in normal operation can use the same subsystems, libraries, and
> > > resources.
> > 
> > There's nothing "special" about /sbin and /bin programs other than they
> > are compiled and linked as static binaries and they don't depend on
> 
> Paraphrased: There's nothing special about X, except that they're
> treated differently than every other binary on the system.

That's bad analogy or something.

It's still possible to statically link every other binary on the system.
I know this as I'm typing on such a system right now.  Static linked
binaries on NetBSD are not in any way "special" and currently
maintaining static linked programs is less "special" than maintaining
dynamic linked ones.  So, one could turn it around and say that the
programs in /usr/bin and /usr/sbin are the "special" ones -- they're the
ones that have more (any!) dependencies and more ways to break than
static linked programs, that's for sure.

(For sure Unix sys-admins are getting better, in general, at avoiding
problems with shared libraries and dynamically loaded extension modules,
but the best way to avoid such problems is still to avoid shared
libraries and other dynamic loading in the first place!)

However the way a program's linked doesn't necessarily make it special,
at least not until the day you can't get at some feature because that
feature was designed purposefully to _only_ work when the program is
dynamically linked (or at least capable of dynamically loading code)
(more about the limits inherent in such a design below too).

In the new regime only /rescue is "different", and it's also somewhat
"special" as proposed since it'll be one massive binary, IIUC.  That
could make it a lot more difficult for _some_ people to patch one
existing component, though happily it doesn't yet affect anyone's
ability to add new programs to the directory in the obvious way.

> Jason already said that isn't the case, so are you throwing alcohol on
> the flames just for fun? (2)

Others, including now Jason it seems, have been fanning the flames far
more-so by threatening lack of ongoing first-rate support for
static-linked systems.  I'm trying to make sure that doesn't happen to
NetBSD.  If I even just feared it would happen anyway, and if I could
amass the resources to fork the code, I would fork the code.  However I
fear forking the code though (it's a _lot_ of work to do properly, never
mind the politics), and I'd rather see NetBSD retain the option of fully
supporting a fully static-linked system, and I don't think I'm anywhere
near alone in that wish.  I'm just trying to be very clear about it now
before effort would be wasted by having to rebuild such support to the
level where it is today.

> NetBSD 'ls' is more complex and special than 4.4BSD's 'ls'. That's a
> comment, but not an argument. It will continue to be meaningless as
> anything but a comment unless someone causally proves that this
> negatively impacts reliability, or some other goal of the project.

Look, I wasn't the one who tried to use complexity as an argument
against keeping at least the programs in /bin and /sbin static linked.
I thought I tried to say that static-linking so was less complexity
(which it clearly is) and thus I tried to invalidate your argument along
those lines.  I also thought I showed quite well how dynamic-linked
copies could be provided at almost zero added complexity.

> This addresses the desire for dlopen() to support locale, but not for
> nsswitch and auth reasons.

I'm on alone in saying that I do not ever want to have to use dlopen()
for authentication and authorization.

>  As far as the locale part, I could stand to
> hear well reasoned arguments for /usr/i18n/, but if they're only for the
> purpose of avoiding /sbin and /bin going dynamic, then don't bother for
> my sake.

The idea is the same as Sun saying that if you want XPG4 compliant
behaviour from some set of tools then you go to /usr/xpg4/bin/ to find
those compliant tools.  So if a user wants tools that are fully
localized then they only have to "localize" their PATH variable first.

In my travels working around the world I've found that system
administrators and operators aren't anywhere nearly so worried about
system programs muttering dates and stuff in "western" formats.  (They
can usually already get system errors in the language of their choice.)
The biggest issues are with localization for end user applications.
People want their databases to sort records in their "proper" way, not
the proscribed Western way, and their word processors to insert dates
and times in their local way, not the Western way (and to heck with ISO
standards -- they're just Western standards! :-).  I have a trememdous
appreciation for these desires -- I have seen first-hand and multiple
times the positive affect they can have on people who've been frustrated
with English-only support on their computing platforms.

In the mean time there's this whole lunatic side of localization in the
"traditional" unix way too.  Sane systems (commercial and research) have
full support for handling of truly international data and documents --
simultaneous use of multiple languages and formats.  Having system error
messages appear in the user's local language are one thing, but it's
going to be too restrictive for many people to lock their applications
into handling one language at a time -- they will often want many at a
time, and there's no real reason why they can't have them all
simultaneously (eg. as in Plan 9, or emacs with MULE).  If I want to
have an application display local time and date in the locally approved
format then why can't I also have an application that displays in all
locally approved formats simultaneously as in this lame example
cut&pasted from my emacs diary window?

	Thursday, August 29, 2002
	=========================
	Sunrise 06:39 (EDT), sunset 19:58 (EDT) at 43.8N, 79.4W (13:18 hours daylight)
	Day 241 of 2002; 124 days remaining in the year
	ISO date: Day 4 of week 35 of 2002
	Chinese date: Cycle 78, year 19 (Ren-Wu), month 7 (Wu-Shen), day 21 (Ji-Si)
	French Revolutionary date: 12 Fructidor an 210 de la Révolution
	Hebrew date (until sunset): Elul 21, 5762
	Islamic date (until sunset): Jumada II 20, 1423
	Mayan date: Long count = 12.19.9.9.13; tzolkin = 7 Ben; haab = 6 Mol
	Coptic date: Misra 23, 1718
	Ethiopic date: Nahas 23, 1994
	Persian date: Sahrivar 7, 1381

(it's far more lame than it could be if the calendar.el stuff were to
make full use of MULE and thus be able to show all the dates in exactly
their regional form, complete with any non-ISO8859 character glyphs, etc.)

That means my application would need concurrent access to _all_ the
locale code _all_ the time!  Dynamic object loading may explicitly
prevent that unless it's designed very very carefully -- i.e. designed
to work in a static-linked environment, but optionally capable of
dynamic loading object modules which have not been static-linked.

As for avoiding an all-dynamic /bin etc., well that's part of the
reason, and of course that's to avoid the performance issues (even
pre-binding and pre-mapping shared library images won't make those
issues disappear completely).  I think another good reason though is to
entirely avoid having to have this /rescue thing.

> Sure they are, but building and testing large parts of the source tree
> on as many architectures as NetBSD supports is problematic.

Building, no, not really, not for 1.6 and beyond as I understand it.

Testing, perhaps, though even that's a solvable problem.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>