Re: [tlug] BSD and Linux (was:Linux and Windows {2k|Xp|Vista} Comparison)

[<stephen@example.com>]

Scott Robbins writes:
 > That's interesting.  From my more BSD-centric perspective the opposite
 > seems true.  Linux seems more fragmented to me. 

I would suppose that's true, today, especially in the workstation-aday
world.  I suspect you'd find a somewhat different story in embedded,
where IIRC there are now about two dozen companies purveying NetBSD.

But I was referring to the situation in BSD a little over a decade
ago, not trying to compare BSD vs. Linux at a given time.

 > On the other hand, there will be other updates that involve the
 > entire rebuilding of world.

Hrm.  I still wonder what would trigger that.

 > In that case, one has to rebuild the entire world before rebuilding the
 > kernel.  After doing that, the patched kernel has always successfully
 > built for me. 

I doubt you *have to*, in some theoretical sense.  But I'll concede
that if you remember doing that more than once, but less than 10
times, it's probably a lot easier to just rebuild world when the
kernel build chokes than to learn enough to build only the tools you
need to rebuild.

 > See above.  The answer is often, though not always, yes.  (Of course,
 > the recent Gnome upgrade, which has nothing to do with either kernel or
 > a very basic system, was a pain for the BSD folks as well.

Oh, everybody I know from the BSD world dislikes GNOME for precisely
that reason.  It's just damn hard to build from sources for an
amateur; you really need to follow somebody's distro, somebody who is
careful about pinning various libraries to stable versions.
Apparently KDE is much better in that respect, but it has its own
risks and other disadvantages.

 > This happens with FreeBSD as well.  Some upgrades break other things.
 > In practice, these are ~usually~ quickly fixed.   (Perhaps because of
 > that integration?)  :)  

This is generally true with Linuces, too.  But it's a distro-level
thing, not a kernel-flavor issue.  I think that one thing (as I
alluded to above re NetBSD and embedded) is that it's much easier for
a *BSD to go proprietary.  I suspect this means that there's more
reason for people doing open, non-commercial work to stick with one
mainline distro (viewing {Net,Free,Open}BSD from the organizational
viewpoint as distros rather than technically as different kernels).
It's hard to fork a fork in that situation.  In the case of Linux,
though, people tend to fork off different free distros, which then
generate further forks.

 > Like many BSD users without much knowledge of internals I tend to glibly
 > (as opposed to glibcly---sorry, couldn't resist) say, "Well, the
 > userland and kernel are more tightly integrated" without really
 > considering what I'm saying. 

Yeah, well, not following core closely in any BSD, I'm not really
sure, either.  But between looking at the design of NetBSD and the
comments that BSDers like Chris Sekiya have made, my feeling is that
the BSDs tend to be built on a consensus about layering and defined
interfaces (which is, for example, a clear factor in the famous
portability of NetBSD across processors).  The kernel VFS interface
code in the Coda distributed file system is cleaner in the BSDs, too.

So from a technical standpoint kernel and userland are presumably less
integrated, being separated by a well-marked API.  While from an
organizational standpoint, they're more integrated, because the kernel
people and the userland people have to interact actively to define the
API.