What, they're going to ship a VR headset without positional tracking? When you turn your head, nothing happens? That's not VR. That's a TV you wear on your head.

That's neat. The demo takes in the video from a video game of the Pong/Donkey Kong era, can operate the controls, and in addition has the score info. It then learns to play the game. How to do that?

It's been done before, but not this generally. "Pengi", circa 1990, played Pengo using only visual input from the screen. It had hand-written heuristics, but only needed vision input from the game. So we have a starting point.

The first problem is feature extraction from vision. What do you want to take from the image of the game that you can feed into an optimizer? Motion and change, mostly. Something like an MPEG encoder, which breaks an image into moving blocks and tracks their motion, would be needed. I doubt they're doing that with a neural net.

Now you have a large number of time-varying scalar values, which is what's needed to feed a neural net. The first thing to learn is how the controls affect the state of the game. Then, how the state of the game affects the score.

I wonder how fast this thing learns, and how many tries it needs.

FastCGI implementations are supposed to execute the specified executable without any parameters from the HTTP request. The FCGI program then reads and processes multiple HTTP requests, with no shell involvement. Unless the program invoked by FCGI itself invokes the shell (which PHP scripts can do), there should be no problem. I'm not a PHP user; someone with PHP internals expertise needs to look at that world for vunerabilities. Can arguments from the HTTP request make it into the environment of subshells invoked by PHP?

If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.

Put a "#" in front of
LoadModule cgi_module modules/mod_cgi.so
in /etc/httpd/conf/httpd.conf. This will totally disable all CGI scripts. That's a good thing. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.

Note that this will break CPanel, but not non-CGI admin tools such as Webmin.

People are out there probing. This is from an Apache server log today from a dedicated server I run.

89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

It all comes down to movie psychology: A 'dashboard' is basically just a boring web based equivalent to the rows of screens and blinking lights and things that the jumpsuited minions hunch over, monitoring feverishly. A 'report' is the thing (piece of paper, datapad, etc. depending on era) that an obsequious yoeman hands to The Leader while he stands in a super-decisive Master and Commander pose in a suitably dramatic part of the set. The Leader then glances at the report and, thanks to the powers of decisive leadership, immediately gleans the relevant information and issues an order to rally his underlings.

'Dashboard' (while more useful) is basically a giant blinking signal that you are a peon, a cog in the machine. 'Report' is the executive summary with all the tedious detail drained out so that you can focus on being a big picture thinker and indispensable idea guy. It's like the difference between the giant bundle of keys that the janitor has (which can get you anywhere in the building; but show you to be a blue collar lackey) and the single RFID card that opens the suites on the top floor.

The real hell is going to be administration:

The big perk of single-sign-on (aside from keeping users from spewing crap passwords) is how nicely it centralizes the credential management. Create a new account? Do it in one place. Lock an account? One place. Change a password, one place. The fact that the user sees very few login screens aside from the initial one is a nice bonus; but not really the major perk for IT.

The assorted password managers in common use are Not aimed at 'faking' single-sign-on. They are aimed at helping a single user remember the credentials they create. If you scrounge, you can probably find an installer that can be automated and deployed; but actually provisioning the stored keys automatically? Automatically updating/reseting/etc. passwords across a zillion 3rd party services? You. Are. Screwed. Best case, roaming profiles, network home directories, or a little folder redirection will ensure that the user gets the same password store on any computer they log in to; but it will still be up to them not to make a total mess of it(and they will).

There is no hope. Honestly, your best bet is probably kidnapping family members of your vendors and threatening to release them in bits sized to fit a matchbox until your vendor gets off their ass and gets AD/OpenDirectory integration working.

So it's telling us just what we already knew? Interesting.

For three or more decades. (Before that some of the classes of things they're comparing didn't exist, with enough deployment, to characterize.)

On the other hand, it's nice to have it confirmed with some rigor and measures.

Oops. Typoed $/watt to $/kW in part of the above and accidentally hit submit rather than preview. My bad.

A dollar capital cost per kW of generation (with a couple decades lifetime minimum) is the ballpark for the breakeven point between grid power and solar generation on mid-US-latitude sunny sites (5ish solar hours/day), with grid power available.

Being remote (so running grid is pricey) or having a small load (so basic connection fees aren't justified) shifts the point to higher dollars/watt, as does an increase in utility rates. Shade, dark weater, and high lattitude shifts it downward. (Forget about solar in Seattle, for instance.)

Solar panels are just starting to drop below $1/W, making them practical in far more places, and making the load size and associated system costs (mounting, inverters, storage) more of a factor.

Over $/W? It needs some exceptional situation to compete with cheap flat panels.

The problem with programming language evaluations is that they tend to be based on small snippets of code, like this one, or data from novice student programmers, or worse, popularity. Yet what really tends to matter is how much trouble a language causes in large systems and in later years. That's where high costs are incurred because changes in module A affect something way over in module Z. Undetected cross-module bugs, high costs of changing something because too much has to be recompiled, that sort of thing. How much help the language gives you then matters.

A really good programming language study should digest data from change logs on some major open source projects.

Honestly, that makes the whole thing seem even weirder and sleazier:

If the restrictions are actually so tepid that fungibility allows a simple reorganization of a few internal payments and no actual changes, then why would anybody bother to have them? Is somebody involved in the process actually that dumb or that petty?

If the restrictions are there for reasons that aren't dumb or petty and spiteful, then one has to be nervous about how they are working, what other mechanisms might be in place to help achieve the same goal, and so on. Given that they are embarrassing, they would not be in either Google or Stanford's interest if they had no other effects besides potential embarrassment. Unless there's a loose idiot involved, somebody thought that they were worth the risk of writing down, possibly for good reasons...

I last tried a Debian install around the time of Dayton Hamvention, so a few months ago. I don't have a bug #, I tried to debug GDM for a while but didn't have enough time. I can try another install sometime soon.

Well, a Core i5 tablet with two parallel screen digitizers is an odd enough bird that you can't expect it to run on the somewhat aged Debian stable. And indeed the older GNOME there handles the touchscreen incorrectly.

Because it has a touchscreen and a separate pen digitizer on the same screen. And now with the keyboard, it also has a Cirque touchpad, for a total of three digitizers.

The Toughpad has a touchscreen and a pen (with a separate digitizer!) and the touchscreen doesn't work properly in the older GNOME in stable.