Unless you're complaining that gasoline stations are a commercial infrastructure, in which case I interpreted that bit to mean electrical infrastructure.
They can be a great option for folks who only occasionally travel long distances, because 98% of the time, you're not dragging the extra weight of an ICE around, and you're (ostensibly) using clean energy to power your car, and you only use gasoline when you're traveling too far for electric cars to otherwise be practical. For people who drive long distances regularly, obviously a hybrid or even a traditional automobile would be a better choice (less pollution, better emissions controls, and better fuel economy in all likelihood).
....as long as you have no intention of going car_range/2 further from your house... Otherwise you're still looking at a commercial infrastructure.
Or a generator pod on a small trailer.
But they can only do that if I've had my phone on since 2003.
What? It will happen automatically when I turn it back on? *sigh*
All drivers on OS X are already required to tell the operating system ahead of time that a device is about to DMA to memory. That's how that VT-d is able to configure the IOMMU hardware to allow those devices to access RAM without worrying about 64-bit address spaces. So the OS already knows precisely which pages of physical RAM should be accessible by PCIe devices using DMA. If other pages of RAM are accessible, that's a bug.
Similarly, making the Thunderbolt controller's IOMMU mappings be driven by that part of the kernel should not break any drivers at all, by definition, because PCIe devices shouldn't be issuing DMA requests except at driver-preapproved locations. So AFAIK, the only way such a fix could break any device would be if that device was trying to do something really dangerous, like reprogramming one of the PCI bus bridges, or reflashing the computer's EFI firmware....
I mean, I suppose that some drivers might be inadvertently configuring a mapping for a page of memory that also contains executable code or class instances (with function pointers), in which case fully fixing this would also require Apple to modify the IOMemoryDescriptor class to ensure that the DMA-enabled pages are whole pages owned by the descriptor, but that should still be pretty minor, and should result in only a modest amount of wired kernel memory bloat.
In the worst case, such a change might require a CPU-driven copy-on-prepare and/or copy-on-complete to work around drivers that provide their own virtual addresses for a memory descriptor that aren't page-aligned, which would cause a big performance hit for those few drivers, but I'd expect most driver developers to quickly fix those design mistakes to eliminate the performance hit. (And that's assuming this isn't done already—for some reason, I thought those buffers had to be page aligned or you'd get a panic, but I'm not seeing anything about it in the docs, so I might be remembering wrong.)
Heesa left een Jar Jar?
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?