So what? "Dumb" terminals have had plenty of intelligence for decades. You do know people did CAD/CAM on them, right?

And yet, in the real world, that's what many single frame mainframe shops manage. Probably because a single frame isn't at all a single frame internally. The only singleton in the equation is the cabinet itself, and (but only if the operator wants) any particular operating system/middleware/application instances that the operator chooses to run that way (which would typically be development instances, not production).

No, they're doing that because somebody had a memory leak 30+ years ago (back when those might have mattered from a system stability point of view), told the operators to reboot (IPL) every week, and the operators have never updated their procedure manuals. I'm not joking. If you tap an operator on the shoulder and say, "Stop rebooting now," problem solved. (Or, for the ultra-conservatives, switch to once every month, then once every year, then not at all.)

Or, in the alternative, somebody decided 30+ years ago that they'd tell the users the system would be unavailable each weekend for a couple hours for "system maintenance" (back when that might have made sense), then, many years ago (and particularly with Parallel Sysplex), when the operators no longer needed the "maintenance window," nobody bothered to tell the users the good news and make it official. Again, I'm not joking. I was at a meeting at a Fortune 100 company where the conversation went something like this.... Web service team: "We need 24 hour Internet access, but you're down every weekend for 4 hours. We want to move off." Mainframe operator: "You need 24 hours? OK, you have 24 hours." Web service team: "But you didn't do anything." Mainframe operator: "We stopped IPL'ing that LPAR at least 10 years ago, and I'm now declaring you have a 24 hour Service Level Agreement. I'll update our SLA just after our meeting. Need anything else?" Web service team: "Uh, that'll do."

If you want 99.999+ percent business service uptime, factoring in both planned and unplanned outages, and even disaster recovery, just ask for it. (Or ask for some other level if that's too much.) It's no myth, it's the owner's choice, consistent with their budget and "reasonable" (but not superhuman) operations staff.

You posted to Slashdot. You're using a thin client. It's called a Web browser. Welcome to the future.

Good question. There are two physical sizes available: a System z10 BC and System z10 EC. The BC is roughly the same size as a single conventional rack of pizza box servers, and the EC is a double wide (about two racks). In refrigerator terms that's probably closer to the JennAir (or two for the EC) but well shy of the cow locker. Here's a picture of the EC shown to scale with two IBM executives: http://japan.zdnet.com/news/hardware/story/0,2000056184,20368219,00.htm?tag=z.keyword.st

Then why aren't you driving a Yugo (I presume)? It has a lower price, doesn't it? :-)

That's up to Microsoft. I can't wait to see Microsoft's mainframe price list. :-) But if Microsoft wants to be competitive with Oracle and IBM, to pick a couple software vendor examples, then for server software at least (e.g. Microsoft SQL Server) they'd license by core. And yes, a core is a core is a core. How the price of that Yugo looking? :-)

That's part of it, but it's not the only part. Otherwise we'd see thousands of virtual machines on a single ESX core, and that's just not what's happening. (The virtualization ratios per core are pretty small. Still useful, though.) Virtualization also places heavy stresses on cache, memory, and I/O performance. IBM System z10 machines are no slouches on CPU -- they have the highest clock speed (4.4 GHz) CPUs with more than 2 cores (they're quad) on the market -- but they balance that with kick-ass cache, main memory, and I/O performance. They also have hypervisors (PR/SM and z/VM) which are extremely refined and uniquely co-evolved with the hardware over decades. Add that all together and you begin to understand why the virtualization ratios get much higher in real world use.

Yes, the usual myriad of analysts (Gartner, Forrester, etc.) have looked at the issue, and, to net it out, they find both IBM System z virtualization and VMware useful and cost-effective. ("Both" is often the right answer, because some workloads do better on one or the other, and most businesses have a mix of workload types.) One bright dividing line has been that VMware obviously can virtualize Microsoft Windows directly (such as Microsoft Exchange and Microsoft SQL Server), while System z could not. But System z has been adding whole operating systems to its virtualization repertoire, including OpenSolaris for System z and now (with Mantissa) Microsoft Windows, so it's moving into new ground.

Cost isn't the only issue of course. Qualities of Service (QoS) are also important. It's undisputed that IBM System z offers the highest QoS characteristics attainable for any particular operating system(s) that run on it. (That is, if you run, say, Linux on an IBM mainframe, from a QoS point of view it'll be the best Linux possible.) High QoS requirements form another bright dividing line.

Really? Because that's not how it works for Linux on IBM mainframes, and there's plenty of experience with that. There really are fewer operations staff required, and those fewer staff deliver much higher quality service.

Windows may still crash on a mainframe, but it'll crash perfectly, exactly as Microsoft intended (or at least coded), consistently every time.

To keep the answer simple, a single mainframe is a cluster. Everything inside is redundant and hot swappable. And it offers those advantages whether or not the software cares to know about it, and without a single dollar of extra labor. (Although, if the operating system and middleware participate, such as z/OS and DB2 data sharing to pick an example, even more amazing things are possible.)

For example, if a CPU core fails, an IBM System z mainframe will detect it, prevent the mis-executed instruction from surfacing to the operating system, take the core offline, provision a spare core, and continue executing without interruption. All without even the operating system programmer having to write a single (probably buggy) line of code. That's just one example. There are huge differences and huge advantages for many (not all) businesses and applications.

Good point. The first comment about "unusual word sizes" was really pretty funny, because the commenter quite obviously has little understanding of computing history. It was the IBM System/360 (the ancestor to today's IBM System z mainframe) that defined the 8-bit byte and 32-bit word as industry standards, influencing CPU architectures (including Intel's) right to the present day. Otherwise we'd probably have multiples of 6 or possibly 7 bits as our foundational standard for computing. (And there was a lot of pressure during the System/360's design to cheapen up the hardware and slice off a bit or two.)

Perhaps the original commenter would like to open up a command line in Microsoft Windows Vista and count the default number of columns. That number is 80. Why 80? Because, coincidentally about 80 years ago, someone at IBM decided that tabulating cards should be 80 columns wide, and IBM's cards were more popular than Remington's. Yes, Grasshopper, Microsoft Windows has an "unusual" column width that persists to this day.

Sorry, you're quite wrong in multiple ways. The first way you're wrong is that, if Mantissa's z/VOS runs X86 software, it runs X86 software. That would include IEEE floating point, Windows Solitaire, whatever. The second way is that mainframes have always been able to execute IEEE floating point in software, but they (also) in hardware implement IBM floating point. (Thus programmers generally used the hardware implementation in their applications, and why not? But nothing prevented them from running IEEE floating point calculations.) The third way you're wrong is that IBM's System z9 was the first machine in the world to implement IEEE754(r) decimal floating point in microcode. Today the only CPUs in the world that implement IEEE754(r) fully in hardware are POWER6 and System z10. And it looks like it'll stay that way: Intel and IBM just disagree about this aspect of CPU design.

I have never heard of a ballistic missile that could not be tracked back to its point of origin. That means if Iran ever launches a missile as a weapon it'll be her last.

1. Satellite links, primarily as backup. LEO satellites are better, if possible.
2. Microwave links, again primarily as backup. Requires line of sight hops but might be appropriate to "skip over" certain places. The taller the towers, the more geography that can be skipped.
3. Tethered balloons. (The U.S. uses these on its borders in its aerostat system.)
4. A polar cable route, such as Norway to Alaska to Japan. With global warming this route becomes increasingly practical, but it might be technically possible already with the help of a submarine.
5. Mesh hops. Scatter numerous radioisotope-powered repeaters along the sea bed and let them chat with each other. Drop a few more every so often to keep the mesh sufficiently healthy.
6. Local network rerouting. As a backup, reroute traffic over the various national short-haul networks between India and Europe. Pay for carriage and let the various countries in between compete.