From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:32:24 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB7416A41F; Sat, 17 Dec 2005 11:32:24 +0000 (GMT) (envelope-from shurd@sasktel.net) Received: from misav08.sasknet.sk.ca (misav08.sasknet.sk.ca [142.165.20.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E2B843D5E; Sat, 17 Dec 2005 11:32:23 +0000 (GMT) (envelope-from shurd@sasktel.net) Received: from bgmpomr2.sasknet.sk.ca ([142.165.72.23]) by misav08 with InterScan Messaging Security Suite; Sat, 17 Dec 2005 05:32:22 -0600 Received: from [192.168.0.193] ([142.165.59.202]) by bgmpomr2.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTPA id <0IRN005EC41W8A10@bgmpomr2.sasknet.sk.ca>; Sat, 17 Dec 2005 05:32:22 -0600 (CST) Date: Sat, 17 Dec 2005 05:32:20 -0600 From: Stephen Hurd In-reply-to: <43A27C32.6020501@samsco.org> To: Scott Long Message-id: <43A3F744.7040301@sasktel.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-ca, en-gb, en-us, en References: <43A266E5.3080103@samsco.org> <20051216082704.GA52634@thought.org> <43A27C32.6020501@samsco.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051108 X-Mailman-Approved-At: Sat, 17 Dec 2005 14:15:12 +0000 Cc: Gary Kline , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2005 11:32:25 -0000 > Security updates will be maintained for quite a while. However, it > takes manpower to test each proposed security change, so it's very hard > to justify doing them 'indefinitely'. The stated policy from the > security team is 2 years. So they will probably support 5.5 into > 2008, but I wanted to be conservative in my statement in case they > have different plans. It seems to me like FBSD may be pushing too much to a new major version. Although NBSD is stepping up the "-release" versions significantly, I feel that FBSD (and friends, but this is hardly the place for B&W about them) are/is moving a bit too quickly. While the SMP changes are nice and all (my main application server at home is a dual coppermine 1GHz), the tty (for example) seems to be getting more and more unstable as it goes on... this seems to a certain degree to be that features in -CURRENT are barely cooking let alone baking, and talk is already that 5.x is obsolete. Pushing off GIANT was a 5.x goal iirc, and making existing changes stable is a per-major goal (again, imho). It seems like the version numbers aren't actually meaningfull anymore. I mean... I'm used to a FBSD that would change majors when an API and/or ABI *needed* changing. It feels like it's happening 'cause it'd be "cool" to have a 7.x now. The FBSD pthread support for example has been better than Linux since libc_r... and it's only improved. But I can't actualy *rely* on anything specific working. A project I work on has had a THREADS_ACTUALLY_WORK flag available for Linux when they acually do (not yet, let's not talk about sigwait()) for the last few years. But I can't depend on a major version for strtold()... can't even depend on a > comparison. It's hard to know what to depend on now... "Things are Changing" and you need to know exactly what you need to discover what is required. A few years ago, I was flabbergasted when I was asked for a way to identify the libc version under FBSD. The need to do something like that never occured to me.... the possibility of having libc "out of sync" with the kernel never even crossed my mind, and the reason was that the whole thing was one system. It's starting to feel a lot more like some Linux system now... only without the spiffy up2date thinger to go with it. Upgrading from major to major has been something I never minded when needed, but it's too needed now and there's nothing to make it happy. Either the OBSD "no need to rebuild GENERIC" model is being accepted, or we're dumping the "/etc/,/usr/*/etc/*" backup and restore model. I love rcNG for example... but my OPL3 no longer does anything usefull... I had an AWE32 with gobs of RAM plugged in and had to use the Voxware drivers until I couldn't... and now I *need* to use timidity because what other choice do I have? I guess I'm old-fashioned, but I just recently managed to have my LaserWriter 16/600 (using the built-in AUI port) be as easy to set up with CUPS as with printcap I was happy and joyfull. But I had to *manually* do the /usr/bin/* and /usr/sbin/* symlinks *and rebuild KDE samba, and OOo. Why? Probobly 'cause I had lpr working before... does the vaunted handbook even suggest CUPS is there the slighest hint of a migration path? My home NIS and NFS server recently became a Solaris 10 one because it Just Works -- despite the inetd, local service, etc horribleness (still not an AMd fan... mount /home via NFS and don't worry) but I'm worried... even I, a FBSD fanatic am moving my servives off of my various FBSD boxes. Why? They may not work when Things are Better. FBSD currently out "sells" any *nix you pick... *BSD, */Linux, heck, *X.. but when Apache and PostgreSQL move to Linux as their primary system (and the world yawns... let's not talk about BDB) this is a wake-up call... I still haven't tried DragonFly, I think their development model is surpassed by FBSD. But hey, they fixed their clock and no other BSD did. Small incremental fixes. Have we lost that? One tool for the job. Perl killed it? FBSD is *NOT* a kernel bsdtar is *way* too late to make excuses for... where did the pascal compiler go? > Significant performance and stability enhancements that simply cannot > be broken up and backported to FreeBSD 5. We are marching towards a > 'Giant-less' kernel, which means continuing better SMP performance and > better UP responsiveness. With 6.0 we are finally starting to see the > benefit of the SMPng work that we've been doing for 5 years. iirc, this was a 5.x goal. We get a Major with no reason. Release notes between Majors are BORING... one needs to look at the userland to get anything they expect to use, and *BASIC* subsystems like the tty suffer. Will UP ever match what it once was?