"In a sense, Gatekeeper is an attempt to extend the company's infamous (but secure) App Store vetting process to the entire web, creating a way to identify and block unsafe applications regardless of where they came from."

Hello Mountain Lion, welcome to your walled garden web...

Actually, that's precisely what it is. Malware is the most comfortable justification, but benign apps are rejected all the damn time for not fitting with Apple's vision or being construed as a competitor to something they either do now or hope to be doing in the near future. Apple may play the 'malware' card in explaining their policy on not accepting language interpreters, but how in the world can that make sense in a heavily sandboxed emulator?

1. Generally databases are backed up to a plain text file. The database being natively in binary isn't just for fun you know, there is good reason.

2. I've never seen this to be the case. Maybe if your spreadsheet is on a local drive and your database is over the internet, but that's not fair, you can have local databases and you can have spreadsheets on slow network shares. Given equivalent situations, I've seen database do a lot better. Incidentally, this is pretty much the *whole point* of the binary format that can't be read in a trivial text editor, performance pretty well requires it.

3. I really wonder what sort of database interface you are using if this is the case. Databases are much much more capable of having quickly defined views of pertinent data. Spreadsheets tend to get awkward with many sheets in a book with lots of columns and very very difficult to pull the data coherently at that point. Of course CSV is even worse, you don't have that extra dimension that 'workbooks' give you to play in.

4. Again, something is wrong if you consider database use to necessitate pasting into a spreadsheet.

Some of the advantages of a DB:
-Performance
-Better facility for multi-user access and edit (far less tempting for someone to 'save off their own copy' to work on and try to merge in later)
-Better programmatic manipulation of data and reports
-Better representation and use of complex data relationships.
-Far more competent facilities for searching (you even admit this one but dismiss it as pointless) Incidentally, the syntax isn't that arcane even in SQL terms, but consider that you perform these searches on a daily basis as you got to arbitrary internet sites and type strings in boxes or select from a drop down.

You have to understand why the tendency for some groups to use/abuse spreadsheets is very very bad. For example, one business demanded I write them a webapp and use an ODBC driver so that the database format was in XLS format so their hr people could do whatever they wanted to the 'database'. When against all my recommendations they implemented it, they suffered greatly and I was the one left with trying to fix or talk people out of bad behavior when things went pretty much exactly as I warned them it would.

Other possiblities include the two environments continuing into perpetuity, MS somehow finding a unified experience that handles both sets of use cases better, or MS giving up entirely on Metro-UI on the desktop. I would treat their Windows 8 ARM play as risking their desktop market to try to force open the phone and tablet markets for them. This isn't too severe a risk, as they hedged their bets on x86 by having the 'traditional' environment and they know from experience that the worst thing that happens is that customers stick with something like Windows 7. I personally think the Metro-UI will fail utterly across all markets even with the 'unified experience' message. In the MS echo chamber they've convinced themselves its inherently superior to everything else even as the market has been pretty cool to their current offerings. They currently cling to the excuse that it's just because it isn't a unified experience with the desktop. After Windows 8 comes out and if Metro fails, I think even MS will run out of excuses and recognize reality.

Consider Silverlight. All indications point toward an endeavor that got no where and did not acheive the death of flash in favor of an MS controlled technology. Did MS continue pushing it beyond all reason in the face of a market that would not accept it? Not really, they've de-emphasized it and moving onto other things in the hopes *something* will stick in a market where more and more computer use is done through a tablet or phone. I would say they should be content with their desktop/laptop market, but I realize they are probably concerned that even if the desktop market doesn't go away, users will learn they don't need an MS platform to do what they want and carry that lesson into the desktop space.

AMD's problem as Apple switched over was that while they were able to best NetBurst and even Core in terms of performance at insignificant difference in the space of desktop-class TDP, AMD had never done a good job of mobile TDP. Keep in mind Apple was just coming off PPC with a particular sore spot driving that move being IBM's inability to deliver a satisfactory low-power product. Intel showing them that they were giving up NetBurst and their Core offering would return to sanity was a good start, but probably insufficient to offset the fact that Apple was giving up 64-bit for a while. However, as Apple looked at the laptop scene, I'd imagine they were swayed by Intel's more coherent mobile strategy.

As much as Apple fans like thinking of their favorite company being the turning point, by volume Apple's choice mattered little and I don't believe it even was of much value in terms of marketing. I don't think AMD really felt their fortunes diminish until Core 2 released, and even then things were reasonably healthy for them as they still some market segments thanks to their Hyper Transport and integrated memory controllers. Nehalem's arrival with QPI and integrated memory controllers with more channels than AMD's offerings caused a pretty precipitous drop as there wasn't much technical reason to go with AMD over Intel any more.

No way was that going to happen. Intel for some crazy reason forgot that one of their *biggest* draws in x86 land was backwards compatibility. Consider the fact that even this very day most applications ship as 32-bit x86 applications. Over 10 years after Itanium's launch and 9 years after the initial availablitily of x86_64 day to day life is still largely based around x86 compatibility. PAE is a servicable workaround still for 99% of applications out there. While it sucks, we'd probably still be on a 32-bit architecture with PAE as Intel continued and failed to get mass-market acceptance of Itanium if not for AMD forcing x86_64 to happen.

Itanium also doesn't get sole blame, Intel was still 'advancing' their x86 technology and did NetBurst at the same time. It is interesting how two of Intel's largest mistakes in the history of their company happened about the same time. While people are talking about how well AMD did, it's actually a pretty big failure that they didn't do *even better* since Intel essentially handed AMD the world on a plate and a multi-year headstart. Even as Intel offerings were stinking up the world, suggesting new case designs to cope with the hopelessly inefficient architecture, AMD *still* was considered by less knowledgeable people as a sort of 'cheap knock-off' brand.

AMD had a wonderful technical position, Intel bet the farm on Itanium and NetBurst. AMD countered with an x86 architecture that was much much more efficient than NetBurst, a 64-bit implementation that didn't break backwards compatibility, and to further embarass Intel an affordable NUMA architecture with on-package memory controllers. For all this, 'Intel Inside' *still* carried some marketing weight despite the horrible tech behind it at the time. AMD failed in two ways:
-They failed in marketing execution to erode the value of 'Intel Inside'.
-When they did succeed, they didn't really come up with any *new* game changing plays. Intel's QPI was catch up to hyper transport, but since then Intel has continued with superior fab technology, advancing performance per clock, more memory channels per package, and incorporating features for particular sore spots like AES and h264 encode/decode. AMD's biggest advantage at the moment is that Intel GPUs are relatively poor and the Fusion line can quite thoroughly embarrass intel at gaming. The problem being the gaming market is very comfortable with discrete GPUs and this difference matters for a relatively small slice of the market.

Of course, that was a problem for AMD, even as in the desktop and server they were eating Intel's lunch, on the laptop front the AMD offerings were kind of uninteresting. Intel mostly spared their mobile offerings from the disaster that was Netburst and AMDs biggest benefit was going head to head with NetBurst.

You'll see AMD pretty much only in Cray offerings where they have a proprietary interconnect currently married to hyper transport. One big thing Cray talks about nowadays is how they are moving to a more processor agnostic interconnect so that they'll soon be selling Intel based systems.

In everything built since Nehalem came out without such considerations, pretty much all of them went Intel because that was the point where Intel began stomping AMD on both work done per clock *and* memory performance. Before Nehalem some workloads still indicated AMD because their memory performance was better, even if the Core2 architecture was besting them on performance per clock.

The first-tier vendors that carry AMD now largely do so because AMD hasn't demanded a socket change in a while and the vendors can get away with supporting new AMD products in 'old' designs with little incremental investment. This along with AMD aggressive pricing translates to pretty inexpensive pricing being possible for them. At very large scale, however, the additional operational expense associated with more servers sucking down more power and HVAC to get the same work done is a problem that becomes difficult to ignore.

The problem with /dev/random is that it frequently is not feasible. The amount of usable entropy in /dev/random is rather low considering some needs. OpenSSL project itself defaults to urandom in fact. Frequently seeding /dev/urandom with /dev/random is a compromise.

I've seen a *lot* of people take shortcuts like feeding in a well-known arbitrary piece of data as an entropy source in a script invoking SSL utilities. They will complain that '/dev/random is too slow (implicitly not realizing the urandom option)' or 'I wanted a script that would work exactly the same in all platforms and this happened to work'. Out of a plethora of better ways to do it they happen to pick the worst because they simply fail to understand the significance of the random source.