Re: HEADS UP: Release schedule for 2006

> 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...

<rant>
<drunk ignore="good idea, I will tomorrow">
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 <whatever> 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?

</rant>

> 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.

</drunk>

Will UP ever match what it once was?