1. 41

  2. 16

    One of the reasons why I view these Flatpak, Snap, … ideas with disdain.

    They are nothing but a software delivery mechanism intended to avoid the oversight and scrutiny of repository maintainers.

    1. 15

      I’m sure the author knows this and this doesn’t invalidate the point of the article, but these “rules of engagement” don’t work in the real world.

      The vendor isn’t just producing software for you, the vendor is producing software for their entire set of users. The vendor needs to make security updates, and the vendor needs to make functionality changes and improvements to make their users happy and not lose them all to a competing vendor. By default these go into the same branch of code because that’s what most customers want (and indeed, practically no-one would prefer a “feature updates without security updates” branch).

      The (average) vendor would be perfectly happy to produce this “security and bug fix only” update stream, provided you paid for it. But paying for it doesn’t mean your several thousand dollar per year license to use their CAD software or a 5 dollar per month patreon to support firefox. It means paying for the entire cost of the engineer(s), support people, sales people, and so on necessary to make the security fix only update stream exist. Even if that was just 1 engineer working fulltime, that would be hundreds of thousands of dollars per year.

      For the vast majority of software no one is willing to pay hundreds of thousands of dollars per year for their security updates. For the rare enterprise software exceptions there are typically long term support releases precisely to allow customers to do that.

      1. 6

        Great summary of the situation. Although improved security would normally be a good reason to upgrade, giving software vendors a blank check on your system just invites them to become insider threats. Microsoft trashed its reputation with me by force upgrading to Windows 10 through its security channel, and that reputation has never recovered.

        1. 5

          This describes my feelings as a user of software quite well, as a developer of software I try to incorporate all of those points. Sadly it feels like I’m the only one. All other developers I know feel way more for short term developer comfort, New resume driven frameworks or whatever rewrite they can force through.

          1. 4

            A timely article given my need to find a new browser after an automatic update ruined my browser a couple of days ago.

            Firefox for Android was updated from a product I was extremely happy with, to a different one I am extremely unhappy with. All without being given a choice or notice.

            1. 4
              • should be incremental and security or bug fixes only
              • should never change the format of data already stored on the system

              Make up your mind mate.

              Often the gnarliest and most urgent bugs that most requiring fixing lie at the persisted data format / structure level and no about of busy work above that layer will fix them…

              Feature Upgrades can often be well thought out and planned and done in a neat open closed extensible backward compatible manner….

              Bugs are often… Oh Shit! We didn’t think of that!

              1. 4

                I agree with parts of the post, but certainly not this:

                More often than not automatic updates are not done with the interest of the user in mind.

                I don’t believe this is true. I don’t have data but I think the main reasons for automatic update are in the interest of the user, the N.1 being security patches (as mentioned elsewhere in the post). Software without at least semi-automatic security updates is one of the main reasons why there is so much malware everywhere and this is clearly not good for users. It’s even worse for hardware. Actually I think most of the “should always” / “should never” bullet points should come with “except for security reasons” (especially the last one, compatibility with plug-ins).

                Another reason is compatibility, especially in the case of networked software. If you change the client - server (or client - client) protocol without automated updates you can never deprecate anything and in the long run it becomes a maintenance nightmare. This gives an edge to your competitors, especially to Web-based software which (almost) always auto-updates. And being uncompetitive is clearly not good for your users in the long run.

                All that being said, the choice depends a lot on who the user is. I think most hardware and software for the general public should come with either automatic or semi-automatic updates enabled by default, unless it is distributed through a package repository / store (which is the ideal case). Professional software which is administered by trained people, for instance, is different.

                For commercial software I think the solution to avoid version explosion is to always limit the duration of user licenses. Even if you want to sell a life-long license, you can structure it so that users have a one-year license for a given version of the software and the right to obtain such a license for the latest version of the software anytime. And then maybe you don’t auto-upgrade, but you tell the user “you must click this upgrade button by this date or you won’t be able to use the software anymore.”

                That being said, I do agree with a lot of the post, especially the fact that if you stop supporting a version there should be a clear upgrade path, that updates shouldn’t be abused for marketing purpose, etc.

                1. 10

                  More often than not automatic updates are not done with the interest of the user in mind

                  I think a more accurate claim would be that more often than not, the outwardly-visible changes that come thru automatic updates are not done in the interests of the end user. It’s primarily a matter of perception, and that perception is what drives the lack of trust.

                  Users don’t see the vulnerabilities they were protected against, but they do see the new ads that have begun to show in their start menu.

                  1. 3

                    Yes, that makes sense. Fully automated updates make that even worse because users don’t even notice the security updates.

                2. 3

                  I think Browser automatic updates are the happy case, but we’re blind to it because there’s a larger dynamic that doesn’t make them feel that good.

                  Browsers really have improved tremendously in the period of automatic updates. You can point to cases where Jaques’ concerns about telemetry, and trashing the UI would apply to browsers, so not every update has been good, but the performance and capability updates are tremendous. I remember having to use a Java client to play Go online, now there’s a nice browser based client.

                  The problem is that the broader ecosystem makes those gains meaningless most of the time. A faster browser often just means that a newspaper or whatever gets more animated ads. Even in less spammy cases, if those performance gains are eaten up by a react SPA, that doesn’t feel like an improvement. In the best case scenario, that’s a nebulous “improvement in development velocity”, but you’re not going to notice that as an end user.

                  1. 2

                    Meanwhile, updating Firefox gives you a “restart” button … that doesn’t restart. Great job.

                    1. 1

                      I think there are 2 types of users. The ones who just want to use their tool and might or might not at some point want new features. And the ones who constantly want new features.

                      I’d say I’m 90% in the first group. When I use a browser, e-mail client or whatever other tool I simply want it to not break. I make my use/purchase decision at the point in time when I test it. If it’s good, it’s good. I can’t remember when I last actively thought “man I wish this had feature X”.

                      It’s a bit different for libraries and stuff used to build other stuff, but then I’m usually also happy to do a major upgrade and have just-bugfix versions for the current major version.

                      1. 1

                        I almost never upgrade once software is working.

                        But especially if there is no clear changelog, e.g. it just says “bugfixes”. And especially if there is no easy path back.

                        Fuck no, get the fuck out of here, hypothetical software developer.

                        You want me to take a risk on my device, without a way back, for what?

                        Breaking something.

                        Telling me my device or OS is no longer good enough for your software.

                        Adding more adds or other shit I don’t want at all.

                        Modifying the UI, giving me more shit to deal with and figure out.

                        Completely redoing the whole UI, usually poorly, and giving me a half-assed barely tested release to test for you.

                        I’m a bit of a slow learner, I admit, but I do learn eventually.

                        I only upgrade software which is not abusive. Otherwise, if it’s already working, I’m not touching it.

                        Keep writing those updates, though. I’m sure someone out there appreciates them. Next time I get a new device, I may too.

                        1. 2

                          I’m slowly moving towards computing environments that enable me to trial a roll-forward before committing (eg nix, proxmox, qubes, docker) because I do want security patches but I really don’t want random shit breaking.

                          1. 3

                            My general solution for this is to have a VM inside which I do all my work.

                            This allows snapshots and, in theory, floating between hardware.

                            The desktop is left with video/music playback, VM management…

                        2. 1

                          I’m one of those types that want programs to behave what I tell it. And on Linux (sans SNAP, because F that), things behave for the most part.

                          On my machine, it’s Firefox, Minecraft, and Steam that don’t behave normally. And I know for Firefox is because of 0-days and all sorts of exploits. They don’t want to be caught with their pants down. So at least for security stuff, I get. But then there’s some janky voice addon, or web-* that can’t easily be turned off, or new firefox cramware like pocket.

                          But I think the absolute worst is my wife’s Windows machine. You look at it funny, and it’ll gobble all the bandwidth of the network and proceed to trash any videoconference. And it won’t inform you of anything, until you get a “shutting down” message. Doesn’t matter how many regkeys I’ve messed with.

                          The more I work on computers, I want a user-program based firewall to let programs have internet access. They shouldn’t, by default. Application creators have shown they’re untrustworthy with that right.