VanLUG Email Archive
> You are saying that the difference between, say, Debian and Redhat is exactly
> like the difference between, say, FreeBSD and OpenBSD.
It's not an exact comparison, no. But it's a fairly similar comparison.
> 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.
One of the key components of Red Hat, from the user's point of
view, is the RPM system, which they have developed. Debian has a
completely different packaging system. Once you get to a command
line, they look pretty similar, and anyone who's used Red Hat will
have a pretty darn easy time with Debian. The same is true of
FreeBSD, NetBSD, and OpenBSD.
There are some pretty large differences in the kernel internals,
but these won't be noticable to the end user.
> 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.
Indeed. In fact, configuration management is the largest current
problem that Free OSes are dealing with in terms of software
engineering. At times, a different configuration is just as good
as having a completely different operating system. (As I've learned
to my dismay, I can compile MySQL `out of the box' without problems
on FreeBSD, NetBSD, and OpenBSD, but I can't compile it so easily
on all Linux systems.)
> 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.
They may not, but especially library workers have to have a big
hand in how you build distributions, or you can run into some nasty
compatability problems. Take a look at the upgrade to the stat()
system call in NetBSD 1.2 -> 1.3, or Solaris 2.4 -> 2.5, for an
example.
> I think that the commercial UNIX vendors did a lot of damage to BSD by picking
> it up and dumping it.
I don't think so. Many commerical vendors just took the code they
liked out of BSD. That's their perrogative, because it was their
OS. You appear to believe that Adding a few BSD-like features to
Digital Unix makes it a BSD system. That's not the case.
> 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.
I don't understand this. You seem to be claiming that diversity is
good in the Linux world, but bad in the BSD world, despite the fact
that there's more diveristy in the Linux world than in the BSD
world? What's going on?
> 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''.
So? How can the user tell the difference? He generally can't. Is
there any effective difference between, say, Sun's NIS and BSD's
NIS? No. So who cares which one you're using?
Just because someone derived some code from somewhere does not
place any obligation on him to merge with the place he derived code
from.
Keep in mind there's a fair amount of BSD code on that Linux box
in front of you.
> > 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.
Well, no, it's not against the law; it's breaking the license. It's
not even entirely certain that that license is enforcable; it's
never been tried in court.
Regardless, you never did answer the question: why is GPL'd software
more open, even though you can do less with it under the license?
> 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.
If a non-distributed modified version doesn't affect anyone, why
should a distributed modified version affect anyone? In both cases,
the effect on those who use the free software appears to be the
same.
> 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.
The `flagship OS' (I assume you're referring to SunOS 4.x) was
replaced a couple of years after that. That means they were probably
working on it at the time. Why on earth would they put several man
years into a product they knew they were about to discontinue?
> Today, you can still find old installations of SunOS
> 4.1.3 with libraries that are far from conforming to C89:
Indeed, I know of some PDP-11s still running Seventh Edition that
are far from conforming to C89 as well. I don't have a clue where
you're trying to go with this.
> ...the presence of representatives at committees doesn't
> necessarily imply a commitment to do any actual work.
Ah, I see. Well, you used a bad example: Solaris conforms pretty
well. In the end, though, I agree with you. The presence of NetBSD
folks on the committee does not imply NetBSD will be conformant
any more than the presence of Linux folks on the committee implies
Linux will be.
> 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.
And NetBSD has not been affected by this?
> 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.
No kidding. Of course, if you hadn't used rotten jump-table-based
shared libs in the first place, you wouldn't have had the problem. :-)
cjs
Curt Sampson
Info at http://www.portal.ca/
Internet Portal Services, Inc. Through infinite mist, software reverberates
Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.