by homeworld.cygnus.com with SMTP; 26 Nov 1998 03:30:14 -0000
Date: Wed, 25 Nov 1998 19:38:53 -0800 (PST)
From: "J. Joseph Max Katz" <jkatz@cpio.net>
To: netbsd-advocacy@NetBSD.ORG,
  FreeBSD advocacy list <FreeBSD-advocacy@FreeBSD.org>, advocacy@openbsd.org
cc: jkatz@cpio.net
Subject: Re: Merging Net/Free/Open-BSD together against Linux
In-Reply-To: <19981126123721.N67961@freebie.lemis.com>
Message-ID: <Pine.NEB.4.02.9811251836580.21114-100000@corinne>
Organization: CPIO Networks
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Great, now I'm adding my $.01.

In the past this has been considered flame bait, but I've now
seen that all three communities won't slam each other at the
first opportunity. Way to go, guys (and gals!)

As a sometimes-user of the various distributions at various
points in time, each OS has its own niche and its own benefits.
Each OS productively borrows from one another-- NetBSD applies 
some of the OpenBSD security patches, OpenBSD takes the ASM IP 
Checksumming from FreeBSD, FreeBSD is now multi-platform. One
day OpenBSD (or NetBSD) will integrate the FreeBSD ARM port, 
OpenBSD will add more utilities to its basic distribution
(based on adding lynx and Apache you can tell it is heading
that way.) Sooner or later the BSDs will have more in common
than they do different.

Any secton in the following starting out with "IMHO" is not flame
bait, but my opinion. Send me PRIVATE mails blasting me on those if
you don't like what I say. I'm speaking for MYSELF, not for any project.

I see exactly four BIG problems with any merging--
1: The technical aspect--  (off the top of my head)
  o messaging all device drivers to one format for this new "mega" 'vmunux'
	This will be the greatest strength gained-- a great collective pool
	which will ensure BSD for generations :)
 	. IMHO-- we need to make as many of these drivers as machine 
	independant as possible. Even if the gscbus is only found on
	PA-RISC machines, we should be able to compile it onto an i386
	kernel if we really, really want to.
  o making sure all syscalls/libaries are backwards compatible with 
	the current setups on all systems. ("foo" on FreeBSD/i386 should
	run the same on this new kernel as it used to.)
  o distribution layout. We all nitpick. OpenBSD follows the decree in the
	BSD Net/2 README to the letter. FreeBSD, if I remember from 
	experience correctly, is slightly different. I can't speak for
	NetBSD.
	. IMHO-- I prefer the Net/2 decree out of anything else I've seen. If
	folks have something better, please step forward
  o IMHO re-entrent kernel. It's debateable, but if we're going to merge the
 	 codebase we should do this. This will make SMP work correctly on
	 all architectures. We could also make SMP work across the board,
	 and make it as MI as possible.

2: The licensing aspect--
  o (Let me annotate this by saying that I'm not an expert on what each
	project is doing or not doing) I think FreeBSD and OpenBSD have 
	pretty similar licensing schemes as of late (BSD +notification of
	other code.) I know NetBSD has some funky licensing in the compiler
	tool chain of its alpha port, and also (I think) in some of the
	machine dependant code. We'd need some folks to clear this up.

3: Packaging/installation--
  o IMHO We need a solid packaging system. Someone on misc@openbsd.org touted
	we should move to RPM. RPM is REDHAT Package Manager. We need our
	own. I propose ".bsz" -- gziped, tarred + header with info on 
	arhitecture + version + dependencies. Ever install a SparcLinux
	RPM onto a i386 RedHat system? :)
  o IMHO Release distributions. Base + extended utils + programming tools + X
	+ kernel source + full source. Easy to use install manager. I heard
	FreeBSD is paying someone to write a really, really, really good
	installer. How easily can this be ported to other architectures. On
	OpenBSD these days there is a SINGLE floppy-ramdisk install on most
	architectures. Even if the box doesn't support floppy, as long as it
	can boot from the drive it loads the ramdisk and you can do the
	install.
  o Release schedules
	o At the last FreeBSD user group meeting was at, jkh admitted to
	being behind its deadlines. (This was almost a year ago.)
	o OpenBSD (like clockwork, ready or not) makes a release every
	six months and only has one version level (2.x, 2.y, etc.) 
	o NetBSD I haven't researched yet. I do know it is different from
	both of the above.
	o IMHO we need to forge ahead and commit to release dates and release
	regardless. We can have major and minor releases-- we make a snapshot
	release every 6 months, but if we have good stuff going we make a 
	big release (like FreeBSD's 3.0.)

4: Code review--
	o ego 'r us.
	o Each group has its own "core" group with its own level of "trust".
	o There are no real "documented" rules on how to get CVS commit 
	access with any group other than the unwritten "you code good and
	often, you in."
	o We're dealing with groups that have splintered because they 
	couldn't agree on this stuff (among quite a few other things.)
	o Security. As a security guy and OpenBSD guy as of late we need to
	constantly audit code-- no new code can be thrown in the tree if it
	hasn't been looked at. I think Net/Free feel the same way, but I
	don't know their internal auditing process.
	o IMHO I'm not a code review guy-- I don't know WHAT we should do
	with this.

If this ever happens, it will be a huge undertaking. If all the "ringleaders"
of the *BSD projects lost their egos, joined in a big circle and hugged and
said "let's merge" there is no way in hell they'd have the man/womanpower to
pull it off and continue the current development.

We'd need a leader to lead the leaders if you get my drift. It won't be
easy.

Jonathan Katz -- jkatz@cpio.net. -- CEO CPIO Networks
-- http://www.cpio.net ---- http://www.openbsd.org --
"You know, Picabo Street is now a doctor. They named the
Intensive Care Unit after her. It's now the 'Picabo ICU'"