Also, you can't climb hills with rail. Standard rails max out at a single-digit percent grade. If you want to climb more than five or six feet per hundred feet, rail can't do the job. That severely limits where you can run it; in particular, it is not practical to run a rail alongside most roads that go through mountains, much less run one at anything approaching a high speed.
Rail is far more efficient. The track itself is cheap, the major cost is actually buying the land. There is very little friction resistance as well.
That's actually a problem past a certain speed. At least in the U.S., they don't allow trains to travel at high speeds in populated areas because they can't usefully stop if somebody walks across the rail. They can't stop because there is very little friction possible. With a closed tube, you don't have that risk, so you can shoot through downtown L.A. doing 250 MPH.
There's nothing that can be done with this sort of automation that couldn't be done with license plate scanning, so even in the worst case, it's a no-op privacy-wise, not a reduction.
Safety is the main reason for this, followed closely by the convenience of not having to waste your commute time paying attention to the road. The reason we don't build rails is that rails are infeasible in many places. There are remarkably low limits to how fast a rail-based system can climb (slope-wise), limits to their turning radius, limits to how quickly they can accelerate and decelerate, etc. that make them utterly impractical as a real-world alternative to roads. Yes, we could potentially change the definition of "rails" to get around those limits (e.g. tubes with wheels all around), but thus far, every suggestion I've seen along those lines ends up being drastically more expensive than roads.
We do need high-speed rail systems for long-distance travel. That would be far better than using air travel for everything. But replacing roads with rails? IMO, that just won't be feasible for the foreseeable future.
Privacy concerns? You're kidding, right? Look, we're either going to automate the roads or we aren't. If we are, the devices have to be able to communicate, which means that a device is going to be uniquely identifiable for at least the duration of a single period of operation. That's unavoidable. And we need to eventually end the use of manually driven vehicles for safety reasons, so the privacy issues simply have to take a back seat in this case. If you want to protect privacy, make it a crime to intercept this data for any purpose other than what it is intended for, and limit (either through new laws or good judicial common sense) tracking by law enforcement to the same sorts of situations in which they would otherwise install a GPS tracker on your car. Require them to jump through the same hoops.
As for NAFTA, AFAIK, there's no reason that we can't require that vehicles brought into the United States comply with U.S. safety standards. Besides, the rest of the world should be working on similar initiatives anyway.
This is not to say that vehicles shouldn't be able to handle unexpected vehicles that aren't transmitting—there are always failure modes to take into account—but those should be the very rare exception rather than the rule, and the automated cars should handle it by giving that vehicle a wide berth.
In the short run, the real question for me will not be how the cars communicate with each other, but how they handle the cars that do not communicate at all. Nobody wants to swap engine oil at 75MPH with the VW Bus going 55 just because the bus wasn't communicating. Just like how nobody wants to meet the driver of that car that had to stop short to avoid a hazard.
All non-automated vehicles should be required to immediately be retrofitted with beacons that identify their GPS location, speed, and whether any indicators are illuminated (brake lights, turn signals). This enhancement could be added to any vehicle with a minimum amount of effort. This at least simplifies things somewhat.
It should also be mandatory that manufacturers support any device/vehicle for at least twenty years.
No, because it is safe to assume that the manufacturers will lock down the device so that only they can create updates for it, and it is safe to assume that manual driving will become more and more restricted over time. Setting any specific time limit is thus equivalent to planned obsolescence on a nationwide scale.
Manufacturers should be required to update the firmware for as long as a single copy of that car is on the road. This encourages the manufacturers to standardize on a single set of software that applies to all of their vehicles over many, many model years, which has the added benefit of dramatically reducing the likelihood of coding errors. If the manufacturer goes out of business, they should be required to spin off a company that owns the source code and rights to do this maintenance. They should be required to set aside a portion of the purchase price of each vehicle in a special safety fund that is protected in the event of bankruptcy, specifically for the purpose of funding such a company, should it be required.
... it just disables itself allowing for manual control.
No, because some people will just not bother to update their firmware, and will just choose to drive manually. Then we'll be in the same position we're in now, having to maintain lots of unnecessary infrastructure (traffic lights, road signs, etc.) that we could otherwise eliminate entirely.
Except on specifically designated manual roads (e.g. scenic routes, long roads in the middle of the desert, etc.), manual control should be restricted to emergencies only (temporary in the event of a complete system failure, to drive it to the nearest spot on the shoulder that is wide enough to pull over so that a tow truck can tow it to a repair shop). Manual driving should be extremely rare, as it puts a significant strain on the traffic control systems.
Firmware should be OTA self-updating, should be signed by the manufacturer, and should be completely transparent to the user. The vehicle should have two boot partitions, and should always update the least recently updated partition. That way in the event of a failure, you can do some magic sequence involving the odometer button and the ignition key to revert a bad firmware install in the unlikely even that it happens. Also, this ensures that if the install fails for some reason, the car can safely wipe that boot partition, load a full copy (non-update) of the new version, and go on as though nothing had gone wrong.
The device should continue running the current version of the firmware until the next time you shut the vehicle off. Then, it should boot from any newly updated firmware. If the boot fails, it should fall back to the previous firmware, wipe the newly updated firmware, and download a fresh (full install) copy again.
The manufacturer should have the ability to push an "unsafe firmware" notice to the device. If the device sees that flag, it should immediately flag that version of the firmware as potentially dangerous. If it is currently booted from the unsafe version and if it has another version installed that is not flagged, it should immediately find a safe spot to pull over, pull over, reboot from the other version of the firmware, and continue the trip. If it does not have a safe version, it should immediately query the server, download a full, known-safe version, overwrite the version that it is not currently booted from, and then immediately find a safe spot to pull over, etc.
Truck speed limits are usually quite a bit slower than car speed limits, so it's a safe bet that if you're passing a truck and only going slightly faster than the truck, you're going 5–10 MPH under the posted car speed limit.
You miss the point. All your connections are going through a node that has no relationship to the node that actually is going to receive the message. Instead of sending the email to google.com, you send the encrypted email to yahoo.com. It decrypts the outer wrapper and the message says simply, "Send this to microsoft.com". It decrypts the outer wrapper and gets the command "Send this to apple.com". It decrypts the outer wrapper and finds the instruction, "Send this to mail.ru". It decrypts the outer wrapper and sees the command, "Send this to google.com". Google then decrypts the outer wrapper and sees "Send this to user foo". User foo then decrypts the email message.
The above is a very simplified example, of course. In a real scheme, those nodes would be randomly chosen devices on the Internet owned by random users, not major email providers. They would be scattered around the world, and would be different for every request. They would randomly delay the message before delivering it. Because of the random delays, for a node delivering a nontrivial number of messages, it becomes absolutely impossible to say with certainty where a message received from any other node was subsequently sent. Therefore, the only way to definitively say where the message went is to actually take over that node used for delivery, or at least force it to log data against its owners' will.
Because the path of any given message is random, the only way to definitively determine the path of any significant number of messages is to control a substantial percentage of nodes in the graph. Because these are spread across multiple countries, and because the address blocks of any data centers would immediately get block-banned, there's no good way to compromise the network in that way.
So basically, short of managing to slip logging code and/or some severe crypto weakness into the software itself without anyone noticing, there's no way for any single entity (or even any multinational group of entities) to realistically thwart the end-to-end privacy.
Darknets refer to connections made through large numbers of peers, such as Tor's onion routing, such that it is not practical to determine where a message came from or where it is going farther than one hop away, and such that it is infeasible to compromise enough nodes to compromise the entire chain of custody for that message. Darknets exist, with varying levels of actual security. They work best for non-interactive communication like email, where each node can hand off the entire message in a single chunk and randomly add multi-second latency to make it even more infeasible to correlate the timing of compromised nodes.
At least for fiction books, if you use HTML with minimal formatting, you might as well provide a plain text file. That sort of defeats the purpose of using HTML and CSS in the first place, which is to have stylized, reflowing content.
By "growing in popularity", I mean that it is being used for more and more things. By ubiquitous, I mean that it is universally available to use because nearly every operating system in existence has built-in support for it. Those two statements are not contradictory at all.
A pipe is a pipe. It's a sealed metal tube that a liquid goes through. And with only minor impeller changes, a pump is usually a pump.
Besides, even for growing algae you probably wouldn't move seawater, for three reasons:
If you want to grow algae with it, you can always truck the salt in and add it at the end of the line. That said, most forms of algae don't care whether they have salt water or fresh water, so the only reason to do so would be if you were growing one of the few varieties that does care.
From all reports, most or all of the countries where spying occurs, despite their very vocal public outcry against what the U.S. is doing, are in fact sharing information with the U.S. government. And even if they don't, the U.S. can simply grab the data on its way out of the country to that server.
The only way to make email secure is to abandon email in favor of a protocol that supports end-to-end encryption, such as iMessage, XMPP, etc. and to tweak your centralized server and/or clients to require that end-to-end encryption be used. And even then, the metadata (who sent mail to whom) is at risk. The only way to prevent metadata from being trackable is to either develop a new system in which locating a user does not require credentials and use Tor to connect to the centralized server (e.g. use wide-area Bonjour to advertise your current IP address) or design a whole new messaging system built in a darknet.
Either way, email is and has always been just as secure as sending a postcard (which is to say, completely insecure), and cannot readily be improved upon significantly in this regard without starting over from scratch.
Slight correction. You won't be able to continue reading EPUB books for the remainder of your grandchildren's lifetimes; they will. Mea culpa.
Right. At least for the small values of forever in which Kovid Goyal and contributors remain interested in the Calibre project enough to keep it going, after which you have to maintain the code yourself if you want it to keep working.
You don't need Calibre to convert it every time you read it. You do it once. Therefore, even if Calibre stops working in the future, that doesn't prevent you from using the books that you've already converted. Hence, "forever".
And the small values of forever in which ePub is a supported format on the devices available to you when your old ones stop working.
Ignoring a handful of special metadata files in their own quirky XML format, (DRM-free) EPUB is nothing more than a zipped folder full of HTML files and PNG/GIF/JPG images (and, occasionally, SVG). Given that HTML is now 23 years old and is still rapidly growing in popularity, and that ZIP is even slightly older, and that both are absolutely ubiquitous as technologies go, barring a technology-destroying nuclear holocaust or some similar catastrophe setting us all back to the stone age, I think it's safe to say that with minimal effort, you'll be able to continue reading EPUB books for at least the remainder of your lifetime, and probably for the remainder your grandchildren's lifetimes.
The biggest difference between time and space is that you can't reuse time. -- Merrick Furst
