Beer is, by definition, based on fermented grain. Sure, there are other (at times odd) ingredients involved in these ancient recipes, but at the end of the day Dogfish Head is a commercial craft brewery, and a very successful one at that. They didn't get where they are by making beers that suck. I've had quite a few of their beers, and while some definitely qualify as strange, most of them are quite good, and all of them are at least interesting.

Modern "embedded" x86 processors generally sacrifice a fair amount of performance to meet their target power/heat numbers. Once you make those concessions, the performance gap relative to ARM narrows considerably. Furthermore, the most computationally demanding tasks in the embedded space tend to be either graphics/video (which will use embedded GPU hardware) or amenable to running on a DSP (implemented using GPU compute or dedicated DSP hardware).

ABI = Application Binary Interface. Defines the pointer sizes and conventions for passing function arguments at the object code level (among other things). The ABI determines how the compiler generates object code for function call/entry/exit, and the width of pointer types.

API defines the interfaces seen by the programmer.

This sure feels a lot like a throwback to the old 16-bit DOS days, where you had small/medium/large memory models depending on the size of your code and data address spaces. We've already got 32-bit mode for supporting pure 32-bit apps and 64-bit mode for pure 64-bit; supporting yet a third ABI is just going to result in more bloat as all the runtime libraries need to be duplicated for yet another combination of code/data pointer size.

I hate to say this since I'm sure a lot of smart people put significant effort into this, but it seems like a solution in search of a problem. RAM is cheap, and the performance advantage of using 32-bit pointers is typically small.

For most embedded applications you're probably better off just running a 32-bit OS and calling it a day. Embedded is mostly on 32-bit ARM processors anyway.

Please read the complete RSA press release and parse it carefully: https://blogs.rsa.com/news-media-2/rsa-response/

They don't deny that they entered into a deal. They deny that they entered into a deal "with the intention of weakening RSA’s products, or introducing potential ‘backdoors’ into our products". In other words, there was a deal, but they are insisting that they didn't realize at the time that the algorithm had a backdoor.

If there was no deal at all, they wouldn't have felt a need to qualify the denial with the above quoted text.

Ubuntu isn't even really an exception. You can still install the barebones "server" flavor, then drop whatever DE you want on top of that. Or start with one DE, then install another DE alongside it. As far as I'm concerned it is just a nit-picky detail of what they happen to promote as the default distribution image.

I was under the impression that they were actually PCP&C designs manufactured by Seasonic under contract. But I could be mistaken.

The article quotes the CEO as saying the company is struggling due to "capital constraints". Then right below that, "This has been a common refrain. OCZ reports lower sales, it blames a shortage of NAND." Does the author truly not understand the difference between a shortage of cash to fund ongoing operations, and a shortage of parts?

Regardless, I don't see their departure from the scene as a great loss. Their spotty reputation for quality and customer service has caused me to avoid their products in general, and has apparently come back to bite them in the ass. The only sad part is that they might take PC Power and Cooling (one of the premier PSU manufacturers from back in the day, which OCZ acquired a few years ago) down with the ship.

Agree 100% with your disdain for "technology as panacea". However, if these tablets did not meet the specs stipulated in the contract that's still fraud regardless of whether it was a good idea in the first place.

Bingo. Comparing the breakage rate for tablets that have been handed out to middle schoolers to that for tablets which have been bought by (and presumably used mostly by) adults is meaningless.

That said, if the contract stipulated that they were supposed to have Gorilla Glass screens and they didn't come so equipped, then that's fraud. If fraud is proven, then hopefully this results in some hefty financial penalties and/or jail time for those responsible.

Maybe that was meant to be in dog years. Or something.

The problem with being solely dependent on binary drivers is that hardware vendors eventually stop supporting older hardware on newer OSes. With a viable Open Source driver, it is (almost) guaranteed that you will still be able to use your device in the next version of Windows, Linux, etc., even if the hardware vendor declines to port the driver or goes out of business.

I don't see what's so hard to sort out. They make a decision to publish the register-level hardware specs, and they post them. All the Open Source devs need is access to the same hardware documentation that nVidia's own driver developers use; they're not looking for the source code to the existing proprietary drivers (though nVidia releasing their own drivers under an Open Source license would be great too).

The main reason Open Source video drivers for newer nVidia and AMD GPUs have had such a checkered history is precisely the lack of public hardware specs. The driver teams have been forced to reverse-engineer some of the hardware features to develop the drivers, which is far from ideal.

Open Source drivers for Intel GPUs have historically been pretty good (well, at least until they started using the PowerVR-based junk...); the issue there has been slow hardware, not buggy drivers.