this post was submitted on 19 Apr 2025
1 points (100.0% liked)

Asshole Design and Crappy Design

24 readers
2 users here now

This community covers both asshole designs and crappy designs.

Discuss manifestations of asshole designs whereby the design is deliberately anti-consumer. Manifestations of crappy designs are also welcome in this forum, which reflect poor designs that are not borne out of deliberate contempt for the consumer.

Use of these prefixes is encouraged:

[a/d] ← you are confident that the design is an Asshole Design

[c/d] ← you are confident that the design is a Crappy Design

[ObD]Obsolescence by Design (a specific variety of a/d).

Unprefixed titles are useful if you’re uncertain whether the design is deliberate.

Rules:

  1. Please avoid posting web-related designs. Instead, post those in:

Related communities

Existence Rationale:

There are other communities for Asshole Designs and Crappy Designs, but all of the communities at the time of our founding exist only on centralized instances. We are currently the sole decentralized community of this kind. (update: another crappy design forum was recently found in the free-world-- see related communities above)

founded 1 year ago
MODERATORS
 

cross-posted from: https://slrpnk.net/post/21031468

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.

no comments (yet)
sorted by: hot top controversial new old
there doesn't seem to be anything here