Slashdot Mirror
Intel using FreeBSD
From Wes Peters, via DaemonNews.
Intel's InBusiness
Storage Station is a network file server in-a-box. Intel, despite their investment in Linux companies, is using FreeBSD as their OS of choice, as they are now stating. Of
particular interest is their Mean Time Between Failure, 77,244 hours, or a
shade under 9 years. That's probably a little on the low side, but quite
respectable nonetheless.
Intel, despite their investment in Linux companies, is using FreeBSD as their OS of choice, as they are now stating.
They do not have an "OS of choice". Intel wants is OS agnostic. They don't care which OS you run, as long as it runs on Intel hardware. Intel probably used FreeBSD for this "file server applicance" because of the BSD license, which is favorable to companies that would like to borrow BSD code for closed, commercial products.
their Mean Time Between Failure, 77,244 hours, or a shade under 9 years.
When Intel quotes a MTBF of 9 years, they are talking about the hardware, most likely the hard disks. They are not talking about FreeBSD.
cpeterso
Having spent 3 days in NYC answering questions...
.1 micron widths, (18 atoms wide!) you have faster migration of the chip chemistry out of where you want, to where you don't want. Even with old TTL, the projected life is 50 years. The newer chips will have less life. (I don't remember the projected life of the newest .18 micron chips)
"Can BSD run this or that?"
The BSDs have support for GNU/Linux binaries. If the program doesn't require a special version of GNU/Linux, or exists as source, it can be made to run on BSD. FreeBSD has some 2,500 different applications. Goto ftp.freebsd.org and look in the packages/INDEX or ports/INDEX and see if your favorite app is listed. If not, port it! (If its hard to port, as the authors to write portable UNIX code, not code for Linux boxes. A foot to the groin, or sticks to the head may help the developers realize that OpenSource is about more than Linux)
"Does BSD preform better than Linux?"
BSD can run Linux binaries. Various studies done via various methods show BSD having a 20% better preformance under high load. If you arn't using your machine alot, you won't notice a difference. If you really care, benchmark it and pick what works for you. Most people have spare CPU cycles, so speed ratings are rather silly.
"Why should I use BSD over Linux?"
If you are in the business of producing software, or producing embedded 'things' (set-top boxes, routers, cameras, controllers, etc la) the BSD licence is simple and easy to understand. The GPL is written to help foster the goal of source code release. If you have no desire to release your code, a BSD licenced base does not have the GPL source code release issues. As a user, BSD can run BSD *AND* Linux shrink-wrapped binaries, whereas Linux can not run BSD. Therefore BSD has a wider base of possible software that can run on it.
As for a 100 year up-time..
As your tempature rises (every 10 degrees increases the reaction rate 2x times), and we approach
If it was said on slashdot, it MUST be true!
Take Redhat/Linux, for example (please :-). Most of what Redhat ships is undocumented, and that which exists is severely underpowered compared with BSD.
For example, let's suppose you'd like to learn about the interface to the system's terminal drivers. That's in tty(4).
That's a huge difference. As you can plainly see, the amount of info on just one device in BSD is much better than on Linux. And if you look at the overall device coverage, the same theme carries through.And that's just part of it. Here's a bug list on Redhat docs that I've submitted, along with programs to automatically detect these problems. You should really read those over to start to get a feel for how bad it is.
I'd like to make clear that redhat has done a very great job at fielding these bugs and trying to do something about them. I am completely happy with their customer service. I'm not trying to knock that.
Some of the tools I used for this are:
- cfman - make sure manpages have accurate SEE ALSOs
- no3man - identify which library calls aren't mannable
- noman - identify which commands are installed without manpages
- scatman - find turds in mantrees
So not only is the documentation exceptionally scarce in Linux, it's very, very buggy. You wouldn't believe how nasty the situation truly is. Run those on your own systems and you'll see what I mean. And yes, I checked this on Debian/Linux and SuSE/Linux as well as Redhat/Linux. It was all nasty. I also checked on OpenBSD, FreeBSD, and Solaris. You'll see that there's a world of difference here. Find yourself a Redhat system and an OpenBSD system, for example, and start poking around. You'll see.My point of view is that it isn't fair to the user of your system for you to ever include something that isn't documented. When I have been part of releases, either the old Unix releases from years ago or even the new Perl releases today, the rule was simple: if it isn't documented, it isn't shipped. No excuses.
I strongly believe that the Linuces should do the same. Let no program or library be shipped which is undocumented. It's the very least a systems integrator can do. That's just part of what we mean when we say that BSD distributions are more "solid" than Linux distributions. The commercial Unices and the free BSDs take this kind of thing seriously. The Linuces, so far, do not. I have hope that this will change, and Redhat has a truly positive attitude about all this, but right now, you just can't compare them.