There's a huge difference in the job market for pure scientists (the "S" in STEM), and IT folks. The job market for someone with a PhD in, say Astronomy is terrible. Lumping these folks together with the legions of code hackers is ridiculous.

Yes, but is that a Postgres problem or a MySQL problem?

Bandwidth is nice and all, but for many uses latency matters more -- any numbers on what that will look like?

The biggest difference is that academic code is _short_. If your whole code base is 10k lines, it's easy to cover all the requirements in a clean design. If you are dealing with millions of lines, there's all kinds of oddball unforeseen interactions and requirements that pop up way late in the game.

So, if I'm a random security researcher, how do I get my hands on these SCADA systems to test them? They certainly aren't open source, and I'm guessing they aren't cheap. I doubt you can just type a credit card number into GE's web site and download one. How do they get one to look at?

ObJwz: http://www.jwz.org/blog/2011/07/mork-keeps-on-giving-when-the-database-worms-eat-into-your-murder-trial/

That mork format was really something else. Whoever thought that having the browser history stored in an impenetrable format with no tools to read it should turn in their nerd badge.

Note the above is certainly true for high-end HPC clusters, but running large Oracle databases on those kinds of machines seems kind of expensive for the performance you get. For Oracle (and other databases), the high-thread count Sparc T-3 / T-4 kinds of processors will give you much better performance at lower cost. Of the few ia-64 installations, I bet most are floating-point heavy HPC clusters, I wonder how many are running Oracle or VMS and "business" workloads.

Of course, if customers actually wanted Oracle on Itanium, there wouldn't have been a lawsuit...

The company that killed WebOS and seriously considered selling off their whole PC business line is desperate to hang on to their Itanium business?

ARM based chips will never be real Intel competitor, in the same way that Intel chips never were a real competitor for IBM z-system class mainframes.

The translation is a bit hard to read, but I can't believe any organization only has 70 trouble tickets in a month for 7,500 machines, regardless of the OS that is running.

The real problem here probably has to do with shared libraries. If you have a function in a shared library with external visibility, the compiler can't remove it, unless it is doing whole program optimizations across all of the programs, and I doubt the LibreOffice builds are doing that.

Given my experiences in Italy, if the neutrinos arrived exactly when they were supposed to, Italians would consider that about 15 minutes too early.

This is one reason there are so many JavaScript (perhaps actually DOM) questions -- where is the documentation to answer questions like "how do I do x, across every major browser versions which didn't really follow standards well"? If I'm programming in, say, Java or C++ with some framework where I control more of the environment, I can go to one place to answer questions, but there's no one definitive source for these cross browser problems.

The phrase "C/C++", that is.

C++, especially modern C++, is such a different language from C, that it makes no sense to talk about them as if they are the same. A decent programmer can learn everything they need to know about C in about two weeks. Modern C++ really takes years to really master. When I interview programmers, I'm immediately skeptical of anyone who claims to know "C/C++". Often, this means the most advanced "C++" feature they use is the // comment.

I always found PostgresQL harder to admin. It needs to be VACUUM'ed periodically. How often? The poor admin is supposed to figure that out themselves. Oh, and don't try to actually use the database during a VACUUM. Even after the autovacuum feature was added, it never seemed to work right, and my databases still needed to be vacuumed by hand, sometimes taking more than a day to run. Even with frequent vacuuming, indexes can get bloated -- I would see indexes with more pages allocated than entries, which needed to be manually reindexed. Worse, you need to tell postgres how much memory to allocate for vacuum'ing, and if you don't get it right, it 'leaks' disk space. None of these sorts of things have ever been a problem for MySQL.