This particular blog post and plan is regarding removing support of old TLS versions and options on the client. Which means that all server administrators need to do is enable TLS 1.2 and modern options.
Old clients (such as Android) will still be fine, if the servers don't also turn off older versions/options.
The problem with this fix is that then as long as you have the fallback, the user gains none of the security properties of TLS 1.3 (since the attacker can always force a downgrade by sending junk to the client during the handshake) and has the additional cost of a second TLS negotiation.
While there was previously this "TLS fallback" implemented in Chrome to work around buggy endpoints, this was primarily due to buggy endpoints* which was a much larger issue and difficult to fix, while these middlebox issues affect a much smaller portion of users and we're hopeful that the middlebox vendors that have issues can fix their software in a more timely manner.
* TLS 1.3 moves the version negotiation into an extension, which means that old buggy servers will only ever know about TLS 1.2 and below for negotiation purposes and won't break in a new matter with TLS 1.3.
While there was a secondary issue with the deployment regarding unofficial builds/derivatives, the field trial was primarily rolled back due to the number of affected customers due to the middle-box issues in their enterprise/edu networks.
This at least means that the developer is aware that these parts of the spec are extensible, and by explicitly ignoring the GREASE values are explicitly choosing to potentially have a broken application in the future. This is a different class of problems than developers who weren't aware certain fields were extensible.
Since computation is measured by bytecode cost of instructions, supporting other languages would require a great deal of effort to do similar bytecode counting and to make sure that the counting across languages is fair and balanced. They've considered doing other forms of computation measurement, but none of the alternatives are very good or deterministic (time, lower-level instruction counting, etc).
In the past we've had it where where each bot is allowed a certain amount of "computation", with different upgrades giving you more "computation" each turn.
Machine-independent isn't really the write word, more of that we want the same two bots fighting on the same maps to be deterministic regardless of the machine its being run on.
For mechanics like this, we've found that bytecode instruction counts are the best metric we currently have, since anything that is time-based could result in different results depending how the CPU schedules the bots, and doing something like using PIN or another system to count assembly instructions turns it into a competition of who can write the most optimized assembly code.
While we do allow bytecode tricks, we want the focus of the competition to be on developing high level macro and bot level micro strategy, instead of spending all the time working on optimizing at the bytecode level. Especially since the main competition period is less than a month, we don't want to encourage time being spent on that.
A majority of them, however since we take source and compile it on the tournament servers, we'd need to get the compile chain and server working with those languages.
We don't explicitly require teams to open source their bot after the tournament, since sometimes teams have special restrictions on publishing their code. But some of the top teams have published their code or framework online in the past.
We're not happy about the restriction either, and hopefully we'll run a Battlecode that doesn't have a programming language restriction, but we haven't found a way to deal with limited instruction count execution that we are happy with that is machine independent, and counting Java bytecode has worked for us so far.
If there are other JVM languages people want supported, we'd be happy to take pull requests on Github once we make the new gameplay public tomorrow.
You can also compete for the top of the scrimmage rankings, and we are considering adding an Open tournament again to allow all teams compete for fame and glory.
Where does it talk only about Google+ Sign-in as the migration from OpenID 2.0?
On the same page, they list how to migrate to OAuth 2.0/OpenID Connect, and even say "If your OpenID 2.0–based app does not need social features or is on a platform not supported by Google+ Sign-In, or if you want to work directly with the OAuth 2.0 REST APIs, then we recommend migrating to Google's OAuth 2.0 login (OpenID Connect) solution, as described below."
There's actually another course (6.824, http://css.csail.mit.edu/6.824/2014/) that runs in the Spring that focuses on distributed systems, and also has had a number of interesting final projects. While we haven't released project writeups in the past, its possible we'll do something similar to 6.858 and put them up online at the end of the class for 2015.
Old clients (such as Android) will still be fine, if the servers don't also turn off older versions/options.