thomaspurchas

Same in Copenhagen[0], but they do appear to have LIDAR units monitoring the track edge at stations without doors.

[0] https://youtu.be/R8QvM000uyE?t=151

I don't think they actually get to drive the train then, just get the press the close door button on the panel. The train still drives to the next station without any human input.

Most automatic trains can't be driven by humans under normal circumstances because signaling information is fed to the train far faster than any human could react to it.

Strange because the DLR is almost completely automated (no driver, but ticket inspector closes the doors) and has no platform edge doors. But they do have emergency stop buttons on the platforms.

The irony of you starting your rebuttal with an ad hominem attack is pretty amusing.

Expecially in reponse to an article that talks at length about others in nutritional science using ad hominem attacks as a primary form of defence against dissident arguments.

I always take issue with the idea that people should just make themselves more "valuable" to get a job.

While it sounds like a good idea in principle, it ignores the fact that without a job many people simply won't have the resources to make themselves more valuable.

It creates a catch 22 situation, and the people it effects the most also happen to be the people who will struggle the most to break out of that situation.

You seem to make the assumption that corrupting the secure enclave firmware is easy, or that its RAM is exposed of chip.

The entire point of an secure enclave is to completely enclose all the hardware and software needed to generate encryption keys in a single lump of silicon.

This means that all of its processing requirements (it's a complete co-processor) are on chip, it's RAM is on chip (not shared with it the main CPU, and probably has ECC), and it uses secure boot to cryptographically verify that it's firmware has not been tampered with before it starts executing. Additionally it may even be possible to update it bootloader in the future to prevent further updates without a passcode.

The end result means that attacking a secure element is very difficult. There are few, if any, exposure points that would allow you to fiddle with its internal state, and any attempts too should result in the secure element wiping stored keys, making further attacks a moot point.

The memcache was purely the result of polling the server every second to keep different JS clients in sync. Admittedly it's not very elegant, but it was something I did just to see how easy it is (backbone makes this really really easy).

Unfortunately you pay for every datastore query, and when 50 odd people have the order page up, each polling every second, thing get a little silly. Additionally with appengine memcache is just one import away.

A stupendous amount. Before starting this project I had never done any complex frontend stuff. Pretty much just HTML CSS and a bit of jQuery.

With this one project I learned about backbone, marionette and the limits of what can be done on the frontend. It was quite a big learning curve, and even now I'm still discovering where the correct balance of frontend-back end stuff is.

Overall a great experience, really opened my eyes to the power of JavaScript, before I had adamantly stuck to nothing more exciting than HTML forms with JS validation.

About two months off and on.