But for Kindle if it's supported in Kindle Previewer, then someone screwed up pretty carelessly.

I'd argue that if any WebKit-based reader doesn't support it, then someone screwed up pretty carelessly, but that's just me. :-)

I am, of course, assuming that Thunderbolt controllers contain an IOMMU, but given that it has to function as a nontransparent PCI bridge when attached between two computers, that should be a safe assumption.

The whole point of requiring every driver to call the prepare method on an IOMemoryDescriptor object before telling a device to do DMA and calling the matching complete method when the I/O is done is so that the OS can create and tear down mappings in various IOMMU hardware to protect the system as a whole from buggy devices (and particularly those that don't understand 64-bit address spaces). If that isn't happening, I'd argue that it is a kernel bug, and given the security implications, a pretty serious one.

Thunderbolt is rather different, because the devices are basically PCI-E cards with a Thunderbolt transceiver bolted on. As such they can do anything that a PCI-E card can do, including accessing all RAM. PC Card devices have the same issue, and so does Firewire. It's a serious issue and tools that exploit it have been available for a while, both open source and commercial.

Here's what I don't get. Back when the G5 came out, Apple used a custom piece of hardware called DART to create a boundary between the I/O address space used by PCI devices and the physical address space used by RAM. It required device drivers to explicitly configure mappings before a PCI device could scribble on RAM, and limited those devices to scribbling over the ranges specified by the OS. That hardware went away with the Intel transition, of course, but most of the newer 64-bit Intel hardware has a feature called VT-d that does essentially the same thing. AFAIK, the 64-bit OS X kernel uses that functionality by default if the hardware supports it, so all of those tools should be completely non-functional on recent Macs running Mountain Lion and later. And I think I remember reading somewhere that Thunderbolt controllers contain an address translation table as well.

With that in mind, how is this Thunderbolt device somehow gaining the ability to tickle hardware that probably doesn't live on the PCI bus, on the opposite side of the Thunderbolt controller, at a location that wasn't explicitly configured for DMA by a device driver? Does it involve rebooting the machine and exploiting a driver bug in EFI?

Heh. I'll show you. I haven't updated my preferred roaming list since 2003. My ancient flip phone will never even see your tower!

On the other hand there is only so much wireless spectrum available that is set aside for 802.11x. Ever been to big even in a hotel where eveybody and their brother has the hot spot function enabled on their phones, is caring around those mobile hot spot things, folks are running classes in conference with their own wireless AP setup for their students, etc.

IIRC, cell phone hotspots deliberately limit their maximum gain to minimize interference. They typically have an indoor range of about 66 feet—essentially, your hotel room and one or two rooms on either side. Based on that, I suspect that those personal hotspots are more likely to be a symptom of the problem than its actual cause.

If you're seeing poor performance on a hotel's infrastructure Wi-Fi network, odds are good that either:

• The hotel doesn't have enough APs.
• The hotel's external bandwidth is insufficient for the traffic.
• The hotel's DHCP server ran out of IP addresses for the number of clients.
• The hotel's DHCP server is buggy and sends out offers based on what the client asked for, without properly checking that the request is sensible (e.g. that it is in the right subnet, that no other client is using that address, etc.).
• The hotel's systems are, in fact, down.

The first one is usually the main problem. Most hotels' networks were designed under the assumption that folks will have at most one Wi-Fi-capable device per room, and that most folks won't be using them at any given point in time. When you have a bunch of geeks with three or four devices, all talking at once, the spectrum can get clogged pretty badly.

There are two possible fixes for that problem. The first fix is to deploy 802.11ac more broadly. For clients that support it, this reduces congestion considerably, both by providing more channels and by reducing interference through beamforming. The second fix is to greatly increase the number of 802.11b/g APs (and, to a lesser degree, 802.11n APs) so that you can reduce their maximum receive and transmit gain settings, effectively creating a large number of very small clusters of nodes instead of a few big ones. Note that these solutions are not mutually exclusive.

Because they don't allow you to bring your own drinks and snacks...and you don't want to be "forced to purchase theirs at a dramatically inflated price". I'm just curious how strong your principles are.

That's not really a fair comparison, for several reasons:

• Movie theaters are considered public locations. Hotel rooms are considered private locations. Just as a hotel cannot authorize the police to search your hotel room without a warrant, it also has limited authority to govern what you do in your room, so long as your actions do not cause damage to the room.
• You stay in a movie theater for the duration of a single movie. Unless your metabolism is insane, you can trivially eat before you go inside and wait to eat again until after you leave. By contrast, you stay at a hotel for several days. Going without Internet service for a week is usually a much bigger burden than going without snacks for 90 minutes.
• Health code regulations often prohibit businesses that sell food from allowing outside food to be consumed on the premises, so even if theaters wanted to allow you to bring food in, they may not be able to do so.
• Movie theaters charge high prices on food to make up for their miniscule profit on movie tickets. Hotels that charge hundreds of dollars per night are making a lot more than a buck per person, so they really don't have any good excuse for ripping people off by charging $15 per day for Internet service.

So although they might be similar in principle, the differences in practice are so large so as to render one a meaningless annoyance that we can live with, while rendering the other a serious act of interference that cannot be tolerated.

There are legit reasons they would want to block all those random wifi hotspots. All those random hotspots are (or could) degrade the performance of the service they are offering. The air does not have unlimited bandwidth. If they knock out all the "rogue" hotspots, they *could* manage the airways within their building better.

Except the reality is that all of those random hotspots are almost by definition physically closer to the user than the ones provided by the hotel, which means the two Wi-Fi radios are likely to be using less power, and thus producing less interference than an extra guest on the hotel's network would produce, not more.

No, there's no legitimate reason for doing this. The only reason they do it is so they can charge as much for one day of service as most people pay for half a month. And yes, I often choose lesser hotels that offer free Wi-Fi over nicer hotels that charge for it. I consider Wi-Fi service to be a basic necessity, and hotels that don't build that into the cost of doing business are not effectively serving my needs.

If a hotel blocked my Wi-Fi hot spot, I would very likely leave their jamming range, go on Hotels.com, leave a negative review, book a different hotel, then go to the front desk and demand a complete refund of the cost of my room. If they refused, I would stand right in front of them while I called my credit card company and issued a charge-back, so that there could be absolutely no doubt in their minds why I did so. I don't care how nice your rooms are. If you're deliberately interfering with my ability to get things done solely so you can make a quick buck, you are not a hotel that is worth staying in.

So the guest is paying to offer Wi-Fi to people, and the hotel might require that the guest instead pay for the hotel Wi-Fi service.

That simply isn't a reasonable thing for a hotel to do. You would never accept a hotel requiring you to wear only hotel-provided clothing in a conference room. How is requiring you to use their Internet connection instead of a connection that you have already paid for any less absurd?

That search for the lowest place without rats in the toilet is why they do bs like this... they have to compete on "price" and then once you're in make up their money on crap like charging you for internets. Works the same way with airlines, and that's why airlines suck now.

See, that's the opposite of my experience. I've never seen a $50-per-night hotel that didn't offer free Wi-Fi. It's the $300-and-up-per-night hotels that charge $15 a day for Wi-Fi. These same hotels also charge five bucks for a tiny little can of Pringles, four bucks for a soda, etc. Basically, they assume that anybody with enough money to stay in those hotels also can't be bothered to walk downstairs and across the street to the gas station to buy a soda.

And the more expensive the hotel, the more likely they are to use a complex Wi-Fi system that requires you to sign in through a captive portal, breaks in fascinating ways, and is horribly unreliable. The cheaper the hotel, the more likely they are to just toss up a halfway decent trunk line connected to a handful of off-the-shelf Wi-Fi base stations, and be done with it. Guess which one actually works reliably? (Hint: It isn't the complex, expensive systems used at the high-priced hotels.)

As for when hotels should be allowed to block Wi-Fi, the correct answer is "never". It is never acceptable to deliberately cause interference with properly licensed hardware operating in a normal manner. It is illegal, unethical, and any hotel doing so should get buried in fines so high that nobody else ever even thinks of committing such an act in the future. Now if those Wi-Fi hotspots are operating incorrectly and causing interference, it is within their right to use passive mechanisms to track them down and ask the customers to stop using them. However, the burden of proof falls on the hotel chain to prove that those hotspots are, in fact, not operating correctly, and that the problem is not caused by the hotel's Wi-Fi network being set up incorrectly (which it almost certainly always is in any of the sorts of hotels that would attempt such jamming).

Let me clarify what I meant by that. Touchscreens built into the console of the car should be banned. Stand-alone GPS receivers are different, because you mount them in the corner of your windshield, so your peripheral vision is still on the road while you're looking at them.

In-dash GPS systems should be banned, both because they seem to universally suck and because using them to figure out where to turn is inherently less safe than using the ones mounted to your window, because you have to look down so far.

Of course, the absolute worst GPS systems are the in-car GPS systems that detect when you're moving and won't let you search or enter a destination location. That makes sense if the driver is operating it, but it basically makes them utterly useless if you have two people in the car and want to figure out where to stop for food (the single most common use of GPS devices, in my experience). Those should be banned because they encourage non-emergency stops on the side of the highway. :-)

Unless you mean the old e-ink Kindles (pre-KF8), that runs contrary to my experience. All the modern Kindle readers are based on WebKit, and WebKit's SVG support is generally very solid. What problems are you seeing?

Yeah, a rate of 1.1 hyphenated words per thousand isn't excessive at all. I grepped my own fiction writing, and determined that I average about four hyphenated words per thousand in fiction, or almost two per average printed page by your metric. One every 2.25 pages is nothing. :-)

So unless there is something more to the licensing terms than you're suggesting, there shouldn't be any problem with creating your content in an open format, and then using KindleGen to generate the content for the Amazon store.

At issue is the fact that Kindle readers can only side-load content in MOBI format (plus non-reflowable horrors), and MOBI-format files can only (usefully) be produced by KindleGen. So the fact that you can sell the content in open formats through other stores is mostly irrelevant; you can't sell the content in open formats to Kindle users because they can't side-load an EPUB, and you can't sell the content in MOBI format because the license for the tool that trivially translates your source files into MOBI files won't let you resell those MOBI files outside Amazon's stores.

So short of you selling it in an open format and telling your users to run a command-line tool, or telling them to install Java and then install Kindle Previewer (which, among other things, provides a crude GUI for KindleGen), what you're advocating isn't a realistic solution.

With that said, Amazon's licensing changes annoyed me enough that I've seriously considered making the Kindle edition of my books available "free for registered EPUB users", so that users submit a web form and provide a copy of the EPUB book obtained from any EPUB store, and a script on the server verifies it and emails them a free copy of the MOBI book, thus effectively selling the MOBI book through every other online store, while still strictly complying with the terms of Amazon's license by only using it "to format works to be distributed at no charge". But although that would be easy for me to do, that's the sort of thing that 99% of writers out there couldn't pull off.

Well, yeah, in this case. But Amazon doesn't generally make it a point to edit books for people. The assumption is that the Kindle MOBI file isn't the original source content, so if Amazon were to monkey with the MOBI data, their changes would just get stomped on the next time the author fixes anything. For Amazon to fix this in a way that would have any permanence, they'd have to add that script as part of kindlegen, and then it would break millions of other books. Better for them to ask the author to fix his or her source content and rebuild the derived MOBI.