Date: Fri, 11 Nov 2005 01:38:09 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Michael Vince" <mv@roq.com>, <gayn.winters@bristolsystems.com> Cc: freebsd-questions@freebsd.org Subject: RE: Status of 6.0 for production systems Message-ID: <LOBBIFDAGNMAMLGJJCKNCEMFFCAA.tedm@toybox.placo.com> In-Reply-To: <43741174.9020303@roq.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: Michael Vince [mailto:mv@roq.com] >Sent: Thursday, November 10, 2005 7:35 PM >To: gayn.winters@bristolsystems.com >Cc: 'Ted Mittelstaedt'; freebsd-questions@freebsd.org >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 >>>underpants. >>>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. >>> >>>Ted >>> >>> >> >>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 >hardware, This really isn't the issue. Drivers and their development are a different issue than internal kernel changes and such. The problem with breaking old hardware, illustrated by the ida0 driver example, is that the manufacturer (ie: Compaq) comes out with a newer intelligent controller and the documentation 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 modifies the driver to work with the newer controller revision and is pretty sure that his mods won't hose up older controller support, but doesen't have an opportunity 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 prune 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 >http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2598 > >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 compiling on an older BSD version from an application like Perl? Unless the configuration 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 the lowest common denominator. Open Source software can be compiled to run on a specific version of FreeBSD and in fact a specific processor, if the developer wants it to be. If you really want to optimize, you should recompile your system to your specific hardware. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNCEMFFCAA.tedm>