From owner-freebsd-arch Thu Jun 13 0:33:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 4616A37B43D; Thu, 13 Jun 2002 00:33:14 -0700 (PDT) Received: from pool0150.cvx22-bradley.dialup.earthlink.net ([209.179.198.150] helo=mindspring.com) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17IP6W-0002cY-00; Thu, 13 Jun 2002 00:33:13 -0700 Message-ID: <3D084A91.FFD1B47@mindspring.com> Date: Thu, 13 Jun 2002 00:32:33 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Doug Barton , "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Subject: Re: RFC: remove xten from the base system? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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