[2025-04-03] Decoupling Updates __________________________________________________________________ There have been countless times where we end users have booted up our computers or unlocked our smartphones, only to find that our home screens and apps have completely changed. Everything is in the wrong place. We can't find programs or apps we installed and used regularly. Menus move around and use different names and icons. When we do find what we want, it doesn't work the same way, or it doesn't work at all. This is the scourge of software up- dates. Not all updates are so bad. The best and most important updates are ones companies hardly ever talk about: security updates. Vuln- erabilities are found in software every day, some extremely serious, and it's important to fix those vulnerabilities. What we're told about, though, and what we're subjected to all too often, are the dreaded feature updates. My biggest frustration with software updates is that companies bundle security updates with feature updates. Security updates are legitimate needs: it can be dangerous to the customer and bad for brand reputation if their products are insecure. But I often can't install those necessary security updates without also installing feature updates I don't want. Such "features" usually include in- creased lock-in, increased data sharing, increased permissions, increased power consumption, decreased compatibility, decreased robustness, decreased portability, and sometimes decreased func- tionality. I deal with enough overselling and under-delivering in my life. I want to avoid bad feature updates: if something works the way it is, I'd much rather keep using it the way it is and simply plug the leaks. However, companies don't give me a choice: if I want the security, I must submit to their control, and if I don't sub- mit, I'm left insecure. FOSS is not immune to the problem either. While I feel most pro- jects do a good job of separating security updates from feature updates, some projects are notorious for not doing so. Two promi- nent examples come to mind--systemd and GNOME--but I'm sure there are many others. I know there are times where the two kinds of updates can't be un- linked. For example, a fundamental feature update might be re- quired to fix a security flaw that is inherent in the program's current functionality. That is a legitimate reason to change a program's workflow, and I accept that. However, this creates a convenient cover for companies to force unnecessary feature up- dates into what should only be a bug fix: "We need to change how all this works because if we didn't, you'll always be in danger!" One way to lessen this problem would be if companies included more detailed changelogs. I find it quite annoying when I see an update queued for an app for a game console, and the only release notes are something to the effect of "we made out software better." Nin- tendo is so well-known for the generic update notes "General sys- tem stability improvements to enhance the user's experience" that it's become a meme in the console hacking community, and third parties have to analyze the updates to figure out what has actual- ly changed. Seeing which security updates are fixed and what fea- tures are included would help me make more informed decisions about whether or not to update my software. __________________________________________________________________ [Last updated: 2025-07-26]