There are few things quite as emblematic of late stage capitalism than the concept of “planned obsolescence”.
I have preordered a framework laptop which will run Linux until it fucking blows up or falls apart.
Enough with being screwed over by well known brands whose interest is just selling you more and more stuff.
Planned Obsolesce should be a crime
I would have agreed with that statement until I saw the most recent Technology Connections video about why the incandescent light bulb has planned obsolescence built in. Sometimes it’s not malicious but to actually provide a compromise leading to an overall better product.
I don’t think software death dates count, tho.
TLDR: I’m still very suspicious of how that is quantified - “leading to an overall better product”.
Who quantifies that and how, on a case by case basis, especially in the form of Chromebooks or phones for revenant, popular examples?
Let’s say it was a laptop: I can see issues with lithium batteries perhaps reaching a cycle count that lead them to be dangerous. Wouldn’t that mean though you should produce a good that has replaceable batteries? Is the battery designed in such a manner on purpose?
Businesses with shareholders that live quarter to quarterly profit are the issue. There is no authoritarian legislator that reallocates resources like China did the last few years, for example, whether you like it or not.
The US relies on legislation to be passed to mandate the changes or prohibit a device from being built a certain way. That legislation can be lobbied for loopholes, have various people in power also own percentages of the companies, etc. Whether you agree with it or not, there are many checks and balances and simultaneously a lack thereof.
but to actually provide a compromise leading to an overall better product.
Could you elaborate a bit more on that?
For incandescent lightbulbs, his point was that bulbs can burn fast and bright or low and slow, and standardizing on a lifespan of 1000 hours was a sweet spot between performance and longevity. For example, it makes 60W bulbs from different manufacturers more interchangeable and less prone to tricky marketing gimmicks like a “long life” 60W bulb that’s dimmer.
Light bulbs aren’t planned obsolescence though, he even said as much in the video, light bulbs more akin to dish-soap which eventually runs out then a device made to be obsolete faster. They are consumable items, which run out or burn out, they are not expensive appliances with long lives, hell he even pointed out that some utilities gave them away for free.
Good, maybe that will get them to stop using Chrome OS in schools, it has been a disaster for computer literacy in general.
The service life of the devices was known up-front. You can check for yourself the service life dates of every Chrome OS machine here:
https://support.google.com/chrome/a/answer/6220366?hl=en
The correct deployment strategy would be to make a big purchase at the front end of a device’s lifecycle and then only replacements from then on out so that you get the most out of every machine. Future capital purchases would be with a new device and termination date.
I think this point is really important, and allow me to go one step further: I work in the public sector of education and purchasing technology is such a complex issue that IT governance has to be involved with decisions like this. That’s to say that, without a governing body to review purchases (outside of whoever handles the actual procurement, i.e. funds leaving the bank account), mistakes like this will happen.
We can be upset with planned obsolescence, but there’s distinctly a human error here where there wasn’t enough research and planning.
Comments upon comments ignorant of the realities of the privacy laws governing this domain and the implications on firmware, driver and OS security support. “Just install Linux on it” is a completely unworkable solution. As some have pointed out, the places where this is done have a much thicker IT departments staffed with higher grade professionals to make it work. The thing to be mad here about is the shit support from vendors across the stack. If I had to guess, the worst offenders are probably the SoC vendors who typically ship firmware and driver updates as is the tradition.
Yeah, bulk imaging computers is really only limited to how many you can hook up to the network. I used to have to image hundreds of computers a day at times, and really the longest part was walking around and restarting them all so they’d PXE boot. The actual process maybe took 2 hours since all the computers were on 100Mb/s connections.
I converted one of these Chromebooks to Linux as a test project and the results were, not good.
To start, they have a bootloader lock screw under the motherboard, so you have to take the entire laptop apart to load anything but unsupported ChromeOS.
Then you have to use a Google tool, can’t remember the specific one, to swap the bootloader. That might be possible to automate but I didn’t look into it because…
… The hardware sucks. We’re talking like 4GB of storage on a lot of these Chromebooks. The driver support is all over the place, and there are issues everywhere even on “supported” distros.
With the vast amount of junk Chromebooks out there, I’m sure community hospice support will get better, but it’s never going to be an easy bulk conversion because of how common the bootloader locks are.
I am actually curious as to how you would make a locked down managed linux OS akin to ChromeOS.
Because Linus Torvalds stupidly refused to change the Linux license to GPL3.
That’s exactly the problem. The standard GNU/Linux distro isn’t suitable to allow carrying the responsibility that an innumerable number of users with physical access won’t be able to pwn those machines. Machines that are used by others too. You absolutely can make an OS like that out of Debian or Ubuntu, or what have you. Google has - Chrome OS - but it’ll take a significant development effort. You’d have to basically redo at least some of the work they’ve done. And let’s say you did all of that. Then you end up deploying it on an ARM-based fleet. And there’s a wild vulnerability in the WiFi firmware blob, and the SoC vendor no longer supports it. Every student has root and we’re back to the original problem. 👨🚀🔫
And that’s why instead of getting hardware from a vendor and hoping for the best, you might want to get it in writing that they’ll support their crap till a date. Then you stamp that as the EOL date for that laptop and you present it as part of the spec to whoever might want to buy this laptop. There’s no escaping this problem unless there are no proprietary blobs on the system, which is unlikely for ARM, or you have a solid development team and you’re large enough to have a source sharing contract with the vendor that lets your team fix the vulnerabilities and support the hardware for as long as you like. It’s probably much easier to achieve on x86, which costs more per unit up front.
