Live data from Hacker News

Samsung Q990D unresponsive after 1020 firmware update

us.community.samsung.com

101–110 of 580 posts

Re: Samsung Q990D unresponsive after 1020 firmware update

#101
post #12

It bothers me that many devices are so easily remotely bricked and that keeping them offline is the only way to avoid such issues. Automated updates were supposed to give us peace of mind instead of having us worried about what bug or enshittification will follow. I’d wager that, for most Internet-connected appliances, keeping them offline or disabling autoupdates have way more pros than cons.

Automated updates are a way for companies to push updates on you without having to first convince you that the updates are good.

Also allows them to ship unfinished/buggy and poorly tested software and "fix it later OTA."

Re: Samsung Q990D unresponsive after 1020 firmware update

#102

Two important features I insist on for products I develop: 1. Staged rollout of firmware updates. It’s common practice for apps and software but for some reason it’s less common with firmware. Rolling out to 1% (or less, depending on scale) of devices and waiting a day is cheap insurance. Side note: Build a good relationship with customer service people so you hear about these things immediately. 2. A failsafe firmwa…

Indeed a golden factory firmware version that will be booted automatically if all else fails and that provides minimum connectivity is crucial.

> will be booted automatically if all else fails

I prefer to keep the factory firmware reset to a manual process that requires user intervention.

For example, holding down the reset button for 10 seconds after plugging the device in.

In my experience, it's not a good idea to have a device automatically roll back firmware and erase user data after failed boots. These mechanisms get triggered too easily during certain power outages (power comes on then goes off just long enough to cause multiple failed boots) or when users are doing simple things like rearranging their power cables.

Re: Samsung Q990D unresponsive after 1020 firmware update

#103
post #33

Earlier quoted context omitted.

Few things over the past few years have infuriated me as much as tracking and advertising being introduced at the OS level, especially on TVs. I'm looking at you, LG! I will gladly pay more for a TV that doesn't try to advertise Roku's streaming service to me or track my kids' watch history. Seems like they are few and far between, though. The best thing we have been able to come up with is leaving the TV itself disc…

> I will gladly pay more for a TV that doesn't try to advertise Roku's streaming service to me or track my kids' watch history. Seems like they are few and far between, though. Plug in an Apple TV?

Apple TV is just as bad (and in the context of the OP's statement, would be the same as a Roku box or an Amazon Firetv).

Re: Samsung Q990D unresponsive after 1020 firmware update

#104
post #12

It bothers me that many devices are so easily remotely bricked and that keeping them offline is the only way to avoid such issues. Automated updates were supposed to give us peace of mind instead of having us worried about what bug or enshittification will follow. I’d wager that, for most Internet-connected appliances, keeping them offline or disabling autoupdates have way more pros than cons.

Damaging or removing features should reopen the return window. Then they will be more careful about what they change.

Re: Samsung Q990D unresponsive after 1020 firmware update

#105

Two important features I insist on for products I develop: 1. Staged rollout of firmware updates. It’s common practice for apps and software but for some reason it’s less common with firmware. Rolling out to 1% (or less, depending on scale) of devices and waiting a day is cheap insurance. Side note: Build a good relationship with customer service people so you hear about these things immediately. 2. A failsafe firmwa…

Most companies don't do this because it's not one of their organizational priorities to have reliable updates. The infrastructure is usually custom built and maintained by a couple of folks who have a dozen other responsibilities they're told are more important. Testing is usually limited by hardware availability and release velocity. "One of every board revision we've ever produced" simply isn't available and waiting two days to run through every firmware version before you release updates is a conversational non-starter with the PMs.

There are commercial offerings (like mender.io, never used) that basically specialize in providing rock solid update infrastructure, but that again takes investment and organizational priority that doesn't exist for non-feature code.

Re: Samsung Q990D unresponsive after 1020 firmware update

#106

Two important features I insist on for products I develop: 1. Staged rollout of firmware updates. It’s common practice for apps and software but for some reason it’s less common with firmware. Rolling out to 1% (or less, depending on scale) of devices and waiting a day is cheap insurance. Side note: Build a good relationship with customer service people so you hear about these things immediately. 2. A failsafe firmwa…

Reverting to factory state seems riskier than last known good state. You could run into things like TLS root authorities not being recognised, deprecated cipher suites, etc. Just because that version worked a decade ago, it doesn’t mean it’s compatible with the world today.

Re: Samsung Q990D unresponsive after 1020 firmware update

#107

HN title is editorialized. I assume "bricked" is a lot worse, i.e., permanent. Comments show that there might be resolutions and potential for firmware patch. [0] Bad updates happen. [0] https://us.community.samsung.com/t5/Home-Theater/Samsung-Q99...

Bad updates happen, but companies with good development practices don't ship catastrophically bad updates. Source: I worked at Samsung

Re: Samsung Q990D unresponsive after 1020 firmware update

#108

Two important features I insist on for products I develop: 1. Staged rollout of firmware updates. It’s common practice for apps and software but for some reason it’s less common with firmware. Rolling out to 1% (or less, depending on scale) of devices and waiting a day is cheap insurance. Side note: Build a good relationship with customer service people so you hear about these things immediately. 2. A failsafe firmwa…

I get the sense that #2 is viewed as a risk for DRM, given all the work that goes into preventing firmware downgrades to potentially insecure firmware. Specifically thinking of the Nintendo Switch[1] that goes so far as to blow fuses on each firmware upgrade!

https://news.ycombinator.com/item?id=23534793

Re: Samsung Q990D unresponsive after 1020 firmware update

#109

Two important features I insist on for products I develop: 1. Staged rollout of firmware updates. It’s common practice for apps and software but for some reason it’s less common with firmware. Rolling out to 1% (or less, depending on scale) of devices and waiting a day is cheap insurance. Side note: Build a good relationship with customer service people so you hear about these things immediately. 2. A failsafe firmwa…

This is the de facto playbook for one of the Mega-Evil Corp.'s CPE firmware (Gateways, IPTV receivers, etc...).

New firmware is pushed in phases 1%, 5%, 10%, 25%, 50% then full scale.

Each stage has some delay incorporated for acquisition/application and then for telemetry (including support contacts from affected accounts) to determine impact and allow for regression fixes.

The other reason they would phase launches is because of firmware builds being used across multiple CPE models and hardware revisions, where only a small subset of hardware could wind up being problematic, but not discovered until deployment.

When you have millions of devices deployed, even a fraction of devices having an issue can create a shit storm on the support side of things.

It all seems so obvious once you know to think about it.

Re: Samsung Q990D unresponsive after 1020 firmware update

#110
post #72

Earlier quoted context omitted.

Great points! As an addendum to this, if #2 becomes untenable for whatever reason (such as a vulnerability in the factory firmware image), then this #3 would be good to strive for as well: 3. have a set of conditions to mark the running firmware image as "safe" and have it become the new fallback firmware image for this scenario. That way you can have a recently up-to-date firmware version constantly trailing the new…

IMO this is a terrible idea for many reasons but the most important of which is: As a consumer I should have the right to have my device revert any b.s. update and get my setup to how it was the day I bought it. So many companies have begun rolling out updates that makes the device I purchased call home before allowing any user functions and if/when that server goes down my device becomes a brick. This behavior essen…

FWIW, my background is in B2B hardware and that's the perspective I am coming here with. Out of curiosity though, how do you weigh your value of control vs. security vulnerabilities? Modern speaker systems allow some form of wireless connectivity, so there is bound to be something and not all consumers will be savvy enough to keep up with security updates on their own.
Post reply on HN