Heads up: this post is from January 2023. Google recently extended the ability to convert controllers to Bluetooth mode by one year. The new deadline is December 31, 2024.
Why even have a deadline? Why not just release the firmware to the public?
What does google gain from stopping people converting stadia controllers to Bluetooth in the future?
I can already see issues like people who bought new old stock who can no longer do anything with them.
The best case scenario is they release a toolkit to flash your own firmware so people can hack on the now completely otherwise useless controllers.
Every thing deployed at Google has all kinds of frameworks and shared libraries and tooling. There are many policies in place to get insure they get newer versions of shared code, such as:
And to maintain these kinds of things, it isn't uncommon for unfunded mandates to be pushed on people that own various tools, such as this one.
Meaning, even to keep a website up at Google, there will be some maintenance burden. Also, I could imagine Chrome pushing some update that would make all of the usb pairing stuff that they do here break at some point, and they will have to do work to keep it working.
I understand there's a forever maintenance thing to forever hosting a website, especially a web application, when its a big behemoth like Google. Lots of compliance reasons and all other organizational policies can make it hard to even just host a file at a URL forever much less an actual interactive application.
I think the real question is why bother doing it with this website? The controller has a USB port on it and I imagine can talk over USB. It would be far better to just have some application which can flash over USB instead of needing some Google-hosted website. Just give me an executable that people can toss on a torrent or whatever. I appreciate they did something to make these controllers useful to people, but it seems like they really didn't pick the best path to achieve that.
I imagine they probably painted themselves into a corner and the firmware update process is so locked down and will only talk to approved Google endpoints over an HTTPS request or something like that and that's the ultimate reason why they went that route. But really I feel that kind of shows a failure to imagine the hardware life after the service.
A website works on all platforms; Mac, Linux, Windows, ChromeOS, ... maybe even Android. An app works on a single platform.
To me, they could put it on github and serve it on github pages. I suspect though that there's a bunch of non-open source libraries being used and getting into a condition that could be open sourced is person power they don't want to spend when they have an infinite list of things to work on.
So sure, release a webpage that you'll only host for a few of years. But then also release a basic executable we can run for the next hundred years after instead of making something that needs Google's blessing and continued effort to exist.
Everything being a website isn't necessarily a good thing.
I think you're missing the point. In this case it being a website is an awesome thing.
The underlying tech is powered by the WebSerial protocol. We basically already have the executable you're asking for. As long as Google supplies the firmware blob (and js source, though this can probably just be ripped from the current web page), anyone will be able to put up a server, and anyone with a modern browser will be able to visit the site and update -- without having to install anything locally.
Given that a 'native' app would probably be some bloated Electron abomination, I was actually pleasantly surprised that Google chose to solve the firmware update problem the way they did; it worked flawlessly for me on Linux which is seldom the case when it comes to these things.
It's hilarious to me you're glad it's not a bloated Electron abomination while also taking about the joys of it requiring a whole web browser to operate.
and you require a whole OS. I expect browsers to outlast OSes. Browsers ran on MacOS 9 and software that ran on those browsers still runs today. MacOS 9 itself, not so much
I've used a lot of old web applications which require some ancient web browser (especially IE) or old version of CGI or PHP to properly be hosted or require some browser plugin that is no longer supported. The idea that it'll continue to work just because it's "web" is once again absolutely hilarious to me. Just wait another five years and all the WebUSB protocols this relies on get reinvented and this gets considered unsafe and deprecated.
And sure, when talking about an OS that's often made a point at cutting off support for old binaries it's not good. You're ignoring the fact I can still run a lot of 30+ year old software on modern Linux and often modern Windows with ease.
Well according to the article the entire firmware flashing process does happen over USB. The website is just a JS executable that uses WebUSB API to perform the flashing process via a browser.
As is also mentioned in the article, the author reverse engineered the site, and create a python script capable to performing the flashing process via standard OS APIs.
Really the flashing site isn’t really “a site”. It’s a hosted executable written in JS that pretty much runs entirely locally, apart from the bit where it downloads the new firmware to be flashed. It should be possible to extract the JS itself, plus firmware blobs, and run that completely offline for as long as browsers support WebUSB. Or you do what the author did and create a Python equivalent.
> Also, I could imagine Chrome pushing some update that would make all of the usb pairing stuff that they do here break at some point, and they will have to do work to keep it working.
That can be solved by developing a flasher in a framework more stable than Javascript and web browsers, like OP did.
Companies been increasingly using the "we can't do X because Y" justification when they themselves are responsible for Y.
The hardware isn't changing. If they aren't going to provide bugfixes and support they can just archive the built artifacts and publish a torrent or public Google Drive folder.
All of the flashing logic is client-side. As a bonus they could archive the whole site. But even if just the firmware blobs were available it would be a huge win as developing another flasher is probably pretty easy with the provided documentation. I suspect that it wouldn't be hard to identify and download most of the firmware that could be used (I don't think there are many controller revisions) but distributing those will be a legal grey area without a proper license from Google which presumably owns the copyright.
Best guess - it’s about support and maintenance. For every tool out there that’s live you’re going to have a degree of overhead to deal with queries and keep it working on the latest OS, browsers etc.
Generally things at Google are built on a stack of private libraries and infrastructure, such that open sourcing something requires a complete rewrite. Unfortunately.
People who suggest this fail to understand that to a google-brained PM it would be a complete and utter career-destroying faux pas to suggest that they should make a non-web app, even for a purpose as trivial as a firmware upgrade.
Doing it via the browser means they get support for Linux out-of-the-box. If this was a long-term thing, they wouldn’t need to care about things like Apple switching architectures for the umpteenth time.
> "Killed by Google" has been claiming it was dead for a long time, but I'm sure will now dishonestly find a way to double-count it.
I haven't gotten around to it yet, but my plan was to merge Google Glass entries. The holy trinity of Google Glass Explorer Edition, Glass OS, and Google Glass Enterprise Edition will become "Google Glass."
This is exactly how Google needed to handle this situation, and they need to be praised for it! The shutdown of Stadia was completely predictable, but I am overwhelmingly surprised at them providing refunds to users for games & hardware and going the extra mile to ensure the hardware is not immediate waste.
As the cryptkeeper over at Killed by Google, I'm very happy with the outcome for Stadia users (myself included). However, I don't think this will move the needle of Google's 'killer' reputation as much as people think given all the skepticism about how long this product would last in the first place. The "death pool," and the people who voted basically predicted the timeline within a few days[1].
The irony is, if Google had made their plan for how to handle end-of-life for Stadia clear from the beginning, they might have got a lot more users.
I'm not sure if their strategy ever changed along the way, but when Stadia was first announced, it was a purely cloud gaming platform where you still needed to buy a license for every game. Not knowing what would happen to my purchased games was the main thing keeping me from trying Stadia - I'd have been happy to use it if it was a Netflix / Xbox Game Pass style service where you pay a flat monthly rate for access to a library, or if it was clear that any games you bought would be refunded if the service suddenly shut down.
As it was though, it seemed as though you could drop a ton of money on Stadia games, and Google might pull the plug the very next day, and you lose everything you just purchased. That worry was the deciding factor for me to never give Stadia a go.
Stadia required custom development work from game developers, my guess is that getting them on board was at least as challenging as getting consumers. It's a risk to tell developers "we're already thinking of how to kill this platform that you're investing in".
It's problematic for a company if they have to announce their EOL plans on product announcement to get interest from customers. Might as well not exist as a company at that point
It's problematic for a company to have EOL plans not because people will assume they will go out of business, but because they might not be able to actually adhere to those EOL plans resulting in a much larger mess than what would have happened if they stayed silent.
It's bad, but I'm not sure it's that bad. In B2B land, loads of contracts have a code-in-escrow clause just in case key people die or the company goes under. One of the key attractions of Open Source is that if the people building it die or don't want to support the tool anymore, you can keep going yourself.
call me cynical but I strongly suspect that rather than behaving honourably, or even thinking of future customer behaviour, Google are trying to evade a class-action lawsuit
the reason that this time they’ve seemingly turned a new leaf is that this time hardware is involved. once something is in someone’s hands and they actually own it, rather than a legally slippery software license or user agreement, you’re looking at something that can be very easily explained to a judge or jury
Strong disagree. For many weeks users have been thinking their controllers are garbage. They might still be. Let's see how well it works. Even if there's compensation I don't like to see stuff that's defective by design. https://www.defectivebydesign.org/
No no no. You see? If you want to be a Birdwatch contributor, you'll have to pay them. /s
It's actually pretty okay. The contributor & rating system seems to work well, and contributions are anonymous. I participate mostly through rating contributions a little here and there when I see some things that are wildly unfounded or misleading claims.
My parent worked at a water treatment plant in a small town. They could have easily screwed around with the chemical compositions without anyone knowing. Nearly anyone could have brute forced the control room: a single key/lock would need to be bypassed. There was no access control or logging to the room itself, and everyone who worked there had a master key to all buildings and facilities. Lab tests were done on site and were recorded manually, so they could easily just lie about the results.
Uh, no. Sign languages, like American Sign Language, are not "simplistic" versions of spoken languages. They are complete, complex languages with their own robust syntax and grammatical structures. A better way to explain this is that it's like an adult who is natively fluent in one language trying to read subtitles in a second language with which they don't have working fluency and rarely, if ever, speak.
To expand on this, it's commonly believed that sign languages are simplified versions of the local spoken language. Indeed, it wasn't until ~1960[0] that these languages were seriously studied as "real" languages.
At least part of the reason a Deaf person might have poor grammar in a spoken language is because said spoken language is almost always at least their second language.
Sign language is more like watching a movie than listening to radio. It's extremely spatial, with space around the body used to indicate grammatical elements and their relation to each other.
Spoken languages are far more similar to each other than to sign languages.
Subtitles are like watching a movie with the green screen instead of the scenery filled in.
