this post was submitted on 11 Oct 2025
24 points (100.0% liked)
technology
24272 readers
322 users here now
On the road to fully automated luxury gay space communism.
Spreading Linux propaganda since 2020
- Ways to run Microsoft/Adobe and more on Linux
- The Ultimate FOSS Guide For Android
- Great libre software on Windows
- Hey you, the lib still using Chrome. Read this post!
Rules:
- 1. Obviously abide by the sitewide code of conduct. Bigotry will be met with an immediate ban
- 2. This community is about technology. Offtopic is permitted as long as it is kept in the comment sections
- 3. Although this is not /c/libre, FOSS related posting is tolerated, and even welcome in the case of effort posts
- 4. We believe technology should be liberating. As such, avoid promoting proprietary and/or bourgeois technology
- 5. Explanatory posts to correct the potential mistakes a comrade made in a post of their own are allowed, as long as they remain respectful
- 6. No crypto (Bitcoin, NFT, etc.) speculation, unless it is purely informative and not too cringe
- 7. Absolutely no tech bro shit. If you have a good opinion of Silicon Valley billionaires please manifest yourself so we can ban you.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Atomic isn’t the direction I’d go with it, you’re likely better off with a dd script.
Some of your emmc speed problems will go away after doing badblocks -wsv -b [your block size as reported by smartctl] or spinrite lvl3+ if you’re able. The reason is that flash sucks and gets worse over time until it’s rewritten but everyone designed the controllers to be write averse so now they fiddlefuck around trying to read data that would be rewritten in idle time by a sane controller/os.
Is your operational model “put all the old hardware back out into the world and then go away” or more like “provide minimal support to these devices once they’re issued”?
Providing minimal support is a huge aspect. It's a small shop and large orders like this aren't uncommon. I'll definitely look into optimizing the emmc, as that's a huge bottleneck. The primary goal is always to eek out as much life from devices that were slated to be landfilled as possible and provide minimal working solutions for free or as close to free as possible.
These Chromebooks are veritable e-waste and making it so we can get some last mile usage out of them while having a system that's moderately fault tolerant (btrfs is good for the unreliability of the emmc) is key. Plus the AB updates mirror normal Chromebook functionality.
The atomic style with flatpak also makes it really hard for an inexperienced end user to fully bork their system as the base image and root is read only. Having all the user files in a separate volume also means it's trivial to migrate them to a new machine or wipe an old one. This is essentially an experiment at this point, but we've had a ton of very positive feedback from people about Linux. All the elderly people find it easier to use since they aren't constantly being pushed notifications and spyware. Plus the atomic updates mean they don't have to worry about manually running
apt/dnf upgradeto get updates and the whole process is just handled automatically in the background.Another way to completely rewrite the emmc, which is often the solution to slow flash, is dd if=/dev/urandom of=/dev/[your device id].
The flash cell loses charge over time and takes more operations to read correctly so you “see” slower reads and writes. It can happen even when reading newly written information because the controller isnt just reading each bit, but whole blocks. So if the controller decided to shove your new 200 byte file in the same 2048 byte block as some old information whose pointer got dropped then it’s still gonna be slow to access that new file because the integrity mechanisms are designed around the mediums physical block size. Rewriting all of it at once fixes the problem.
It’s often worth losing one of your minimum ten thousand write cycles to get normal predictable io performance back. Also going over your rated write cycles just means the flash will lose data integrity over time faster when powered off. I have a scratch device on my server made from many old ssds that is completely fine despite coming up on a million plus write cycles because I’m not relying on it to endure being turned off for a month.
It may be worthwhile to consider working out how to do a swap when someone brings you a non working unit. Then you can hand over a new one, make sure they’re able to use it and have their files or access to their passwords (bitwarden?) or whatever then handle the returned unit on your own time.