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?
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
