There's a 50mph road not far from where I'm at, with several intersections with traffic lights on it. The yellow light lasts more than 5 seconds.

That's just so wrong. Nope, the airbags are the supplemental restraints. They work together with seat belts. Airbag deployment in a frontal collision actually makes you more likely to get injured if you wear no seatbelts, than if you had none - at least for the driver. I've had a T-bone with side airbag deployment, and I can assure you that in this particular case, the seatbelts alone would have done nothing. Again: the restraint system in a car is designed as a system. It's not designed to save you from anyone's folly, it's designed to save you from effects of sudden deceleration. The causes of such sudden deceleration can be and often are beyond human control.

For what amounts to read-only data, it's a trivial problem with multiple, trivial solutions.

This is a site serving what amounts to static content with simple lookup. There's zero reason to even use a database outside of startup. On startup simply put it into a native data structure in your programming environment of choice, and be done. MongoDB with replica sets, my ass, that's just crazy. The whole lookup application could be a couple of files on a CDN, a single executable and a single bootstrap data file. And syslog somewhere to listen to the traffic updates. It could run on a VM image with a dozen files on it - literally. Heck, you might not even need any dedicated application servers. Just slice-and-dice the data into multiple, reasonably-sized json files, sliced by VIN ranges, as have the webapp do the lookup entirely using the static content. Then all you do to deploy is upload a bunch of files to a CDN.

The "enterprisey" scalability is probably an entirely overblown and over-the-top approach for such a simple web app. All of the executable and the data needed to serve this app fits comfortably in memory, all at once. You don't need anything fancy. The "effort" needed for lookups and generation of the replies is really tiny, as long as you use a solution that is compiled (or JITed). I'm pretty sure any modern multicore desktop machine would easily handle all of the load and completely saturate a couple gigabit pipes with html in response to the requests. Images and static content belong on a CDN (duh).

The entire dynamic content of the site could be served by a simple C++ executable that doesn't even need to use a database outside of startup. Populate a couple static data structures from sqlite, use libmongoose, microhttpd or a similar httpd library, and you're done. Fast n' easy, the entire deployment could consist of two files: a staticly linked server executable + bootstrap data file. The whole code, with syslog output, could probably fit a couple thousand lines or two, with comments and license headers :)

Buffer is one way of looking at it. Another way is a multiple-issue pipeline.

Or, perhaps, they are absurdly bad at catching the real ones, so they must turn the imaginary ones into real ones since they are much easier to catch.

"to arouse lust towards children" One could equally say that this satisfies said lust without, you know, involving any real children...

I'm probably feeding the troll, but who the fuck cares if the middle is not thin? Heck, I'd say who the fuck cares if the sides aren't thin - I have no problem with the look of the inch-thick '07 aluminum iMac. It'd be sheer insanity to try and make the whole thing as thin as a laptop, with the power supply inside of it. You can save quite a bit of money by not making it super-thin where the guts are.

These days the "hackery" is equivalent to booting to a working partition (can be on a USB stick) and running Multibeast. It's about as fire-and-forget as it gets.

There are two ways to a hackintosh: using random hardware, and using hardware that's purposefully selected to use the same components that Apple uses in their hardware. The "I''ll just try running OS X on whatever I have" route is perilous and ill-advices. Buying stuff from tonymacx86's buyer guide is a much saner choice, and it worked great for myself.

I've been using one for almost a year now, and there's no looking back. It was only tricky to set up because initial releases of Mavericks were trickier than the current release. I'd say it was a day well spent to set it all up. These days, using it is no different than using any Apple hardware would be, except that after OS version upgrades one has to reboot to the recovery partition and re-run Multibeast.

Modern HDDs media have coercivity so high that the Earth's magnetic field, and the fields from nearby "electronics", are immaterial. The best thing you can do to a HD is leave it alone, not spinning, in a non-condesing atmosphere. As long as the spindle doesn't seize up due to lubricant migration, it might well last for centuries.

Graphics cards really need bandwidth only for texture uploads, and if you're shuttling images between the CPU and the GPU. For many high-performance games, the bandwidth requirement for the CPU-GPU links is rather models.

Thankfully, it acts as a PCIe bridge, too :)