Hacker News Reader

Comment by kyrra | Hacker News Reader

Googler, opinions are my own.

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:

https://opensource.google/documentation/reference/thirdparty...

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.

View on HN

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.

Yup even Android, Chrome on Android supports WebUSB so I usually use it to flash different firmware to my Nintendo Switch on the go.

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.

Reply on news.ycombinator.com