Re: Offering my assistance for Debian/BSD port (we Re: BSD vs GPL Flamewar (was Re: Debian FreeBSD))
On Sun, 2 May 1999, Darren O. Benham wrote:
# This is just a start. Since it looks like there really is going to be an
# interest, debian-bsd@lists.debian.org has been created...
Yes and I am now subscribed. :) Note: what follows are
suggestions only and in some spots borders on rambling so
please bear with me.
# The first thing I've been struggling with is deciding just where to draw
# the line. Should we try to use GNU glibc or should we use BSD's libc?
I'm still not quite sure what the Debian/BSD charter entails
but from what I've seen I gather it is to have a *BSD
kernel with a Debian userland. So it all really depends on
whether you want what is left of the system to identify itself
as a *BSD or Debian/Linux system. I'd suggest you leave the BSD
libc in initially. The biggest thing missing in BSD's libc is
getopt_long which is easily attainable from any number of GNU
programs. There are other SysV-related things, but these
almost always handled properly by GNU configure and friends.
It might help me get a grasp on how I can best help if you were
to briefly list the things you would like to see in Debian/BSD.
Debian's package system is a given. Keep in mind that FreeBSD
has in the neighborhood of 2500 ports of third party software,
many written specifically for Linux for which the work of getting
it run under FreeBSD has already been done. Also many of these
are apart of the default userland on */Linux distributions. You
could perhaps leverage some of that work.
# If we use glibc, are we going to have a problem with running a "commercial"
# or other package that was prepared for *BSD?
Can't say for sure, but I'll fathom a guess and say yes, since
that commercial software might use (mis)features specific to
BSD. If you're really up for it you could provide *BSD
"emulation" [1] similar to the Linux emulation that is already
there in *BSD and ditch all of the BSD personality traits for
all but closed-source software.
# What *is* the compatiblity of the various flavor's of *BSD now? (Net, Open
# and Free... and?)
To the best of my knowledge the versions of BSD are as you
mentioned plus BSDI, and PicoBSD. Here's how they shake out.
BSDI: the commercial ~equivalent of FreeBSD.
PicoBSD: special FreeBSD configurations tuned to work from a
single floppy. All of them built and maintained in the same
CVS tree, by the same people as the rest of FreeBSD.
FreeBSD: Their claim to fame is Intel support and SMP. They
have a pretty good Alpha port, and a budding Sparc and MIPS
port. They are the largest of the offerings, with the most
developers, users, ports, etc. The original FreeBSD team were
those that were on one side of the Bill Joy argument. [2]
NetBSD: They run on anything and if they don't someone is surely
working on it. They don't have SMP for any arch. This is the
group of people on the other side of the Bill Joy argument.
OpenBSD: The result of a huge fight in the NetBSD community
that resulted in a fork of developers. The code is nearly
identical to NetBSD except with alot of security-related fixes.
So back to your question, all of them share code and binaries.
For instance, FreeBSD's Alpha port came from NetBSD. FreeBSD
made enhancements that eventually made it back into NetBSD.
NetBSD took FreeBSD's ports tree and in exchange taught FreeBSD
how to handle different archs in the same tree. Bottom line
outside the kernel, the userlands all have the same look and
feel. What works on one will work equally well on another.
On closer inspection, you will notice that some of the
implementations are different but the end result is nearly always
identical to the untrained eye. Very similar to what you see in
Linux today except that Linux distributions all have the same
kernel (possibly with distribution-specific tweaks to turn on
SMP by default for instance) and nearly identical userlands.
-steve
[1] It is not really emulation in the true sense of the word.
[2] From what I gather this was over whether they should focus
efforts on the i386 port or go for the whole enchilada.
Reply to: