The last TCO I was involved with actually showed that the mainframe was the more cost effective approach for the use case at hand.
TCO estimates are the finest snake oil money can buy. I see them periodically, and often times it doesn't take me long to change some tiny assumption (like swapping a DS8k for a lower function faster disk subsystem on the PC cause it doesn't need FICON for example) to throw the results off. Sometimes simply changing vendors is enough. The ones I'm particularly fond of can be found on IBM's site where they compare 10 year old PC clusters with the latest piece of IBM gear. Well duh, newer hardware had better be cheaper than the old stuff on a price/performance curve otherwise why upgrade?
RAIM memory system? Many of those RAS features are system level features anyway, so isolating CPU RAS features doesn't really do justice for either of them.
Function: to assure that ECC/chipkill failures on a memory controller/DIMM/bus can be worked around.
Its not "RAID" type functionality as such, but x86s have been doing mirroring for a long time.
Modern ones can do either mirroring and/or sparing or variations thereof depending on the machine vendor.
The sparing is basically as efficient (2/3 available memory) as RAIM. Mirroring doesn't use the memory as efficiently as RAIM does, but I don't see IBM publishing Read/Modify/Write timings for their RAIM systems. Probably because its _NOT_ good, doing RAID in memory is going to affect the latency of the system, which is of course probably more critical in most applications than the bandwidth.
I have a z114 which supports this, I can probably benchmark it tomorrow with it on vs off. I don't think its turned on, but the main memory latency numbers by my measurement are pretty bad anyway so I didn't dig to deep into it.
I suspect that IBM added the RAIM functions because they were preparing for the the flash options on the ec12. It makes sense for flash because of the issues with flash reliability and the natural page mode access of flash could be aligned with the RAIM strip size.
IBM basically doesn't have a power budget for these things (although they claim the new ones are greener). That allows them to build machines with blower motors that are two feet across and heatsinks that weigh more than my whole desktop.
That doesn't mean they run super fast, Intel and IBM with POWER (and others) have done amazing things with the power budgets they stay within.
. We actually benchmarked performance on the mainframe vs. Wintel servers/clusters and found a huge performance increase on the mainframe. Otherwise, we wouldn't have switched those servers to the mainframe (heavy database usage). There are many web servers on the mainframe, but it's used for more back end work. (It could also run Windows I think I read recently, although I can't see the point).
Wow, I would be, quite an accomplishment, what did you compare a ec12 with a bunch of single socket x86s? I have a z114 with some IFLs and a couple partitions of zos. I can show you the CPU and memory benchmarks compared to an assortment of x86 hardware. Then there is IO, apples to apples (aka match the spindles/etc) ficon sort of sucks. All the ficon disks IBM sells basically are SAS disks so your paying IO penalties against the disk subsystem. With flash disk on the PC its not even close when your talking about IOP/s.
But what I see more frequently is someone comparing the mainframe running old fairly low level code against java on the PC. Right there your talking a huge advantage on the mainframe because java sucks for IO, and for large footprint applications the garbage collector kills cpu/memory performance.
The fairest benchmarks I look at are linux on the IFLs vs PCs. I have yet to see the mainframe come withing 30% of mid-range x86 servers (say DL580s and IBM x3850) on any CPU or memory benchmark running C/C++ code. The IO numbers can get pretty bad because the coupling links are easily flooded if you have a decent SAN attached. The move to cabled pcie bumped the bandwidth to 80Gbit, but that really isn't anything to write home about. So, you have to be very careful about card layout in the IO expansion drawers.
I don't have access to one of the new ec12's (maybe at some point) but the claimed 30% performance boost might put them on equal footing to some of my x86 hardware (much of which is a few years old too). I'm guessing to build a zlinux config with the same performance as my $50k DL580 would cost about 2-3 million.
Oh, and don't get me started on zVM vs vmware. Its not really even fair.
Because a midrange mainframe costs > a million dollars before you add the storage, maintenance etc. You want a fast mainframe your talking tens of millions.
You can buy a lot of x86 hardware, and support talent for that kind of money.
Personally, if wouldn't have used HADOOP. If a single mainframe can handle it, I can build an x86 server to do the same. The mainframes advantage at this point is that everything is so close to the medal it runs fairly fast. Put Java into the mix on the x86 its no surprise that it takes a cluster to match the mainframe running cobol. Especially if your trying to do IO.
Mainframe CPU's tend to have far more error detection and correction.
"Tend to" is now false. It has been since the nehalem based xeons. Intel seems to have picked the large scale Unix and Mainframe RAS features for the CPU and busses and made sure they can match them bullet point by bullet point.
I challenge you to find a RAS CPU feature on your mainframe that you don't think I can find on a modern xeon.
pseries aren't mainframes. Those are just big unix machines, and the markup on them is nowhere near the zseries mainframes. Plus AIX basically doesn't have any vendor lock. Applications ported to AIX from some other unix can just as well be ported somewhere else like linux. Try porting the mess of cobol/JCL/etc running on z, or even i series apps. That takes real money/development effort.
The problem is that eventually someone notices the cost price/performance between z/p and x86 if everything is running in a posix environment.
That they sell to go with the servers? All three of those items are high margin and more than make up for the lack of margin on the servers themselves. How long is it going to take Lenovo to start selling enterprise storage or networking gear? They had better get some kind of agreement from lenovo that they won't sell gear in any of those categories for the next decade or two.
I can't really see people calling up lenovo and ordering a bunch of servers, and then calling up IBM and ordering storage. If nothing else they are going to call up netapp, EMC and Snoracle as well.
Maybe IBM doesn't care about the "low end" stuff people are connecting to their x86 servers. Sell a few less DS3500s milk the DS8k customers some more.
The problem is that "low end" x86 hardware is slowly but surely eating into what remains of the unix/midrange "server" market. Sure a couple customers here and there buy a mainframe and run zlinux on a couple IFL's they basically get for free after buying the mainframe. But in the end, can they support a business on such a tiny portion of the market? Even major mainframe customers like American Airlines have publicly stated they are moving away from the mainframe.
I suspect they will continue as they have for the last decade, selling pieces of the company, moving all the engineering to cheap labor countries, and charging their existing customers a heavy ransom for the privilege. But at this point in time IBM is beginning to look like Sun circa 2001.
CE's don't even carry proper toolkits anymore. All the FRU's come with whatever tools are required to replace them, and larger items shipped by IBM come with wrenches and tools necessary for install. So the customers end up with a tool and supply pile if the CE comes often. And its not just screwdrivers and sockets. Its hard hats, klein cable fishes, and tons of single use tools like 3" wrenches, etc. Each with a specific purpose, but replacing a common tool like a crescent wrench with some stamped steel single use tool.
The problem is _WHERE_ java is actually used. For the most part that is "enterprise software" and embedded gear. At work its pretty much unavoidable, from the IP KVM's, and fibre switches with their java applets to enterprise middleware running all over the place. Its apparent what all those java developers have been doing for the last decade.
In many cases, simple HTML applications would have been much better but some organization hired a java programmer to write the back-end and the front-end ended up being java too. I can't tell you how often I've seen something as simple as a little monitoring app with a dozen configuration options that requires java and 500MB of memory to retrieve a dozen log messages a day and show a couple blinking lights.
For the home user its pretty easy to avoid java. public web sites rarely have java applets (can't even remember the last one I saw). The few consumer java applications almost always have competitors that are just as good (and generally perform better anyway). I refused to install java on my home machines ~7-8 years ago. I haven't missed it. Flash is nearly there too.
So in many ways, an IT guy could hide/avoid a lot of the java problems by disallowing java applets at the firewall/web proxy level. Personally, if I were a CTO or similar I would include a platform/java questionnaire in my RFP/purchasing matrix and deduct points if the item has java.
It might be possible to write good java applications, but from what i've seen applications written in java seem to be the lowest quality ones. Whether that is some kind of self selection process for java programmers, development managers, or something fundamental in the technology I can't say, but it does appear to be there.
While VM does not have much overhead it does have some.
This is the common view, but its a gross generalization. For some problems you won't be able to measure much of a difference. These problems tend to be problems that are low thread count (1-2 loaded threads) and have a high cache/TLB hit rate with few kernel interactions. On the other hand, applications pegging out more than 8 CPUs, or doing a lot of cacheline ping-ponging, etc tend to take a noticeable hit. Furthermore, applications that are doing a crapload of IO through adapters that are neither pass-through, nor have SR-IOV or similar high speed IO support and appropriate hypervisor support will be hit with orders of magnitude performance problems. Even with support, picking the wrong set of adapter vendor/hypervisor/OS can have pretty serious performance impacts.
So as you said, put it on the bare metal if your having performance problems. But this is sort of my problem with many of the modern developers mindset. The lets just throw another VM at the problem attitude is so wrong its amazing. I think its founded on the fact that a huge number of people in the IT industry don't understand the difference between throughput and latency when it comes to performance problems. I see it all the time with the "we just need another VM" mindset. Half the time the problem is that the attached disk subsystem is doing 300IOPS cause its running on some internal RAID6 with 4 disks and each IO is doing a read/modify/write cycle. Plug in a SSD and reduce the physical server count from 10 machines to 1. Or for that matter move a table out of the database to a memory mapped file, and return the results directly from the mapped page rather than bouncing it through a socket, and then copying it a couple times through some interpreted scripting language before before the ethernet adapter finally DMA's it out. Its amazing when you show someone that the 1.5k piece of data they are returning was copied 30 times around in memory 20-50 times and that is what their CPU is spending all its time on.
Building codes don't address explosions like this.
No, thats a zoning problem. Something that Texas basically doesn't have. Well, I should rephrase that. Texas has a lot of zoning commissions, the problem is that they can't enforce anything. The state laws are written in a manner such that the landowners can request zoning changes, and the boards basically can't refuse.
And, the regulations in Texas can be overridden if it poses undue financial restriction, or some BS like that. So, basically the act of the zoning board refusing to promote something to some kind of retail or commercial properly is overridden by the needs of the landowner. That is why you have apartments and condos being built (literally) 15 feet away from freight lines, and gas stations being built on top of creek tributaries, etc..
The results are usually predictable. In Austin the freight train derailed and slammed into a condo that had just been completed a couple years ago (http://www.kwtx.com/home/headlines/27183369.html). Thankfully, it wasn't a bad derailment and the part of the building it struck was vacant.
But, anyway common sense and public good falls to the needs of the landowner to maximize their profits in Texas. Its not even news anymore when the legislature passes some law to ban some obscure practice some town/etc is doing to protect their residents from some corporate interest hell bent on making a buck. Damn the damage. Heck Texas even has "Tort Reform" which is code-speak for making sure that when the explosion kills a bunch of people in an apartment complex an chemical factory built to close together no one can be held liable for ignoring common sense (and getting zoning permit wavers).
Uh, yah any unix/windows machine can store core dumps. That gives you one piece of the puzzle, but is rarely sufficient, especially if its an error in processing or whatnot and the system continues to run due to error handling.
Maybe, but do you really think the fallout model would work, when people know that all they have to do is dig through a couple feet of concrete and they will have food and a chance to survive?
There are lots of projects like this already, including a number more focused on science than building a bomb shelter. Which is where most of the planet based projects like this stop. They stock up supplies for a while and figure that is all they have to do because they can re-emerge in a couple years to the garden of Eden.
Besides, being stranded somewhere, tends to bring out the creative resources a lot more than being in a glass dome, where all you have to do is break the glass and your safe. Humans do best in situations where they are dying pushing some boundary forward. How much do you think we would know about scurvy, etc if everyone was content to only sail a couple miles off shore.
Are you sure? Because where I'm at (Texas), the steel is in the form of rebar. Concrete is the main structural component. Steel bridges are usually trestle. Because even back when steel bridges were popular there was incentive to save money on the steel.
But, Yah that is the problem with analogies now isn't it...
So, now the developer has this great tool that runs on their desktop that helps them debug the program. Now what happens when it fails in the field? Did the developers spend the time to create sufficient tracing/logging functions so that the end user can report the failures?
The largest problem isn't "debugging" during development, its "debugging" post failure analysis of field problems. Its such a large problem that nearly all "software engineering" and related process is focused on moving the debugging aspects to the developers machine, rather than getting the end customer involved.
When I first started writing code, I spent a lot of time in step/trace debuggers. Now I would say its probably less than 1% of my development time. That is for a number of reasons, the least of which is that I can almost always "see" the bugs in the code without having to run it. For code I'm writing, the output is almost always sufficient to find the bug without really having to think about it. That is something I couldn't do 15 years ago.
Can you imagine how annoying it would be if architects kept saying "The Romans figured out arches two thousand years ago, why do these new kids keep reinventing the wheel" ?
Uh, I think you got your analogy a little wrong. What happens in software is more like "Arches suck cause they are old, and suspension bridges are hard to build. Steel is cheap, lets just build a couple stone pillars and layer on steel to span the gap".
Why would we go to the moon? Why not send robots? It seems pointless to send humans to do something a machine can do better.
This has been answered a hundred times before by people who can do a much better job. Still...
Its not so much the destination that's important, but the technology to get there and survive. Neither is it about packing up a bunch of stuff from earth and taking a vacation on the moon. Its about building sustaining environments that don't require resupply from the earths biosphere. That is part of why there are so many "biology" experiments on the ISS.
If as a species we wish to survive, at some point we will have to learn how to live outside of the earths biosphere. Now is as good a time as any to learn how to do that because the future is not clear. It is entirely possible that in 50-100 years this planet won't support human life any where near the scale it currently does. If we manage to survive climate change without huge population loss, then there are dozens of other catastrophic things that may do us in.
Having the knowledge of how to survive in a man made biosphere is _NOT_ easy, and may be the key to our future on this planet even without the space aspects. Building power sources that don't involve the sun or carbon cycles is the future as well. Neither of which is particularly useful farther out in the solar system.
The problem with the ISS, is that it exists in a vacuum. There aren't any raw materials to use that haven't come from earth. We need an ISS on an asteroid, or the moon.
Windows 9, scales your 4k desktop so its effectively 320x200, and changes the user interface so the only buttons that work on your keyboard are the up/down/enter buttons.
Microsoft, of course, claims huge improvements in users ability to learn the interface because everything including typing is done by selecting options with the up/down buttons.
All the PC manufactures run by overpaid CEO's that don't know shit about technology promptly release laptops with 320x200 resolution 15" screens claiming that the PC will regain marketshare against the tablets now.
If you use a database you MUST understand and use the relational aspects of things. If you use the database as just a key:value store I will personally beat the ever living shit out of you.
Like all simple rigorous rules. This is sort of bad advice in a lot of circumstances. Sure inventing your own hashing function and using the hashes as the keys in a relational DB is stupid. That said, focusing on the main relationships with your tables, and not trying to describe every single edge case will massively simplify the schema. Plus, there are tons of little pieces of information that often need to be persisted, that just don't tend to have any kind of obvious relationship to anything else in the schema. Being able to add key:value attributes on the fly in the code without screwing with the schema can be a huge bonus to initial productivity. Sure if at some point you discover common, frequently used attributes, or you have some kind of performance issue because your reading some value out of a key:value store frequently then by all means fix it.
All that said, I'm not really a fan of trying to eak performance out of a databases. Use the database for what its good at, complex relationships, and easy storage/retrieval of information. But if your app is trying to do 500k updates per second to a single table, its probably a better idea to seek alternatives rather than throw a bunch of money at database hardware. I have my own mental rule, is this code path going to be a hot one? Yes, then no database queries. There are a ton of strategies for moving the queries/updates out of the paths that are performance sensitive.
What I mean is that there is sufficient hardware to host the pages. My first web server was a 486. So people don't have to run general purpose PCs all the time at home.
The little wireless firewall/routers that everyone has at home are already web managed. So there is a web server of some sort running on the devices. The one I have it can be turned on facing the internet. The one I have also has a USB port, and can host CIFS and DLNA content. And that is all out of the box without any custom firmware. Sure, its not a "firewall" at that point, but their capabilities are already crossing a bunch of lines.
Its not much of a stretch to imagine using some of that storage or providing some to host a user generated set of pages out of the box.
They will also be more careful about investing "for the long term" if they know someone like Google can come in at any time and make their investment worth less than they expected it to be.
First, google has said they are doing this because the incumbents aren't. Secondly, everyone has costs associated with running the fiber. The first company that gets into the neighborhood is going to be able to command significantly higher margins until the second. Hence they will be able to recupe a larger portion of the investment before they have any real competition. Basic business. The problem is that the incumbents are really happy charging everyone top dollar for services that don't cost them anything to provide and they apparently have some kind of unofficial agreement not to truly compete. Otherwise they would be racing to install the technology with the lowest cost and the largest long term return. Right now that equation's result is "do nothing", cause we are in a local maximum due to the really high margins they command because there isn't any competition.
I mean think about it. If you live in a city in the US, there's no *technical* reason that you can't have 100 megabit/sec up and down to your apartment.
Yah, exactly, its almost literally flipping a switch with DOCSIS 3, which is pretty much available everywhere today in the cities.
Pfft, those prices are right in line with the total price for a two year contract on an iPhone,
Forget the iphone, the cable companies cheap plans are generally in the $100 a month range for "triple play" or whatever they call it in your market. If you actually want fast internet, and some sports channels your probably paying closer to $200 a month.
And the expensive part of the infrastructure (the cable down the street) lasts decades. How many years has the phone company milked the unshielded twisted pair they strung in the middle of the last century, or the cable companies that strung coax in the 70-80's. Whoever installs fiber will probably be able to milk it for the next 20-50 years. Its quite possible the fiber networks that are being installed today will form the backbone of communications for the next millennium. Frankly, the guys running the phone/cable companies need to be strung up by their shareholders. Whoever installs the fiber network of the future will put the phone/cable companies out of business and then proceed to milk the results a long time. The part that shocks me is that the phone/cable companies even install anything other than fiber in new neighborhoods.
Slashdot Mirror
The last TCO I was involved with actually showed that the mainframe was the more cost effective approach for the use case at hand.
TCO estimates are the finest snake oil money can buy. I see them periodically, and often times it doesn't take me long to change some tiny assumption (like swapping a DS8k for a lower function faster disk subsystem on the PC cause it doesn't need FICON for example) to throw the results off. Sometimes simply changing vendors is enough. The ones I'm particularly fond of can be found on IBM's site where they compare 10 year old PC clusters with the latest piece of IBM gear. Well duh, newer hardware had better be cheaper than the old stuff on a price/performance curve otherwise why upgrade?
RAIM memory system? Many of those RAS features are system level features anyway, so isolating CPU RAS features doesn't really do justice for either of them.
Function: to assure that ECC/chipkill failures on a memory controller/DIMM/bus can be worked around.
Its not "RAID" type functionality as such, but x86s have been doing mirroring for a long time.
Modern ones can do either mirroring and/or sparing or variations thereof depending on the machine vendor.
For example random google hit:
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00502616/c00502616.pdf
The sparing is basically as efficient (2/3 available memory) as RAIM. Mirroring doesn't use the memory as efficiently as RAIM does, but I don't see IBM publishing Read/Modify/Write timings for their RAIM systems. Probably because its _NOT_ good, doing RAID in memory is going to affect the latency of the system, which is of course probably more critical in most applications than the bandwidth.
I have a z114 which supports this, I can probably benchmark it tomorrow with it on vs off. I don't think its turned on, but the main memory latency numbers by my measurement are pretty bad anyway so I didn't dig to deep into it.
I suspect that IBM added the RAIM functions because they were preparing for the the flash options on the ec12. It makes sense for flash because of the issues with flash reliability and the natural page mode access of flash could be aligned with the RAIM strip size.
Fastest clocked != best performer..
IBM basically doesn't have a power budget for these things (although they claim the new ones are greener). That allows them to build machines with blower motors that are two feet across and heatsinks that weigh more than my whole desktop.
That doesn't mean they run super fast, Intel and IBM with POWER (and others) have done amazing things with the power budgets they stay within.
. We actually benchmarked performance on the mainframe vs. Wintel servers/clusters and found a huge performance increase on the mainframe. Otherwise, we wouldn't have switched those servers to the mainframe (heavy database usage). There are many web servers on the mainframe, but it's used for more back end work. (It could also run Windows I think I read recently, although I can't see the point).
Wow, I would be, quite an accomplishment, what did you compare a ec12 with a bunch of single socket x86s? I have a z114 with some IFLs and a couple partitions of zos. I can show you the CPU and memory benchmarks compared to an assortment of x86 hardware. Then there is IO, apples to apples (aka match the spindles/etc) ficon sort of sucks. All the ficon disks IBM sells basically are SAS disks so your paying IO penalties against the disk subsystem. With flash disk on the PC its not even close when your talking about IOP/s.
But what I see more frequently is someone comparing the mainframe running old fairly low level code against java on the PC. Right there your talking a huge advantage on the mainframe because java sucks for IO, and for large footprint applications the garbage collector kills cpu/memory performance.
The fairest benchmarks I look at are linux on the IFLs vs PCs. I have yet to see the mainframe come withing 30% of mid-range x86 servers (say DL580s and IBM x3850) on any CPU or memory benchmark running C/C++ code. The IO numbers can get pretty bad because the coupling links are easily flooded if you have a decent SAN attached. The move to cabled pcie bumped the bandwidth to 80Gbit, but that really isn't anything to write home about. So, you have to be very careful about card layout in the IO expansion drawers.
I don't have access to one of the new ec12's (maybe at some point) but the claimed 30% performance boost might put them on equal footing to some of my x86 hardware (much of which is a few years old too). I'm guessing to build a zlinux config with the same performance as my $50k DL580 would cost about 2-3 million.
Oh, and don't get me started on zVM vs vmware. Its not really even fair.
Because a midrange mainframe costs > a million dollars before you add the storage, maintenance etc. You want a fast mainframe your talking tens of millions.
You can buy a lot of x86 hardware, and support talent for that kind of money.
Personally, if wouldn't have used HADOOP. If a single mainframe can handle it, I can build an x86 server to do the same. The mainframes advantage at this point is that everything is so close to the medal it runs fairly fast. Put Java into the mix on the x86 its no surprise that it takes a cluster to match the mainframe running cobol. Especially if your trying to do IO.
Mainframe CPU's tend to have far more error detection and correction.
"Tend to" is now false. It has been since the nehalem based xeons. Intel seems to have picked the large scale Unix and Mainframe RAS features for the CPU and busses and made sure they can match them bullet point by bullet point.
I challenge you to find a RAS CPU feature on your mainframe that you don't think I can find on a modern xeon.
pseries aren't mainframes. Those are just big unix machines, and the markup on them is nowhere near the zseries mainframes. Plus AIX basically doesn't have any vendor lock. Applications ported to AIX from some other unix can just as well be ported somewhere else like linux. Try porting the mess of cobol/JCL/etc running on z, or even i series apps. That takes real money/development effort.
The problem is that eventually someone notices the cost price/performance between z/p and x86 if everything is running in a posix environment.
That they sell to go with the servers? All three of those items are high margin and more than make up for the lack of margin on the servers themselves. How long is it going to take Lenovo to start selling enterprise storage or networking gear? They had better get some kind of agreement from lenovo that they won't sell gear in any of those categories for the next decade or two.
I can't really see people calling up lenovo and ordering a bunch of servers, and then calling up IBM and ordering storage. If nothing else they are going to call up netapp, EMC and Snoracle as well.
Maybe IBM doesn't care about the "low end" stuff people are connecting to their x86 servers. Sell a few less DS3500s milk the DS8k customers some more.
The problem is that "low end" x86 hardware is slowly but surely eating into what remains of the unix/midrange "server" market. Sure a couple customers here and there buy a mainframe and run zlinux on a couple IFL's they basically get for free after buying the mainframe. But in the end, can they support a business on such a tiny portion of the market? Even major mainframe customers like American Airlines have publicly stated they are moving away from the mainframe.
I suspect they will continue as they have for the last decade, selling pieces of the company, moving all the engineering to cheap labor countries, and charging their existing customers a heavy ransom for the privilege. But at this point in time IBM is beginning to look like Sun circa 2001.
CE's don't even carry proper toolkits anymore. All the FRU's come with whatever tools are required to replace them, and larger items shipped by IBM come with wrenches and tools necessary for install. So the customers end up with a tool and supply pile if the CE comes often. And its not just screwdrivers and sockets. Its hard hats, klein cable fishes, and tons of single use tools like 3" wrenches, etc. Each with a specific purpose, but replacing a common tool like a crescent wrench with some stamped steel single use tool.
The problem is _WHERE_ java is actually used. For the most part that is "enterprise software" and embedded gear. At work its pretty much unavoidable, from the IP KVM's, and fibre switches with their java applets to enterprise middleware running all over the place. Its apparent what all those java developers have been doing for the last decade.
In many cases, simple HTML applications would have been much better but some organization hired a java programmer to write the back-end and the front-end ended up being java too. I can't tell you how often I've seen something as simple as a little monitoring app with a dozen configuration options that requires java and 500MB of memory to retrieve a dozen log messages a day and show a couple blinking lights.
For the home user its pretty easy to avoid java. public web sites rarely have java applets (can't even remember the last one I saw). The few consumer java applications almost always have competitors that are just as good (and generally perform better anyway). I refused to install java on my home machines ~7-8 years ago. I haven't missed it. Flash is nearly there too.
So in many ways, an IT guy could hide/avoid a lot of the java problems by disallowing java applets at the firewall/web proxy level. Personally, if I were a CTO or similar I would include a platform/java questionnaire in my RFP/purchasing matrix and deduct points if the item has java.
It might be possible to write good java applications, but from what i've seen applications written in java seem to be the lowest quality ones. Whether that is some kind of self selection process for java programmers, development managers, or something fundamental in the technology I can't say, but it does appear to be there.
While VM does not have much overhead it does have some.
This is the common view, but its a gross generalization. For some problems you won't be able to measure much of a difference. These problems tend to be problems that are low thread count (1-2 loaded threads) and have a high cache/TLB hit rate with few kernel interactions. On the other hand, applications pegging out more than 8 CPUs, or doing a lot of cacheline ping-ponging, etc tend to take a noticeable hit. Furthermore, applications that are doing a crapload of IO through adapters that are neither pass-through, nor have SR-IOV or similar high speed IO support and appropriate hypervisor support will be hit with orders of magnitude performance problems. Even with support, picking the wrong set of adapter vendor/hypervisor/OS can have pretty serious performance impacts.
So as you said, put it on the bare metal if your having performance problems. But this is sort of my problem with many of the modern developers mindset. The lets just throw another VM at the problem attitude is so wrong its amazing. I think its founded on the fact that a huge number of people in the IT industry don't understand the difference between throughput and latency when it comes to performance problems. I see it all the time with the "we just need another VM" mindset. Half the time the problem is that the attached disk subsystem is doing 300IOPS cause its running on some internal RAID6 with 4 disks and each IO is doing a read/modify/write cycle. Plug in a SSD and reduce the physical server count from 10 machines to 1. Or for that matter move a table out of the database to a memory mapped file, and return the results directly from the mapped page rather than bouncing it through a socket, and then copying it a couple times through some interpreted scripting language before before the ethernet adapter finally DMA's it out. Its amazing when you show someone that the 1.5k piece of data they are returning was copied 30 times around in memory 20-50 times and that is what their CPU is spending all its time on.
Building codes don't address explosions like this.
No, thats a zoning problem. Something that Texas basically doesn't have. Well, I should rephrase that. Texas has a lot of zoning commissions, the problem is that they can't enforce anything. The state laws are written in a manner such that the landowners can request zoning changes, and the boards basically can't refuse.
And, the regulations in Texas can be overridden if it poses undue financial restriction, or some BS like that. So, basically the act of the zoning board refusing to promote something to some kind of retail or commercial properly is overridden by the needs of the landowner. That is why you have apartments and condos being built (literally) 15 feet away from freight lines, and gas stations being built on top of creek tributaries, etc..
The results are usually predictable. In Austin the freight train derailed and slammed into a condo that had just been completed a couple years ago (http://www.kwtx.com/home/headlines/27183369.html). Thankfully, it wasn't a bad derailment and the part of the building it struck was vacant.
But, anyway common sense and public good falls to the needs of the landowner to maximize their profits in Texas. Its not even news anymore when the legislature passes some law to ban some obscure practice some town/etc is doing to protect their residents from some corporate interest hell bent on making a buck. Damn the damage. Heck Texas even has "Tort Reform" which is code-speak for making sure that when the explosion kills a bunch of people in an apartment complex an chemical factory built to close together no one can be held liable for ignoring common sense (and getting zoning permit wavers).
Uh, yah any unix/windows machine can store core dumps. That gives you one piece of the puzzle, but is rarely sufficient, especially if its an error in processing or whatnot and the system continues to run due to error handling.
Maybe, but do you really think the fallout model would work, when people know that all they have to do is dig through a couple feet of concrete and they will have food and a chance to survive?
There are lots of projects like this already, including a number more focused on science than building a bomb shelter. Which is where most of the planet based projects like this stop. They stock up supplies for a while and figure that is all they have to do because they can re-emerge in a couple years to the garden of Eden.
Besides, being stranded somewhere, tends to bring out the creative resources a lot more than being in a glass dome, where all you have to do is break the glass and your safe. Humans do best in situations where they are dying pushing some boundary forward. How much do you think we would know about scurvy, etc if everyone was content to only sail a couple miles off shore.
Are you sure? Because where I'm at (Texas), the steel is in the form of rebar. Concrete is the main structural component. Steel bridges are usually trestle. Because even back when steel bridges were popular there was incentive to save money on the steel.
But, Yah that is the problem with analogies now isn't it...
So, now the developer has this great tool that runs on their desktop that helps them debug the program. Now what happens when it fails in the field? Did the developers spend the time to create sufficient tracing/logging functions so that the end user can report the failures?
The largest problem isn't "debugging" during development, its "debugging" post failure analysis of field problems. Its such a large problem that nearly all "software engineering" and related process is focused on moving the debugging aspects to the developers machine, rather than getting the end customer involved.
When I first started writing code, I spent a lot of time in step/trace debuggers. Now I would say its probably less than 1% of my development time. That is for a number of reasons, the least of which is that I can almost always "see" the bugs in the code without having to run it. For code I'm writing, the output is almost always sufficient to find the bug without really having to think about it. That is something I couldn't do 15 years ago.
Can you imagine how annoying it would be if architects kept saying "The Romans figured out arches two thousand years ago, why do these new kids keep reinventing the wheel" ?
Uh, I think you got your analogy a little wrong. What happens in software is more like "Arches suck cause they are old, and suspension bridges are hard to build. Steel is cheap, lets just build a couple stone pillars and layer on steel to span the gap".
Why would we go to the moon? Why not send robots?
It seems pointless to send humans to do something a machine can do better.
This has been answered a hundred times before by people who can do a much better job. Still...
Its not so much the destination that's important, but the technology to get there and survive. Neither is it about packing up a bunch of stuff from earth and taking a vacation on the moon. Its about building sustaining environments that don't require resupply from the earths biosphere. That is part of why there are so many "biology" experiments on the ISS.
If as a species we wish to survive, at some point we will have to learn how to live outside of the earths biosphere. Now is as good a time as any to learn how to do that because the future is not clear. It is entirely possible that in 50-100 years this planet won't support human life any where near the scale it currently does. If we manage to survive climate change without huge population loss, then there are dozens of other catastrophic things that may do us in.
Having the knowledge of how to survive in a man made biosphere is _NOT_ easy, and may be the key to our future on this planet even without the space aspects. Building power sources that don't involve the sun or carbon cycles is the future as well. Neither of which is particularly useful farther out in the solar system.
The problem with the ISS, is that it exists in a vacuum. There aren't any raw materials to use that haven't come from earth. We need an ISS on an asteroid, or the moon.
Windows 9, scales your 4k desktop so its effectively 320x200, and changes the user interface so the only buttons that work on your keyboard are the up/down/enter buttons.
Microsoft, of course, claims huge improvements in users ability to learn the interface because everything including typing is done by selecting options with the up/down buttons.
All the PC manufactures run by overpaid CEO's that don't know shit about technology promptly release laptops with 320x200 resolution 15" screens claiming that the PC will regain marketshare against the tablets now.
If you use a database you MUST understand and use the relational aspects of things. If you use the database as just a key:value store I will personally beat the ever living shit out of you.
Like all simple rigorous rules. This is sort of bad advice in a lot of circumstances. Sure inventing your own hashing function and using the hashes as the keys in a relational DB is stupid. That said, focusing on the main relationships with your tables, and not trying to describe every single edge case will massively simplify the schema. Plus, there are tons of little pieces of information that often need to be persisted, that just don't tend to have any kind of obvious relationship to anything else in the schema. Being able to add key:value attributes on the fly in the code without screwing with the schema can be a huge bonus to initial productivity. Sure if at some point you discover common, frequently used attributes, or you have some kind of performance issue because your reading some value out of a key:value store frequently then by all means fix it.
All that said, I'm not really a fan of trying to eak performance out of a databases. Use the database for what its good at, complex relationships, and easy storage/retrieval of information. But if your app is trying to do 500k updates per second to a single table, its probably a better idea to seek alternatives rather than throw a bunch of money at database hardware. I have my own mental rule, is this code path going to be a hot one? Yes, then no database queries. There are a ton of strategies for moving the queries/updates out of the paths that are performance sensitive.
What I mean is that there is sufficient hardware to host the pages. My first web server was a 486. So people don't have to run general purpose PCs all the time at home.
The little wireless firewall/routers that everyone has at home are already web managed. So there is a web server of some sort running on the devices. The one I have it can be turned on facing the internet. The one I have also has a USB port, and can host CIFS and DLNA content. And that is all out of the box without any custom firmware. Sure, its not a "firewall" at that point, but their capabilities are already crossing a bunch of lines.
Its not much of a stretch to imagine using some of that storage or providing some to host a user generated set of pages out of the box.
They will also be more careful about investing "for the long term" if they know someone like Google can come in at any time and make their investment worth less than they expected it to be.
First, google has said they are doing this because the incumbents aren't. Secondly, everyone has costs associated with running the fiber. The first company that gets into the neighborhood is going to be able to command significantly higher margins until the second. Hence they will be able to recupe a larger portion of the investment before they have any real competition. Basic business. The problem is that the incumbents are really happy charging everyone top dollar for services that don't cost them anything to provide and they apparently have some kind of unofficial agreement not to truly compete. Otherwise they would be racing to install the technology with the lowest cost and the largest long term return. Right now that equation's result is "do nothing", cause we are in a local maximum due to the really high margins they command because there isn't any competition.
I mean think about it. If you live in a city in the US, there's no *technical* reason that you can't have 100 megabit/sec up and down to your apartment.
Yah, exactly, its almost literally flipping a switch with DOCSIS 3, which is pretty much available everywhere today in the cities.
Pfft, those prices are right in line with the total price for a two year contract on an iPhone,
Forget the iphone, the cable companies cheap plans are generally in the $100 a month range for "triple play" or whatever they call it in your market. If you actually want fast internet, and some sports channels your probably paying closer to $200 a month.
And the expensive part of the infrastructure (the cable down the street) lasts decades. How many years has the phone company milked the unshielded twisted pair they strung in the middle of the last century, or the cable companies that strung coax in the 70-80's. Whoever installs fiber will probably be able to milk it for the next 20-50 years. Its quite possible the fiber networks that are being installed today will form the backbone of communications for the next millennium. Frankly, the guys running the phone/cable companies need to be strung up by their shareholders. Whoever installs the fiber network of the future will put the phone/cable companies out of business and then proceed to milk the results a long time. The part that shocks me is that the phone/cable companies even install anything other than fiber in new neighborhoods.