Status of 6.0 for production systems

Ted Mittelstaedt tedm at
Fri Nov 11 09:38:30 GMT 2005

>-----Original Message-----
>From: Michael Vince [mailto:mv at]
>Sent: Thursday, November 10, 2005 7:35 PM
>To: gayn.winters at
>Cc: 'Ted Mittelstaedt'; freebsd-questions at
>Subject: Re: Status of 6.0 for production systems
>Gayn Winters wrote:
>>>There are some things broken in 5.4 that are still broken in 6.0
>>>with regards to support of older hardware.  In particular the ida
>>>driver is a mess - EISA support in that was busted years ago,
>>>then 5.X busted support for more 'modern' systems like the
>>>Compaq 1600R   HP  "DL" series of systems are kind of a moving
>>>target anyway, unfortunately.  For those sytems I still use 4.11
>>>(in fact I just setup 2 new 4.11 production systems two days ago)
>>>However, 6.0 is a requirement for currently shipping hardware, in
>>>particular the Intel series of boxed "server" motherboards, if you
>>>want to use raid and sata drives, since Intel seems to like to change
>>>it's motherboard chipsets as fast as most people change their
>>>I'm actually building a 6.0 production server today.  (5.4 and earlier
>>>will not recognize the disk array)
>>>It would be nice if we could get more support for SATA raid in
>>>the atacontrol program.
>>On the plus side, I've thrown a lot of hardware at FreeBSD with great
>>success. On the other hand, FreeBSD's primary weakness seems to be the
>>support of newer hardware. I suppose I shouldn't be surprised
>to hear of
>>problems with older hardware as well, and Ted's solution of pairing
>>older hardware with an older release seems reasonable if in
>fact one has
>>the experience to support the older release.
>I prefer the idea of the FreeBSD team aiming at only the latest
>hardware, all I use is brand new server equipment.
>I don't like the idea that FreeBSD features and performance development
>could be hampered by the core guys trying to make stuff work on old

This really isn't the issue.  Drivers and their development are a
issue than internal kernel changes and such.  The problem with breaking
old hardware, illustrated by the ida0 driver example, is that the
(ie: Compaq) comes out with a newer intelligent controller and the
on that says it's backwards compatible so the older drivers will still
work with
it.  Then we come to find out that this isn't true - so the driver author
the driver to work with the newer controller revision and is pretty sure
his mods won't hose up older controller support, but doesen't have an
to test with it (either doesen't have the hardware or some other reason)

> in fact if it was a fact that a lot more performance and
>features could be in 6.x if they dropped support for everything below
>1ghz for x86 I would be happy, I got a few older machines but
>they could
>go onto NetBSD since its a very similar OS as it has the same rc script
>system which FreeBSD imported from NetBSD to start with.
>Admittedly if Microsoft were trying to make Windows XP run well
>on a 486
>it wouldn't be nearly as a likable OS it is today.

That's not true either.  If Microsoft were trying to make it work on a
486 it
would run a lot better on bigger hardware because they would have to
all the fat off it.

Haven't you ever noticed with Windows that the user interface speed is
still the same today, with brand new hardware, as it was 10 years ago
on older versions of Windows?

Try running Windows 98 one day on brand new hardware - it is almost a
religious experience.  Open a window and Bang - it's there, completely
drawn in, so fast you can't even see it draw.  THAT is how it's supposed
to be.  The problem is the stupid consumers don't understand that every
year that they buy newer and faster hardware it just helps Microsoft to
make their stuff slower.  So they never get ahead.

>AMD64/EMT64 appears to be the mainstream high performance future and
>should get the most support, although some technologists are
>saying that
>Itanium is going to make a come back believe it or not, check out the
>latest anandtech article for example
>If theres some guy who uses a 386sx 25mhz to run his water gardening
>sprinkler system he should let go of demanding 6.x work on his system
>and just use what he needs such as 4.x

6.x will not boot on a 386, the math coprocessor emulator is not in
the generic kernel anymore.

>And if he needs say the latest perl 6 to control his sprinkler system
>and its not available in 4.x any more then he should just use NetBSD,
>NetBSD is for all types of hardware and is a fine OS.

That is not a FreeBSD issue, that is an issue with the Perl development
team and what -they- choose to support.  You frankly sound like you have
never compiled anything from scratch.  The entire point of scripts like
'configure' is to setup options so an application will compile on any OS
version.  In any case why possibly would you strip out support for
on an older BSD version from an application like Perl?  Unless the
script for Perl sees an older OS it does not add in any of the
crutch-code to
help it build and run on the older OS.

You need to quit thinking in binary terms.  The tradeoffs you are
referring to
only exist in binary software because it has to be compiled to run on
lowest common denominator.  Open Source software can be compiled to
run on a specific version of FreeBSD and in fact a specific processor, if
developer wants it to be.  If you really want to optimize, you should
your system to your specific hardware.


More information about the freebsd-questions mailing list