Not a false dilemma, a false assumption. How do you demonstrate the proposition that a car without manual override controls (beyond just a big red stop button) is both individually and systemically safer than one without?

And what driver is going to wait and see if the car is capable of avoiding an accident if they are going to be the ones liable for that accident and told they must take control of the vehicle if they think the car is about to collide with something? Basically you are talking about taking a sophisticated collision avoidance system and short circuiting that by telling the driver they must take control of the vehicle if they think there is a problem. That could demonstrate that autonomous cars are less safe because people will be turning off the collision avoidance system at exactly the wrong times, but yet they will be reacting more slowly than people without autonomous cars because manual drivers are already actively driving.

What California is doing is starting from the assumption that not having a manual override is less safe, which I believe is a false assumption and actually undermines safety efforts. And it could also undermine efforts to roll out these cars.

I am all for the option of manual controls and would probably choose to have manual controls for a car that I owned, but I think that the more compelling case and safer option will be to remove the manual controls and I think the only way you prove that is by allowing the cars to demonstrate the capability.

Many of the most potentially beneficial things that could happen as a result of autonomous cars are those use cases where a driver isn't always at the wheel ready to take immediate control of the vehicle. Car sharing, taxi services, elimination of drunk driving, transportation for the disabled, highway driving at closer spacing which might make a human operator uncomfortable and prone to take control, congested city driving where vehicles could be routed and dispatched more efficiently or just told to "go park and come pick me up in twenty minutes" are all use cases where you don't want to require that someone is 'at the wheel' at all times.

With the real potential for saving lives and helping improve quality of life robot cars should be allowed to prove themselves with and without old school manual controls and all the legal requirements, increased costs and liability that retaining those controls imply.

Windows $[4+4]

First you have to allow the new technology. Requiring a licensed driver be at the wheel ready to take control of the vehicle at all times is not allowing the new technology it is hobbling it and potentially undermining the most compelling use cases that will save and improve lives. Simply require that the manufacturer demonstrate the ability of the car to drive like any taxi driver would be required to demonstrate an ability to drive to receive a license.

I think California is playing it wrong and unsafe. I agree there needs to be a big red button on cars which brings the vehicle to a safe stop much like there is on passenger trains, but this move by California seems more like something pushed for by entrenched vested interests and not driven by safety considerations. Lives will be saved when we allow cars to go pick up people that can't drive, don't have licenses or don't want to drive themselves. The implication of this move is that a human driver is going to be responsible for the operation of the vehicle at all times. Rather it should be the manufacturer of the vehicle which is liable for any defects of the autonomous system when it is driving autonomously. And it should be an option moving forward, even a safety feature, to allow cars without manual driving options except for the big red button.

Compared with the track record for human drivers which is proven to be completely unsafe?

Too late. Net Neutrality is a response to the reality of local monopolies. It is a direct result of the fact that many places have local monopolies or non-competitive (probably colluding) duopolies. If we had healthy competitive markets with five or six providers available to each household, then it would not be necessary to have net neutrality because who would buy service from a provider which had poor connections to the people and services you wanted to communicate with? All we would need would be transparency and truth in advertising... which we don't have either since companies are secretive about the business decisions they are making in order to throttle some communications.

To me the bare minimum short of Net Neutrality would be requirements, like those imposed on Tobacco advertising, that Verizon FiOS and Comcast really suck for sites they choose to black ball. Something like making them display their connection speeds to other networks and which content is on those other networks on every single advertisement. Then people could really know what they were getting. Because right now I pay for something like 25M/25M and sometimes I get that and sometimes I don't. It depends on the site. So what I really want to know as a customer is what are the differences between Verizon FiOS and Comcast in their actual delivery times, not just what they say they are selling me.

If I can't rely on these companies to do their best not to screw me over depending on with whom I want to communicate, then I want to know exactly how they are screwing me over and not delivering on their promised speeds.

A big citation needed there. The last time I looked at the data was in 1998, but back then English tax payers were paying an average of around £100 each for the upkeep of Scotland, if you didn't include the north sea gas revenues.

The problem is that X was designed for network transparency in a usage model that no longer exists. X is great for network transparency when the server is doing all of the drawing. Unfortunately, the server can't do simple things like antialised line drawing, so people render on the client and then push (uncompressed) pixmaps to the server. A few issues with X11:

Some trivial things, like the fact that command IDs are 8 bits and over half of them are taken up by 'core protocol' things that no one uses anymore. this means that every extension (i.e. the stuff people actually do use) ends up providing a single 'do stuff' command and then a load of subcommands. This limits the number of extensions that you can have loaded and, because the assignment of extensions to command numbers is dynamic, makes intelligent proxies just that little bit harder to write.

There's no easy way for an application to get all of its server-side state. This means that you can't, for example, have the X server crash (or even restart cleanly after an upgrade) and have all clients reconnect and recreate their windows. The Windows and BeOS display servers, for example, have this feature. You also can't tell an application to disconnect from one server and move its windows to another easily. This ought to be basic functionality for a client-server windowing system. There are proxies that try to do this, but they break in the presence of certain (commonly used) extensions.

There is no security model. Any app can get the entire input stream. Keyloggers for X are trivial to write as are programs that inject keystrokes into other applications. Neither requires any special privilege, nor do applications that subvert the display hierarchy (e.g. window managers).

The XRender extension is basically useless. It lets you do server-side compositing, which ought to make things fast. OS X gets a lot of speedup from doing this for text rendering: programs (well, system libraries that programs use) render glyphs in a font to server-side buffers and then the server composites them in the correct place. This doesn't work well with X, because most toolkits aren't set up to do text drawing on the server but everything else on the client (which is needed because the server doesn't provide a rich set of drawing primitives). Fixing this would mean adding something like the full set of PostScript or PDF drawing commands to the server.

XLib is an abomination. It starts with an asynchronous protocol designed for latency hiding and then wraps it up in a synchronous interface. It's basically impossible to use XLib to write an application that performs well over high-latency (more than a few tens of ms) link. XCB is somewhat better, but it's fighting toolkits that were designed around the XLib model so ends up being used synchronously.

None of the network-transparent audio extensions caught on, so your remote apps can't even make notification beeps (worse - they can, but on the remote machine).

If you designed a modern protocol for a network-transparent windowing system, you'd end up with something a lot like a web browser. You'd want PostScript drawing contexts (canvas tags, in HTML5 parlance), server-side caching of images and sound samples (image and audio tags, in HTML5 parlance), and OpenGL contexts. The library would keep a list of all of the contexts that it held on behalf of the program and would be able to recreate them on demand and request that the program reinitialise them. You'd be able to run small snippets of interpreted code on the server (so that things like pressing buttons or opening menus didn't require a full network round-trip - something that DPS and NeWS got right in the '80s, but X11 got wrong). You'd ensure that input events only went to the current view or its immediate parent (if explicitly delegated), or to a program that the user had designated as privileged.

It's possible to do a lot better than X11. Unfortunately, most projects that try seem to focus on irrelevant issues and not the real ones.

There's nothing intrinsically good about the UNIX mindset. For example, UNIX originally put globing in the shell as a work around for not having shared libraries and claimed it was a feature (which led to all sorts of problems - for example */*/* can overflow the command-line argument length limit, whereas a system that had put globing in a shared library would have lazily expanded it in the called program). The problem with the systemd developers is not that they lack the UNIX mindset, it's that they produce utter crap and somehow are able to market it successfully.

That particular use is quite uncommon, but it's increasingly common to stick a recovery root partition in flash (or even in a kernel-embedded RAM disk on a recovery USB drive or similar) so that if you screw up some core configuration you can boot the core system and recover everything else. Keeping it small and self-contained has several advantages. If it's being loaded to RAM on recovery boot, you don't want it to be large and you do want to be able to write the recovery images quickly. If it's in flash (or even a separate FS on the main storage pool) then you don't want it to be too big.

It matters less for big users, who will fix a machine by simply reimaging it and have redundant everything, but if's very useful for a small company that only has a few servers. It's also useful if you're building an appliance and want to be able to have two root partitions that you switch between for atomic updates (boot one, update the other, reboot on the other, always have one bootable root).

The only thing ARM ships that might speed up Dalvik is Thumb-2EE (a.k.a. Jazelle RCT), which neither Dalvik nor ART actually use. No idea what your /proc/cpuinfo is talking about.

On the Western Values issue. I don't think the problem is that we are imposing our values on others. I think the problem is that we aren't even adequately promoting those values here at home. We end up calling for Democracy and Freedom in the rest of the world and then sending arms to whichever dictator and despot is the most willing to brutally suppress any groups that might threaten our foreign policy. Even when those groups are moderate groups simply looking for a more equitable system of government in their own country. And our foreign policy is based not on the spread of freedom and democracy around the world, but based on securing foreign trade and foreign resources for very short term and short sighted economic purposes. If we truly believe that more representative systems of government and more freedom and liberty should be the goal for a more prosperous, equitable and free world, then we should act accordingly. I believe the ideas of liberty and democracy are ideas worth spreading and supporting.

Actually, C is used in these cases specifically because it is cross-platform, not for 'platform-specific optimisations'. The core of most of the popular apps on iOS and Android is the same, with a thin layer of platform-specific code, which is Java on Android or Objective-C on iOS. For games, the amount of Java code is typically tiny - create an OpenGL context and pass it to the native code, which is identical on both mobile platforms. This is a big part of the reason why there are so few apps for Windows Phone compared to the other platforms: by forcing WP apps to be entirely managed code, they make it hard to port apps.

Yes you can and most of the most-downloaded apps in Google Play use a significant amount of C (often everything except a basic launcher).