VanLUG Email Archive
> On Sun, 30 Aug 1998, Kaz Kylheku wrote:
>
> > BSD doesn't have a zillion different distributions? That's a good one!
> > BSD has a zillion different organizations with many distributions each!
> >
> > Let's see, there is OpenBS, Net BSD, FreeBSD, BSD/OS... Then there
> > are operating systems that were derived from BSD code like SunOS,
> > ancient HP-UX, ...
>
> Currently there are three free variants of BSD out there: FreeBSD,
> NetBSD and OpenBSD. How many Linux distributions are there? Compare
> the two numbers. The Linux one is bigger. End of story.
I refuse to compare quantities when I'm not convinced that their
type is compatible.
You are saying that the difference between, say, Debian and Redhat is exactly
like the difference between, say, FreeBSD and OpenBSD. If this is the case,
than I accept the validity of the comparison. But smell a fallacy here,
arising from the realization that Debian and Redhat don't actually develop the
key components of the system but are packagers. They are based on the same
Linux kernel, libraries and other paraphernalia. Whereas FreeBSD and NetBSD
are distinct operating systems.
I think that it's not a bad thing that in Linux, the packagers and developers
are different teams. This is often the case in commercial software
organizations. Putting a distribution together is a large task, and not
everyone agrees about how it should be done. And not every type of distribution
is suited to every type of user.
Furthermore, people who work on things like libraries, device drivers or
portions of the kernel often don't have any interest in plodding through
the mundane routines of software that makes installation easier,
not to mention running a software distribution business.
Companies like Sun or Microsoft have centralized distributions. Not having
centralized distributions is yet another way in which Linux is different.
I've heard rumors that with one particular software vendor, installing
the latest working OS involves applying five hundred service packs to a
distribution of MS-DOS 3.3 which has led some VAR's to revolt and form their
own distributions to make things easier for the customers. :)
> If you insist on counting commerical OSes as well, BSDI is still
> alive, but the old HP/UX and SunOS are both dead. But then, are
I think that the commercial UNIX vendors did a lot of damage to BSD by picking
it up and dumping it. There comes to mind a rather unfair image of a bunch of
hungry hackers feeding on a bloodless, discarded husk. :)
I think it's cool that it continues to prosper, but it would be great
if the BSD camps could merge into a single item. Including BSDI.
> you going to count Solaris and new HP/UX in with the Linux camp
> because they're all System-V-like?
To say that something is ``System V like'' is not the same as saying that
something is ``derived from System V code'' or is ``a derivative work based on
System V release 4''.
Solaris is derived from this code. Linux supports (some of) the System V
programming interfaces (streams being a notable exception) but I can say with
near certainty that there isn't a shred of SVR4 code in it. Otherwise the
lawyers would have had a field day with Linux years ago, would they not?
> > You mean there aren't any proprietary operating systems that are based on
> > BSD code?
>
> Yes, there are. How does this make the BSD source base less open?
> I'd bet that there are changes to Linux kernels out there that are
> not distributed as well.
It is one thing to adapt Linux ``in house'' to particular requirements, and
another to redistribute the modified version without complying with the GPL.
Such redistribution is against the law.
If it's not distributed, it doesn't have to comply with the GPL which
is concerned with the conditions of redistribution. And such modified
versions don't affect anyone, so this argument is a strawman.
(Or this is a legal gray area at best: does in house distribution within one
company fall under the terms of license?)
> > What steps are the various BSD sects taking toward Unix98 compliance?
>
> All the BSDs have representatives on the committees, as far as I
> can tell. Unix98 is hardly a panacea, though since it covers only
> one CPU family (i386) and one word size (32 bits) last I checked.
Sun Microsystems sent a representative (Scott James?) to the ANSI C committee
which produced the 1989 standard. He might even have been a voting member. Yet
the language changes made by that group of people somehow never made it into
Sun's then flagship OS. Today, you can still find old installations of SunOS
4.1.3 with libraries that are far from conforming to C89: some functions, like
atexit or memmove,a re missing, others, like sprintf, have an incorrect
declaration, and others, like realloc, behave in a non-conforming manner. The
moral of the story: the presence of representatives at committees doesn't
necessarily imply a commitment to do any actual work.
My reason for mentioning Unix98 was that a big reason for the library upheavals
in the Linux world (which are being managed quite well, as far as I can tell)
are largely due to upheavals in the UNIX world. There are new API's to conform
to, such as POSIX 1003.1c threads. Threads are a new thing to UNIX and Linux
alike; adding threading support to an existing library is more than just
throwing in a few extra functions like pthread_create(). The addition of
threading has far-reaching impact on other parts of the library, whose
semantics are changed to accomodate threads. It suddently matters whether a
given function is thread-safe or whether or not it is an asynchronous
cancellation point.
The GNU/Linux world has taken the bull by the horns and produced a new library.
It's possible to use the new and old library simultaneously, thus applications
compiled and linked to use either one are both supported. This is no different
from the transition from a.out to ELF; in fact it is less drastic. The a.out
to ELF transition was managed very well; only those who converted an a.out
system to ELF by hand have any rememberance of pain! Rotten jump-table
based shared libs are a long forgotten hack. Sometimes a little fundamental
cleansing does a lot of good, especially when viewed retrospectivelly.
Now we can argue whether it would have been more appropriate to revamp the
existing library to produce a new version that is backward compatible
with existing applications. Maybe that it was not possible says something
about the quality of Linux software development, maybe it does not.
At times it does seem like the path toward the current state of Linux was
strewn by hacks, like those old jump-table shared libs. It seems that we have
gone through periods where the hacks have had to be shed, like various shells
in the lifetime of a crustacean. :)