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.
A year has approximately 9000 hours in it
To get mean uptimes of ~77,000, simply run, for example, 9 computers for a year. One should crash once.
There are a lot more than 9 computers in the world running -BSD, so you could take a sample on the number of computers running -BSD, and the number of times those computers had to reboot in, say a month. In 31 days, there are 744 hours. To get a total uptime of ~77,000 hours, simply run 1000 computers all month.
Given, you'd need more than just this to get an average mean uptime, but you get the idea.
Of course, I could be wrong.
BitPoet
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
/me picks up dead horse
/me beats hose
Why would INTEL choose FreeBSD when Linux has all of the (deserved or not) hype, momentum, and business interest?
To answer that question, get a room full of lawyers for computer company legal departments together and have them read the GPL.
.. ask them if they'd like their company's product to be involved with the GPL license.
I understand the GPL. You understand the GPL. Maybe 95+% of slashdot readers understand the GPL, but do you think that corporate lawyers for tech companies who make their money from intellectual property protection are eager to get involved with anything that might require disclosure of their intellectual property?
I'm betting that many companies have official policies (enforced or not) against opensource software due in part to fear of the GPL.
so... the decision comes down to linux+gpl_potential_legal_worries or *BSD+100%_FREE_No_strings_attached .
And the legal department chooses which one??
__
Despite how we try to ignore them, facts take their toll.
You figure it by running a large sample for a short period of time, and then extrapolating the mean time according to a standard distribution.
Translation from statistician: you expect failures to follow a normal distribution, or bell curve. Let's say you run a thousand machines for a month or two as part of your testing. Even with a very long MTBF, you'll have a couple of failures.
You can also use component failure data to figure this out (what's the MTBF of the motherboard, of the processor and other critical components) but aggregating these numbers increases your errors somewhat.
--
--
There is no premature anti-fascism. -Ernest Hemingway
If that's true then:
A list of things likely to fail before FreeBSD
The strange thing is that I bet any 9 year old computers running FreeBSD have Y2K BIOS issues and will fail in what now, less than 2 weeks?
Good thing most of us won't be around to see it, as the Korean, Indian and Pakistani nukes simultaneously launch at 12:00:00 on Jan 1st and wipe us out, turning the survivors into horrible mutant-zombies.
Completely off-topic but (and maybe this would make a good Ask Slashdot) does anybody have any good suggestions for post-apocalyptic type movies to watch over the next couple of weeks? How about video games? For that one I know only of the "Fallout" series.
MTBF is indeed misleading because one of the
factors that goes into it is "design life".
For example, if you have a hard drive with
a MTBF of 150,000 hrs (== 17yrs) that does
not mean that it will fail in 17 years, or
that 150,000 of them would produce one failiure
every hour.
It means that if you replace each drive before
the end of it's design life (5yrs) you will
have a failiure on average every 150,000 hrs.
If you use a device beyond it's design life it
will almost certainly fail.
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.
The implication seems to be that FreeBSD, out of the box, isn't "optimized specifically for file serving"; neither are, as far as I know, Linux, Solaris, HP-UX, Digital UNIX, Windows NT, .... This doesn't ipso facto mean that their performance is "not very good(!!)", it just means that they're at least intended to be reasonably good, out of the box, at a variety of functions, even if this might be at the expense of performance for any particular application.
I don't know about any difficulties in porting GNOME, but it wouldn't surprise me a bit if GNOME was Linux specific.
The GNOME builders are pretty much GPL advocates. Note the similarity between the names GNU and GNOME?
I find it interesting that someone who appears to support a software license that allows the closing off of modifications to "OpenSource" software seems to have an issue with others not writing their software in a form that is optimally available to them.
The whole point of the GPL is that all "boats" that ride on the tide created by it will rise evenly, or at least you can choose how much of the tide you wish to take advantage of. With BSD style licenses, some of the boats can suddenly become sea planes. These craft can benefit from the rising tide, if they chose, but can travel apart from the tide. GPL advocates feel that someone who benefits from their tide should contribute back innovations that allow new technological advances. Seems fair to me.
The GPL is about fairness, not freedom in the sense of "free beer". It's more like you can come enjoy the "free beer", but you're required to share any beer you brew.
The GPL recognizes the reality that left on it's own, software tends to become closed and militates agains this trend.
GPL advocates definitely are generally against having the rising tide floating ALL boats. For example, most GPL advocates are not in favor of floating Microsoft's boat.
Sheesh, to reestablish my reputation as a recovering Karma Junkie, I'll probably have to make several offtopic or "first posts" now. *SIGH*
-Jordan Henderson
http://www.faqs.org/faqs/arch-storage/part2/sectio n-151.html (Very thorough and careful)
http://www.westerndigital.com/products/drives/driv ers-ed/mtbf.html (What Western Digital has to say about MTBF)
http://www.storage.ibm.com/storage/oem/tech/mtbf.h tm (What IBM has to say about MTBF)
--------------------
As an aside, this is an interesting example of the breakdown of moderation on Slashdot. Several people are posting fairly coherent and, at least, pseudo-technical explanations about the calculation of MTBF, but I wasn't able to resolve who was right. The moderation points did not help me either, because they are being assigned by random people I can't trust. I thought, "It is unlikely that very many people on Slashdot actually know how how MTBF is done," and, "It is unlikely that those who actually do know MTBF have the moderation points."