This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

About FreeBSD..

Posted by: PeterWemm on April 05, 2005 09:27 AM
Well, formal releases of FreeBSD/amd64 have all been Jinxed. We've managed to get a stinker series of problems in every release so far. 5.3 suffers from the Syskonnect/Marvell driver nightmare as well as a couple of other serious bugs that affect machines with more than 4GB of ram.

To top it off, FreeBSD 5.3/i386 added thread-local-storage right at the last minute that wasn't compatable with FreeBSD/amd64's 32 bit environment. So as a result, 5.3-amd64 cannot run 5.3-i386 binaries. How's that for bad timing?

Most of the syskonnect/marvell driver problems are specific to particular versions of the silicon. If the reviewer had run with different hardware, their stability results would have been significantly better. I personally use (older revision) syskonnect/marvell network hardware on all of my development and desktop machines.

Some of the problems that the reviewers ran into was because of the design. We implemented FreeBSD/amd64 primarily as a 64 bit platform with 32 bit support as a distinct second priority. We were thinking of how the world would be looking in 1, 2, 5 or even 10 years. We knew about Intel's 64 bit contingency plans for years, and we knew that the writing was on the wall for 32 bit silicon. We didn't want to be stuck with decisions that resulted from temporary expediency for 32 bit coexistence. We figured that within a few years, 32 bit compatability wouldn't be much of a factor - at least in unix environments where FreeBSD tends to get used a lot. We didn't want to be stuck with 64 bit as an add-on, instead of as the primary mode of operation. I guess time will tell if we made the right choice.

But don't dismiss the 32 bit environment entirely. We have some FreeBSD 4.x i386 environment on FreeBSD/amd64 machines at work, in a production environment, to stress test it and make sure we catch problems. (And yes, we are finding plenty!). This is maturing quite quickly.

We made a bunch of other decisions that we knew were going to be painful to start with, but were going to pay off over time. For example, we use a 64 bit time_t throughout the system, both in the kernel and userland. Our libc time code is good for a few trillion years, y2038 isn't going to be a factor for us.

Anyway, we took some brave decisions that we knew were going to hurt us in the short term, but with the hope that we'd end up with a cleaner system in the end.


Return to 64-bit Linux and BSD are maturing steadily