I mostly love updates of FOSS software, each time it feels like receiving a tiny gift from a developer somewhere in another corner of the world. I run Arch so I get multiple gifts each day.
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.
It's true... before software was continually updated, a software update (aside from small security/bug fixes) was something people got excited about and anticipated for good reason. Now, they're things people tend to dread.
A lot of (but absolutely not all) FOSS software still comes with that sense of excitement for updates rather than fear.
A classmate of mine was committed to this position. He told me that each time he updated his device he lost functionalist that he liked, was given functionality that he disliked, and of course the issue of greater resources such as battery drainage.
I'd speculate the amount of people who have experienced malware that an update would have protected them from is orders of magnitudes smaller than the amount of people who have reliably experienced things worse after update or the update is the malware.
I also hate updates. They practically never solve problems I have but they do break working setups, lose settings, expose me to tutorial/walkthrough/new feature nags, force me to re-install other software that is now broken, break things like python envs (in the case of a brew update) and golang installs (when MacOS devs fuck with clang), threaten me with reboot loops (Sonoma), rearrange things (why does MacOS keep changing their settings app?), cause existing software to stop working because of API updates that developers can't keep up with (Android is particularly bad about this) or just generally force me to close all my shit to restart for the update to take effect.
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 would find the option to update on selective things to be more valuable. I would happily update security-only updates, but maybe pass on others, such as updates to the UI, or general functionality of the device. What I dislike more than anything is when I am forced to update for non-security reasons; for example Microsoft products!
The biggest thing we've got wrong with the modern approach to update is, in my opinion, combining security updates with feature updates. They should be separate. You always want security updates. You may not want feature updates.
I've thought for a long time that it would be nice to have versioning at the function and data structure level. Not to mention tools to auto-build a wrapper around newer libraries. Even if incomplete it'd sometimes do the job.
I take this stance. Almost always, the new software is worse in some way than the old, either taking away some capability to make room for a new product you would have to buy, or by breaking support with hardware you already own. It's my position that software was almost universally better 20 years ago.
Software 20 years ago was less capable. But software 20 years ago also didn't expect to keep making money after it was sold to you. So the motivation of the vendors has changed. Formerly: Deliver, once, a product that's good enough so you'll be pleased - and recommend it to others. Now: Suck you into becoming an ongoing revenue source, even (or particularly if) that means a less good user experience (e.g. ad overload, dark patterns, turning "for life" features into "paid subscription" features on upgrade, etc. etc.)
> It's my position that software was almost universally better 20 years ago.
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.
You used to have to save before printing because printing could crash your app or your entire computer. Occasionally, I print something now and have a minor moment of panic remembering that I haven't saved in a while.
It also used to be that saving could crash. And that saving could save a file which open could not open.
> It also used to be that saving could crash. And that saving could save a file which open could not open.
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).
Neither of those things were ever universally true (I don't remember ever encountering either of those issues, personally). They may have been a problem with the particular program(s) you were using?
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.
I don't refuse to update software, but I do prefer to wait for as long as possible (preferably until I see a number of reports from others who have updated) and I absolutely don't want automatic updates at all.
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.
My issue with updates/downloading is the lack of software manager to updates software in Windows. It was a pain to go to various websites to download a package and install/upgrade a updated version. Back then when I have Win 98SE, I relied on FileHippo to scan and provide information if there are updates for my installed software. In XP and Win7, I only update software that have issue or something that I need to check. It was nice for some software that come with their own updater. I was thinking about my experienxe with Ubuntu (Ibex version) with their apt-get and the package manager. To my surprise, there are package managers for Windows, Chocolatey and Scoop. This was before Windows Store come to fruitation. Chocolatey is my main package manager for my Windows and I had been using it ever since. This allows me to have a peace of mind for me to updates my software particularly command line tools, Chocolatey made it easy for me and automate the environment variables for me if the software needs it. And no more for me to open up Google and search for the name of the software, `choco search <app_name>` and it will give me a list of the software and I just install from there. I use `choco upgrade all -y` and it just handles it without needing my input further.
The best thing about 'winget' is being able to have a powershell/batch script in you usb stick to install the last version of most of the software you use.
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.
I've been slowly digging into Winget Configuration [0] since I started exploring the Dev Home (Preview) app on Windows 11. I still have too many machines that can't upgrade to 11 right now, but Winget Configuration seems a real neat way to bootstrap new machines. (I know that you can use Winget Configuration on Windows 10 without the Dev Home UI, but the UI is one of the more compelling things about it, I think.)
Winget is great package manager. I am staying with Chocoately due to WinGet have less software in their catalogue. WinGet are missing software that I regularly use in my Windows that I am able to get it through Chocoately.
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 workflow to submit new packages seems easy enough, it's a simple PR process to a GitHub repo [0], if you want to try to help fix that.
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.
That's also what is bad about winget - not having scripting language. AFAIK there were 0 incidents with choco scripts, they are mostly trivial to review (choco also has team of reviewers and no package can be published without being reviewed) and many tools simply can't be installed without PowerShell - the idea of "help some of the upstream packages clean up their installers" is irrational and unrealistic - some of those tools may be even done with the upgrades, which doesn't mean they shouldn't get a package.
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.
I appreciate that we're probably going to continue to have opposite opinions on this.
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).
> Open source is full of instances where the person packaging the software is not the original developer.
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
> 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.
>> 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
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.)
Some programmers are hell-bent on removing features, particularly those in the graphical world.
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
I'm refusing to update to Windows 11, and won't do until I buy a new machine or something like that, and I wish I could go back to Windows 7, where the task manager doesn't get frozen when things go bad or where there are programs like "Settings" made with that Metro/UWP apps that go slower than most Electron apps written in JS.
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.
My grandpa can't accept windows 10 and had to stuck with win7. I remembered that he actually loves my old hackintosh setup, so when he's computer died I bought him a m1 Mac.
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)
> 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'm typing this on an Essential PH-1 phone I took out of the box a week ago to replace the Essential PH-1 I have been using daily since 2017. I never updated the other phone once and it lasted 6 years of significant use.
I did update this one to Android 10 - I don't want 6 years out of this one.
Frequent minor updates on F-Droid are why I stopped using a certain developers simple line of apps. F-Droid requires manual updating and I wonder if it occurred to this dev what a timesuck he had turned his apps into.
To be honest, I've rarely lost any functionality because of a new feature release of any software. I can't even think of a security update that caused any problems in the last few years.
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.
> It still seems weird to me to reject any software updates based on broken functionality.
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.
I hate updating video games. More often then not they remove some awesome exploits or feature that I may want to make use of or removing inappropriate content for censors
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.