Note that certs can and are used for things other than SSL on DNS names. In fact, the field used for the domain name is "Common Name". The CN field is used for a dozen things depending on what the cert is used for.
We should probably blame Netscape and everyone else who pushed using X.509 unchanged instead of trivially adding a field that required a valid DNS name.
This is a mismatch between the X.509 standard and how browsers use it. Most interesting is that the browsers have the information to correctly parse it, whereas the CAs don't have the information to do so, unless they are only issuing certs for SSL. As someone who would like to see widely usable PKI outside of the web-browser, I'd really rather fix the browsers than break the certs.
Microsoft is a marketing company more than a software company. This is a deft stroke of shaping opinion. Why?
Because the tacit assumption is that Open Sourcers focus on price, not value. They want to provoke the predictable "Microsoft software is too expensive" response. It lets them cast Open Sourcers as not being able to bridge the gap between technology and product.
Technology does something specific. A product solves a problem. All that this line of commentary does is to underscore Microsoft's message that Open Source isn't ready for business. Railing about expense without attacking the core problem of value only plays into Microsoft's hand.
What's more tragic is that they may be right. There are precious few Open Source technologies that are developed and focused to the point of being a product.
I did a control system for a covered skid that contained three natural gas compressors. They had to pump it up to 3600 psi (245 atmospheres). It was for fueling vehicles. The pressure had to be that high so that the tank would equalize to a reasonable pressure / gas content in under 10 minutes.
It was 40 degrees F in the winter and 95 degrees F in the summer. Took about 6 months so I got to feel both. It also reeked of natural gas, was greasy, oily, etc. There were metal shavings and fumes from all of the machining and welding.
I also worked a similar gig off and on for about two years involving a circuit-board drilling operation. Imagine walking through a factory floor with acid baths and various machinery to work on scoring machines and massive computer-controlled drills. The drills were pretty serious (60krpm) and they each had a 1.5 ton block of granite just to dampen vibration. To this day, it's the only computerized machine I've worked on that required a pneumatic hook-up.
Here's a photo of the drills from the internet: http://www.cerambus.com/equip/images/4-MK%205%20DR.JPG
As of Python 2.6, look at the multiprocessing module.
The shared memory feature is nice.
As of Python 2.6, look at the multiprocessing module.
Look at the multiprocessing module.
Not only does it implement processes in a way that is quite similar to the existing threading implementation, but it provides a ton of synchronization / locking primitives that work seamlessly across processes. This includes the ability to utilize shared memory. It's crazy that this module doesn't get more press, because there's nothing quite as easy in most other languages.
Actually, cartesian products and joins aren't gone. It turns out that they just end up being done client side.
It's the tragedy of "join-less" databases. Joins do something that you need. The lack of joins forces people to correctly normalize, which ironically they should have been doing anyway. It doesn't take away any genuine need to join though.
In the end, the problem is that people just want a "default tool". They don't want to think about their requirements for data consistency. The really scary bit is that while RDBMses are the "default tool" of yesterday and slacker DBs are the "default tool" of tomorrow, neither of them are really the "problem".
The "default tool" attitude IS the problem. Unless you carefully weigh your data consistency requirements, you shouldn't be making that call at all.
I welcome the slackers and all of their new options along the spectrum of speed versus consistency. It's just that most of the people developing applications scare the shit out of me. They're so cavalier (or should I say, "agile", or maybe "pragmatic") about requirements that it's truly disturbing.
That said, if you're really interested in all of the options, I also recommend checking out memcachedb, memcacheq, and redis.
Maybe it's a declarative language?
I don't know why, but "They dropped dolomite on it." made me think of http://www.imdb.com/title/tt0072895/
The biggest difference between time and space is that you can't reuse time. -- Merrick Furst