I think the author is vastly overestimating the importance of the box. Sure, I'll grant you that the Apple boxes are nice, but the only people that get that attached to the box are people that are already attached to the device inside. And that's pretty common for iDevices.

By the way, I didn't have any problems opening the Nexus 7 box. I saw the funny video before I got my device, so I was probably compensating. At least, I had a knife to cut the tape holding the box shut. After that it was smooth sailing. I don't know why the reviewers had such a hard time. Maybe they just had performance anxiety by being on video.

Again, I'll grant that the de-boxing process wasn't as nice as my iPad's box, but it wasn't unpleasant by any means. On a scale from 1-10, with 10 being an iPad box and 1 being the stupid sealed plastic containers, I'd put it at about a 7. It wasn't particularly memorable, and that's probably fine.

Wouldn't the hospitals and doctors still have a profit motive? And, with health insurance policies typically set up so the individual see's little cost to themselves for procedures and tests, who would be providing a counterbalance to the doctors' profit motives to keep costs moderately sane?

I actually think the public option was a good idea, although mostly for folks that don't/can't get insurance through their employer. But I don't think it was actually going to help noticeably with costs.

You were already doing that before, partly through your taxes, partly through effectively paying higher amounts to hospitals, in order to compensate hospitals for the all the ER visits they get from people without insurance (and thus likely never pay). You potentially could have ended up in the situation you were worried about if the Supreme Court struck down the individual mandate, but kept the rest of the law.

How would a TPM do that? TPMs, for the most part, can just do things the main CPU asks it to do, like storing hashes or performing digital signature operations. TPMs can't, despite widespread FUD, interfere with software running on the main CPU. And it certainly can't stop malicious software from overwriting critical OS files.

Actually, it's a one-time $99 fee to sign an unlimited number of binaries.

Secure boot is absolutely effective without a TPM. It's largely independent. As you seem to know, UEFI Secure Boot does a verified boot- verifying signatures on code before executing it. Systems with TPMs do a measured boot- hashing any code executed during boot and storing the hash (no, TPMs won't stop you from running software).

Now, what Ubuntu is apparently trying to do defeats the purpose of UEFI secure boot. They must be locking GRUB2 down in some way. If GRUB2 is left wide open, then the signed Ubuntu first stage bootloader, combined with GRUB2, can bypass the UEFI secure boot mechanisms on everyones' machines. If an attacker starts doing that, the Ubuntu bootloader signature is going to be revoked.

The difficulty in that is that there are still a lot of PCI/PCIe cards out there that don't have UEFI option ROMs. Notably, you might want to use that 2-year old video card when your system is booting. Or, maybe you have an I/O card that you're booting off of. Certainly not everyone is going to need that, but enough users are going to be pretty upset (think: big enterprise customers with lots of users) that I don't think they could do that. However, before Microsoft announced the requirement that systems ship with a UEFI Secure Boot off-switch, I thought some laptops might ship without that option. Still, I think there are enough corporate customers running older Windows OSes or Linux on new systems that OEMs wouldn't do that. I don't think Microsoft is planning a patch to Win7 so that it works with Secure Boot enabled. A lot of corporate customers will be running that for a while.

How/why would the chainloaded [modified] Windows boot manager refuse to run? The way UEFI Secure Boot works is that the UEFI BIOS will verify the signature on an EFI executable prior to passing control to it. The UEFI BIOS largely relinquishes control of the system to the bootloader when it executes it. The bootloader will itself call the next piece of code that runs, not the UEFI BIOS, which is why the bootloader needs to do its own signature verification on the OS (or second stage bootloader) to maintain the trust chain. But, the bootloader absolutely could pass control to something without verifying its signature. And, if that's a maliciously modified Windows bootloader, that second bootloader could be designed to execute a maliciously modified Windows kernel without verifying its signature first.

I've been an unRAID user for a couple years now and I'm reluctant to to strongly recommend it. Lime Technology, the small company behind unRAID, seems to be a one-man show. And that one man seems to disappear for weeks or months at a time. If customer service and technical support are important to you, and you desire timely updates for new features and bug fixes, then unRAID might not be for you. I've largely lost confidence in the unRAID developer. unRAID v5 has been in beta for almost 2 years. At first it seemed like the developer was struggling to fix some compatibility problems that plagued recent releases, but more recent messages indicated that he wasn't paying attention to all the people complaining about those compatibility problems. Now that's he's finally listening to the bug reports things are looking up. He released V5 RC1 about a week ago, but pulled it down after a day due to the bug reports he received. But, a couple days later he posted a new version that seemed to clear up the major compatibility issues people were having for the last 6 months. That was great, although part of me is even more upset now that I know he could have easily fixed the bugs introduced in the betas 6 months ago if he had just listened to the beta testers.

Anyways, unRAID's features are a pretty good fit for the OP, but as an overall product it might not be great for his needs if he wants good support and updates.

You're right- I was wrong. I was thinking about QAM, where each QAM channel can support two HD channels (or 3, if you recompress the video like Comcast). I knew the bandwidth was essentially the same between QAM and ATSC channels, but I forgot that all the error correction drops the effective data rate from 36mbps to 19mbps. 19 would be enough to carry two H.264-compressed HD streams (which aren't widely used or supported for ATSC), but its not enough for 2 mpeg-2 streams.

Verizon's LTE coverage is actually pretty good. They cover lots of major cities, and since they're using a relatively low frequency, it penetrates walls and into buildings much, much, much better than Sprint/Clear's wimax coverage. Verizon claims to cover about 75% of the population with their current LTE deployment, which I believe based on the traveling I've done.

Of course, it seems sucks down the battery. That will be the case until LTE is everywhere, allowing Verizon to switch to Voice-over-LTE and turn off the CDMA radio in phones that have 4G coverage. Right now you always need the CDMA radio on if you want to be able to get calls.

Sure, but how many of those people are watching the major networks? You don't even need 25 digital channels to provide those.

He's probably counting the subchannels. For instance, a lot the major networks have 2-4 programs sharing the same channel. One digital TV channel is perfectly capable of handling 2 HD streams, or more if you use SD streams. So, a lot of networks will have one HD channel, and one or more SD channels airing stuff like weather, maybe a simulcast of the HD stream in SD, and possibly a third SD stream that just airs weird stuff.

25 channels seems like plenty to me. There's only 5-8 major networks (depending on what you consider 'major'), whose affiliates are collectively probably responsible for 98% of what is watched. A single digital channel can carry two HD channels, so 25 channels can carry up to 50 HD programs. That would push the smaller guys out, sure, but I think it is worth it to free up some spectrum for wireless Internet. There's only so much spectrum that is suitable for wireless Internet- it basically needs to be below 2600Mhz to have much of a chance at penetrating walls, and things around 700-1000Mhz do much, much better. Digital television is sitting on some of the most desirable spectrum out there, and quite frankly, a lot of it is being wasted right now.

First, the UEFI secure boot requirement is mainly for client systems. Microsoft is making it optional for servers, and many won't implement it for legacy support reasons. But perhaps even more relevant, the MS requirements definitely don't apply to the types of servers you have in mind, which rarely come with an OS installed.

Second, I suspect many, if not most, rackmount servers still undergo a provisioning process whereby each server is individually configured some minimal amount. Some probably already have to have their BIOSes configured for various reasons. So, for systems destined to run Linux, it can be disabled (if someone can't manage to sign GRUB). For systems that will run Windows, it can stay enabled. Actually, a third situation is probably even more likely- a server destined to run a hypervisor. Given how much VMWare and Citrix care about security, I'm sure they'll support signed bootloaders once servers start supporting UEFI secure boot.

Third, the types of servers that really aren't ever touched come with BMCs with nearly unfettered access to system settings, including BIOS. Even though its a bit of a security vulnerability, I'm sure BMCs will be able to disable UEFI secure boot on server systems.