Please don't upgrade Docker without asking first
github.com
github.com
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.
Sure, underlying components are open source, but I've seen no other effort to glue them together in a cohesive, single-purpose package like Docker Desktop.
Keeping people on the latest version of your software has very clear benefits to both you and your users. Unfortunately, as we see here, it can also have downsides. Ultimately it's up to the developer to decide what trade off works best for them. Input from users is important, but it's not the users' decision.
I've had the position of saying that something desired will not be done with the only thing I could honestly say without airing private disagreements being "reasons", as the person I was talking to knew I also didn't think it made sense.
Deflecting with vague statements has also been a tactic I have used, hoping that they would not persist.
That's what all of us who have ever had to go out and work around annoying decisions want you to realize.
He clarifies a little bit further down the thread:
> It's not a bug because it's working exactly as designed. We're very aware that you regard it as a misdesign.
If a project / community has adopted specific definitions for given words such as "bug", "feature request", etc., then IMO you should not get mad at people for using them as defined.
You may feel strongly that the auto-updating feature is a terrible idea in application, and you may even disagree with this project's decision to define a "bug" as "something that isn't working as designed", and that's fine. But I don't think it suggests that Stephen does not understand the issue, or did not read the thread.
And also, who says that mis-designed features aren't bugs? In this case, they designed a bug, and shipped it.
Autoupgrading might totally be a misfeature for your usecase, but it's how this program works. If you don't want it to do that, then uninstall it.
Or how it doesn't work, in this case.
> If you don't want it to do that, then uninstall it
And use what? There are no alternatives. Should I quit my job while I'm at it? Maybe I can just downgrade it .... oh wait ..
This broke production environments. That is a bug.
Bugs can introduce new development to meet acceptance criteria, if that is the right way to solve the bug.
Edit: kelnos accurately pointed out that I should have said development environment, and not production.
Presumably it also would flawlessly autodeploy the fix for that bug when it gets released.
So, there was a bug. A UX bug. Bugs aren’t software-exclusive.
I may be misunderstanding your point.
What's the point of having versions if you can't install them?
I think auto-upgrades of Docker are totally fine if it makes the lives of Docker devs easier and they can concentrate on more meaningful things. After all, the majority of the user base is not paying a single cent for the software. If a paying customer complains about auto-upgrades and wants to buy into their own support branch, that's a different story.
I've no idea if Docker's auto-upgrades also include minor an major versions, though.
This broke development environments. I really hope no one is using Docker Desktop running on Mac in production.
Not to trivialize the issue; lost productivity due to a a bug in a software update sucks. But people are not getting irate customer phone calls or losing revenue because of product downtime due to this.
It could be an indirect cause of irate calls because there’s a bug in production but the dev environment is broken by Docker’s auto-update so the devs can’t work on a fix for the production bug.
If it breaks even just my desktop working environment, and that impairs my ability to remediate a production problem, it's causing production downtime. Dev environments aren't decorative.
It benefits everyone if we improve software. It benefits nobody if everyone never reports their problems and simply quietly disappears and quit their job when something in the software they use needs to be fixed -- and I think it's pretty obvious that course of action is unreasonable and unworkable.
If you don't like the way that convenience is provided to you, then yes, you don't need to use it, and that is not tantamount to telling you to give up and go move to Canada.
The developers have chosen to implement autoupdating.
That meant that in December they pushed a version which had a bug in it, and users received the bugged version. Then they pushed a version with a fix, and users received the version with the fix.
That doesn't seem worth throwing a tantrum over.
- Docker for Mac has no alternative.
- Docker for Mac periodically ships bugs that make the program (and Docker itself) unusable.
- Devs cannot downgrade -- so their workday can be productive and not wasted on fighting with the tool.
You seem to be implying that people are entitled. I suppose technically this can be true but Docker for Mac is viewed as a critical infrastructure and thus people should have venues to make it workable even if the latest version is bugged. They ask for choice and are against force automatic updating to the latest version.
> That doesn't seem worth throwing a tantrum over.
Such emotional reactions cast a doubt on whether you are arguing in good faith.
Hell, a huge chunk of dev work is rethinking design decisions that are misguided/under specified/break things because you only see these issues once you start having to implement details.
someone else said "this is how you get forked" and they are right for foss things, but docker isnt so trickier
It would be reasonable for people to build better tooling around rkt, or jump on the podman bandwagon
On a side note, I see plenty of developers click the "Remind Me Later" button over and over and over on the update dialog for their dev tools (and even OS). As a pathological example, I noticed one of my coworkers running a 3-year-old version of IntelliJ IDEA recently when he shared his screen on a Zoom call. But people who don't even install patch updates for months is common as well.
Docker Desktop is produced by a for-profit company, and while it is free of charge itself, it is a key customer-facing part of an ecosystem Docker monetizes by selling subscriptions to services which it leverages. It's not some solo developer’s spare time project, and if Docker wants to be a viable business, it won't be treated like one.
It's not like the developers of some OS-es didn't work hard for users to have this attitude. Nowadays you better wait at least a few days before you give in and agree to update your system, it's just a sane approach to risk control.
If these people are paying for Docker Desktop, then, sure, maybe they're entitled to upgrades and support on their terms. But if they're not, I'm completely sympathetic toward developers trying to reduce their (unpaid) support burden.
Yes, this might turn people off and hinder adoption, but that's their choice to make.
EDIT: But seeing this in Docker doesn't surprise me at all. It's this kind of project that knows better than you. Compare this with general purpose tools such as SSH, Git, gcc. There's nothing special about projects like Docker and Snap and they will get eventually replaced by projects that expose more knobs to fit (private) use cases of other users.
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.
>For those with this pain right now: I think installing Docker Desktop 2.5.0.1 is the only solution.
Well that sure backfired.
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.
In my experience the overwhelming majority of bug reports do not include the version.
A bit rude, but it gets the point across...
Here's a process I've done, it may sound like a lot of work but it goes quickly if your tools are set up properly:
Require versions and logs with bug reports; checkout the tag for that version; build; reproduce the issue and if it doesn't reproduce on the latest build then it might've been fixed (can ask other devs, reference changelogs and recently closed issues, git blames in that part of the codebase to lead back to PRs, etc.); then investigate.
If the bug is already solved in a newer version, you can close the ticket or provide a hotfix build with the fix if it's low effort (big architectual changes are a no-go; now you have a reason why or why not to provide a fix).
If the bug hasn't been solved, you can fix it for the customer and forward port that to the latest dev branch. Two birds with one stone.
> reproduce the issue and
To be fair, just reproducing an issue can sometimes take days.
Because that still requires time to deal with, especially if you have free-form support avenues, like a Slack channel. If someone comes in and pastes a stack trace, I still have to take time to ask them what version they are using, and tell them to try on the latest version. And no amount of bot autoresponses will ensure you don't have to get personally involved.
Yeah, if it's something like GitHub Issues, you can set up an issue template that requires the version number, and a bot that checks all submissions and auto-closes if the version number is missing or not the latest. But at least for one project I work on, it's rare that someone goes to the issue tracker first before asking for help in Slack.
But the whole goal of auto-upgrading is to avoid the spread versions
Maybe you wouldn't have so many versions if you slowed down and actually took the time to make sure each version you do eventually release was more stable...?
With a lot of "modern" software, I feel like it's not just "move fast and break things" anymore, it's "keep moving and breaking things". In particular, certain types of software like browsers and OS invoke feelings of dread upon each update: "what did they break/what user hostile crap or other unwanted changes did they try to sneak in this time?"
Docker is, like a lot of other software, "foundational" in that its error-free operation is relied upon by many. How can developers build anything reliable if the foundations are shaky?
Maybe that's partly why retrocomputing is so popular. With something like a C64 you never have to worry about the platform changing, so you can spend all of your energy on solving the problem you had in mind, instead of the ones created by the platform trying to shift under you.
At least we don't have to worry about a Skynet I guess.
People who use this saying to keep moving forward should be aware of the fact that Facebook no longer use this (). I've heard "Move fast with reliable infrastructure". In other words, Facebook invest massive amounts of money to allow them to test and deploy new features without breaking the whole site. If you don't want to make that investment, you don't get to move fast without breaking things.
I'm not in Facebook, above information is from a podcast. If you are from Facebook, I'd love your input
Considering that containers and orchestration is still a rapidly changing field I disagree with this assessment.
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...
[1]: https://github.com/docker/roadmap/issues/183#issuecomment-79...
Which of course punts the concern from "Docker Desktop is installing potentially-broken updates without my consent" to "Docker Desktop is consuming network bandwidth - which might very well be metered - without my consent" - that is, hardly an improvement.
If the Docker folks could not be actively hostile to user experience for two seconds, that would be great :)
Oddly, stephen-turner claims that Sparkle is part of the reason it's taking some time to fix the issue. Direct quote:
> As said above, we're working on this: we're planning to download the update in the background and then give the user the choice whether to update to it on next start. It's taken a little longer than we hoped because the Sparkle framework we use on Mac doesn't expect that workflow: once the update has been downloaded, it wants to apply it without confirmation at next shutdown. We are keen to retain the invisible download but give the user a choice whether to apply it later.
It's hard to understand why they're struggling with a problem that seems to be solved by every other app that uses Sparkle...
- [0] https://github.com/docker/roadmap/issues/183#issuecomment-79...
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.
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".
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.
Adding a new package often triggers a re-resolve of all installed versions. Whether any updates happen at that time depend on how you've set versions bounds: e.g. https://stackoverflow.com/questions/48911625/npm-how-to-inst...
> the conclusion that auto-updates are a "better experience"
I don't know that they are necessarily a better experience overall, but it is certainly a worse experience to run into a bug or limitation that has already been resolved in a newer version.
There is a class of developers who feel very, very strongly that updating the user's software should be their decision, and not the user's. For the lazy or reckless user's own good, or whatever.
Edit: and I can’t help pointing out the irony of this being a consideration on a thread about Docker.
"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."
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.
Heck within the first few weeks of dockerizing our system at a startup (c. 2015), they introduced a backward-incompatible change to docker-compose that we only found when onboarding new employees -- the exact thing it's supposed to be for!
As tempting as it is to weigh in publicly on such matters, the best way for a developer to get results is often to say little in public and try to resolve the issue behind the scenes (as was apparently done here).
"How should we improve user experience? I know! Let's ruin user experience by forcing users to signup for an account they don't actually need! Brilliant!"
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 :)
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.
And this applies outside of software, too. Apple dropped the headphone jack, so guess what every other phone manufacturer wants to do? Samsung shoved ads into its smart TVs, so guess what every other TV manufacturer wants to do? So much for product differentiation.
It does by default, using roughly the same method. Gratefully you can turn it off.
Edit: gratefully in terms of peace of mind. I’ve only ever been pleased when I do finally let VSCode updates install.
Looked over their FAQ, and yeah, I'm super surprised that you're right, I don't remember ever turning it off.
By your definition, all viruses, malware, and ransomware are simply bugs.
Defect!
I am talking about the malware itself...
Pretend you write malware. Your malware does what you want it to do: it destroys data. Is the data destruction a bug? Nope. Not a defect, either. It's a feature; the intended effect.
Docker intended for Docker Desktop to auto update. So, it's not a bug, but a feature. Misguided feature? Sure. User-hostile feature? Yep! It's a feature, anyway.
Atleast when you get a prompt you know why stuff fails afterward. Debugging silent auto update issues is a nightmare.
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.
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.
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.
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.
You don't notice all the updates that are flawless.
It pretty much always just... works. New exploits just get patched out.
Of course, with the exception of the new "Gutenberg" editor, WP has always been ultra conservative in terms of major usage change.
"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."
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).
> 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.
> 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!
I am NOT your beta-tester.
(See also “other duties as required” in your job description...)
SaaS is literally you being subject to unpredictable A/B tests, UX changes, API changes, etc. This is what people signed up for. Automatically managed updates. I don't know too many places that don't rely on some sort of cloud service/SaaS today. Can Github even hit two nines availability this year, I wonder. But we all sit idle while they fix their shit for the 8th time this month.
lol I'm sorry, but what? this is total amateur hour
I'm in total disbelief - this isn't how you deliver 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...
More performant, better battery life and keeps your crotch from igniting.
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.
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.
Having one company be totally in control of runtime environments just isn’t robust. There are just too many scenarios where some issue they face internally could cause a massive disruption.
And when I looked I didn’t find any Docker alternatives, so I just stuck with plain old Bash scripts, rsync, running the app in Ubuntu.
I use them for everything where I can. Years of docker in production has burnt me out. I've come to loathe its design and anti-patterns. There's also just plain ridiculous stuff like making people signup for an account to download it on windows/mac
It might do, I haven’t had the time to investigate. It was 3-4 years ago when I had to make the decision. I remember there was some open source tools mentioned on some websites, but I certainly didn’t get the impression it was very easy to get it working.
I guess that was the appeal of Docker, they had done all the difficult part and created a product. But then it’s the ‘all eggs in one basket problem’, and other stuff you mentioned like the signing up for accounts etc.
I had so many other things to learn and build at the time, that the extra complication of containers didn’t make sense.
If I was in a situation where I was building out a fresh site I would for sure give LXD another look.
That's a decision that needs to be completely reversed, and the executives that approved that need to be dismissed immediately.
Like, each type of application I have to run in my fleet needs the right environment, with proper settings, packages, etc. And when a developer at the company needs to work on that service locally, they need a prod-like env spun up quickly and simply that they can easily work in.
There's many ways to do this, like "one prod box and ssh" but they all have tradeoffs...
Is there a file format like "docker-compose.yml", where I can describe a handful of Jails that can talk to each other in their own virtual network, and that sets up a handful of services exactly as I describe?
Ideally, a Windows user, a Linux user and a Mac OS user check out this file, run a command ("voodoo up") in the directory of that file, and have a VM with the FreeBSD jails setup running exactly as described in the file.
I'd pay money for that.
- FreeBSD style jails already offer docker config, but here is an article showing a few basic things going on, notably the Network Access section has a FIXME by it: https://bsdwatch.net/articles/jails-as-virtual-servers
- For network isolation it looks like this package could help: https://klarasystems.com/articles/virtualize-your-network-on...
- For reproducibility you can use the FreeBSD package builder: https://docs.freebsd.org/en/books/handbook/ports/#ports-poud...
- FreeBSD has a Linux compatibility layer. FreeBSD running Docker: https://www.gamsjager.nl/2019/01/11/How-to-run-Docker-on-Fre...
- This thread is interesting: https://forums.freebsd.org/threads/docker-is-dead.69955/page...
I am going to explore this more in the coming weeks as I play around with FreeBSD.
Heroku's always nice and simple for getting stuff out there.
Vagrant + a provisioner of your choice is still good alternative and works solidly for local development if you want to keep developing away from the local filesystem.
There are quite a few options that don't involve docker at all, it just takes a little research to remind yourself that there's a world outside of the one presented by docker :/
Edit: s/pacman/podman/
Unless you’re on a Linux, where podman and podman compose _almost_ are an equivalent.
But then, you can easily rollback a version on most distributions, and you don’t have the auto update in the first place.
Looks like a PM somewhere learned a crucial product lesson today.
- A beta stream that's one release ahead, which tends to be selected by web developers and other whiny^H^H^H^H^H demanding users.
- Gradual release of new versions, starting with something like 1% of users, then 10%, then 100%.
- Significant changes are behind run-time flags (chrome://flags), and ship disabled by default. After one or often several releases, where it can be optionally enabled, it becomes enabled by default, with the ability to back out if something goes wrong. Finally, only once it's been successfully enabled for several releases, the flag and the old code can be removed.
- Nobody minds if a feature doesn't make it in to a release; there'll be another one in month or two. There's no pressure to cram in something half-baked to meet a deadline.
Probably a no-win situation overall for the dev team, however.
Is it possible to download docker source from github.com, git checkout some version tag, build, and viola?
On windows one could even use docker in WSL2.
Every version after that either doesn't start [1] or makes 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.
Currently it’s explaining a complicated install with 15 steps vs one click on Docker Desktop EXE. So podman will never be accepted in workspaces.