There's a lot of room for improvement in programming languages. New features aren't just novelty. The database/language impedance mismatch is still pretty big, language feature to support multithreading are still weak, strongly typed languages still need to handle "dynamic-ness" better. Microsoft has done a great job of introducing new features that people actually want while still maintaining backwards compatibility. Oracle is being way too conservative here and it does matter to their customers - even the big ones.

I spent a lot of time recently working at a fortune 20 company. Java was the official programming language of the company, but the Enterprise Architecture group was starting to lean closer to .Net when I left.

Java has been playing catch up with C# for almost ten years. Attributes, generics, and lambdas were all added to Java long after they were added to C#. Also, Microsoft made them part of the runtime, while Java only made them part of the compiler (for the most part), so the features work a lot better in C#.

The point of this article is that Oracle has been slowing down the pace of innovation to an even slower pace than Sun was at, and Sun had already lost a five year head start to Microsoft very quickly.

"runtime and a language with a huge install base" describes a future where Java just coasts. By contrast, Python, Ruby, and .Net are all runtimes and languages (several languages in the case of .Net) with a huge install base that are actively introducing new frameworks, development tools, and feature on a regular basis. I'm calling an interpreter a runtime for the purposes of this conversation.

The number of possible valid credit card numbers is so small that any hashing solution can be brute forced very quickly, even if each record has its own salt. The only protection would be to make the algorithm secret, but then you've just reduced your system to security by obscurity and as soon as someone figures out the algorithm, you're toast.

I wouldn't recommend Office Automation on a server if there is any alternative. For beginners, there's too many gotchas and for advanced users, there's plenty of alternatives that will do what you want without too much difficulty. Office with .Net is especially problematic because the COM components run as out-of-process servers and due to .Net's garbage collection and COM interoperability, they are difficult to get to shut down properly.

In the payment card industry, this is called a token, not a hash. The difference is that a hash can be algorithmically generated from the source material, while a token cannot. Because there is no forward link outside the entity that generated the token to go from card to token, the tokens can be different at each merchant, making a loss of token much less of a problem than a loss of hashes would be. It's also 100% infeasible to break the token generating algorithm since there isn't one. In my experience, tokens are simply generated sequentially (skipping those that don't pass Luhn check). Another beauty of tokens is that they can pass validity checks for credit card numbers, so they can be handed to third-party software and treated just like card numbers, but without the risk of breach.

They implemented it the way they did so they can sell it as a drop-in solution that requires no coding changes. Unfortunately, a security technologies don't matter as much as processes do, so this product, like all other silver-bullet products, will never be all that good.

You mean regular DBAs like the next Edward Snowden? Inside threats are important and are one of the reasons this feature exists. LitchField did what he does best; he showed that the product doesn't quite live up to the marketing material.

How would a hashed credit card number ever be useful? You would have a really hard time sending a request for payment to a payment processor if you did.

They didn't say that. They said that the 40% "dwarfs the number of watchlisted people suspected of ties to al Qaeda, Hamas, and Hezbollah combined". That means that the second list is only a small portion of the remaining 60%. It also means that most of the 60% aren't suspected of having ties to the three groups - and therefore also are probably false positives. Note that they said "suspected", most of the 60% aren't even suspected of having ties to the big three.

Maybe he's Bill Mensh who actually did lay out the 6502 by hand.

That's why I was careful to say "end-to-end encryption" instead of "https". If you aren't using the public CA infrastructure, your data may be private.

Is this article suggesting that new communication paradigms are a bad idea because the security gear optimized for the old paradigm won't work? Should we wait for the security industry to invent multipath TCP? BTW, this is the same security gear that can already be thwarted by end-to-end encryption. How is this any different?

Believe me, this install will never be PCI complaint. Either they will choose a solution that doesn't store cardholder data, or will outsource the credit card processing to someone else. It isn't cost effective to have a PCI compliant installation this small. So, this issue can be ignored when discussing "should a server like this have a firewall?".

Yes, it's legal. But, Southwest's Contract of Carriage lists 13 reasons that boarding can be denied. "We disagree with you" isn't on the list. So, they violated their own contract and they owe the passenger between 200 and 400 percent of the fare, depending on how late he gets to his destination.