Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Jun 2002 00:32:33 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        Doug Barton <DougB@FreeBSD.org>, "Jacques A. Vidrine" <nectar@FreeBSD.org>, freebsd-arch@FreeBSD.org
Subject:   Re: RFC: remove xten from the base system?
Message-ID:  <3D084A91.FFD1B47@mindspring.com>
References:  <Pine.NEB.3.96L.1020613030718.43059A-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
> On Wed, 12 Jun 2002, Doug Barton wrote:
> > 1. Some people actually use it.
> > 2. The code has kernel bits (thus it's hard to port, not sure how true
> > this is).
> > 3. It's easier to keep in synch if it's in the tree, since people will see
> > it get broken.
> 
> The model used for Coda is to store the kernel module in the base tree,
> but keep the userland stuff in a port.  This allows the kernel module to
> track changes in the base system kernel closely, removing that maintenance
> issue and keeping it in synch, but doesn't keep the stuff in the base
> system that doesn't really fit well.

Coda has a project.
Perl has a project.
TCL has a project.

Xten does not have a project.

This is effectively saying "Get a project to support you, because we
are about to throw you in the ocean".

Xten is significantly different that Perl and TCL.  It is sufficiently
different from Coda -- the Coda code in FreeBSD is a port of the Coda
project software to FreeBSD, whereas the Xten code in FreeBSD did not
come from an external source.

Xten is most analogous to the video and sound drivers in FreeBSD; the
majority of people using FreeBSD on rack mounts would be just as happy
is, for example, "vidcontrol" became a port.


I think this is really about two things:

1)	The Perl advocates trying to punish everyone for getting rid
	of Perl in the base system, even though FreeBSD's Perl support
	has actually improved, since the system Perl left out important
	(to the Perl people) features.

2)	People wanting the FreeBSD base to be broken into optional
	subsets, and attacking a weak target, just like a company
	filing a lawsuit against the littlest offender in order to
	get case law on their side (e.g. they failed with Sendmail,
	which was too big, so they are trying to get the camel's
	nose into the tent in another way).

3)	People who want to make changes radical enough to break things,
	but who are too lazy to clean up the mess once they are done.

If it's mostly #1, then the Perl people should continue the fight
that they started, rather than showing sour grapes simply because
they didn't refuse to yield, in the end.

If it's mostly #2, then the place to work towards that is not by
pushing everything else out of FreeBSD, until it's nothing more
than a kernel, just like Linux.  If they want this, they can either
go over to Linux, or they can contribute code to the work that Eric
Melville was doing.

If it's mostly #3, well, it's really insane to let one person end
up in control of the entire project just because they have the
biggest chainsaw.  That's not what FreeBSD is supposed to be about.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D084A91.FFD1B47>