Yup, you're right, they've been hit by overwhelming 8 TB/day. The point (still true) is that that amount of data was hadled by whole pod with cumulative data throughput of at least 350 TB / day. And that, while not large enough to hold 8 TB data, any of those drives is capable of such daily average data rate, thus the difference in average datarate thrown at pods of different HDDs is not showing the difference in performance of those drives at all.

Do the maths. You can get 1TB 7200 RPM drive for ... say 60$. 1TB SSD costs you from 350$ upwards (that's at newegg's). The power consumption of typical HDD is around 6W and depending on electricity rate (at my place it's around 25c/kWh) it takes around 22 years to burn enough electricity to cover the drive price difference. And with larger single drive sizes this comparison gets even worse for SSD.

The only reason to ditch HDDs in favour of SSDs is performance. If you only use your data at low speed (such as streaming single Blu-ray video at 54Mbps), any semi-modern HDD will do.

How about some elementary arithmetics instead?

1TB of data per day on average boils down to neighbourhood of 11.5MB per second. I doubt that you are currently able to purchase a hard drive that can't sustain writes at several times higher speed. And that's single drive write performance while beforementioned 1TB data did hit whole Pod and was presumably spread over all of drives in the Pod. Hence the figure 1TB daily data is not showing any kind of performance limits ...

More likely the meaning of 1TB daily data was that both test pods got hit by similar amount of data which is not showing the speed difference but rather showing that drives were not idle and thus the nil failure rate was a result which can be achieved under moderate load (things do tend to break under load more often).

OOP is, IMHO, over-rated. And you can use whatever you want from bash if built-in functionality is not (good) enough for you ... just as you can use .NET from powershell.

And don't whine at the syntax, bash inherits legacy from Thompson shell (yup, that's Ken Thompson we're talking about) via Bourne shell. And that legacy starts in 1971. And legacy is good for many things.

If you want smething more modern, you're free to use whatever interpereter language (perl, python, Tcl, Erlang, Ruby, PHP, Emacs, TeX, ...) as your default command line interpreter.

... which allies exactly? Germany? France?

You're not entirely right. They both receive partly pre-rendered content. Dumb terminals receive data about which character they need to display at certain (relative) screen location, however the shape of characters is done by terminals. X terminals receive parts of display content pre-rendered as bitmaps, they don't invent any of contents. Indeed they don't receive exact display contents in full and every time (eg. acording to refresh rate), they need to re-assemble full display content from incremental updates received from the mainframe/X client ...

Back in year 1999 (yup, that's full 13 years ago) I was using my desktop Linux (Red Hat Linux 5.1) on DEC alpha, which was fully 64-bit kernel and user space. We've been running Linux on some seroius DEC alpha machines instead of running DEC's own UNIX implementation (OSF/1) because it actually behaved better.

After I changed my employer in 2002, I had to downgrade to i386 version (being much more stable than amd64 at the time).

The thing is that with state-of-the-art equipment (not considering antiquated nor cutting-edge equipment) the price/performance curve tends to be flat at the low-performance part and then starts to rise towards high-performance. Meaning that at certain capacity upgrading it is not cost effective any more. At this point, one can decide either to upgrade anyhow and handle the increased price/capacity in some way (eg. charging customers more for same service) or not to upgrade and keep consumption under control.

A bit rough example: if you eat say 2 Big Mac per day, each costing you a $, why doesn't McDonalds offer you eat-all-you-can for 60$ per month? This would make their income the same as it is today, right?
Because many users would over consume and/or start throwing food away (even more than they already do). Which means that they'd have much higher costs ...

The fact is that many of heavy-users of unlimited (or nearly unlimited) plans abuse the bandwidth they've given.

Another common misconception is that telcos still pocket absurdly high profits. They do fine, but their profits dropped a lot. A decade ago, most profits in mobile telecommunications went to telcos and telecom equipment manufacturers. Only small share went to VAS providers and handset manufacturers. Recently things turned upside down: most money goes to VAS (Google et co. through advertising money) and smart handset manufacturers (Apple, Google, Samsung, ...) while less money lands n pockets of telcos and consequently telecom equipment manufacturers. One can not make real money selling infrastructure and unlimited plans are final proof of it. And to add a nail to the coffin: there are only a few telecom-grade equipment manufacturers and the competition between them is not as fierce they want us to believe. It's much less fierce than in general IT industry meaning prices are not always falling with sale volume as one would expect.

In short: as telco industry slave (I'm working for them) I can tell you that things are not nearly similar as in general IT, so one can not make direct comparisons.

You pay things metered because this is a perfect way of keeping consumption under control.

It's not actual transferred bit that costs telco. It's overall capacity that costs telco and if overall consumption is kept under a certain threshold, capacity of infrastructure can be kept lower and thus cheaper.
Did you ever notice that 100Mb ethernet switches generally cost slightly less than 1Gb ones and the 10Gb ones are quite significantly more expensive? Ethernet switch is not consumable, it's infrastructure (among other things).

A proper telco-grade base station consumes whole lot of electric power just to provide coverage. And some more to actually pass bits to/from users. It really depends on electricity prices, but that can raise to a few hundred euro per month. If there are only a few users with unlimited wireless broadband plan in the covered area (and thus they enjoy high speed), then their subscription only pays electricity of the base station. There's also backhaul and core network which also associate some expenses.

Those bastards telcos actually want to get their investment paid back in a decent time frame and also make some profit. Old (copper) infrastructure had paid back the investment way back, while new infrastructure (fiber, wireless) did not.

Talk about US petrol prices. In Europe, petrol price is in vicinity of 1.50€ per litre (likely even more), which is in neighbourhood of $7/gallon.

Exactly. So killing everyone's battery isn't due to P2P back-end. Unless smoke is caused by battery being killed.

What exactly is P2P back-end?