Um don't you need protons for that also? Adding neutrons would just create isotopes...
No. You have to overcome the charge of the protons to get them to enter the nucleus. If it were easy to get protons to enter a nucleus, we would have had fusion decades ago.... Of course the universe wouldn't exist as we know it, but that's not really germane to the discusison. Neutrons, having no charge at all, fly right in and collide, unimpeded by the electron cloud or the protons.
If I remember correctly, there's a very unstable intermediate isotope of Uranium created that almost immediately emits a beta particle which converts a neutron to a proton.
You missed the other key application... A cheap ready supply of neutrons is exactly what you need to transmute elements... Sadly, this includes the most common element transmutation carried out by mankind to date... U-238 to Pu-239. Cheap tabletop neutrons means cheap Pu-239 without the cost & mess of having a breeder fission reactor...
This will make non-proliferation all the harder.:(
Actually... I was going to suggest he get checked for diabetes.
The glucose spikes in the blood cause the lens in the eye to swell. Basicly, vision shifts with blood glucose. You eat something starchy, or containing sugar, blood glucose goes up, the lens swells. BG peaks, and starts to drop, and the lens shrinks. It can be rather aggrivating for an uncontrolled diabetic, and one of the first symptoms people actually notice.
I'm curious why you think this isn't happening already, and why the government should receive the additional revenue rather than the oil company shareholders. This is a dangerous combination of social engineering and coveting other people's money. Personally I think your $your_favorite_modern_convenience should be taxed to fund $my_favorite_government_pork_project.
There's also individual component issues to consider. A Honda CR-V might have a engine/transmisison combination that weighs in at maybe 300 - 350 Kg total. The now out-of-production Ford Excursion with the 7.3l diesel engine has a rigid engine/transmission combination that is up around 1000 Kg (and a total vehicle mass over 3600 Kg!) . A 1000 Kg cast iron engine/transmission is not going to behave in any meaningful elastic way in a collision with a 350 Kg aluminum engine/transmission, and both these masses are right up front. You can almost ignore the Excursion's engineered chassis crumple zones once the radiators have crushed and the engine blocks make contact.
The amusing premise here is that the wording suggests we can somehow reduce the number of large body on frame vehicles on the road. This isn't going to happen in any meaningful way any time soon. The world operates with pickup trucks that can tow 5,500 Kg, and class 8 semis that can tow 30,000 Kg. I am unaware of any unibody vehicles that are capable of exceeding 50% of mass cargo capacities, or 2 to 8 times their mass towing capacities. This isn't to say its impossible, but they do not exist at this time. Even if they did, you'd still have a massive non-elastic engine and transmission to contend with, because moving these cargo masses takes a lot of power. The wording seems carefully chosen to place blame with the body on frame vehicles that run our economy rather than the flimsily constructed light unibody vehicles. Light unibody vehicles have been known killers for a long time. Technology has made them quite a bit safer over the last couple decades, but tech costs $$. There's obviously an agenda at work here...
Which is what I suspected... But I haven't had to time to sit down and figure out for myself.
More importantly though, most of my coding would be best described as "system management" scripting. Automated install and configuration of large applications. Some languages are better at this than others. Perl is excelent, but I'd like something with ground up OOP support. I haven't had time to learn Ruby, so I don't know if it meets my needs. Everyone fawns over Rails for web development, which I'm simply not interested in.
Python would appear to have most of what I need, but it also appears that GVR wants to enforce his view of what is "correct" on the rest of us via whitespace significance. I'm probably getting old and cranky, but I don't feel like I need to have my hand held like this, and I certainly don't need the aggrivaiton that comes with it when trying to debug something.
Ruby is on the list. I'm not into web development though, so I'm still trying to sort out the relevance. I do systems QA development, and Perl works fine, but the OOP stuff bothers me. It works... But there's just something not right about it.
haha, never mind that this is exactly how your code should be indented in the first place....
I'm not going to disagree. I just don't need the associated misbehavior that comes along with it if I fail to indent things right. Copy/Paste mistake, or similar and you have problems. Most of the major languages have chosen to ignore the significance of whitespace. It's a substantial mindset to relearn.
We're talking about a scripting language. Development speed is important to me, and I don't need my scripting language being needlessly pedantic because I cut and pasted an old section of code. Is this a form of laziness? Yes, absolutely. Is it wrong? My CPU's don't seem to have an opinion, it's all 1's and 0's to them.
I have a choice of several dozen languages to choose from. Why pick one that would annoy me? YMMV.
Funny you should mention that. After meaning to for years, I finally got around to getting the "Learning Python" book... I made it to page 149 where it says "Python uses the indentation of statements under a header to group the statements in a nested block." I stopped reading and tossed the book on my bookshelf on a shelf full of unused & unloved technical manuals. It now sits between the Postscript redbook from 1990, and a late 80's book on Ada. It really belongs next to a Fortran book, but I don't own one.
A shame too... The rest of the language is so clean.
I seem to remember hard drives that came with factory windows. CDC's, and IBM's mostly.... Dam... I'm getting old.
Anyhow... I saw a FH 5 1/4" drive with a plexiglass cover back in the mid-1980's. Doing this is old news. I was thinking about building a "visable" webserver out of an old Sun IPC back 1996. I was going to silicone the whole thing to the window in my office door, and then rig it up to the net.
Red Hat / Fedora Team spent about a year cleaning it up and porting it to linux, or didn't you bother to read the summary?
"Porting to Linux" is and of itself a mindless statement, since this is Netscape DS, aka iPlanet DS, which is an antique fork of Sun's current SJES DS, all of which have been running on Linux for better part of a decade.
It will be interesting to compare Fedora DS to Sun's current offering. Sun even provides an open source tool for this called SLAMD.
Unlike the SS5/170's bug which is well known, but needs documentation/source to fix, the Ultra 1's bug is hardware based (unreliable in 64bit mode due to a RED_STATE bug, that takes any real advantage from the Ultra1 that it had). With that bug in mind, it's more or less a turbo'd SS5/170 due to even Solaris not using the 64bit side.
The UltraSPARC-1 64-bit bug is highly unlikely to occur. It's a sequence of instructions that no compiler is going to generate. You have to want it to happen, and hand craft the code to do so. I'll admit this makes for a denial of service hole if you run in an untrusted environment. I've run Solaris in 64-bit on Ultra 1's & Ultra 2's w/US1 modules as desktops for years, it's a one line option enable, and I've never had a problem. FWIW, there was a bug on the SS5-170 under one release of Solaris, that suffered an infinite loop problem running certain gcc generated code, and it required a power-off reset. So the TurboSPARC isn't perfect either.
As for the U1 being a "turbo'ed" SS5-170... Not even close. The SS5 has narrow antique SCSI-II, 10base-T ethernet and a 256mb memory limit. The U1 can be had with wide SCSI and fast ethernet, can configure more RAM, and has a much faster memory system. The ZX framebuffer you mentioned was a double width card, and the TZX was a double width card with a fan card in the third slot, so it's not like you'd have much room to work around these shortcomings. (T)ZX frame buffer support was removed before Solaris 8, which probably forked back in 1997. There's probably very few people left at Sun that even remember it, let alone worked on the drivers. The other SS5 24-bit framebuffer option, the S24 was a POS. I've never met anyone that liked it.
I wouldn't consider the SS5 to be one of Sun's "great" workstations. It was a refined LX, which was a lower cost SS2, which was a souped up SS1 (which was a kick ass machine back in 1989!). The SS5 was a nice little affordable desktop back in it's day. Like the 486 that was it's contemporary, it's day has come and gone. Throw it in the back room running a DNS server if you must, I admit I have a SS5-170 here at home, which I bought for $10 at a flea market. But get over it and move on. If you're truely hung up on the 4m's, go find a SS20 chassis. It was a much more capable machine.
which really leaves old Solaris versions (if you can get them)
Solaris 9u7 is less than two years old. Free as in beer download, and really quite nice. They even fixed logging UFS! A fitting end to the Sun4m's.
As for the fork, if they could bring code from the Ultra out, there's no real reason they couldnt have brought enough code and binaries out to give 32bit one last version to build onto.
If you read the OpenSolaris site, there is some discussion on this. The problem is, the sun4m code was torn out early, and then the kernel was modified to take advantage of features that don't exist in the 4m hardware. If you put the 4m support back, you either loose major feature enhancements, or fork the kernel. Again, Solaris is not NetBSD... They're not going to carry HW support forward forever, and sacrifice major enhancement opportunities, just so you can run on 10 year old hardware. Sun left the 4m's behind long before the OpenSolaris effort started.
BTW - If you read the docs, Solaris 10 requires 512mb of RAM (mostly IMNSHO due to the memory pig called Gnome), so the SS5 would be off the list even if the other 4m's were still supported!
Even if the licensing is friendly, this is from the company that doesnt mind dropping hardware support in 2 versions.
Huh? The last 32-bit chassis, the SS5 & SS20 shipped in 1995. That's 10 years ago. Solaris 2.4, 2.5, 2.5.1, 2.6, 7, 8, and 9 thru the latest 9u7 run on them just fine. Solaris isn't NetBSD. They don't carry support forward for everything. The decision about when to drop the SS5 was probably made back in 1996, when the Ultra's started shipping in numbers. They set a roadmap, and stuck to it.
When did the Solaris 10 branch fork? I'll bet it was back in 2001. Back then Sun execs were probably still thinking they were going to see a recovery in a quaretr or so, and "OpenSolaris" wasn't a priority. So I'm guessing you're complaining about decisions that were made long ago, under much different circumstances.
Bite the bullet, and buy a newer pizza box. There's thousands of Ultra 1's floating around out there for cheap. And consider this... Now that Solaris 10 is open source, they can never do this to you again.
Reykjavik is reputedly the least polluted city in Europe
Not to slight the Icelanders in the least... It sounds like a neat Island, and I'd love to visit it... But... Isn't this a bit unfair to the rest of Europe? You know, the part that isn't completely surrounded by several thousand kilometers of ocean? The Europe that's actually *IN* Europe...
ne of the other big loosers will be scientific collaberations (like those CERN runs to analyze collider data) because ALOT of their computing power is in the US.
is their contribution to the Nazi party by selling them computers which, unless I'm mistaken
You're mistaken. Computers were not invented until the waning days of WW2, and IBM didn't build the 701 until 1952, and the 702 in 1953. IBM's German sub-corp did sell them tabulating equipment in the 1930's, which was used at concentration camps. This arm of IBM was nationalized by the Nazi's in 1941, and IBM HQ lost control of it. Concentration camps were not illegal in time of war, the fact that they were actually extermination camps only came out later. Trying to hold IBM responsible smacks of revisionism.
IBM has a number of firsts in human rights, including:
The first corperation to support the United Negro College Fund in 1944.
and
The first US corperation to mandate equal opportunity employment in 1953.
The odd thing about this sad state of affairs.... If I'm reading this right, the Federal Government retains royalty free rights to virtually all the research it has funded. Which means, at least in theory, it could seriously leverage its position to purchase drugs for the medicare prescription benefits. Something that has apparently not occured...
Which just goes to show who the politicians really represent.
One million email accounts is quite a lot. You getting into the big league ISP category with something like this. It's not a one person operation to put something like this together. You're going to need a substantial number of well trained people to do this. There's only a couple players in the field at this level. Sun's JES Messaging system owns a sizeable chunk of the market, followed by OpenWave and a small gaggle of fly-by-nights with unproven track records.
Some of the larger email systems however are homegrown using open source parts. Yahoo and Google immediately come to mind, and they do work quite well. But you probably don't have the resources that they do to engineer & test something like this. Yahoo is rumored to have more than 200 people working on email alone.
Sun has a deployment like this canned, sitting on a shelf in Santa Clara. Tell them what you need, write a check, and they'll show up with the kit. 99.999% uptime if you write a big enough check. Make them to throw in the Waveset stuff.
Very interesting... The wording leaves one thinking Intel & BlueArc are announcing this. In fact the SPECmail report shows CommuniGate submitted the results. Why would Intel want to push a disk array that uses a Freescale PPC chip?
Sure looks like a general purpose CPU to me. Same family as used in the current Mac PB's, iBooks, and the Mini, with a bunch of speedy I/O stuff bolted on. This really isn't all that interesting a disk array. The Sun T3 used in the previous record is conceptually similar, though smaller. More importantly it uses FC/AL attach to the server, and this is NAS via NFS. I'm a big fan of networking, but this strikes me as one of those places where you're better off with a dedicated storage I/O channel like a FC/AL.
I'm left wondering why they chose NFS attach, and why Intel is mentioned as announcing this, since it promotes a Freescale processor in the disk solution, and from the actual SPECmail report, CommuniGate did the testing. Quite dodgy... I'd be a bit pissed if I were Intel.
Interestingly enough, they set their record using a message store mounted on NFS. It had 140 FC/AL attached disks, and 14Gb of RAM.
Virtually every file handle an MTA writes to is opened "O_SYNC". One of the quickest ways to make Sendmail or other common MTA's go fast is to mount their delivery queues on a solid state disk. I'm betting this disk array is turning around the queues without ever committing the data to the platters. (Not that there's anything wrong with this...) I am left wondering if there isn't some bit if NFS trickery not reported in the config.
But looking at the Sun entry, the old record was set using 2 year old software, and a much smaller disk configuration. Sun will probably update their entry in the near future, just to reclaim the crown. Email is much more an I/O problem than a CPU problem. Sun used to push their mail server on much larger HW, but most ISP's don't want to buy big boxes these days. The small to medium sized boxes, connected to a SAN are more cost effective, permit redundancy and easier maintenance.
Slashdot Mirror
Um don't you need protons for that also? Adding neutrons would just create isotopes...
No. You have to overcome the charge of the protons to get them to enter the nucleus. If it were easy to get protons to enter a nucleus, we would have had fusion decades ago.... Of course the universe wouldn't exist as we know it, but that's not really germane to the discusison. Neutrons, having no charge at all, fly right in and collide, unimpeded by the electron cloud or the protons.
If I remember correctly, there's a very unstable intermediate isotope of Uranium created that almost immediately emits a beta particle which converts a neutron to a proton.
You missed the other key application... A cheap ready supply of neutrons is exactly what you need to transmute elements... Sadly, this includes the most common element transmutation carried out by mankind to date... U-238 to Pu-239. Cheap tabletop neutrons means cheap Pu-239 without the cost & mess of having a breeder fission reactor...
:(
This will make non-proliferation all the harder.
Actually... I was going to suggest he get checked for diabetes.
The glucose spikes in the blood cause the lens in the eye to swell. Basicly, vision shifts with blood glucose. You eat something starchy, or containing sugar, blood glucose goes up, the lens swells. BG peaks, and starts to drop, and the lens shrinks. It can be rather aggrivating for an uncontrolled diabetic, and one of the first symptoms people actually notice.
I'm curious why you think this isn't happening already, and why the government should receive the additional revenue rather than the oil company shareholders. This is a dangerous combination of social engineering and coveting other people's money. Personally I think your $your_favorite_modern_convenience should be taxed to fund $my_favorite_government_pork_project.
There's also individual component issues to consider. A Honda CR-V might have a engine/transmisison combination that weighs in at maybe 300 - 350 Kg total. The now out-of-production Ford Excursion with the 7.3l diesel engine has a rigid engine/transmission combination that is up around 1000 Kg (and a total vehicle mass over 3600 Kg!) . A 1000 Kg cast iron engine/transmission is not going to behave in any meaningful elastic way in a collision with a 350 Kg aluminum engine/transmission, and both these masses are right up front. You can almost ignore the Excursion's engineered chassis crumple zones once the radiators have crushed and the engine blocks make contact.
The amusing premise here is that the wording suggests we can somehow reduce the number of large body on frame vehicles on the road. This isn't going to happen in any meaningful way any time soon. The world operates with pickup trucks that can tow 5,500 Kg, and class 8 semis that can tow 30,000 Kg. I am unaware of any unibody vehicles that are capable of exceeding 50% of mass cargo capacities, or 2 to 8 times their mass towing capacities. This isn't to say its impossible, but they do not exist at this time. Even if they did, you'd still have a massive non-elastic engine and transmission to contend with, because moving these cargo masses takes a lot of power. The wording seems carefully chosen to place blame with the body on frame vehicles that run our economy rather than the flimsily constructed light unibody vehicles. Light unibody vehicles have been known killers for a long time. Technology has made them quite a bit safer over the last couple decades, but tech costs $$. There's obviously an agenda at work here...
Which is what I suspected... But I haven't had to time to sit down and figure out for myself.
More importantly though, most of my coding would be best described as "system management" scripting. Automated install and configuration of large applications. Some languages are better at this than others. Perl is excelent, but I'd like something with ground up OOP support. I haven't had time to learn Ruby, so I don't know if it meets my needs. Everyone fawns over Rails for web development, which I'm simply not interested in.
Python would appear to have most of what I need, but it also appears that GVR wants to enforce his view of what is "correct" on the rest of us via whitespace significance. I'm probably getting old and cranky, but I don't feel like I need to have my hand held like this, and I certainly don't need the aggrivaiton that comes with it when trying to debug something.
Ruby is on the list. I'm not into web development though, so I'm still trying to sort out the relevance. I do systems QA development, and Perl works fine, but the OOP stuff bothers me. It works... But there's just something not right about it.
I got to work with INMOS Transputers back in 1988. Been trying to forget them ever since.
haha, never mind that this is exactly how your code should be indented in the first place....
I'm not going to disagree. I just don't need the associated misbehavior that comes along with it if I fail to indent things right. Copy/Paste mistake, or similar and you have problems. Most of the major languages have chosen to ignore the significance of whitespace. It's a substantial mindset to relearn.
We're talking about a scripting language. Development speed is important to me, and I don't need my scripting language being needlessly pedantic because I cut and pasted an old section of code. Is this a form of laziness? Yes, absolutely. Is it wrong? My CPU's don't seem to have an opinion, it's all 1's and 0's to them.
I have a choice of several dozen languages to choose from. Why pick one that would annoy me? YMMV.
Funny you should mention that. After meaning to for years, I finally got around to getting the "Learning Python" book... I made it to page 149 where it says "Python uses the indentation of statements under a header to group the statements in a nested block." I stopped reading and tossed the book on my bookshelf on a shelf full of unused & unloved technical manuals. It now sits between the Postscript redbook from 1990, and a late 80's book on Ada. It really belongs next to a Fortran book, but I don't own one.
A shame too... The rest of the language is so clean.
I seem to remember hard drives that came with factory windows. CDC's, and IBM's mostly.... Dam... I'm getting old.
Anyhow... I saw a FH 5 1/4" drive with a plexiglass cover back in the mid-1980's. Doing this is old news. I was thinking about building a "visable" webserver out of an old Sun IPC back 1996. I was going to silicone the whole thing to the window in my office door, and then rig it up to the net.
Red Hat / Fedora Team spent about a year cleaning it up and porting it to linux, or didn't you bother to read the summary?
"Porting to Linux" is and of itself a mindless statement, since this is Netscape DS, aka iPlanet DS, which is an antique fork of Sun's current SJES DS, all of which have been running on Linux for better part of a decade.
It will be interesting to compare Fedora DS to Sun's current offering. Sun even provides an open source tool for this called SLAMD.
Unlike the SS5/170's bug which is well known, but needs documentation/source to fix, the Ultra 1's bug is hardware based (unreliable in 64bit mode due to a RED_STATE bug, that takes any real advantage from the Ultra1 that it had). With that bug in mind, it's more or less a turbo'd SS5/170 due to even Solaris not using the 64bit side.
The UltraSPARC-1 64-bit bug is highly unlikely to occur. It's a sequence of instructions that no compiler is going to generate. You have to want it to happen, and hand craft the code to do so. I'll admit this makes for a denial of service hole if you run in an untrusted environment. I've run Solaris in 64-bit on Ultra 1's & Ultra 2's w/US1 modules as desktops for years, it's a one line option enable, and I've never had a problem. FWIW, there was a bug on the SS5-170 under one release of Solaris, that suffered an infinite loop problem running certain gcc generated code, and it required a power-off reset. So the TurboSPARC isn't perfect either.
As for the U1 being a "turbo'ed" SS5-170... Not even close. The SS5 has narrow antique SCSI-II, 10base-T ethernet and a 256mb memory limit. The U1 can be had with wide SCSI and fast ethernet, can configure more RAM, and has a much faster memory system. The ZX framebuffer you mentioned was a double width card, and the TZX was a double width card with a fan card in the third slot, so it's not like you'd have much room to work around these shortcomings. (T)ZX frame buffer support was removed before Solaris 8, which probably forked back in 1997. There's probably very few people left at Sun that even remember it, let alone worked on the drivers. The other SS5 24-bit framebuffer option, the S24 was a POS. I've never met anyone that liked it.
I wouldn't consider the SS5 to be one of Sun's "great" workstations. It was a refined LX, which was a lower cost SS2, which was a souped up SS1 (which was a kick ass machine back in 1989!). The SS5 was a nice little affordable desktop back in it's day. Like the 486 that was it's contemporary, it's day has come and gone. Throw it in the back room running a DNS server if you must, I admit I have a SS5-170 here at home, which I bought for $10 at a flea market. But get over it and move on. If you're truely hung up on the 4m's, go find a SS20 chassis. It was a much more capable machine.
which really leaves old Solaris versions (if you can get them)
Solaris 9u7 is less than two years old. Free as in beer download, and really quite nice. They even fixed logging UFS! A fitting end to the Sun4m's.
As for the fork, if they could bring code from the Ultra out, there's no real reason they couldnt have brought enough code and binaries out to give 32bit one last version to build onto.
If you read the OpenSolaris site, there is some discussion on this. The problem is, the sun4m code was torn out early, and then the kernel was modified to take advantage of features that don't exist in the 4m hardware. If you put the 4m support back, you either loose major feature enhancements, or fork the kernel. Again, Solaris is not NetBSD... They're not going to carry HW support forward forever, and sacrifice major enhancement opportunities, just so you can run on 10 year old hardware. Sun left the 4m's behind long before the OpenSolaris effort started.
BTW - If you read the docs, Solaris 10 requires 512mb of RAM (mostly IMNSHO due to the memory pig called Gnome), so the SS5 would be off the list even if the other 4m's were still supported!
Even if the licensing is friendly, this is from the company that doesnt mind dropping hardware support in 2 versions.
Huh? The last 32-bit chassis, the SS5 & SS20 shipped in 1995. That's 10 years ago. Solaris 2.4, 2.5, 2.5.1, 2.6, 7, 8, and 9 thru the latest 9u7 run on them just fine. Solaris isn't NetBSD. They don't carry support forward for everything. The decision about when to drop the SS5 was probably made back in 1996, when the Ultra's started shipping in numbers. They set a roadmap, and stuck to it.
When did the Solaris 10 branch fork? I'll bet it was back in 2001. Back then Sun execs were probably still thinking they were going to see a recovery in a quaretr or so, and "OpenSolaris" wasn't a priority. So I'm guessing you're complaining about decisions that were made long ago, under much different circumstances.
Bite the bullet, and buy a newer pizza box. There's thousands of Ultra 1's floating around out there for cheap. And consider this... Now that Solaris 10 is open source, they can never do this to you again.
Temkin
For now... Pending the outcome of the 2006 Congressional elections, and the 2008 Presidential election.
Reykjavik is reputedly the least polluted city in Europe
Not to slight the Icelanders in the least... It sounds like a neat Island, and I'd love to visit it... But... Isn't this a bit unfair to the rest of Europe? You know, the part that isn't completely surrounded by several thousand kilometers of ocean? The Europe that's actually *IN* Europe...
ne of the other big loosers will be scientific collaberations (like those CERN runs to analyze collider data) because ALOT of their computing power is in the US.
They're on Internet2.
is their contribution to the Nazi party by selling them computers which, unless I'm mistaken
You're mistaken. Computers were not invented until the waning days of WW2, and IBM didn't build the 701 until 1952, and the 702 in 1953. IBM's German sub-corp did sell them tabulating equipment in the 1930's, which was used at concentration camps. This arm of IBM was nationalized by the Nazi's in 1941, and IBM HQ lost control of it. Concentration camps were not illegal in time of war, the fact that they were actually extermination camps only came out later. Trying to hold IBM responsible smacks of revisionism.
IBM has a number of firsts in human rights, including:
The first corperation to support the United Negro College Fund in 1944.
and
The first US corperation to mandate equal opportunity employment in 1953.
The odd thing about this sad state of affairs.... If I'm reading this right, the Federal Government retains royalty free rights to virtually all the research it has funded. Which means, at least in theory, it could seriously leverage its position to purchase drugs for the medicare prescription benefits. Something that has apparently not occured...
Which just goes to show who the politicians really represent.
One million email accounts is quite a lot. You getting into the big league ISP category with something like this. It's not a one person operation to put something like this together. You're going to need a substantial number of well trained people to do this. There's only a couple players in the field at this level. Sun's JES Messaging system owns a sizeable chunk of the market, followed by OpenWave and a small gaggle of fly-by-nights with unproven track records.
Some of the larger email systems however are homegrown using open source parts. Yahoo and Google immediately come to mind, and they do work quite well. But you probably don't have the resources that they do to engineer & test something like this. Yahoo is rumored to have more than 200 people working on email alone.
Sun has a deployment like this canned, sitting on a shelf in Santa Clara. Tell them what you need, write a check, and they'll show up with the kit. 99.999% uptime if you write a big enough check. Make them to throw in the Waveset stuff.
Very interesting... The wording leaves one thinking Intel & BlueArc are announcing this. In fact the SPECmail report shows CommuniGate submitted the results. Why would Intel want to push a disk array that uses a Freescale PPC chip?
The interesting bit is that the storage is pure hardware; there is no PCI bus or general purpose CPU between disk and LAN slowing things down.
The SPECmail report says it's a Freescale MPC7457B PPC chip, and specifically mentions NFS, not SMB. http://www.freescale.com/webapp/sps/site/prod_sum
Sure looks like a general purpose CPU to me. Same family as used in the current Mac PB's, iBooks, and the Mini, with a bunch of speedy I/O stuff bolted on. This really isn't all that interesting a disk array. The Sun T3 used in the previous record is conceptually similar, though smaller. More importantly it uses FC/AL attach to the server, and this is NAS via NFS. I'm a big fan of networking, but this strikes me as one of those places where you're better off with a dedicated storage I/O channel like a FC/AL.
I'm left wondering why they chose NFS attach, and why Intel is mentioned as announcing this, since it promotes a Freescale processor in the disk solution, and from the actual SPECmail report, CommuniGate did the testing. Quite dodgy... I'd be a bit pissed if I were Intel.
Interestingly enough, they set their record using a message store mounted on NFS. It had 140 FC/AL attached disks, and 14Gb of RAM.
Virtually every file handle an MTA writes to is opened "O_SYNC". One of the quickest ways to make Sendmail or other common MTA's go fast is to mount their delivery queues on a solid state disk. I'm betting this disk array is turning around the queues without ever committing the data to the platters. (Not that there's anything wrong with this...) I am left wondering if there isn't some bit if NFS trickery not reported in the config.
But looking at the Sun entry, the old record was set using 2 year old software, and a much smaller disk configuration. Sun will probably update their entry in the near future, just to reclaim the crown. Email is much more an I/O problem than a CPU problem. Sun used to push their mail server on much larger HW, but most ISP's don't want to buy big boxes these days. The small to medium sized boxes, connected to a SAN are more cost effective, permit redundancy and easier maintenance.
4am. Also.... A bit faster than 65 mph. Empty space = No cops.
More proof that one can type and hit a bong at the same time.