Re: tlug: FreeBSD News issue 2

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "jb" == Jonathan Byrne <jpmag@example.com> writes:

    jb> From: craigoda@example.com <craigoda@example.com>

    >> The community that produced Linux supports a wide variety of
    >> distributions.  I think that the main unresolved issue that
    >> prevents Linux from being used in circumstances where it is the
    >> right choice in a wider range of areas is the danger of Linux
    >> splintering.

This may be, but ...

    jb> <SNIP>

    >> a single filestructure.  When Linux resolves the issue of
    >> different filestructures, it will be poised to dominate over NT
    >> in the enterprise.

This is certainly not true.  Win95 and NT (up to 3.5, anyway) have NO
standards for file hierarchies.  It is very very hard to find
something unless you already know exactly where to look for it.  Of
course, that's exactly what Bill Gates has in mind....

    jb> However, the fact that there is one FreeBSD with one file
    jb> structure is a definite strength.  The wide variety of Linux
    jb> distributions have been a great strength for Linux in terms of
    jb> innovation, raising its profile, and rapidly popularizing it.
    jb> The different distributions are a core part of the cooperative
    jb> development model that worked so well to bring Linux this far.

Different distributions are not the reason for the variety of file
systems.  Almost all the distributions claim FSSTND (or FHS)
conformance.  There are slight differences among the distributions in
things like the handling of init scripts, but these are very minor.

The reason for the lack of effective standardization is the variety of 
applications.  Localization/internationalization/multilingualization
is one area where we just don't know yet.  I've burned Scott Stone's
ears about the /usr/jp and /usr/ml hierarchies in TurboLinux, but it's 
a plausible approach to the problem of keeping both tetex and pTeX on
the same Linux system.  I don't know how to do it right; I have an
intuitive dislike for /usr/jp is all.  I may go back to Debian
permanently after the beta test is over, partly because of this
personal taste.  But I'm glad somebody's trying it.

Right now I've blown off my /usr/local hierarchy; I just don't have
one at all.  Instead, I'm using something that Barry Warsaw (of Python 
and Emacs cc-mode.el fame) invented, the "depot architecture."  This
makes in convenient for me to keep a lot of junk I can't afford to
have on a small disk on my roadwarrior notebook (eg, source code and
multiple binaries of XEmacs for comparison testing) on my Sparc, and
yet all of my machines have the same PATH and so on.

This is quite hard to do with a /usr/local or /usr/share kind of
architecture.  But I don't know that this is perfect.  I don't think
we're ready to standardize distributed file systems.  Although
single-host systems have the FSSTND/FHS to go by, it doesn't help much 
(and in a few places gets in the way of) distributed file systems.

    jb> Another area that would be nice to standardize would be
    jb> packages.  Not easy, I know, since there are Debian Adherents,
    jb> RPM adherents, and others.  But a single, unified packaging
    jb> system that included all of the best features of existing ones
    jb> (or alternatively, became a superset that could install *any*
    jb> package format) would really help Linux a lot.

The "alien" package does this quite well for Debian, and (I think)
reasonably well for RPM-based distributions (although I don't have
much experience in that direction), for standalone applications.

But this isn't good enough for the core distribution.  You can't mix
Debian kernel/module packages with RedHat networking utilities and
daemons and TurboLinux X.

    jb> A unified standard on what libraries to use, so that we
    jb> wouldn't get things like some distributions apparently going
    jb> to glibc before it was really ready for prime time (which
    jb> seems to have been the case with RH 5.0?) would also be
    jb> useful.

Tell Scott Stone about it.  I ragged on him about that too ... but
this was definitely customer-driven for TurboLinux, and I would guess
for RHL too.  And Debian, although it hasn't released a glibc system,
hasn't been releasing libc5 systems either.

But this is really why we can't have a single packaging system that
does everything.  It just wasn't known when glibc would be ready.
More important, it wasn't known exactly how glibc was going to screw
things up, and thus how it would affect dependencies.

    jb> A consortium forming standards for these things would give end
    jb> users confidence that anything for Linux would work on any
    jb> Linux distribution, while still leaving developers free to
    jb> innovate and compete on things like utilities, user
    jb> interfaces, etc.

    jb> No OS is perfect in this area.  There is a lot of MacOS
    jb> software that requires system 7.5 or higher to run, for
    jb> example.  Windows 95 and NT, and FreeBSD, probably have a few

FreeBSD is right up there with IRIX and HPUX and Win32 as a platform
that beta versions of XEmacs fail to build on on a regular basis.  I'm
not sure why it seems less stable than Linux in this one case.  It's
certainly very stable in other applications.

    jb> issues of their own, as well.  And Linux is certainly not
    jb> awful in this area.  But a solid base of standards common
    jb> among all distributions would be able to take Linux from being
    jb> good in this area to being the best in this area and leading
    jb> the industry.

And the day after that it will be fossilized and obsolete.  :-)

All of this stuff is treated by POSIX, in one way or another.  Some of 
it is practically defined by POSIX, others are hardly affected at
all.  One suspects that the difference is the degree of maturity in
the various subfields of OS design.

    jb> Ideally, such a consortium might expand to include Linus
    jb> Torvalds and kernel development?  Why?  Because if an IS
    jb> executive asks what will happen to FreeBSD kernel development
    jb> if the head of FreeBSD steps in front of a truck and is killed
    jb> tomorrow, there's a ready answer.

*BSD had a clear lead over Linux in terms of the kernel for several
years.  That's gone.  Partly that's gone because Bill Joy and a couple
of others couldn't agree on who was going to run the show.  There are
still BSD advocates, but neither Linux nor FreeBSD is the cutting edge
anymore.  If anybody has organization, it's GNU.  Anybody ever seen a
running HURD?  Well, if you mention "Linux System" without emphasizing
GNU over Linux, RMS is likely to stampede a HURD of GNUs all over you,
but other than that....

On the other hand, with Linux you got the bazaar in full swing.

    jb> I agree with Craig that splintering could be a danger for
    jb> Linux, and I think the time has come for the industry to take
    jb> steps to resolve areas where there is splintering, and to
    jb> prevent further splintering in the future.

I would say this is more likely to cause stagnation; there just isn't
that much energy for the kind of standardization effort you're talking
about.

For example, there's been a crying need for a real Japanese locale
database for 2 years.  But it's boring.  We finally look like there's
going to be something, but even TurboLinux doesn't really have it.

There's a danger that I won't be using Linux 2, 3 years down the road
if it all splinters.  But I wouldn't bet that the replacement is going 
to be FreeBSD.

Steve



--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: (?) July, 19:30 Tengu TokyoEkiMae 03-3275-3691
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp