This post’s title question is a quote from Red Hat Linux founder Bob Young, emphasizing the benefit of open source software allowing you to inspect and modify your software tools.
Let’s take some creative license with the car analogy.
Would you buy a car that has the battery riveted into the chassis? Let’s say doing so frees up the engine bay a little and allows for a larger battery than the standard cubic 24F battery since its custom shaped into a body member cavity. I would wager most folks would balk at this design choice knowing that batteries expire within a few years and would rather be able to replace the battery without also needing to swap out the front quarter body panel.
Would you buy a car whose engine has the water pump, alternator, A/C compressor, and power steering accessories welded into the engine block instead of conventionally bolted on? While we’re at it, turn them all internal facing so they’re driven by a sealed chain. Let’s propose that permanently fusing these accessories into the engine at the factory nets some performance increase and allows the car designers to shave 3 inches from the engine bay and give that space gain into the passenger cabin. I can almost guarantee someone living in Florida, USA during a humid summer season being told their A/C compressor is broken and has to get a whole new engine put in isn’t going to care as much about the few HP or foot-well room bought by the “fully integrated” engine design.
Now, my examples focus more on the hardware serviceability side of things. But it is important nonetheless because such measures preventing you from maintaining your systems within practical reason have encroached gradually over time with little protesting.
Non-user replaceable batteries have proliferated across most contemporary smartphone offerings, thereby placing a hard limit to use life as service life of Li-Ion batteries is just a few years regardless of use duty. Batteries internally glued to the chassis has been a feature on several higher profile laptop models, making repair a potentially dangerous undertaking.
RAM modules soldered onto the motherboard instead of installed into slots isn’t exactly a new invention — I saw it on a couple lower-end Intel-486 based desktop computers back in the mid-1990s. As those models were marketed for institutional use, my guess is it was due to budgetary reasons. Modern laptops that use soldered RAM will claim it helps thin the chassis (whether or not it matters to the target clientele). Granted, for some slim focused ‘s’ notebooks the tradeoff may be warranted, but is odd when an productivity oriented, unashamed thicker ‘T’ notebook uses soldered RAM. Although RAM failures are quite rare these days, a non-replaceable module is yet another unnecessary system failure point.
Back to my fully integrated engine thought from earlier, soldered RAM (and soldered CPU) may be a non-issue for the appropriate target audience who might be more willing to scrap the entire system of either of those parts started acting up. However, bundling the non-volatile data storage within the weld is asking for trouble no matter the end user. Within such a system, if the main board becomes inoperable for whatever reason (bad power rail, water ingress, exposure to leaked battery acid, etc) the user data is not retrievable. Not only that, SSDs themselves are a consumable component with a finite (although usually long) erase/write life and also not immune to controller silicon failures.
Its easy to envision the not so pleasant future where even though you purchase computing hardware, you really only lease them. The ‘just don’t buy it’ doesn’t always cut it because its not just one offending company, nor is it limited to computer hardware.
The debate on right-to-repair may be promising, but it is a complex discussion with many intricacies that can trip up most legislative bodies who are distracted by the lobbying parties of interest while (hopefully) balancing the reach of government.. Impactful and straightforward, yet non-draconian directives may be hard to come by. How do you go about mandating design for serviceability at the legal level with non-ambiguous verbose? Is it “serviceable” if a board or module can be swapped out, or is the requirement satisfied only with schematics, firmware, and access to vendor specific custom chips?
The mitigation options readily available for preventing computing failure fallout includes redundant data backup/recovery measures, and fallback computing systems at the standby.