Just because someone doesn't put up a mechanism to prevent this, doesn't mean this use of their system is authorized. If they have a policy, either in written TOS form or something automated like robots.txt, and you violate it, this could be considered unauthorized access under the law, and you could personally be held criminally responsible.
Fission and fusion can both be either endothermic or exothermic, depending on what you're working with. If you're working with atoms lighter than Iron, you get energy from fusion, and fission requires providing energy. If you're working with atoms heavier than Iron, you get energy from fission, and fusion requires providing energy. If you're working with Iron, you have to provide energy for both.
...is rising to the level of complexity of a simple operating system. They do a lot of very smart things in there to catch problems before they become unrecoverable, and they even report them to you via SMART so you can tell when they're at an increased risk of failure.
The catch is, there are several different ways to optimize firmware. Drives intended to be used in RAID arrays have different firmware from drives intended for desktop or laptop use. If you use desktop drives in a large RAID array, with a rather fault-intolerant parity RAID implementation, YOU ARE AN IDIOT AND DESERVE WHAT YOU GET.
The hard disk vendors aren't idiots. They make nice, fat margins on drives that get used primarily in RAID 5 arrays, and they're not about to let that revenue stream dry up. You'll have to pay a little more for the RAID-optimized drives, but the price gap between bargain SATA and RAID SATA is much smaller than the gap between IDE and SCSI, so it's still worth it to an awful lot of people.
If you have a strictly linear update model, you can get away with just about any numbering scheme you want. This is a rare situation. Usually you'll end up maintaining multiple releases, such that version 6.0 is not a strict superset of version 5.4 in terms of features and bug fixes. If your customers are smart, they'll see through any numbering games, so you should just be honest with them. If your customers are stupid, make sure you get your bonuses in cash, because there's no telling if the gravy train will last long enough for your options to be worth anything, because you're completely at the whim of the marketing gods.
It may be worthwhile to call your first beta version 1.0, and work up to a 2.0 commercial release, to appease some PHBs, but if your customers distrust you so much that management is seriously considering calling the initial release 8.0, lying to them so transparently will only make the problem worse.
Rather than making shit up like this, just call it Widget Tycoon 2009, and use build IDs for patch levels. If all goes well, you might even be able to get your customers to pay to upgrade to what would otherwise be point releases every year or two. Who wants to be running Widget Tycoon 2009 in the year 2011?
Re:Kernel changes I wanted in as of v1.0
on
Linux 2.6.27 Out
·
· Score: 2, Insightful
If you want a stable kernel module ABI, use an enterprise distro. They go to great lengths to preserve 3rd-party module binary compatibility, because their customers pay them to do this. The upstream kernel is not about to freeze innovation for your convenience.
Re:A question here. Really, no kidding...
on
Linux 2.6.27 Out
·
· Score: 1
Yes and no. If you have a newer EeePC with an atl2e chip, Atheros posted an atl1e driver (which also drives atl2e) and that has been merged in 2.6.27. If you have an older EeePC with an atl2 chip, I didn't start getting new patches from Atheros for that driver until *after* they posted atl1e, so that's queued up for 2.6.28. Most distros currently use the pre-merge atl2 driver, or you can download it from http://people.redhat.com/csnook/atl2/
The good news is that Atheros is committing to much more active upstream involvement going forward, so we can expect more timely support of new hardware from them in the future.
A few months after the initial release of desktop i7 chips, they'll release a chip that can handle up to 2.0V DDR3 running at up to 2.4 GHz. The CPU will cost $1500, have an unlocked multiplier, and require a $300 motherboard, a $200 power supply, and a $100 cooling device to function with the out-of-spec enthusiast RAM. Gamers with more money than sense will eagerly shell out for it, and blame Nvidia's drivers when they only get an extra 1.3 FPS over JEDEC-compliant mainstream CPU/RAM configurations.
Until a few months ago, I regularly answered this question for enterprise Linux customers, so I humbly submit that my anecdotal experience is marginally more informed than most here.
Memory capacity and bandwidth is improving orders of magnitude faster than disk throughput and latency, and this has been true for decades. If the workload stays the same, you should generally have a lower swap/RAM ratio on newer hardware than older hardware, because it's so much cheaper these days to add more RAM, and adding more swap can actually make your system slower when you finally start using it, because it takes much longer to page in 8 GB of data from disk than 4 GB.
The kernel virtual memory (VM) subsystem is a briar patch of carefully-tuned code which, whenever altered, almost always causes a regression for some obscure combination of hardware and software that someone somewhere cares an awful lot about. This is not due to inherent bugginess, but rather the fact that the VM is essentially in the business of predicting the future, which is mathematically impossible to always get right. As a result, developers tend to be very conservative about VM optimizations, so the VM tends not to adjust its assumptions about hardware quite as quickly as the hardware itself changes.
The upshot of all of this is that as time goes by, swap becomes more of a lifeline for worst-case memory shortages and less of an optimization to make the system behave as though it had more memory. This is not to say you should do without it completely, but the ratio tends to keep going down. For desktop use, I've been using a 1:1 ratio for a while, and honestly, that's probably too large for how I use it. Digging out of 2X swap takes *more* than twice as long as digging out of 1X swap, because you end up thrashing back through the stuff you've already paged in and out before you get to the rest. Think of the Tower of Hanoi problem as an extreme worst case. Beyond a certain point, you really want the kernel to refuse memory allocations and/or invoke the OOM-killer to kill off your misbehaving app and restore performance for the rest of the system.
Whatever you do, you shouldn't go completely swapless unless you really know what you're doing. Having just a few hundred megabytes of swap on a huge 4-socket server gives you a buffer against out-of-memory conditions that could bring down the whole system. In this extreme case, it's actually *good* that swap is slower than RAM, because it stalls userspace page dirtying while waiting for I/O, leaving the CPU free for the kernel to scan for pages that should be paged out, faster than userspace can dirty them.
If you're stuck on a small system you can't upgrade, having a high swap/RAM ratio might still make sense, but modern hardware tends to have much more and faster RAM and only slightly faster I/O.
If you've got a carefully tuned database server that's reserving much of its memory for hugepages, you should start your calculation with the amount of *swappable* RAM, which is the RAM not set aside for hugepages. So, if you've got 16 GB of RAM, and 12 GB reserved in hugepages, you only want swap proportional to 4 GB of RAM.
The proportion itself is still a delicate matter. On a desktop system where you may open lots of applications, and then leave some of them idle for days while using other resource-intensive programs, it may make sense to go as high as 1x. On servers where latency is important, you probably don't want to go higher than 0.25. If you've got a batch compute system where you feed it a huge amount of work and expect it to be done when you come back several hours later, it can still make sense to have upwards of 2x as much swap as RAM. It might be sluggish to give you a login prompt, but that doesn't necessarily mean it's thrashing inefficiently if you have a fairly sequential access pattern.
If all of this confuses you, and your distribution recommends 2 GB by default at install time, odds are you'll do okay with that, at least for the near future. Once solid-state storage becomes mainstream, most of what I've said in this post will be completely obsolete.
If you're being managed intelligently, you'll be given time, on the clock, to log out of the phone queue and focus on projects to make the organization operate more efficiently. Sounds like you're not.
I bet that for every malicious logic bomb, there are a hundred cases where a leaving employee takes with them the exclusive knowledge required to maintain some component of a critical system. What might have taken an hour to document will take their replacement a man-week to figure out, possibly with production services impacted, and there's no malice involved.
I suspect that properly resourcing and managing IT organizations to avoid *this* problem would prevent most of the frustration that leads to logic bombs.
I've been in northern New Mexico during the monsoon season. It's like being on the east coast in the South in May. In central Virginia, it's common to have 90F+ temperatures and 90%+ humidity every single day for the entire month of August. Coastal Florida is much more brutal.
Of course, it's entirely possible that those environmental differences won't have much of an impact on failure rates, but they should really do a scientific test in such a climate before recommending this technique to everyone.
...doesn't fluctuate that much, and is nearly always very low. I'd be very curious to see how a similar experiment goes in a place like Florida, that's at least as hot and much more humid.
Do you have a government-sanctioned license? Lawyers do. Accountants do. They're real professionals. If they screw up badly enough, they lose the right to work in that field. If you screw up really badly, you just lose your job. Most employers will only confirm that you worked there and you showed up when asked for a reference, to avoid lawsuits, so there's very little accountability beyond the job for IT workers. Sales and HR aren't professions either, but they're fields in which it's much harder to quantify expertise. If the companies that are testing you could quantify their expertise, they'd jump at it.
Of all the indignities visited upon IT workers, this seems like a rather bizarre one to choose to complain about.
If you look in the upper right corner of the display, you can see a particle/antiparticle pair generated by a collision with ambient matter in the not-quite-vacuum. It doesn't have the full force of a collision between the two beams, but if the one beam is running at full strength, it's still more powerful than anything generated by previous accelerators, and not far from what you'll get with the head-on collisions.
I have an old 12" powerbook with 384 MB of RAM. It started gathering dust when I got a much larger laptop for work, since modern ajax-and-flash-heavy websites were really crawling with so little memory, and that's using both Firefox 2 and Safari. When Firefox 3 came out, I heard how much lighter it was, so I gave it a try. Lo and behold, my old laptop had new life! Safari still feels a little snappier when I only have one tab open, but that's a fleetingly rare condition. Gecko isn't just the technology we have right now, it's the vibrant developer community hard at work making it better. WebKit has less ambitious aims, and achieves them well, but Mozilla would be throwing the baby out with the bathwater if they told everyone to forget Gecko and learn how to do that same optimization work on WebKit.
XFS is a very complex filesystem, and it was designed and optimized for high-end equipment, the sort where you can be reasonably sure that a synchronous write is committed to disk or a battery-backed write cache when it returns. If you're using IDE disks with unreliable power, those assumptions are violated. People who have used XFS on high-end servers are probably baffled by your experience, but at the low end it's not uncommon.
So, if reiser is out, and XFS is out, you're left with JFS and ext3/ext4. JFS will probably work well, but I have no experience with it. In fact, most people have no experience with it, which means it'll be harder to get help if stuff breaks. ext3 is rock solid, albeit sometimes at the expense of performance. ext4 should fix the major performance concerns while preserving the stability and the benefits of ubiquity. The catch is, it's still considered to be in development.
Personally, I like living on the edge, so I'm using it quite a lot, and it's performing very well, with no data integrity problems, even after unclean shutdowns. It sounds like this is more of a migration plan than something you really need to configure this second, so if reiserfs is working well for the moment, I would stick with it until ext4 is declared to be done.
Of course the joints were badly formed. We were cutting 1/8" x 1/8" sticks of balsa wood with box cutters. Part of the lesson was to minimize complexity. This is an important consideration in industrial construction as well, due to the law of large numbers. No matter how strong your average joint is, there will always be some that are much weaker. Once one bad joint goes, the rest will soon as well due to the shift in stress. If you have more joints (and thus more bad joints) you're at much greater risk of losing enough joints to bring the whole thing down. This is one of the reasons many bridges are overengineered by several orders of magnitude, and why some still fail in spite of that.
In our case, it was considered an engineering problem, so there were certain inviolable constraints, but as long as we satisfied those we were free to do whatever we pleased. I'm sure plenty of composite construction techniques could have improved our results, but given the time constraints and the fact that any wood used in testing came out of the total available for construction (quite reasonable real-world engineering constraints) we were forced to innovate conservatively. We hadn't been taught anything about surface lamination, so the glue technique was certainly creative, but applying that reinforcement indiscriminately turned out to be less efficient than applying it judiciously in the places where it was needed the most.
Engineering doesn't stifle creativity, it just guides it in a more practical (and often less exotic) direction than pure science. If my motherboard had been designed by scientists, maybe it would have used the original poster's proposed technique, but it would have cost much more, and I would have bought a different one instead.
I think someone pulled the same stunt on our professor in the past, which is why we were given 6 36" sticks to build a 20" x 2" span. That enforced a somewhat more conventional approach. It's rather difficult to drive a car across a rope.
The contest was to build the most weight-efficient bridge, using only balsa wood sticks and wood glue. Efficiency was judged by (failure load)/(bridge mass). The highest load, by far, was born by a bridge that had been totally coated with wood glue. Unfortunately for them, this coating raised the bridge mass by nearly 50%, so their bridge was still less efficient than my team's, which used a more conventional truss design, with a coating of glue around the joints. Nearly every bridge in the class failed first at a joint, so reinforcing the beams themselves was a waste.
The point is that applying the same reinforcement everywhere tends to be a serious waste of resources that would be better applied to the most critical areas. This is why my shiny new motherboard has a few components embedded in epoxy, surrounded by metal heatsink-like rings. Unlike other motherboards I've used, this one has no large components sticking up from the PCB, so I'm guessing that they singled out those bulky components, shrunk them down, and then added the epoxy and rings to allow them to operate safely at a smaller size.
Not all clock cycles are created equal. The z10 burns an awful lot of them doing various mainframey things behind the scenes. I've built kernels on a 2-cpu z9 guest, and it crawls compared to my dual-core desktop, but that's not what you buy a mainframe for. You buy it for all those things it does behind the scenes without you ever having to think about them, so your mission-critical database never goes down and never flips a single bit, even if CPUs, DIMMs, or whole logic boards fail.
Yes and no. If your commodity servers are running at 100% CPU utilization, then definitely not, but that's not the case for most commodity servers. Most commodity servers use about 15% of their peak CPU capacity on average, and just need the extra capacity to handle peak load. With a mainframe, you can put a whole bunch of these in one box, and overcommit your hardware resources. Priorities are enforced in hardware, so you're not putting your high-priority ERP app at risk by consolidating your minor app servers there. Mainframes are designed to run at 100% capacity 24/7/365, and for mere thousands of dollars you can get consultants to help you with capacity planning, so you don't buy any more $100k CPUs than you need.
Slashdot Mirror
Just because someone doesn't put up a mechanism to prevent this, doesn't mean this use of their system is authorized. If they have a policy, either in written TOS form or something automated like robots.txt, and you violate it, this could be considered unauthorized access under the law, and you could personally be held criminally responsible.
Fission and fusion can both be either endothermic or exothermic, depending on what you're working with. If you're working with atoms lighter than Iron, you get energy from fusion, and fission requires providing energy. If you're working with atoms heavier than Iron, you get energy from fission, and fusion requires providing energy. If you're working with Iron, you have to provide energy for both.
...really include p0rn-comfort?
...is rising to the level of complexity of a simple operating system. They do a lot of very smart things in there to catch problems before they become unrecoverable, and they even report them to you via SMART so you can tell when they're at an increased risk of failure.
The catch is, there are several different ways to optimize firmware. Drives intended to be used in RAID arrays have different firmware from drives intended for desktop or laptop use. If you use desktop drives in a large RAID array, with a rather fault-intolerant parity RAID implementation, YOU ARE AN IDIOT AND DESERVE WHAT YOU GET.
The hard disk vendors aren't idiots. They make nice, fat margins on drives that get used primarily in RAID 5 arrays, and they're not about to let that revenue stream dry up. You'll have to pay a little more for the RAID-optimized drives, but the price gap between bargain SATA and RAID SATA is much smaller than the gap between IDE and SCSI, so it's still worth it to an awful lot of people.
If you have a strictly linear update model, you can get away with just about any numbering scheme you want. This is a rare situation. Usually you'll end up maintaining multiple releases, such that version 6.0 is not a strict superset of version 5.4 in terms of features and bug fixes. If your customers are smart, they'll see through any numbering games, so you should just be honest with them. If your customers are stupid, make sure you get your bonuses in cash, because there's no telling if the gravy train will last long enough for your options to be worth anything, because you're completely at the whim of the marketing gods.
It may be worthwhile to call your first beta version 1.0, and work up to a 2.0 commercial release, to appease some PHBs, but if your customers distrust you so much that management is seriously considering calling the initial release 8.0, lying to them so transparently will only make the problem worse.
Rather than making shit up like this, just call it Widget Tycoon 2009, and use build IDs for patch levels. If all goes well, you might even be able to get your customers to pay to upgrade to what would otherwise be point releases every year or two. Who wants to be running Widget Tycoon 2009 in the year 2011?
If you want a stable kernel module ABI, use an enterprise distro. They go to great lengths to preserve 3rd-party module binary compatibility, because their customers pay them to do this. The upstream kernel is not about to freeze innovation for your convenience.
Yes and no. If you have a newer EeePC with an atl2e chip, Atheros posted an atl1e driver (which also drives atl2e) and that has been merged in 2.6.27. If you have an older EeePC with an atl2 chip, I didn't start getting new patches from Atheros for that driver until *after* they posted atl1e, so that's queued up for 2.6.28. Most distros currently use the pre-merge atl2 driver, or you can download it from http://people.redhat.com/csnook/atl2/
The good news is that Atheros is committing to much more active upstream involvement going forward, so we can expect more timely support of new hardware from them in the future.
A few months after the initial release of desktop i7 chips, they'll release a chip that can handle up to 2.0V DDR3 running at up to 2.4 GHz. The CPU will cost $1500, have an unlocked multiplier, and require a $300 motherboard, a $200 power supply, and a $100 cooling device to function with the out-of-spec enthusiast RAM. Gamers with more money than sense will eagerly shell out for it, and blame Nvidia's drivers when they only get an extra 1.3 FPS over JEDEC-compliant mainstream CPU/RAM configurations.
Until a few months ago, I regularly answered this question for enterprise Linux customers, so I humbly submit that my anecdotal experience is marginally more informed than most here.
Memory capacity and bandwidth is improving orders of magnitude faster than disk throughput and latency, and this has been true for decades. If the workload stays the same, you should generally have a lower swap/RAM ratio on newer hardware than older hardware, because it's so much cheaper these days to add more RAM, and adding more swap can actually make your system slower when you finally start using it, because it takes much longer to page in 8 GB of data from disk than 4 GB.
The kernel virtual memory (VM) subsystem is a briar patch of carefully-tuned code which, whenever altered, almost always causes a regression for some obscure combination of hardware and software that someone somewhere cares an awful lot about. This is not due to inherent bugginess, but rather the fact that the VM is essentially in the business of predicting the future, which is mathematically impossible to always get right. As a result, developers tend to be very conservative about VM optimizations, so the VM tends not to adjust its assumptions about hardware quite as quickly as the hardware itself changes.
The upshot of all of this is that as time goes by, swap becomes more of a lifeline for worst-case memory shortages and less of an optimization to make the system behave as though it had more memory. This is not to say you should do without it completely, but the ratio tends to keep going down. For desktop use, I've been using a 1:1 ratio for a while, and honestly, that's probably too large for how I use it. Digging out of 2X swap takes *more* than twice as long as digging out of 1X swap, because you end up thrashing back through the stuff you've already paged in and out before you get to the rest. Think of the Tower of Hanoi problem as an extreme worst case. Beyond a certain point, you really want the kernel to refuse memory allocations and/or invoke the OOM-killer to kill off your misbehaving app and restore performance for the rest of the system.
Whatever you do, you shouldn't go completely swapless unless you really know what you're doing. Having just a few hundred megabytes of swap on a huge 4-socket server gives you a buffer against out-of-memory conditions that could bring down the whole system. In this extreme case, it's actually *good* that swap is slower than RAM, because it stalls userspace page dirtying while waiting for I/O, leaving the CPU free for the kernel to scan for pages that should be paged out, faster than userspace can dirty them.
If you're stuck on a small system you can't upgrade, having a high swap/RAM ratio might still make sense, but modern hardware tends to have much more and faster RAM and only slightly faster I/O.
If you've got a carefully tuned database server that's reserving much of its memory for hugepages, you should start your calculation with the amount of *swappable* RAM, which is the RAM not set aside for hugepages. So, if you've got 16 GB of RAM, and 12 GB reserved in hugepages, you only want swap proportional to 4 GB of RAM.
The proportion itself is still a delicate matter. On a desktop system where you may open lots of applications, and then leave some of them idle for days while using other resource-intensive programs, it may make sense to go as high as 1x. On servers where latency is important, you probably don't want to go higher than 0.25. If you've got a batch compute system where you feed it a huge amount of work and expect it to be done when you come back several hours later, it can still make sense to have upwards of 2x as much swap as RAM. It might be sluggish to give you a login prompt, but that doesn't necessarily mean it's thrashing inefficiently if you have a fairly sequential access pattern.
If all of this confuses you, and your distribution recommends 2 GB by default at install time, odds are you'll do okay with that, at least for the near future. Once solid-state storage becomes mainstream, most of what I've said in this post will be completely obsolete.
If you're being managed intelligently, you'll be given time, on the clock, to log out of the phone queue and focus on projects to make the organization operate more efficiently. Sounds like you're not.
I bet that for every malicious logic bomb, there are a hundred cases where a leaving employee takes with them the exclusive knowledge required to maintain some component of a critical system. What might have taken an hour to document will take their replacement a man-week to figure out, possibly with production services impacted, and there's no malice involved.
I suspect that properly resourcing and managing IT organizations to avoid *this* problem would prevent most of the frustration that leads to logic bombs.
I've been in northern New Mexico during the monsoon season. It's like being on the east coast in the South in May. In central Virginia, it's common to have 90F+ temperatures and 90%+ humidity every single day for the entire month of August. Coastal Florida is much more brutal.
Of course, it's entirely possible that those environmental differences won't have much of an impact on failure rates, but they should really do a scientific test in such a climate before recommending this technique to everyone.
...doesn't fluctuate that much, and is nearly always very low. I'd be very curious to see how a similar experiment goes in a place like Florida, that's at least as hot and much more humid.
Do you have a government-sanctioned license? Lawyers do. Accountants do. They're real professionals. If they screw up badly enough, they lose the right to work in that field. If you screw up really badly, you just lose your job. Most employers will only confirm that you worked there and you showed up when asked for a reference, to avoid lawsuits, so there's very little accountability beyond the job for IT workers. Sales and HR aren't professions either, but they're fields in which it's much harder to quantify expertise. If the companies that are testing you could quantify their expertise, they'd jump at it.
Of all the indignities visited upon IT workers, this seems like a rather bizarre one to choose to complain about.
So you paid money for a GUI that selects command-line options?
I'm in the wrong line of work.
If you look in the upper right corner of the display, you can see a particle/antiparticle pair generated by a collision with ambient matter in the not-quite-vacuum. It doesn't have the full force of a collision between the two beams, but if the one beam is running at full strength, it's still more powerful than anything generated by previous accelerators, and not far from what you'll get with the head-on collisions.
I have an old 12" powerbook with 384 MB of RAM. It started gathering dust when I got a much larger laptop for work, since modern ajax-and-flash-heavy websites were really crawling with so little memory, and that's using both Firefox 2 and Safari. When Firefox 3 came out, I heard how much lighter it was, so I gave it a try. Lo and behold, my old laptop had new life! Safari still feels a little snappier when I only have one tab open, but that's a fleetingly rare condition. Gecko isn't just the technology we have right now, it's the vibrant developer community hard at work making it better. WebKit has less ambitious aims, and achieves them well, but Mozilla would be throwing the baby out with the bathwater if they told everyone to forget Gecko and learn how to do that same optimization work on WebKit.
XFS is a very complex filesystem, and it was designed and optimized for high-end equipment, the sort where you can be reasonably sure that a synchronous write is committed to disk or a battery-backed write cache when it returns. If you're using IDE disks with unreliable power, those assumptions are violated. People who have used XFS on high-end servers are probably baffled by your experience, but at the low end it's not uncommon.
So, if reiser is out, and XFS is out, you're left with JFS and ext3/ext4. JFS will probably work well, but I have no experience with it. In fact, most people have no experience with it, which means it'll be harder to get help if stuff breaks. ext3 is rock solid, albeit sometimes at the expense of performance. ext4 should fix the major performance concerns while preserving the stability and the benefits of ubiquity. The catch is, it's still considered to be in development.
Personally, I like living on the edge, so I'm using it quite a lot, and it's performing very well, with no data integrity problems, even after unclean shutdowns. It sounds like this is more of a migration plan than something you really need to configure this second, so if reiserfs is working well for the moment, I would stick with it until ext4 is declared to be done.
Of course the joints were badly formed. We were cutting 1/8" x 1/8" sticks of balsa wood with box cutters. Part of the lesson was to minimize complexity. This is an important consideration in industrial construction as well, due to the law of large numbers. No matter how strong your average joint is, there will always be some that are much weaker. Once one bad joint goes, the rest will soon as well due to the shift in stress. If you have more joints (and thus more bad joints) you're at much greater risk of losing enough joints to bring the whole thing down. This is one of the reasons many bridges are overengineered by several orders of magnitude, and why some still fail in spite of that.
In our case, it was considered an engineering problem, so there were certain inviolable constraints, but as long as we satisfied those we were free to do whatever we pleased. I'm sure plenty of composite construction techniques could have improved our results, but given the time constraints and the fact that any wood used in testing came out of the total available for construction (quite reasonable real-world engineering constraints) we were forced to innovate conservatively. We hadn't been taught anything about surface lamination, so the glue technique was certainly creative, but applying that reinforcement indiscriminately turned out to be less efficient than applying it judiciously in the places where it was needed the most.
Engineering doesn't stifle creativity, it just guides it in a more practical (and often less exotic) direction than pure science. If my motherboard had been designed by scientists, maybe it would have used the original poster's proposed technique, but it would have cost much more, and I would have bought a different one instead.
I think someone pulled the same stunt on our professor in the past, which is why we were given 6 36" sticks to build a 20" x 2" span. That enforced a somewhat more conventional approach. It's rather difficult to drive a car across a rope.
The contest was to build the most weight-efficient bridge, using only balsa wood sticks and wood glue. Efficiency was judged by (failure load)/(bridge mass). The highest load, by far, was born by a bridge that had been totally coated with wood glue. Unfortunately for them, this coating raised the bridge mass by nearly 50%, so their bridge was still less efficient than my team's, which used a more conventional truss design, with a coating of glue around the joints. Nearly every bridge in the class failed first at a joint, so reinforcing the beams themselves was a waste.
The point is that applying the same reinforcement everywhere tends to be a serious waste of resources that would be better applied to the most critical areas. This is why my shiny new motherboard has a few components embedded in epoxy, surrounded by metal heatsink-like rings. Unlike other motherboards I've used, this one has no large components sticking up from the PCB, so I'm guessing that they singled out those bulky components, shrunk them down, and then added the epoxy and rings to allow them to operate safely at a smaller size.
Not all clock cycles are created equal. The z10 burns an awful lot of them doing various mainframey things behind the scenes. I've built kernels on a 2-cpu z9 guest, and it crawls compared to my dual-core desktop, but that's not what you buy a mainframe for. You buy it for all those things it does behind the scenes without you ever having to think about them, so your mission-critical database never goes down and never flips a single bit, even if CPUs, DIMMs, or whole logic boards fail.
A z10 has 336 I/O controllers. Each one is a ppc processor. You do the math.
The last time I saw a zSeries tape drive, the tape controller was a pSeries.
Yes and no. If your commodity servers are running at 100% CPU utilization, then definitely not, but that's not the case for most commodity servers. Most commodity servers use about 15% of their peak CPU capacity on average, and just need the extra capacity to handle peak load. With a mainframe, you can put a whole bunch of these in one box, and overcommit your hardware resources. Priorities are enforced in hardware, so you're not putting your high-priority ERP app at risk by consolidating your minor app servers there. Mainframes are designed to run at 100% capacity 24/7/365, and for mere thousands of dollars you can get consultants to help you with capacity planning, so you don't buy any more $100k CPUs than you need.