SSDs can only tolerate a certain number of writes to each block. And the number is low. I have a 64gb SSD that went into a permanent read-only mode. 64gb is still today a very useful capacity. Thus the usefulness is cut short by hardware design deficiencies.

Contrast that with magnetic hard drives which often live beyond the usefulness of their capacity. That is, people toss out working 80mb mechanical drives now because they’re too small to justify the physical space they occupy, not because of premature failure ending the device’s useful life.

Nannying

When an SSD crosses a line whereby the manufacturer considers it unreliable, it goes into a read-only mode which (I believe) is passworded with a key that is not disclosed to consumers. The read-only mode is reasonable as it protects users from data loss. But the problem is the nannying that denies “owners”¹ ultimate control over their own property.

When I try to dd if=/dev/zero of=/dev/mydrive, dd is lied to and will write zeros all day and report success, but dd’s instructions are merely ignored and have no effect.

The best fix in that scenario would generally be to tell the drive to erase itself using a special ATA command, like this:

$ hdparm --security-erase $'\0' /dev/sdb
      security_password: ""

      /dev/sdb:
       Issuing SECURITY_ERASE command, password="", user=user
      SG_IO: bad/missing sense data, sb[]:  70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      SG_IO: bad/missing sense data, sb[]:  70 00 0b 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Not sure why my null char got converted to a yen symbol, but as you can see the ATA instruction is blocked.

Here is a take from someone who endorses the nannying. The problem is that there is a presumption on how the drive will be used. Give me a special switch like:

$ hdparm --security-erase $'\0' --I-know-what-I-am-doing-please-let-me-shoot-myself-in-the-foot /dev/sdb

and this is what I would do:

$ dd if=KNOPPIX_V8.2-2018-05-10-EN.iso of=/dev/foo
$ hdparm --make-read-only /dev/foo

When the drive crosses whatever arbitrary line of reliability, it’s of course perfectly reasonable to do one last write operation to control what content is used in read-only mode.

5 years later when a different live distro is needed, it would of course be reasonable to repeat the process. One write every ~5 years would at least keep the hardware somewhat useful in the long term.

¹ “owners” is in scare quotes because of the sensible viewpoint “if you don’t control it, you don’t own it”. We are not in control as a consequence of nannying.

This is a newer product on the market, its a great idea, where the USB-C plug can swivel. I assume their goal was to make it easier to charge your device while also using it, and to make the cable last longer. The swivel part is great when it works but it's super fragile and broke for me in two weeks.

Figured this would resonate with people here and have some overlap with this community.

"The idea behind this is that we want to log every single instance of a company taking part in one of these anti-ownership practices where they deceive you, where they take away your ability to have privacy, where they take away your ability to repair what you own, where they take away your ability to say you own what you own."

Video Explanation: Consumer Action Taskforce: EXPOSE EXPLOITATION & HOLD COMPANIES ACCOUNTABLE!

Work in Progress Wiki: CAT Consumer Action Taskforce Wiki

I have an old TomTom. Abandoned by TomTom with no map updates available. They claim the maps are too big for the storage space (apparently they don’t know they could distribute smaller regions to overcome that).

Anyway, I connected the standalone TomTom device to a PC running the old software, which normally syncs points of interest and manages the data. The piece of shit software decided to go to the cloud and discover a lack of map maintenance, and then took the liberty of removing the maps from my device with no replacement maps. The desktop software basically sabotaged the device.

So I reinstalled the original factory desktop software from CD and kept it air gapped -- with an expectation to at least install the original factory maps. The software refused to run until it could check for updates. Would not move forward. Once I let it connect, TomTom had taken their server offline. So I’m dead in the water.. no way forward and no way backward.

Regarding lifetime updates: IIRC TomTom and Garmin both advertise free map updates for a “lifetime” on their not-so-old devices. Don’t be fooled.. it’s not your lifetime they are talking about, but something they have defined as like 10 years or something. Read the fine print.

Smartphones are a shit-show so I bought some old Sony Ericsson feature phones from a flea market, expecting Gammu¹ to work as reported. It worked on one phone but not others (despite all of them reportedly working with Gammu).

Some msgs arrived and got trapped on the phone, which happened to have a dysfunctional screen. And gammu failed to access the phone (though it works on some phones). So I needed to run Sony’s proprietary garbage (“PC Companion”) on a Windows machine to get the msgs.

Sony’s PC Companion is designed to phone-home. The software launches but immediately goes to the cloud to check for updates so it can update itself. So obviously offline people are inherently fucked -- they can never sync their desktop and phone without the cloud.

But worse: Sony has taken down their server. Thus rendering all Sony phone syncing software installations useless. This thread is to document the big “Fuck you” from Sony to their customers.

¹ Gammu is free software syncs to old feature phones. You can send and receive SMS using the commandline this way.