This is tangential to your overall point; but Amazon's strategy seems to be not no advertising; but rather advertising a new way to buy Amazon stuff to existing Amazon customers. You see some chatter about the e-ink models(though less now, since they aren't trying to sell an entire product category to the non-techies); but the tablets are largely invisible unless you go to amazon.com, at which point you'll see references to the things all over the place.

Given the reports about Amazon's negligible margins on the hardware, and their aggressive re-skinning and integration with their own store of stock Android, it seems likely that they mostly care about taking existing Amazon customers and turning them into better Amazon customers, while the other players are more interested in moving units across the board.

It could also be an OEM-relationship thing: The PC OEMs are largely at MS' mercy; but if MS makes it clear that they are cutting everyone else out of the Windows-on-tablets action entirely, that would presumably inspire the OEMs to do everything in their power to bring their A game to Android for tablets, along with bread-and-butter traditional desktop and notebook PCs(not that this would be their preferred strategy; but if MS wanted to muscle them out of tablets, they wouldn't have too much choice).

If Microsoft wants to avoid that, they must ensure that there is still room for the OEMs to move enough product that cooperation is more rewarding than defection(for desktop/notebook win32 cases, MS has nearly unlimited leverage, are they going to ship ReactOS or something?; but Android vs. 'Metro'-on-tablet is much less clear). If they are trying to make room for their frenemies, it makes sense for them to ship a polished device agressively(to scare them into getting off their asses and building decent products); but not necessarily in huge quantity(so that the OEMs can move their stock as well and, if they don't fuck it up, take over more of the market when Intel does their next silicon revision).

The MS/OEM situation is a little... delicate.

They let someone wearing a simple Casio watch into a high-security environment?

Oh, I don't dispute the general point, Linux is a bit of a pig by embedded standards(albeit a very convenient pig, since it can remain so familiar even on fairly tiny systems or very large ones); but any slowness in the Playbook's boot is likely to be the fault of whatever RIM has heaped on top of QNX, since it's actually a very punchy machine by RIM's historical standards(and substantially more powerful than the Pi: higher clocks, twice the cores and RAM, ARMv7 vs. v6, etc).

For reasons that are sufficiently messy that I certainly couldn't do them justice(and there really isn't any point in copy/pasting a pretend understanding from wikipedia and just wasting space) ozone levels vary considerably over time, both because of natural seasonal weather patterns and because of changes in the presence of various ozone-depleting synthetic compounds.

My understanding is that trends on atmospheric concentration of more or less all of the really nasty ozone-depleting compounds have been positive since regulation went into effect; but that the size and shape of the ozone hole has been a great deal more chaotic from season to season(shape counts, for our purposes, because ozone thinning over the antarctic is a bad sign; but the number of epidemiologists who care about penguin melanoma is limited, while ozone thinning over Australia is directly troublesome).

Some companies will be surprisingly helpful(so long as it's kept to discussion, not actual parts shipped) about your older gear if the notes in their file on you suggest that the reason you have older gear from them is because you buy a boatload of their stuff every year and this particular item is from the boat 4-5 years ago.

Others will be less surprisingly helpful for a per-incident fee for taking your call at all.

(There is also an edge case, that I've only seen once or twice: If you bought the cheapo warranty; but the product is new enough that their high rolling customers still have it under the Serious Classy Gold Enterprise Warranty, and you can convince them that you've found a real problem, rather than just fucked up, you are suddenly a valuable guinea pig who might save them some trouble with people they still have obligations to, rather than just a panhandling nuisance.)

The one detail(unsurprising; but not...exactly...made obvious in Brookstone's documentation or in their "Only @ Brookstone" branding) is that this little toy comes from our friends on the Pacific Rim at Guangzhou Fantasia Creation Toys Co. Ltd.

The Playbook packs a (atypically, for a RIM device) capable OMAP4430 and 1GB of RAM. I don't know if anybody has Linux running on one; but it's pretty much identical in spec to the Pandaboard, for which reports on Linux performance are not at all hard to find(though many are for the 1.2GHz 'ES' version, which should skew things a touch).

Unthrilling by the standards of linux running on one of Intel's little toys(probably with actual GPU support, no less!); but easily within the realm of endurable.

Stop, stop, you are making Larry Ellison's lawyers cry.

Wait, actually, that's probably a feature. Carry on.

As it happens, we call tanks 'tanks' because the brits called their tanks 'tanks' in order to convey the impression(pre-release) that they were not tanks...

Plus, unless your jurisdiction's laws regarding covert videotaping are atypically robust, the fact that the perv-cam is hidden in a fake fire alarm may violate more rules than the fact that you installed it above the bed in that apartment you rent out!

The mere presence of Flash on the system allows it to be craftily run in more areas than you might expect(as with the 'flash exploit embedded in an Office document' story seen here just recently, along with PDFs in Acrobat and a bunch of other abominations). Even if you can find the correct toggles to shut that off, Flash's updater can't really be trusted not to merrily reinstall things whenever the next update comes out; but running a version of Flash that isn't the newest is just asking for trouble...

If it were only confined to a browser(and a browser that didn't trust it in the slightest), it wouldn't be so bad.

I don't know how much demand there would be for this; but there would seem to be a middle-ground option that would solve the problem:

If you don't know exactly what hardware the OS will be booting on; but do know that it won't change, you can probe once, save the results, and use them to charge blindly forward on all future boots.

You would still need the added complexity of the probing and modularity capabilities, and the added size of all the possible drivers, so the savings would only really be in boot time; but you could do it.

What I don't know is whether there would be enough hardware falling in this area to get support(either OSS that isn't bit-rotting or commercial that has enough customers to be reasonably priced per-unit). The PC/server markets can't assume static hardware(even laptop, and some tablet, users sometimes plug in USB devices if nothing else, and are probably even more likely to do mean things like putting the OS to sleep and then changing the hardware out from under it) and the really serious embedded people are not going to like the additional size and complexity.

The S29GL032N on the main system board is a 4 megabyte Spansion flash chip. Not luxurious; but well within the realm of a router-sized embedded linux(though it neither implies nor excludes a bunch of embedded OS options).
 
As for speed, Linux can be made to be quite snappy; but it wouldn't surprise me if enough of the lag is in starting up network-related stuff, along with whatever server program the device uses to allow the client to connect to it, that you wouldn't be able to readily distinguish between Linux, Vxworks, BSD or WinCE on speed alone: sure, an embedded OS booting from solid-state storage on known hardware should move like lighting; but then it has to bring up an external USB device, do the WPA dance, send a DHCP request and receive a reply, and then start up whatever server program the firmware guys threw together for the client to connect to. And then we don't actually know how often the client side of things actually polls the IP where it thinks the device is supposed to be, or whether the device sends out some sort of broadcast when it comes up, or what. Too many variables to even say how fast the OS comes up.

What baffles me is that the author of TFA is apparently geek enough to take a screwdriver to a $150 toy; but is making dumb guesses about OS type based on boot time even though he found a populated serial header, with RX and TX labelled, no less... C'mon, man, you can be pretty sure that the thing is 3.3v(based on the flash IC and lack of visible level converters, might be 5v or 5v-tolerant, highly unlikely to be RS-232), the pins are labelled for you, and it'll probably boot-spew something at you, why are you guessing based on boot time?

I suspect that it's a matter of Brookstone's style. They do a lot of relatively pricey and dubiously useful novelty gadgets(the sort of thing you end up with if you do your technology shopping from the 'Skymall' catalog...) That's the sort of business with enough churn in the product catalog that you'd bankrupt yourself doing a lot of fully-custom parts, so you'll see moderately mod-friendly levels of modularity, lots of space between parts unless mechanically necessary, connectors rather than ribbon cables or soldered components, and so on; but it also isn't one that allows you to specialize around a few core products that you relentlessly refine over several product generations for maximum elegance in mass production and service.

Their price tags, and target market, likely keep them from going with the very nastiest build quality(the product manual, while no doubt uninformative, was probably in readable English, as well); but I wouldn't expect to find either beautifully refined elegance or impressive-but-deeply-DIY-unfriendly extreme miniaturization and integration in their stuff.