Date: Tue, 18 Mar 1997 10:46:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni) Cc: terry@lambert.org, jb@cimlogic.com.au, srn@flibble.psrg.cs.usyd.edu.au, freebsd-platforms@freebsd.org Subject: Re: To share or not share ? (was: Someone working on a SPARC version?) Message-ID: <199703181746.KAA09797@phaeton.artisoft.com> In-Reply-To: <332E4DC0.6455@fps.biblos.unal.edu.co> from "Pedro Giffuni" at Mar 18, 97 00:09:36 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > NetBSD doesn't want our ports tree > > > > > > > > Unlikely... what benefit could they perceive in this? > > > > > > I don't know why, perhaps they like building their things the old way > > > (that is not too different), anyway if they'd wanted it, they could have > > > adopted it long ago, like OpenBSD did. > > > > Ports tree; not build tree... > > Is this the typical "if I can't beat him confuse him" strategy? I've > been saying ports tree from the start. No. You are saying "ports tree". You *should* be saying "build tree". That a piece of user space code is part of the "ports tree" or that it is part of the "base distribution" is irrelevant. You keep trying to draw a distinction between the two, and that's an artificial distinction of build process that you just can't reasonably make. We have the build process for user space which *includes* the build process for what we call "ports". > > The VM, as John Dyson has pointed out in the past, is not irretrievably > > architecture specific. I don't believe there is a technical issue at > > all... I have had FreeBSD's VM code working on Alpha and, more recently, > > PPC hardware, with only minor changes. > > I have also heard that, it is not 386 specific, but rather "FreeBSD > specific", you're right, but I haven't heard of anyone using FreeBSD's > VM under NetBSD (did you?). Yes; I have a tape with a DEC Alpha NetBSD with Jeffrey Hsu's patches to make it work on the 21066/21066A based PCI machines, pre the NetBSD release that could do it, including my FS changes and an older version of the FreeBSD console code, PCAudio driver, and John's VM system. It's on tape because the machines Jeffrey Hsu and I were using for the FreeBSD port were loaners, and had to go back. > > My challenge can be restated as: > > > > "provide conclusive technical arguments pro divergence" > > > > I maintain that there are no good technical reasons for divergence, > > only political ones. > > I agree with you, please don't asume things I haven't said, specially if > you can't see me while we are communicating. You wanted clarification; this is just clarification. I'm not trying to jump down your throat. > I say it's just the way the world works (I don't like it either): it's > faster for both parties to implement what they lack, than to convince > the two teams to unify, in fact we now have three teams! Negotiations are not what make a unification unlikely. If you were here fore the last attempt, or if the list archives archived that discussion, it's possible to find out what the sticking points were. Mostly they were control issues, not "failure to implement desired features" issues. > Of course, it would be very stupid from myself not to admit that we need > to modify our tree following the NetBSD example (BTW, IMO, the best time > to do it is ASAP, can someone illustrate me on what are the clear > objectives behing 3.0-current ?). But we should protect our evolved code > (LKMs and devices) from being swapped because another OS has a prettier > structure than ours. You are talking about a large scale code merge and a restructuring of the build tree. I agree totally, 100%. Restructuring the build tree must occur before the code merge, and therein lies a lot of the problems (political ones) with the idea. Many FreeBSD'er's actively oppose a tree restructuring, siting tool incapacity (it's possible to maintain CVS history if you are willing to use "sed") and other bogus arguments. FreeBSD bystanders: notice I said *code* merge, not *group* merge; there may or may not be a loss of distinctive reasons to maintain seperate groups following a code merge; who cares? ...it's irrelevant to what needs to be done. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703181746.KAA09797>