The stats don't show that that its helping but you in Victoria you can (and will) get a ticket for going 103.1 in a 100 km range. The road between Melbourne and Sydney has cameras that take photos of registration (licenses) plates about 8 times along the 6 hr trip and if you are more than 3% over, they send you a ticket in the mail.
Note that the Australia Design Regulations for vehicles state a speedometre only needs to be accurate to +/-10%, so you should be able to challenge any speeding ticket that falls within that bound fairly easily.
With that said, pretty much all speedos read low by ~4-5%, so if you're ticketed for >5% or so over, it's essentially guaranteed you "knew" you were speeding.
Only a script kiddy would be asking how to crash windows on slashdot. If you are smart enough to use a web browser you are smart enough to google it.
Whether or not I can find some random method for crashing Windows is irrelevant. The question was can you provide details *for the situation you described*.
You do the best with what you have got, you will not have an unlimited budget of money and time no matter where you work or what you do.
The point is that the competent and responsible admin has made sure the business is *already* aware of the potential risks in their systems before any goes wrong. Ie: he should not be under pressure to get a machine to reboot as quickly as possible because the fact that it takes X amount of time to do should already be known by everyone involved, all of whom have agreed that X (more appropriately, several times X) is an acceptable period of unavailability for that machine. If X is not acceptable, then there should be a contingency plan in place to deal with the assumed failure and that plan should be put in effect when the failure happens.
When something unexpected happens it's never acceptable to blame people or tools, save it for later when all the facts are in.
I'm not quite sure why you think this is relevant. How long a machine takes to reboot is not "unexpected", nor are the consequences of a given machine being unavailable. If they are, then someone is grossly incompetent.
That's just foolish. Real world experience says you can't predict what's going to fail and you can't plan for what you don't expect.
If you can't predict - and propose steps to minimise, if not completely eliminate - the vast, vast majority of probable failure scenarios in your IT infrastructure, then you shouldn't be in any way involved in managing it.
Here, let's go back to the original scenario:
However boot times on servers are much more important. Say you have a power cut, your UPS fails and you have 10 racks of stuff to get up and running PDQ. You really will care about the 3 minutes extra per server you spend watching it POST check ram and scan for SCSI disks before it even gets to the filesystem checks.
There is nothing in that paragraph that could be justifiably not predicted and communicated to the business. Power fails. UPSes fail. Sometimes machines just crash. However, they take known amounts of time to start. The time and steps taken to ascertain functionality after an outage are (or certainly should be) also known.
I really don't think you have ever worked in IT. I'm starting to wonder if you have ever worked -ANYWHERE-.
Heh. That's pretty funny coming from the person apparently suggesting it's impossible predict with any certainty what's going to happen when a machine reboots and one has to be "thinking on their feet" when it happens.
Thinking on your feet is critical to any and all professions not just IT.
Next time you find yourself "thinking on your feet", ask yourself how much of that time could have been spent "thinking on the sofa" beforehand.
Not really. It's well proven that people will break any limit a little as long as the risk/benefit is in their favor, and won't back down until you're way over the limit.
"Well proven" where ?
Speeding is a very good example, I think everybody agree you need speed limits and can't have people going 100 km/h through a residential area that should have 35 km/h.
If someone is prepared to do 100km/h down a residential street, then a number printed on a sign is in no way going to deter them.
So you make the limit 30 km/h, most people drive 35 km/h but you can hit those going 40 km/h+ hard because they're like "way over". Those that go 35 km/h aren't practically punished because there's so many and the fines would be so little because it's just over, in fact the speeding cameras and traffic controls normally don't issue tickets at the lowest level. It wouldn't matter if the limit is 40, 50 or 60 km/h, it's always this way.
It is not. *Properly* set speed limits, using the 85th percentile rule are only exceeded by a minority of people, and that proportion drops off further as the speed limit is increased (ie: does not stay constant, as you suggest).
If you have a section of road where the 85th percentile is 40km/h (let's say, outside a school at 3:30pm), then posting an 80km/h limit is not going to result is people driving down that street at 80km/h+.
Call it a little bit of marketing - instead of increasing the limits and having a real sharp dropoff, they put the limits very conservatively, let people skirt the rules a little and get general agreement that too much is too much.
If a significant proportion of people are exceeding the limit, then the limit is too low.
So it's much more about human nature than actually being bad laws.
So how do you think your "human nature" works on roads that have no speed limits ? You think everyone just keeps accelerating until they hit their vehicle's top speed ?
There is a large body of research and well understood science behind setting speed limits. Even though it is typically ignored and/or improperly used by politicians who see it as an easy source of revenue, and scorned by save-the-children types who have no idea what actual road safety entails, it most certainly exists - and it in no way supports the assertion that "people will break any limit a little".
Contingency plans can fail too and depend on having enough budget.
If the business isn't prepared to pony up the money, then it clearly doesn't consider that particular risk significant. This is not the fault of the admin or the software.
To the specific example given, however, the point is simple: if the time it takes to reboot a machine (or, indeed, the fact you need to reboot a machine at all) has a negative impact on availability, then your architecture is either broken or fundamentally incapable of providing the service level demanded of it. This is true regardless of what OS you're running.
Individual machine downtime - *especially* scheduled downtime - should not affect service delivery. If it does, your architecture is fundamentally broken and the person who designed and/or approved it has failed in their job.
Can you provide examples of how contingency plans fit into every possible IT failure?
If you list some potential failure scenarios, I'm sure I can come up with a plan to cover pretty much all of them.
You're not going to get that kind of uptime from a Windows box even without problems, thanks to patch tuesdays.
You don't _have_ to patch, you know, only if you are (or think you will be) impacted by the problems fixed.
Of course, it depends on how downtime is defined. If you use Microsoft's definition, "scheduled maintenance windows" are not classified as down time, but the rest of the world defines such things as down time.
No, it doesn't. Most SLAs allow for scheduled maintenance and do not consider that downtime. In any event, if your environment is such that the service must remain available during maintenance periods, then you can't do it with a single server, regardless of what your OS is.
without redefining down time like Microsoft does, you will never achieve that kind of uptime on Windows unless a) the box NEVER get infected b) you NEVER install the Windows updates and c) you NEVER change the configuration or change/update any software.
If your requirement allows for only minutes or hours of downtime per year, then you *must* have multiple servers to be able to confidently deliver it. Once you have multiple servers, individual server outages for scheduled maintenance, are irrelevant.
However boot times on servers are much more important. Say you have a power cut, your UPS fails and you have 10 racks of stuff to get up and running PDQ. You really will care about the 3 minutes extra per server you spend watching it POST check ram and scan for SCSI disks before it even gets to the filesystem checks.
If you cared that much, you'd have contingency plans in place so that how long those servers took to restart didn't matter.
Yes, we do, and that is wasteful. With faster boot and support for wake-on-lan in routers, we could be making significant energy savings.
Boot times have exactly zero to do with why I leave my PCs on all the time and, I suspect, the same is true for the vast majority of people who also do so.
MS-DOS was QDOS brought and rebranded. MS didn't create it yet they told everyone they did.
Where did they say that ?
The windows desktop environment was a mac or PARC or X clone, not sure which. It wasn't new but they pushed it like it was.
You have an example of Microsoft saying that Windows was the first GUI, or something similar ?
The Windows NT OS was reimplementation of VMS and UNIX systems, only not done nearly as well as either. They called it NT for New Technology and marketing it as the stable 'business' alternative to dos based windows.
And which part of their marketing was "lying about having done it first" ? Do you have some quotes ?
Excel was a Lotus 1-2-3 clone. The pivot tables accountants love so much were copied from Lotus too. They sell their office package like crazy but they didn't develop the core of it.
"Develop" in what sense ? The code itself ? The idea ? Are you seriously suggesting anyone who implements an existing idea is a liar ? Because that's going to make pretty much every software developer in the world a liar.
Word was a wordstar clone.
And they lied about it being "the first" where, exactly ?
Internet Explorer was a mosaic clone. Although MS are giving it away for nothing they are still marketing it like crazy.
Actually it was a straight-our Mosaic fork (at least until the IE3.x rewrite). However, when did they claim it was the first web browser ?
Active Directory is just a LDAP clone. They market it as something which will solve all the worlds problems.
Actually it's a lot more than an LDAP clone, and whether they market it as being a good solution is utterly irrelevant to your claim about them "lying about having done it first".
All your complaints about are just about normal marketing, that everyone does. A long way from your claim of "lie about having done it first".
First, look at those opterons again and look at the 4 socket plus 4 socket riser Tyan stuff again, you information is somewhat out of date which is why I'm talking about new possibilities while you are putting forward what has only recently become an incorrect argument.
Supported CPU Series: AMD 45nm Quad-Core Opteron 8300 Series Processors [...]
AMD's FAQ also notes that 2000-series CPUs only support two socket boards.
If you have information about 2000-series CPUs working in 8-socket boards, then by all means share it, but it certainly appears that would be news to both Tyan and AMD.
You end up with annoyingly long periods of time where one node is still going and other nodes are waiting for it. When the price point shifts radically why take "adequate" when "good" isn't much more expensive.
Because at this point it appears "good" is still much more expensive.
Also you have entirely missed the point that there are many jobs that are entirely CPU bound and that is what I was writing about, I'm saying there are many cases where you have jobs that are purely limited by how many instructions you can do and that is what you throw systems or clusters with a lot of CPUs at.
I haven't missed the point at all, I'm simply highlighting the fact that such jobs - where a cluster of machines interconnected with Ethernet, Infiniband, or similar won't do it just as well, and a lot cheaper - are few and far between.
IMHO your example has a premise that experience with both Xeon and opteron systems shows has little merit about the speed difference, your misunderstanding of my statements and your mixing up of terminology of CPU to the stupid salesfolk form instead of anything of technical use is too much for me to handle this late at night.
Uh huh. Perhaps you can enlighten me about how I have misused any terminology rather than wave your hands about.
More like $635 Australian each for a cheaper 6 core opteron which still has decent speed. Your economy hasn't tanked so much that adds up to $2,500 US each.
You are looking at the 2000-series CPUs that only work in dual-processor configurations. You need 8000-series processors for your 8-socket board, and on NewEgg the cheapest ones are priced at 2,139.99 (missed them the first time and only saw the 8435s at $2,649.99 each).
There are many, many situations where you want that much power in a single box and would even like a cluster of them if you can afford it - just not in your garage or a web server.
No, there's aren't. You only need such a large amount of processing power in a single box if your applications is highly reliant on extremely low-latency and high bandwidth between processing units for decent performance. Those are niche situations.
Ask nearly any engineer, geophysicist (or scientist in nearly any field), industrial designer, movie special effects people etc etc.
Most of these applications are handled more than adequately with Ethernet, Infiniband and/or Fibre Channel interconnects. Rnedering special effects, in particular, is one of those "embarassingly parallel" problems where a large number of relatively low-powered machines work exceptionally well. This is especially true when you start looking at the relative prices (see below).
Since it's getting to around the $5000 mark for such a 48 core system it suddenly gets to the point where you can find a lot of uses for them.
It's not. Assuming you're referring to the Tyan S4985-E, your 48-core system is going to have a starting cost somewhere in the ballpark of US$20,000, using the 2.4Ghz 8431s @ ~$2,100ea (assuming about $3,000 for the rest of the machine).
Now, a quad-core 5500-series Xeon has about the same performance as a 6-core Opteron at the same clock speed. So you'd need 8 CPUs in a cluster to match the "48-core" machine you're talking about in terms of processing power. Using Dell's off the shelf hardware, you could do that for:
$14,000 (four dual-CPU Precision 5500s @ ~$,3500ea)
$11,000 (four dual-CPU R410s @ ~$2,700ea)
$9,000 (eight single-CPU XPS 9000s @ ~$1,100ea - though you sacrifice ECC to do it).
Admittedly most developers do not have a clue how to write applications that can actually use more than a single core in an era where kids have handheld dual core video games (Nintendo DS), but the hardware is there.
The biggest problem is that the vast majority of problems simply aren't parellisable, which is then exacerbated by the fact that CPU power is typically not the main bottleneck in a system.
because the menu is one click move mouse (to read the menu, not once dialog windows get involved).
The ribbon is 2 clicks, fairly distant, with the second one on a very small button, for each menu heading.
This is ludicrously pedantic. I doubt you could even measure the difference in time it takes for one vs the other with a stopwatch, and even if you could it certainly wouldn't be significant.
Or someone could use the ribbons as toolbars, but turn on the menu when they wanted to search though the menu.The thing is that the Ribbon already behaves essentially the same way as a menu, if you're "hunting around".
OS X, however, was made after Apple finally scrapped OS 9 for a bold new OS.
But then they went and reimplemented basically the same GUI on top of that OS...
Yes, a lot of people back then complained about how "confusing" it was, but now, I don't think you can get anyone to honestly say they like OS 9 better than OS X.
Maybe you should read about John Siracusa's thoughts on the Finder. Or Tog's thoughts on the Dock.
The OS X GUI is designed (and updated) first and foremost to look cool. Usability is very much a secondary priority (a sad inversion of Apple's history).
The reason I feel so confident walking around and fixing my user's problems even though I may never have worked with the program they are using before, is because menus make things easy to find. http://www.xkcd.com/627/ [xkcd.com]
I think you need to read the text in that first decision box a bit more closely.
But, when I want to autofit cells width in Excel (I actually couldn't find this in office 2k7), I used to select a column and go to the menu, now I need to select a column, go to the correct ribbon, then potentially open the menu with the very small hard to hit open menu button.
For reference, you can just double-click on the divider between the two cell heading buttons ('A', 'B', etc) to autofit the selected cells.
This is fine and dandy, until I picked the wrong one, and need to click another small open menu button (or even a new ribbon).
How is this any different from clicking the wrong thing in a menu, though ?
Even MS understood this with Win7, where they made the overall UI responsiveness faster, even if the actual things are still loading.
They understood it a lot further back than that. In Windows 95, the foreground window thread automatically ran at a higher priority than background window threads.
(Heck, Windows has pretty much _always_ had one of the most responsive UIs.)
A system with Tyan boards (main plus riser) giving you 8 SOCKETS with the cheapest 6 core opterons you can get is not going to be much more than twice the price of that Dell and give you 48 CPUs (so long as you have the same amount of memory on both).
Just the CPUs for that setup cost over $2,500 each (Opteron 8435s). Somehow I don't think you're going to be price-competitive.
There are very, very few situations that need that much processing power in a single box.
Firstly, I was wrong initially. I accidentally selected the wrong starting config for the 500 and thus only got the single-CPU version not the dual. However, the price difference is still significant.
FWIW -- I can't really get a Dell with the same components as the entry level Mac Pro (which uses the Xeon 3500 series in a single chip configuration) to be 2/3 less.
I didn't say 2/3 less, I said 2/3 as much (so 1/3 less). I also said a Precision *5500*, not 3500.
As per the post I originally replied to, an 8-core Mac Pro is $3299 base. Adding Applecare to match the standard Dell warranty, and you get $3,548.
A Dell Precision 5500, with the same 2.26Ghz CPUs, 6GB RAM and an 80GB drive (this is a processing node, remember) is $2,731. Bumping the drive up to 500GB gives $2,977.
So not 30% cheaper, but still 15% - not insignificant (and unlike Apple, Dell will actually give you discounts if you're buying a few of them).
I can configure this machine to be the same basic (with a fairly superior graphic card I might add): Dell Precision T3500 64bit... but the price is right up there around 3700 bucks which is more than the entry Mac Pro with same processor, etc...
Wow. I can't even begin to think what you've added to a *3500* to get the price up to $3,700 (for $3,700, I can spec a 3500 with 12GB of RAM, four drives in a RAID10, two video cards and two 20" screens). However, even assuming you meant a *5500*, for the $3,568 cost of a Mac Pro you get a 5500 with the same CPUs, twice as much RAM, a better video card, a slightly smaller hard disk, and enough change to buy dinner.
Slashdot Mirror
The stats don't show that that its helping but you in Victoria you can (and will) get a ticket for going 103.1 in a 100 km range. The road between Melbourne and Sydney has cameras that take photos of registration (licenses) plates about 8 times along the 6 hr trip and if you are more than 3% over, they send you a ticket in the mail.
Note that the Australia Design Regulations for vehicles state a speedometre only needs to be accurate to +/-10%, so you should be able to challenge any speeding ticket that falls within that bound fairly easily.
With that said, pretty much all speedos read low by ~4-5%, so if you're ticketed for >5% or so over, it's essentially guaranteed you "knew" you were speeding.
Only a script kiddy would be asking how to crash windows on slashdot. If you are smart enough to use a web browser you are smart enough to google it.
Whether or not I can find some random method for crashing Windows is irrelevant. The question was can you provide details *for the situation you described*.
You do the best with what you have got, you will not have an unlimited budget of money and time no matter where you work or what you do.
The point is that the competent and responsible admin has made sure the business is *already* aware of the potential risks in their systems before any goes wrong. Ie: he should not be under pressure to get a machine to reboot as quickly as possible because the fact that it takes X amount of time to do should already be known by everyone involved, all of whom have agreed that X (more appropriately, several times X) is an acceptable period of unavailability for that machine. If X is not acceptable, then there should be a contingency plan in place to deal with the assumed failure and that plan should be put in effect when the failure happens.
When something unexpected happens it's never acceptable to blame people or tools, save it for later when all the facts are in.
I'm not quite sure why you think this is relevant. How long a machine takes to reboot is not "unexpected", nor are the consequences of a given machine being unavailable. If they are, then someone is grossly incompetent.
That's just foolish. Real world experience says you can't predict what's going to fail and you can't plan for what you don't expect.
If you can't predict - and propose steps to minimise, if not completely eliminate - the vast, vast majority of probable failure scenarios in your IT infrastructure, then you shouldn't be in any way involved in managing it.
Here, let's go back to the original scenario:
However boot times on servers are much more important. Say you have a power cut, your UPS fails and you have 10 racks of stuff to get up and running PDQ. You really will care about the 3 minutes extra per server you spend watching it POST check ram and scan for SCSI disks before it even gets to the filesystem checks.
There is nothing in that paragraph that could be justifiably not predicted and communicated to the business. Power fails. UPSes fail. Sometimes machines just crash. However, they take known amounts of time to start. The time and steps taken to ascertain functionality after an outage are (or certainly should be) also known.
I really don't think you have ever worked in IT. I'm starting to wonder if you have ever worked -ANYWHERE-.
Heh. That's pretty funny coming from the person apparently suggesting it's impossible predict with any certainty what's going to happen when a machine reboots and one has to be "thinking on their feet" when it happens.
Thinking on your feet is critical to any and all professions not just IT.
Next time you find yourself "thinking on your feet", ask yourself how much of that time could have been spent "thinking on the sofa" beforehand.
Not really. It's well proven that people will break any limit a little as long as the risk/benefit is in their favor, and won't back down until you're way over the limit.
"Well proven" where ?
Speeding is a very good example, I think everybody agree you need speed limits and can't have people going 100 km/h through a residential area that should have 35 km/h.
If someone is prepared to do 100km/h down a residential street, then a number printed on a sign is in no way going to deter them.
So you make the limit 30 km/h, most people drive 35 km/h but you can hit those going 40 km/h+ hard because they're like "way over". Those that go 35 km/h aren't practically punished because there's so many and the fines would be so little because it's just over, in fact the speeding cameras and traffic controls normally don't issue tickets at the lowest level. It wouldn't matter if the limit is 40, 50 or 60 km/h, it's always this way.
It is not. *Properly* set speed limits, using the 85th percentile rule are only exceeded by a minority of people, and that proportion drops off further as the speed limit is increased (ie: does not stay constant, as you suggest).
If you have a section of road where the 85th percentile is 40km/h (let's say, outside a school at 3:30pm), then posting an 80km/h limit is not going to result is people driving down that street at 80km/h+.
Call it a little bit of marketing - instead of increasing the limits and having a real sharp dropoff, they put the limits very conservatively, let people skirt the rules a little and get general agreement that too much is too much.
If a significant proportion of people are exceeding the limit, then the limit is too low.
So it's much more about human nature than actually being bad laws.
So how do you think your "human nature" works on roads that have no speed limits ? You think everyone just keeps accelerating until they hit their vehicle's top speed ?
There is a large body of research and well understood science behind setting speed limits. Even though it is typically ignored and/or improperly used by politicians who see it as an easy source of revenue, and scorned by save-the-children types who have no idea what actual road safety entails, it most certainly exists - and it in no way supports the assertion that "people will break any limit a little".
What that says about human nature [...]
It says much more about the laws than the people.
So, that would be a "no", then.
Contingency plans can fail too and depend on having enough budget.
If the business isn't prepared to pony up the money, then it clearly doesn't consider that particular risk significant. This is not the fault of the admin or the software.
To the specific example given, however, the point is simple: if the time it takes to reboot a machine (or, indeed, the fact you need to reboot a machine at all) has a negative impact on availability, then your architecture is either broken or fundamentally incapable of providing the service level demanded of it. This is true regardless of what OS you're running.
Individual machine downtime - *especially* scheduled downtime - should not affect service delivery. If it does, your architecture is fundamentally broken and the person who designed and/or approved it has failed in their job.
Can you provide examples of how contingency plans fit into every possible IT failure?
If you list some potential failure scenarios, I'm sure I can come up with a plan to cover pretty much all of them.
You're not going to get that kind of uptime from a Windows box even without problems, thanks to patch tuesdays.
You don't _have_ to patch, you know, only if you are (or think you will be) impacted by the problems fixed.
Of course, it depends on how downtime is defined. If you use Microsoft's definition, "scheduled maintenance windows" are not classified as down time, but the rest of the world defines such things as down time.
No, it doesn't. Most SLAs allow for scheduled maintenance and do not consider that downtime. In any event, if your environment is such that the service must remain available during maintenance periods, then you can't do it with a single server, regardless of what your OS is.
without redefining down time like Microsoft does, you will never achieve that kind of uptime on Windows unless a) the box NEVER get infected b) you NEVER install the Windows updates and c) you NEVER change the configuration or change/update any software.
If your requirement allows for only minutes or hours of downtime per year, then you *must* have multiple servers to be able to confidently deliver it. Once you have multiple servers, individual server outages for scheduled maintenance, are irrelevant.
However boot times on servers are much more important. Say you have a power cut, your UPS fails and you have 10 racks of stuff to get up and running PDQ. You really will care about the 3 minutes extra per server you spend watching it POST check ram and scan for SCSI disks before it even gets to the filesystem checks.
If you cared that much, you'd have contingency plans in place so that how long those servers took to restart didn't matter.
Yes, we do, and that is wasteful. With faster boot and support for wake-on-lan in routers, we could be making significant energy savings.
Boot times have exactly zero to do with why I leave my PCs on all the time and, I suspect, the same is true for the vast majority of people who also do so.
That's not an "application level error".
MS-DOS was QDOS brought and rebranded. MS didn't create it yet they told everyone they did.
Where did they say that ?
The windows desktop environment was a mac or PARC or X clone, not sure which. It wasn't new but they pushed it like it was.
You have an example of Microsoft saying that Windows was the first GUI, or something similar ?
The Windows NT OS was reimplementation of VMS and UNIX systems, only not done nearly as well as either. They called it NT for New Technology and marketing it as the stable 'business' alternative to dos based windows.
And which part of their marketing was "lying about having done it first" ? Do you have some quotes ?
Excel was a Lotus 1-2-3 clone. The pivot tables accountants love so much were copied from Lotus too. They sell their office package like crazy but they didn't develop the core of it.
"Develop" in what sense ? The code itself ? The idea ? Are you seriously suggesting anyone who implements an existing idea is a liar ? Because that's going to make pretty much every software developer in the world a liar.
Word was a wordstar clone.
And they lied about it being "the first" where, exactly ?
Internet Explorer was a mosaic clone. Although MS are giving it away for nothing they are still marketing it like crazy.
Actually it was a straight-our Mosaic fork (at least until the IE3.x rewrite). However, when did they claim it was the first web browser ?
Active Directory is just a LDAP clone. They market it as something which will solve all the worlds problems.
Actually it's a lot more than an LDAP clone, and whether they market it as being a good solution is utterly irrelevant to your claim about them "lying about having done it first".
All your complaints about are just about normal marketing, that everyone does. A long way from your claim of "lie about having done it first".
I think the 'Genuine Innovation' bit comes in when they lie about having done it first in some huge expensive marketing campaign.
Can you provide an example of this ?
no shit. I wince every time I have to type a path with "Documents and Settings". ..
If you insist on using the commandline, maybe you should learn some of the shortcuts ?
Chain crashes of multiple machines do happen and application level errors often cause a blue screen and leave no logs to indicate what went wrong.
Can you provide details on how to replicate this behaviour ?
Ever seen a virus wipe out over a thousand production servers in a day? I have on windows but never on anything unix based.
Can you provide details on how it managed to do so ? Vectors, ACL misconfigurations, etc ?
First, look at those opterons again and look at the 4 socket plus 4 socket riser Tyan stuff again, you information is somewhat out of date which is why I'm talking about new possibilities while you are putting forward what has only recently become an incorrect argument.
From Tyan's page:
Supported CPU Series: AMD 45nm Quad-Core Opteron 8300 Series Processors [...]
AMD's FAQ also notes that 2000-series CPUs only support two socket boards.
If you have information about 2000-series CPUs working in 8-socket boards, then by all means share it, but it certainly appears that would be news to both Tyan and AMD.
You end up with annoyingly long periods of time where one node is still going and other nodes are waiting for it. When the price point shifts radically why take "adequate" when "good" isn't much more expensive.
Because at this point it appears "good" is still much more expensive.
Also you have entirely missed the point that there are many jobs that are entirely CPU bound and that is what I was writing about, I'm saying there are many cases where you have jobs that are purely limited by how many instructions you can do and that is what you throw systems or clusters with a lot of CPUs at.
I haven't missed the point at all, I'm simply highlighting the fact that such jobs - where a cluster of machines interconnected with Ethernet, Infiniband, or similar won't do it just as well, and a lot cheaper - are few and far between.
IMHO your example has a premise that experience with both Xeon and opteron systems shows has little merit about the speed difference, your misunderstanding of my statements and your mixing up of terminology of CPU to the stupid salesfolk form instead of anything of technical use is too much for me to handle this late at night.
Uh huh. Perhaps you can enlighten me about how I have misused any terminology rather than wave your hands about.
More like $635 Australian each for a cheaper 6 core opteron which still has decent speed. Your economy hasn't tanked so much that adds up to $2,500 US each.
You are looking at the 2000-series CPUs that only work in dual-processor configurations. You need 8000-series processors for your 8-socket board, and on NewEgg the cheapest ones are priced at 2,139.99 (missed them the first time and only saw the 8435s at $2,649.99 each).
There are many, many situations where you want that much power in a single box and would even like a cluster of them if you can afford it - just not in your garage or a web server.
No, there's aren't. You only need such a large amount of processing power in a single box if your applications is highly reliant on extremely low-latency and high bandwidth between processing units for decent performance. Those are niche situations.
Ask nearly any engineer, geophysicist (or scientist in nearly any field), industrial designer, movie special effects people etc etc.
Most of these applications are handled more than adequately with Ethernet, Infiniband and/or Fibre Channel interconnects. Rnedering special effects, in particular, is one of those "embarassingly parallel" problems where a large number of relatively low-powered machines work exceptionally well. This is especially true when you start looking at the relative prices (see below).
Since it's getting to around the $5000 mark for such a 48 core system it suddenly gets to the point where you can find a lot of uses for them.
It's not. Assuming you're referring to the Tyan S4985-E, your 48-core system is going to have a starting cost somewhere in the ballpark of US$20,000, using the 2.4Ghz 8431s @ ~$2,100ea (assuming about $3,000 for the rest of the machine).
Now, a quad-core 5500-series Xeon has about the same performance as a 6-core Opteron at the same clock speed. So you'd need 8 CPUs in a cluster to match the "48-core" machine you're talking about in terms of processing power. Using Dell's off the shelf hardware, you could do that for:
$14,000 (four dual-CPU Precision 5500s @ ~$,3500ea)
$11,000 (four dual-CPU R410s @ ~$2,700ea)
$9,000 (eight single-CPU XPS 9000s @ ~$1,100ea - though you sacrifice ECC to do it).
Admittedly most developers do not have a clue how to write applications that can actually use more than a single core in an era where kids have handheld dual core video games (Nintendo DS), but the hardware is there.
The biggest problem is that the vast majority of problems simply aren't parellisable, which is then exacerbated by the fact that CPU power is typically not the main bottleneck in a system.
because the menu is one click move mouse (to read the menu, not once dialog windows get involved).
The ribbon is 2 clicks, fairly distant, with the second one on a very small button, for each menu heading.
This is ludicrously pedantic. I doubt you could even measure the difference in time it takes for one vs the other with a stopwatch, and even if you could it certainly wouldn't be significant.
Or someone could use the ribbons as toolbars, but turn on the menu when they wanted to search though the menu.The thing is that the Ribbon already behaves essentially the same way as a menu, if you're "hunting around".
OS X, however, was made after Apple finally scrapped OS 9 for a bold new OS.
But then they went and reimplemented basically the same GUI on top of that OS...
Yes, a lot of people back then complained about how "confusing" it was, but now, I don't think you can get anyone to honestly say they like OS 9 better than OS X.
Maybe you should read about John Siracusa's thoughts on the Finder. Or Tog's thoughts on the Dock.
The OS X GUI is designed (and updated) first and foremost to look cool. Usability is very much a secondary priority (a sad inversion of Apple's history).
The reason I feel so confident walking around and fixing my user's problems even though I may never have worked with the program they are using before, is because menus make things easy to find. http://www.xkcd.com/627/ [xkcd.com]
I think you need to read the text in that first decision box a bit more closely.
But, when I want to autofit cells width in Excel (I actually couldn't find this in office 2k7), I used to select a column and go to the menu, now I need to select a column, go to the correct ribbon, then potentially open the menu with the very small hard to hit open menu button.
For reference, you can just double-click on the divider between the two cell heading buttons ('A', 'B', etc) to autofit the selected cells.
This is fine and dandy, until I picked the wrong one, and need to click another small open menu button (or even a new ribbon).
How is this any different from clicking the wrong thing in a menu, though ?
Linux can look like anything including but not limited to various generations of Windows, MacOS, NeXT and BeOS.
Sadly, however, it rarely _works_ like them.
Even MS understood this with Win7, where they made the overall UI responsiveness faster, even if the actual things are still loading.
They understood it a lot further back than that. In Windows 95, the foreground window thread automatically ran at a higher priority than background window threads.
(Heck, Windows has pretty much _always_ had one of the most responsive UIs.)
A system with Tyan boards (main plus riser) giving you 8 SOCKETS with the cheapest 6 core opterons you can get is not going to be much more than twice the price of that Dell and give you 48 CPUs (so long as you have the same amount of memory on both).
Just the CPUs for that setup cost over $2,500 each (Opteron 8435s). Somehow I don't think you're going to be price-competitive.
There are very, very few situations that need that much processing power in a single box.
Firstly, I was wrong initially. I accidentally selected the wrong starting config for the 500 and thus only got the single-CPU version not the dual. However, the price difference is still significant.
FWIW -- I can't really get a Dell with the same components as the entry level Mac Pro (which uses the Xeon 3500 series in a single chip configuration) to be 2/3 less.
I didn't say 2/3 less, I said 2/3 as much (so 1/3 less). I also said a Precision *5500*, not 3500.
As per the post I originally replied to, an 8-core Mac Pro is $3299 base. Adding Applecare to match the standard Dell warranty, and you get $3,548.
A Dell Precision 5500, with the same 2.26Ghz CPUs, 6GB RAM and an 80GB drive (this is a processing node, remember) is $2,731. Bumping the drive up to 500GB gives $2,977.
So not 30% cheaper, but still 15% - not insignificant (and unlike Apple, Dell will actually give you discounts if you're buying a few of them).
I can configure this machine to be the same basic (with a fairly superior graphic card I might add): Dell Precision T3500 64bit ... but the price is right up there around 3700 bucks which is more than the entry Mac Pro with same processor, etc...
Wow. I can't even begin to think what you've added to a *3500* to get the price up to $3,700 (for $3,700, I can spec a 3500 with 12GB of RAM, four drives in a RAID10, two video cards and two 20" screens). However, even assuming you meant a *5500*, for the $3,568 cost of a Mac Pro you get a 5500 with the same CPUs, twice as much RAM, a better video card, a slightly smaller hard disk, and enough change to buy dinner.