FreeBSD 5 you have failed me

M

M11

Does Not Follow Instructions.
Joined
Jun 8, 2004
Messages
2,336
Recently, I have been trying to use FreeBSD 5.2.1 on a few machines, and like its status implies, it certainly is not release grade. but intended as a technology preview. Between the random lockups, the horrid IDE speed, and the one time the OS totally died following an Apache build, I just would like to encourage others to use 4.10, the current production release, as it has been a solid performer in the past for non-desktop (server/terminal) based solutions.

I'd like to hear some of the comments/opinions/experiences of other members regarding FreeBSD in its current states.

Please note that this is not a request for help, but an invitation for discussion.
 
Strange. It's been working perfectly on three (very) different machines for me over the last year, and I have nothing negative to say about it.
 
Agreed...Alpha, dual PII Xeon, dual PIII/733, Duron 900, Celeron 1400, it doesn't matter. 5.2.1-RELEASE has been a tank. I don't run it "in production" yet simply cause I know a lot is going to be changing for 5.3-RELEASE, but I've never had any stability problems or anything with 5.2.1-R...Which is a big improvement over earlier 5.x-RELEASEs.
 
I ran FreeBSD 5.2 for a little while, and din't notice many problems. But then I went back to Linux anyways.

Wait for 5.3, which will be the real release of FreeBSD 5.x.
 
BillLeeLee said:
Wait for 5.3, which will be the real release of FreeBSD 5.x.
Click to expand...
I agree totally, and can't wait for a current stable build of this OS. 4.x is kinda old, but isn't lacking in any way. I guess thats just a habit of mine to run the latest current, although I sometimes forget there is nothing broken or lacking with the old FreeBSD (other than x64 support)
 
Yeah, I've been running 4.x for years now. I've been very happy with it. I've held off on switching my production boxes to 5.x, but the time to do so is getting close.
 
I've been living dangerously and loosely tracking -CURRENT on one of the machines, and hell, even that has been fine.

Another thing: Is there anyone else but me who's almost disturbed by the absolute lack of anti-BSD trolling here? It's unsettling :D
 
HHunt: actually, no, you're not. I expected someone to ask why we run FreeBSD by now.

Sometimes I miss the trolls. :(
 
Nah, the linux-BSD split is viscous. No need for arguement between fanboys who will never change. Myself, I run linux and BSD, and make use of the strengths of both systems.
 
M11 said:
the one time the OS totally died following an Apache build
Click to expand...

That's happened to me twice. First time was an ACPI bug (fixed now), second was faulty hardware.
 
Snugglebear said:
That's happened to me twice. First time was an ACPI bug (fixed now), second was faulty hardware.
Click to expand...
my hardware is fine-the machine is running slack 10 now

it would just lock without symptom or error immediately past the bootloader. yeah, its weird.
 
I've moved most of our production rackmounts to FreeBSD 5.2.1. Not the smartest move but the system has been very fast and rock-solid.
 
I have been running a desktop FreeBSD 5.2.1 installation on an Asus A7N8X Deluxe (with both 3Com and nVidia NIC) and a PNY GF4MX440 and 120 gig Maxtor HD without any problems.

Don't use it for anything hard core but I haven't had any major problems [Knock on Virtual Wood]. But I'd agree that for production, stick to 4.x.
 
I run FreeBSD 5.2 on 2 production machines, 2 development machines and 1 as a desktop. I use apache 2, php, bind, openssl, openssh, and mysql quit a bit, never had a problem.

I even have a sun ultra5 running 5.1 and its been stable without any glitches.

The issues you are having would strongly indicate hardware issues. But since you say its fine runing slackware I cant say.
 
This is not a deliberate bash on linux, but over the years I've found it far more tolerant of bad hardware than other unices. However, this is not `good` tolerant, rather `blissfully ignorant until data corruption shoves a broom handle up your ass` tolerant. That same machine FreeBSD 5.x puked up on ran linux for several years without a hitch until I tried to get some old, archived data off it that turned out to be garbled. Solaris also crashed on that machine, and if Solaris crashes, you know instantly the hardware is borked. All that led to thorough diagnostics and eventually the trash can.
 
You've noticed that too? FreeBSD seems to be much less "forgiving" of flaky hardware.
 
I've noticed it as well, and it helps with making sure servers are in working order. BSD is far better than linux in this regard. Why the Linux community doesn't do it this way is beyond me, especially in server grade distros. I could understand for noob flavors like fedora or mandrake, but other distros could benefit much from less tolerance of hardware hazards.
 
There was a point when I considered that a feature, too. At least they have a set of efforts underway to allow proper operation with small failures (marking segments of memory as bad, identifying errata in chipsets & processors and using workarounds, etc.).
 
Snugglebear said:
There was a point when I considered that a feature, too. At least they have a set of efforts underway to allow proper operation with small failures (marking segments of memory as bad, identifying errata in chipsets & processors and using workarounds, etc.).
Click to expand...
Errata is one thing. But rather than work after ability to deal with bad memory, I'd rather have it alert me, and then I'll go change the memory out. RAM is so cheap, I can't imagine why a server admin would not opt to replace a partially failed stick that will only get worse with time. If it runs long enough to get the replacement installed, then its good enough for me.
 
Linux gets a lot of support and has a solid user base in many countries that aren't so wealthy. They generally get stuck using older hardware for longer, and a few failed addresses in a stick is a very expensive problem unless you can just run with it (rather like it was here back about 10-20 years ago). A few lines of code to produce an OS-level workaround is preferable to purchasing prohibitively expensive hardware or just crossing your fingers.
 
HP has been the one pushing the multi-head linux systems in poorer countries. The fact still remains that linux is mainly developed by geeks in industrialized countries who have every intention of using it themselves. When it is said that linux is free software, the free refers more to the freedom to change and distribute it than an underlying goal to eliminate cost. This mission of open source software has, however, worked out nicely for developing nations or organizations on a budget. I don't want to derail this thread much, just my observations on linux.
 
Also, regarding memory: for common, non-ECC, memory, it's kind of hard to detect an intermittent failure in a chip while running[1], so handling memory errors during operation is not practically an option. (Excluding known bad areas is another matter, of course.)

But this is another tangent, isn't it :D


[1] (How would you? Duplicate or checksum everything?)
 
Tandem computers did a lot of work on that back in the 90s using common hardware. However, a good deal of more robust solutions were created by IBM, HP, and I think DEC, too. You'll find these in their mid to high-end RISC solutions. People can go on and on about how uber-l33t their x86 machines are, but frankly, they're Pintos compared to the UNIX on RISC machines. Really, how many of you have computers that can email you when the processor errors and/or dies?
 
Snugglebear said:
Tandem computers did a lot of work on that back in the 90s using common hardware. However, a good deal of more robust solutions were created by IBM, HP, and I think DEC, too. You'll find these in their mid to high-end RISC solutions. People can go on and on about how uber-l33t their x86 machines are, but frankly, they're Pintos compared to the UNIX on RISC machines. Really, how many of you have computers that can email you when the processor errors and/or dies?
Click to expand...
My opteron box can. It can drop a processor and potentially live, and shut down memory chips if too many errors are detected in them(it uses ECC):D
 
Nice :)

It's not quite as cute as the IBM mainframes that will do every computation twice and compare the results, taking a processor offline if it's inconsistent, but still.

(As for service and mail: The best storage solutions and support deals have you reciving a harddisk in the mail, with a notification on what drive to replace it with (or a tech arriving to do it for you), before you notice that something's wrong. That's kind of impressive.)
 
You must log in or register to reply here.
Back
Top