The Never-Updaters: Why Some People Refuse to Download New Software
wsj.com
wsj.com
On the other hand, I mostly dislike updates of proprietary apps. They tend to be much larger in size (I'm on a metered connection) and usually don't have my best interest in mind.
A lot of (but absolutely not all) FOSS software still comes with that sense of excitement for updates rather than fear.
From a developer perspective, even worse (though not exactly the same) is having to modify working code due to developers making arbitrary backwards incompatible changes that I have no choice but to incorporate because node/react/security etc. updates.
Generally speaking, my enthusiasm for software development has fallen off a cliff in no small part because of the bit rot imposed on me from incessant updates.
I'm not aware of ever having been affected by an unpatched vuln, but many times I have lost configs, data, or time to updates.
While some things are better now than then (almost entirely because the hardware is better), it does seem clear to me that on the whole, software is generally worse now. Sometimes a whole lot worse.
It also used to be that saving could crash. And that saving could save a file which open could not open.
Software is better now.
Regardless, as I said, some things are better now. But a lot of other things are worse. I suppose that whether software is better or worse overall now depends on which things bother you more.
For me, there's no question that software overall is not as good as it was.
This situation has improved a lot, but there are still cases when they (Microsoft Office) still don't get it (for example with OneDrive failing to connect)
> Software is better now.
There is an arms race for more features which leads to more code and libraries which has forced developers to be more careful. But, rewrinting the GUI, breaking existing functionality ( i had to search today how to enable the vertical ruler in MS Word, only to find out that it is enabled but Word will not display it, except if i click in this area and only lasts until i move the keyboard cursor), changing the GUI (new xsnow will not start because it ignores the command line parameters and starts a config dialogue), ignoring years of GUI design (Android- status messages obscuring the input field, transient windows with no ok or cancel which last forever, gray on gray, and so on) does not improve anything. On the contrary, today's program are more anti user than programs 5 years ago (or 10, or 15).
Updating software is risky and can come with functionality loss, unexpected functionality/workflow changes, etc. Which means I want to do it when I have a couple of days available to recover from it.
https://learn.microsoft.com/en-us/windows/package-manager/wi...
The only 'requirement' to use winget is updating Microsoft Store after installing Windows and install 'App Installer' from the Store, at least in Windows 10.
[0] https://learn.microsoft.com/en-us/windows/package-manager/co...
It missing some like mupdf, TeX Live, Tixati, Q-Dir, Emulators, UMLs, etc. Through it have MiKTeX but I was burned by miktex's package update procedure weirdness.
The big thing is that winget requires "proper" MSI or MSIX-backed installers (MSIX, MSI, APPX, and most .exe installers) rather than scripts so given the list you've provided some of what you may need is to better help some of the upstream packages clean up their installers/fix bugs in their installers on Windows. (Package update weirdness sounds like a common class of installer bug, sadly.)
That installer focus is one of the things I like and trust about winget. For the most part it is really easy to verify that winget isn't automating much more than what you could do by hand: it is often grabbing the exact same installer you'd go to someone's website to grab, validating hashes for that installer, then running it (in silent mode). One of the reasons I gave up on Chocalatey years ago was too many "packages" were complex PowerShell scripts and I started feeling like I needed to audit every single one (and every version of it) before running it. Some of the "common" packages were full of opinionated scripts that were doing way too much, and some of the uncommon scripts would sometimes have malware in their scripts (and that may be a late change after years of good scripts, too); I reported it every time I saw it, but at some point you report too many and you lose trust in the whole ecosystem. At the moment trusting winget is still quite a bit easier, even after the burnout I had from choco.
Furthermore, many choco packages are embedded and contain the software, which means they can be cached (artifactory, nexus etc.) do not depend on vendor location and can work forever (like development dependencies). All of this makes winget vastly inferior to choco at this moment and suitable for hobby/home use, not serious things like maintaining CI/CD pipeline.
Choco package number and speed of update is on par with Arch.
The good thing about winget is it comes with Windows, which is probably the only one at this point.
MSI (and MSIX) are complex databases of pain, but they absolutely know how to uninstall everything that they are told to install and that machinery is well tested now across way too many Windows versions. On the other hand, if someone even bothers to test a script-based uninstall is a crapshoot.
> the idea of "help some of the upstream packages clean up their installers" is irrational and unrealistic
Not really, it is standard open source practice. Installers aren't the most interesting or glamorous thing to maintain so they often welcome any help that they can get.
Most Windows users still don't use any package manager in 2023 and still prefer good installers directly from upstream sources.
> some of those tools may be even done with the upgrades, which doesn't mean they shouldn't get a package.
Ruby's Windows installer has long been run by third party developers. Git for Windows started as a third party operation before getting officially blessed. Open source is full of instances where the person packaging the software is not the original developer. (That most of Linux packaging, even, it's not just a Windows phenomenon.) Without "official" blessing from upstream it can be hard to get people to trust your distribution, but if upstream isn't bothering with maintenance anyway, it is no longer their project. (That's also extremely common in Linux software packaging, new maintainers are often blessed because they did a good packaging job.)
> Furthermore, many choco packages are embedded and contain the software
My experience was very few of the packages I used did that and almost all revolved around some ad hoc Invoke-WebRequest or similar somewhere in their PowerShell scripts, but obviously that is my own anecdotal experience and I'm glad for you that you've had a better time trying to CI/CD with choco than I ever had.
Some people have built custom sources for winget to help with CI/CD scenarios. Out-of-the-box caching/CDN for the primary public sources is still an active discussion, but the neat thing is that it is an active discussion out on GitHub so that you can directly voice your "serious" use cases, if you wish. A good thing about winget is that it is extensible (custom sources) and developed in the open on GitHub (Chocolatey went corporate and a lot of discussion moved proprietary and some of it went closed source years ago).
How is that different. You seem to compare about method/language used.
> MSI (and MSIX) are complex databases of pain, but they absolutely know how to uninstall everything that they are told to install and that machinery is well tested now across way too many Windows versions.
They can do whatever developer wanted to do. Otherwise, we wouldn't have those gazilions of special cleaners/uninstallers we have
> My experience was very few of the packages I used did that and almost all revolved around some ad hoc Invoke-WebRequest
It was the case in the history, 5+ years back. Now big number of packages are not like that. I personally do not use non-embedded packages for office work. See https://github.com/chocolatey-community/chocolatey-packages/...
> Some people have built custom sources for winget to help with CI/CD scenarios
Yeah, you can fix anything. I keep rejected choco packages on my github too.
> Out-of-the-box caching/CDN for the primary public sources is still an active discussion,
I wouldn't use CDN, its just one dependency replaced by another. Cashing is irrelevant if you do not embed the software.
> but the neat thing is that it is an active discussion out on GitHub so that you can directly voice your "serious" use cases
You can have active discussion on GitHub with choco guys. I am sure results in winget case are not going to be much different. In my experience, way more pain than being useful.
So, to recap, the setup is almost the same with choco being small company and MS not. Choco is vastly better with features. I am moving to winget for various other reasons, that I won't talk about here and it has nothing to do with the tech.
> They can do whatever developer wanted to do. Otherwise, we wouldn't have those gazilions of special cleaners/uninstallers we have
The MSI engine was built out of the pain of Windows 3.11 DLL Hell and is not the hero that Windows deserved but the unfortunate anti-hero that Windows needed.
Have you ever tried to build an MSI directly? (With WiX, for example?) These are complex databases of pain precisely because they track file history and dependency maps to an absurd degree because MSI expects a need to rollback everything at any time, but also can't break other apps and needs to be able to repair things.
MSI's biggest problems aren't that it does whatever developers want to do, but that it wants to do a lot of things developers don't want to do or care about. That's why few developers actually want to build installers with something like bare metal WiX and still use MSI builders like NSIS and InstallShield and Active Installer and a million others. Those builders certainly give developers an impression that they do whatever the developers want them to do, but MSI is a leaky abstraction at best and they still have warts from it on the one side (there are so many of these builders because they eventually all get eaten up inside from the complexity and harshness of MSI), and on the other side some of their "do whatever you want" they offer to developers are custom shims (InstallShield notoriously included some incredibly buggy ones that Windows to this day monkey patches bug fixes into) or custom scripting languages (NSIS can do pure MSI, but also makes it way too easy to just write custom scripts that skip the MSI engine altogether).
We have gazillions of "cleaners/uninstallers" not due to deficiencies in MSI itself, but due to:
* Weird non-MSI shims embedded into EXEs
* Weird scripts that run outside of MSI
* Users confusing Program Files/Program Data and User Data and assuming that uninstallers should remove User Data they generated
* "Make my computer appear to be faster" will always be a massive vector for spyware and adware (most of the "cleaners/installers" out there are one, the other, or both; arguably most of them are also actively dangerous to system performance because the Windows Registry is ultimately a big dumb MRU cache and regularly churning that cache in search of "cleaning" deoptimizes the actual things that need to be cached for fast access and also the Registry is optimized for infrequent writes/deletes and the "cleaners" are bad about thrashing that performance too)
(MSIX is a lot easier to write by hand than MSI with WiX, but also makes even more assumptions about file versioning and package management locations and is even less "do whatever the developer wants" by default and needs to opt-in to increasing levels of developer "I solemnly swear I know what I'm doing." that eventually get developers back to WiX levels of complexity with a subtly different XML syntax.)
> It was the case in the history, 5+ years back.
I'm glad to hear choco has gotten better than when I quit using out of script auditing pain.
> I wouldn't use CDN, its just one dependency replaced by another. Cashing is irrelevant if you do not embed the software.
Caching/CDN here means "embedding": it is a map from Official Installer URL to some Hosted Installer URL with high replication (CDN) and locality (CDN+Local Caching). With Choco embedding you are paying Choco to host installers on their CDN and then happy with your local caching options as you download them. The only big remaining difference for "embedding" is that Choco uses ZIP files that contain both XML metadata for choco and installers (.PS1, .BAT, .EXE, .MSI, .MSIX, etc) whereas winget's current architecture would have you cache two files (YAML manifest and .MSI/.MSIX/.EXE installer). If you like, you could also ZIP the two together for true "embedded", but there are some benefits to not doing that as well.
> You can have active discussion on GitHub with choco guys. I am sure results in winget case are not going to be much different.
I did have some bad experiences trying to discuss something with choco over GitHub. It didn't feel like they were using GitHub Issues as primary and instead were using some other issue tracker, I don't know what. It's again possible that these bad experiences were early in the license switch from being a purely open source project to being closed source with open source "customers" and things may have gotten better since those experiences that I had. The current website doesn't give a great impression on this: the only GitHub link in the header and footer is just a "social media icon". The Report Bugs page does link directly to two GitHub repos, but at the bottom as implied last resorts (unless "Security") and instead suggests you use Google Groups mailing list (or Twitter, lol) first for "open source users" and special support emails for licensed business/pro users. It certainly isn't the impression of "GitHub native discussions".
On the other hand, Microsoft often seems serious about "GitHub native" and winget is certainly in that list of almost every discussion, including some "internal ones" is either in GitHub Issues or GitHub Discussions boards. There's no other mailing list. Things are deeply cross-linked (including into PRs and release notes) and winget looks way more open source and open community than choco on a bunch of little things, despite the disparity in company sizes.
In my experience as a poor and mild open source developer, winget seems welcoming to open community discussion contributions in a way that choco hasn't in way too many years. (I was somewhat involved in early choco. It's commercial licensing pivot lost me in a lot of different, little ways.)
Take firefox for example, one of my favorites to rag on. Many will tout how quick it has become to which I say "So what? I don't allow any javascript". Or maybe touting new image and video formats. I will just point at libavformat and libavcodec. What they have done is removed xul, removed scrollbars, removed rss, removed the text encoding menu, removed unsigned extensions, and every year there is some new vision about how the ui must look.
I am apprehensive of the coming KDE version 6. I can't imagine how people must suffer on autoupdating systems whether that is linux, mac, windows, or some godforsaken mobile device.
> can’t seem to free up enough space
Technical issues are completely understandable. I am lead to believe most devices are tiny and will hide your files from you nor do they easily support external storage. Therefore I am not at all surprised people can't remedy this.
> unsent messages
If you sent it then it was sent. Relying on remote software to delete it is insane. I see all the times people edit a message from matrix. To be honest I see it as a feature and apparently one that would be removed if updated.
> When a device no longer gets the newest OS, it’s time to upgrade to a new machine
Consoom!
What even is it doing? It printed before the update and keeps printing after the update
I blocked chrome from updating because it would peg my cpu a few times per week. After the 10th time, I stopped the update and haven’t had that problem yet.
There aren’t really any new features from chrome I want for weekly updates and the suckiness of their updater. I just reinstall every few years.
I also find that updates are usually a pain. They do dumb stuff with cpu and disk. They consume a lot of data (my isp caps me at a TB) and so aren’t a good value.
“Security” isn’t a real reason for super frequent updates.
After spending days with him over TeamViewer and video call, I finally understood that the reason why he couldn't accept windows 10 - the desktop icons were moved in a way he doesn't remember. (he has hundreds of them, and yes we bought him a big screen)
Why do you / do you not accept software updates in your os/dependencies/packages?
Do you naturally gravitate to something like CentOS and/or stick to LTS distro releases?
How do you reconcile believing that you improve your software against the idea that others make theirs worse?
It all depends. As an employee, I just accept that there's little I can do about the whole situation because the causes of it are things I have no control over[1]. This issue is actually one of the ones that gets me thinking that there isn't much room for engineers like me in the software industry anymore.
With my own software, I do have that control, so I avoid the practices that I think are leading to not optimizing for quality.
[1] In my current position, my employer does not engage in the practices that I think are problematic, and I am proud of the quality of our work. But it's a special case because we produce industrial machinery and the software has to be rock solid when shipped, constant updating isn't possible, etc.
I did update this one to Android 10 - I don't want 6 years out of this one.
The article mentions iOS and macOS updates and I can relate to that somewhat, though. OS X 10.7 at the time was horrible. It had known memory leaks that never got fixed and you _had_ to update to 10.8 to fix it. There was also a version that introduced a new DNS forwarder which was so broken that Apple rolled it back in a point update.
It still seems weird to me to reject any software updates based on broken functionality.
Oh, I actually do stay away from updates on one device. My HP printer would reject my third party toner if I would update it and that's why I keep it disconnected from the internet.
Does it seem weird to you because you've never suffered due to a change in the feature set? I can understand that. If you haven't felt the pain, it's hard to be very sympathetic.