[HN Gopher] Please don't upgrade Docker without asking first
___________________________________________________________________
Please don't upgrade Docker without asking first
Author : timmytokyo
Score : 122 points
Date : 2021-03-22 21:19 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rubyist5eva wrote:
| shenanigans like this is why I switched all my projects to use
| Podman, docker is just trash software
| rattray wrote:
| Auto-updates _by default_ are great, but having no way to opt out
| of auto-updates (or at least, an update to a given known-bad
| version)? That 's pretty bad.
| akvadrako wrote:
| Agreed. For example iOS and stock Android, terrible designs.
| anaerobicover wrote:
| You can opt out of auto-update on iOS (for both individual
| apps and the OS).
| rightbyte wrote:
| Why would you want auto-updates though. It just breaks your
| stuff. Grandmas' or devs' alike. Noone benefits expect apps
| with user hostile functions being pushed without a way to say
| no.
|
| Atleast when you get a prompt you know why stuff fails
| afterward. Debugging silent auto update issues is a nightmare.
| rattray wrote:
| On average, updates make stuff better. Getting them
| automatically and quickly is, on average, a good thing.
|
| Only when that becomes untrue for a sustained period of time
| should you turn off updates, but at that point, you're just
| sticking to a single pinned version until you're able to
| switch to a competitor.
|
| Vendors who just keep pushing user-hostile shit should lose
| customers, not (just) updaters.
| rightbyte wrote:
| Ye well I am fine with auto updates as long as it is
| possible to disable (without hacks or esoteric config
| settings in GUI apps). The convinence of having the
| computer click "install latest version" in a prompt for you
| is minimal.
|
| I think it should be the user's choice. This trend in slow
| rollouts to see what breaks and using users for beta
| testing is annoying.
| capableweb wrote:
| I don't think what you're saying is necessarily true.
| Browsers for example are very resilient at this point, and
| seem to handle auto-updates just fine. Worst case scenario
| you can use a different browser for a couple of hours. The
| upside is that auto-updating works in most cases and users
| hardly notice, while you're shipping security fixes straight
| to them.
|
| With developer tools it's different. Your tool stops working
| and suddenly you cannot work. You often can't just change the
| tool either, without having to rewrite stuff. For this, it's
| necessary that versions stay the same until we're ready to
| upgrade. Same goes for libraries you're using and so on.
| TylerE wrote:
| Seems like you've got a bit of reverse surviorship bias here.
|
| You don't notice all the updates that are flawless.
| thitcanh wrote:
| Really? Autoupdates are why we don't have to code for Chrome
| 12 today. Autoupdates are awesome, just not for business,
| sometimes.
| sjwright wrote:
| Browsers have the benefit of _massive_ interest in their
| beta releases. This substantially reduces the number of
| breaking changes which make it into auto-updated versions.
|
| Perhaps Docker could learn from this and only auto-update
| to versions which have been used by a large audience for N
| weeks with no regression reports.
| DubiousPusher wrote:
| Isn't the widely accepted solution to this to just have a limited
| number of LTS versions?
| umvi wrote:
| Yeah, I like the way Ubuntu handles it. Basically, if you come
| boo-hooing in Issues and you are using an ancient non-LTS
| version, you'll be asked to install an LTS (or latest) version
| first.
| rattray wrote:
| If I were to start a company tomorrow, what should I use instead
| of Docker? Heroku and dev laptops' filesystems?
| yepthatsreality wrote:
| FreeBSD
| rattray wrote:
| With VM's for local development? What to use for ensuring the
| right package versions are installed etc? Terraform?
| bojo wrote:
| I believe they were alluding to jails as the alternative
| here.
| gugagore wrote:
| https://github.com/docker/roadmap/issues/183#issuecomment-74...
|
| > Blocking outgoing network connections to desktop.docker.com can
| keep you on on the functional 3.0.1 by not allowing the auto-
| upgrade to 'find' the broken 3.0.2 version, this can be used as a
| temporary patch. You'd need somethling like Little Snitch to
| achieve it, but at least you won't lose a Monday.
|
| I use Little Snitch, usually on "Alert Mode", and I almost
| breathe a sigh of relief whenever I block an automatic outgoing
| connection to an upgrade server. It can be distracting and
| annoying to block connections at a granularity to keep the
| application working correctly, and sometimes I get a bit fed up
| and just allow all connections, but usually temporarily. Since I
| even want to be consulted for outgoing network connections, you
| bet that I want to be consulted before a software upgrade!
| brnt wrote:
| Try podman, I really like it.
| alibarber wrote:
| I've also been using it and found it to be really good. Has
| helped me understand much more about containers and I'm a fan
| of its approach. Buildah is also a powerful tool.
| kevinmgranger wrote:
| How does that help users on macOS?
| broknbottle wrote:
| https://developers.redhat.com/blog/2020/02/12/podman-for-
| mac...
| SilverRed wrote:
| Docker does not run on macos. It runs in a VM on mac. Podman
| also runs in a vm on macos.
| heavyset_go wrote:
| Last time I tried it, particularly using it for a Docker
| Compose replacement, it certainly wasn't the drop-in
| replacement that had feature parity with Docker that it was
| promoted as.
| lopatin wrote:
| I'm astonished by the pushback from the Docker devs on this.
| rflay, ThomasNegeli, and Nuru did heroic work by gently and
| thoroughly explaining why mandatory, automatic updates are
| unacceptable for a dev tool. I would not have been so patient.
|
| The fact that they had to hold the maintainers hands through this
| is disappointing. "it's a feature request not a bug" shows
| Stephen did not even understand the problem he introduced. Either
| that, or he didn't read all the comments before him.
| phendrenad2 wrote:
| This is how you get forked. They're risking the business on
| some dumb dark pattern here.
| aftbit wrote:
| It looks like they've listened and decided to add a prompt before
| updating:
| https://github.com/docker/roadmap/issues/183#issuecomment-79...
|
| Personally I don't see why auto-update is the job of the
| software... why not just use a system-wide package manager? I
| suppose on Mac or Windows, that means using the Store, which
| heavily restricts what software can do. How shortsighted...
| wlesieutre wrote:
| Outside the Store, most Mac software uses Sparkle for updates,
| which gives you a nice UI with patchnotes and a choice to
| update or not (or even opt-in to automatic updates if you're
| feeling brave): https://sparkle-project.org/
| gugagore wrote:
| > why not just use a system-wide package manager?
|
| Here's a question:
|
| Even supposing all we had is e.g. Debian distros, why does
| Docker Hub exist? Why not just host all the artifacts in some
| repository and allow `apt-get install docker-image-$image-
| name`?
|
| Why do so many programming language ecosystems use their own
| package management (Python's PyPi and pip, Rust's crates,
| Node's NPM, ...)
|
| I'm open to people's thoughts on the way in which this
| following analogy doesn't hold. But I think the general (and
| imo deeply unfortunate) answer is that the software can provide
| a better experience if it handles these things like self-
| updates, even if it shouldn't be its "job".
| bojo wrote:
| > Why do so many programming language ecosystems use their
| own package management
|
| Because then you have to support maintaining your ecosystem
| in a dozen or more variations of OS ecosystems. Easier to
| bring your dep manager to the OS than the other way around.
| xxpor wrote:
| >why not just use a system-wide package manager?
|
| I mean lets not pretend that's a good choice for either devs or
| users either. From the user side, you're a the mercy of how
| fast your distro decides to package new versions. For most
| things that's fine, but for your main product you might want
| something newer. Of course devs can setup their own repos but
| then the devs have to do additional packaging, host infra, etc.
|
| From the dev side, getting packages accepted into various
| distros can be a pain in the ass. Just look at the recent
| blowup around the Python Cryptography package when they decided
| to add Rust and Gentoo's complaints.
| gugagore wrote:
| Do you have a reference for your final example?
| tim-- wrote:
| I think the grandparent is referring to this?
| https://lwn.net/Articles/845535/
| kzrdude wrote:
| Look over to the snap store on Ubuntu, and it's hard to stop
| updates there too, they just update when they want.
| 2OEH8eoCRo0 wrote:
| alias docker=podman
| olivierduval wrote:
| What's surprising me most is how much the devs/IT guys are
| considering that the computer of their users belong to them and
| that they can choose to do whatever they want because they write
| the software !!!!
|
| How is the "auto-updater" different from any malware calling
| remote website or mining bitcoins???? In both cases, the dev
| decided what must happen with the users computer without its
| consent !
|
| Even Windows allow to disable updates...
| slig wrote:
| Has version 3 improved docker on macOS in any way?
| purerandomness wrote:
| No. We're still on the last stable version (2.5.0.1)
|
| Every version after that either doesn't start [1] random
| containers miraculously stop working. The 2.x version has your
| CPU burning, but that seems to persist in 3.x [2] I stopped
| trying after they pulled in the auto-upgrade feature. Our team
| has no time playing bug-hunt easter egg at random times.
|
| I honestly don't comprehend how this software gained such a
| wide adoption on Macs. Docker on Linux works flawlessly
| meanwhile.
|
| [1] https://github.com/docker/for-mac/issues/5146 [2]
| https://github.com/docker/for-mac/issues/5116
| smoldesu wrote:
| No, and it's very likely that Docker may never improve very
| much on MacOS. There was already no shortage of trouble on x86
| MacOS, I doubt the switch to ARM (and ostensibly, Big Sur) will
| make things any easier.
| devinrhode2 wrote:
| I understand where the docker devs are coming from.
|
| Is it possible to download docker source from github.com, git
| checkout some version tag, build, and viola?
| jlv2 wrote:
| This response totally misses the point.
|
| "Sorry about it, we rushed a bit the last update and introduce a
| severe bug. I'll try to fix it today and if I cannot, rollback
| last grpcfuse patches."
| coldtea wrote:
| They also explain why the think what they do is the way to go,
| nonethless, in the very next paragraph.
| elliotpage wrote:
| An addendum by another developer later on doubly misses the
| point:
| https://github.com/docker/roadmap/issues/183#issuecomment-75...
| Zealotux wrote:
| It feels like an habit of the Docker team, they always try to
| defend their anti-user decisions with vague and uninspired
| corporate bs. They're barely trying. Another classic:
| https://github.com/docker/docker.github.io/issues/6910
| p1necone wrote:
| Wowww: https://github.com/docker/docker.github.io/issues/6910
| #issue...
|
| What the hell does "Docker's new direction to go back to its
| roots and focus on developer tooling" even _mean_? Docker
| _is_ developer tooling, that 's the whole product. That's not
| "going back to your roots" that's just doing your damn job.
| protomyth wrote:
| Well, the _Also I 'm going to move this into the roadmap, as
| it's a feature request not a bug._ is just as bad. If the
| process broke my desktop then it is a bug.
| capableweb wrote:
| Yes, it does. But your comment also misses the conclusion of
| the discussion:
| https://github.com/docker/roadmap/issues/183#issuecomment-80...
|
| In the end, seems they are changing course after listening to
| user feedback. Clearly auto-updating works in some contexts,
| but not in others, and now we can all learn from it :)
| dvt wrote:
| > Clearly auto-updating works in some contexts, but not in
| others, and now we can all learn from it :)
|
| I think the point was that we all knew auto-updating doesn't
| make sense in the context of developer tools. I'd even argue
| GitHub Desktop shouldn't be auto-updating. As a matter of
| fact, VSCode doesn't, and my _compilers_ certainly don 't.
| capableweb wrote:
| Agree. "I was just following a successful model" is not the
| right way to approach engineering, without understanding
| the trade-offs and it seems that step was missed when
| implementing it in the first place.
| protomyth wrote:
| Auto-updating does not work in any context because you can
| seriously break the end users stuff with no recourse. It
| needs to ask, always as you don't know what else is going on.
| Animats wrote:
| Resistance is futile. You will be upgraded.
| MattGaiser wrote:
| Companies are in a hard spot here.
|
| Don't upgrade and you get blamed even if the software is very
| out of date.
|
| Upgrade automatically and other groups get mad.
|
| Seems like you need to default to auto update but have an opt
| out.
| [deleted]
| magicalhippo wrote:
| > Seems like you need to default to auto update but have an
| opt out.
|
| We have that. Our software auto-updates, but when you start
| our program you get a launcher where you can select one of
| the last five minor versions for each available major
| version.
|
| Typically the next major version is made immediately
| available and active in the test environment, while a "boss
| user" gates them in prod.
|
| When setting a new major version as active, the previous ones
| are still available for a long time, along with any potential
| new minor versions for those.
|
| This has made our life so much easier, since any critical
| issues can almost always be worked around by the user simply
| launching a previous version, either minor or possibly major.
| So we can be much more aggressive with pushing out changes,
| which our customers also appreciate.
|
| It's not perfect but works very well for us and our customers
| seem happy.
|
| It does require us being careful when making database schema
| changes, or similar potentially breaking changes. But a lot
| can be handled quite transparently in the database (using
| views typically) or through code, and our database upgrade
| tool can also migrate data as a last resort.
| airhead969 wrote:
| Join us or your API will stop functioning.
| f430 wrote:
| Question, why do we use Docker?
| purerandomness wrote:
| Vagrant could have easily won by supporting Linux containers,
| and improving the developer experience.
| yepthatsreality wrote:
| Brand recognition created from saturation of bloggers writing
| how-to guides about it.
| jerhewet wrote:
| Please don't upgrade ANYTHING without asking first.
|
| I am _NOT_ your beta-tester.
| coldtea wrote:
| Well, big chance that you're not their paying customer
| either...
| bigiain wrote:
| Ummm, I have some bad news for you...
|
| (See also "other duties as required" in your job
| description...)
| jchonphoenix wrote:
| Your response is dripping with entitlement.
|
| You likely don't pay for Docker and do not provide any
| beneficial relationship to Docker. Why should they be beholden
| to your opinions? If they wanted to ship you buggy software,
| that's within their right. You then have the option to decide
| whether or not you want to use it. That's within your right.
| king_magic wrote:
| It feels like your response is dripping with a lack of
| exposure to the kind of insane enterprise-wise nightmares
| that auto-upgrades with breaking changes cause.
| kazen44 wrote:
| there is a reason many ops teams prefer to not run the
| latest and greatests bleeding edge, no matter what features
| they bring.
|
| Breaking changes in some cases can be a real problem.
| [deleted]
| qeternity wrote:
| Docker for Mac is a dumpster fire. We gave up on it a year ago.
| There are loads of hot-reloading dev-stack-in-the-cloud solutions
| nowadays that anyone who can avoid local Docker should.
|
| More performant, better battery life and keeps your crotch from
| igniting.
| Swaglord333 wrote:
| Amen
| sdfhbdf wrote:
| There should be (2020) added to the title
| simias wrote:
| >But the whole goal of auto-upgrading is to avoid the spread
| versions, it's a mess to investigate when you have reports from 1
| year old version, that's the main reason why we choose to do
| that.
|
| Why not just outright reject issues on outdated version of the
| software? Decide that you won't support versions older than x and
| roll with that. This way the users can consider that when they
| weigh the risks of updating.
| kazen44 wrote:
| > Why not just outright reject issues on outdated version of
| the software? Decide that you won't support versions older than
| x and roll with that. This way the users can consider that when
| they weigh the risks of updating.
|
| i don' t understand why this is not something more companies
| do.
|
| Most operational systems (networking equipment, server
| equipment etc) have release cycles, in which current version -2
| is the usual schedule in regards to support.
|
| Or just do it the way openBSD does it, and only support the
| last two releases of the software.
| throwaway823882 wrote:
| "But the whole goal of auto-upgrading is to avoid the spread
| versions, it's a mess to investigate when you have
| reports from 1 year old version, that's the main reason
| why we choose to do that."
|
| I see this all the time, especially in open source products. A
| vendor decides to screw over its users because the vendor wants
| less work and doesn't feel like finding a better solution. And
| they usually get away with it, because big open source projects
| are incumbents that are very hard _not_ to use.
|
| If you make a product, _please_ prioritize solving the user 's
| problems and pain over your own. Not only is it the compassionate
| and ethical thing to do, but it also helps engender goodwill for
| your product. People often choose a product solely because of
| their feelings for it (branding 101).
| gugagore wrote:
| You went from "open source products" to "open source projects"
| , and I'm confused about your point. Is Docker an example of
| both an open source project and product?
|
| > If you make a product, please prioritize solving the user's
| problems and pain over your own.
|
| I'm not sure I understand the context under which you want this
| prioritization. Just asking for clarification.
| renewiltord wrote:
| Ah, I understand the devs here, evergreening means you don't have
| support spread. But it's a dev tool and pinning is a crucial
| feature for devs.
|
| Looks like a PM somewhere learned a crucial product lesson today.
___________________________________________________________________
(page generated 2021-03-22 23:00 UTC)