Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.uoregon.edu!arclight.uoregon.edu!feed1.news.erols.com!uunet!in1.uu.net!news.new-york.net!news.put.com!main.put.com!le From: Louis Epstein <le@main.put.com> Subject: Re: FBSD Future... Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: usenet@news.put.com (The Root) Message-ID: <Pine.BSF.3.91.961011121248.28443A-100000@main.put.com> References: <Dz37x9.7vC@news2.new-york.net> <199610111548.JAA29164@trout.mt.sri.com> Mime-Version: 1.0 In-Reply-To: <199610111548.JAA29164@trout.mt.sri.com> X-Nntp-Posting-Host: main.put.com Date: Fri, 11 Oct 1996 12:30:21 GMT Lines: 92 On Fri, 11 Oct 1996, Nate Williams wrote: > In article <Dz37x9.7vC@news2.new-york.net>, Louis Epstein <le@put.com> wrote: > >Well,I see that the expected release of 2.2 has been pushed back from > >late summer '96 to first quarter '97,quite a jump,and I wonder what > >more there is to it past Walnut Creek's desire to keep the CDROMs > >semi-annual. > > It really has little to do with WC, and more to do with developer > burnout. The 2.X cycle has been very stressful given that that we've > been running two development branches for almost 2 years, so the > developers decided to give themselves a break and back off on the 2.2 > release. (Although, -current [pre-2.2] has been relatively stable as of > late, so it's looking pretty good.) Will the delay mean any added features that wouldn't have gotten in this year? > >I gather that 2.1.6 will be released on the net only,not on CDROM,so > >how would one handle an upgrade from 2.1?(No point in going to > >2.1.5 first if 2.1.6 is coming). > > What's this about 2.1.6? It's the first I've heard about it, and I'm > one of the developers. :) It's mentioned on the freebsd.org web pages..."A 2.1.6 release will probably occur on this branch some time in the next 2-3 months,just to clean up a last few remaining nits from 2.1.5". > >How long would I have to take my > >ISP down to go to 2.1.6,and get it in shape to honor the 9-12 character > >IDs enabled by a kernel recompile for my 2.1??And what would I actually > >gain by so doing? > > Upgrading to 2.1.5 will buy you stability and improved security. There > were some fairly significant bugs/holes that were fixed, plus as an ISP > you *really* want some of the BIND fixes that went into 2.1.5 dealing > with classless addressing which is becoming more prevalent. There are > also alot of cleanups done to the system, plus keeping fairly current > means that IFF you find a bug/security problem it's alot easier to > upgrade your sources from a more recent release than an older release. (Of course,this was the reason to wait for 2.1R rather than 2.0.5...) > Given that this a volunteer outfit, you'll probably find someone running > a recent release that can help you out vs. telling you to upgrade if you > have problems. > > As far as upgrading the sources to have longer ID's, I don't see what > it'll buy you IMHO, but I'm an old-timer who prefers short email/account > names. :) It'll buy me the ability to have someone used to being longusername@elsewhere.com not have to be lngusrnm@put.com. Since I have a number of long IDs in use already,I have to make sure they don't lose access in the upgrade.I enjoy having a very short ID(le@put.com) myself,but flexibility counts. > It took me about 4 hours to upgrade each system to 2.1.5 from 2.0, > although I could have done it much quicker if I wasn't so paranoid or I > tried to automate it more. > > >Which SNAPs of 2.2 will be on the CDROM for SNAP subscribers? > >501 was,626 wasn't,were 801 and 1006? > > I *think* 1006++ will be on a SNAP CD. Jordan fixed a couple bugs and > will probably re-roll the 1006 SNAP before putting it on CD. > > >For a got-to-stay-up business like an ISP,it might be better to wait > >for a 2.2.x after 2.2R gets its bug reports dealt with...I guess > >the first such release is at least 9 months off. > > I disagree completely. I have critical systems, and I upgraded every > one of them to 2.1.5 b/c of stability and security. 2.2 will contain > alot more 'experimental' stuff (even # release), and as such will > probably not be as stable as 2.1.5. You're misunderstanding me here...I'm saying that I would want the most mature release of the -stable branch,but would hold off on the 2.2.x branch until x is no longer 0 so that its stability is increased. > >(64-bit 3.x is presumably years away still). > > 64-bit is probably more like 6.x or something. Hmm,isn't SCO(which the non-commercial UNIXes are supposed to be years ahead of) already doing a 64-bit version? So what major enhancement would you think will precipitate renumbering from 2.x to 3.x?