People asked for the feature. The company gave a reasonable explanation of why they didn’t want to do it—-that it would increase the burden on them. As a very reasonable compromise they coded up the feature and are offering it to actual customers. That way they can offset the extra burden with money, again from actual customers. Nothing about this is unreasonable except the massively entitled whining.
This is not a feature, though, especially not a new one. This is just asking for payment for the software to not do something to your machine. This kind of behaviour so far was only present in ransomware.
All the code required for this to work was already there. They only spent developer time changing it to only be available to Pro users.
You can rationalise this all you want, but this is just hostile, desperate and lazy behaviour from a company that's too desperate to make money, but is has continuously proven to be unable to come up with better ideas for attracting paid users. As others have mentioned, they got millions in funding so far but still have no idea how to make money.
Had it been announced a month earlier people would be sure it was an April Fool's joke.
Crazy how "not doing something unwanted to my computer" is considered a feature.
I remember when the user was in control of their own computer, not rando 3rd party companies. I issue a command to the computer, and the computer executes the command. If I want to update a piece of software, I update it. I guess this is a dinosaur mentality now.
This whole "allow the software to do whatever the developer's company wants or stop using the software" trend is pretty nasty.
No one is making you run Docker Desktop. It is not holding you hostage. There are alternatives in this very thread. Comparing it to ransomware is absurd.
People asked for the feature to be disabled. There was a lengthy discussion in GH [0] aptly named "Please don't upgrade docker without asking first" few months back regarding why this shouldn't happen (auto updates, that is).
Considering that the team that codes the software acknowledged they screwed up [1] having to pay for this I have to agree with the comment that says this amounts to ransomware. "Pay us or risk getting f*ked up by our updates".
I don't see it that way. The team has released new versions with major issues on a fairly regular basis, and this was exacerbated by having a forced auto-update that could only be resolved by dropping down to v2.5. So they pushed people to an older, stable version they didn't want to support.
To my mind, the decision here shouldn't have been to make people pay protection money to stop a new release breaking their setup. They could make the whole damn thing paid-for instead and I'd be happier with that.
There is clearly something missing in their development and QA process that causes this auto-updating to be so visible and painful. They could have kept the feature as-is and worked on making sure new releases were solid, while also having a mechanism to revert.
I have no problem with my browser updating itself that way, as I never notice if something broken and got rolled back in the canary stage.
To be honest, avoiding criticism by whining about entitlement adds no more to the conversation than pure entitlement itself. I can't see any purpose it serves other than to start a flame war.
They didn't just put out Docker with a sign up that said "free stuff" though. They actively solicited the users; they told the community "Hey, use our software, you can trust us". If you do that you do have an obligation.
It's like, if you beg your friend to let you give them a lift and don't show up, you can't turn around and call them a "choosey beggar" because the lift was supposed to be free.
The response in that thread isn't _remotely_ reasonable, of course you can't make a developer tool like this auto-update.
Or give away free tree planks to build houses, but then later you say now everyone has to pay for the planks, or you'll magically change the planks to an a bit weaker kind of tree.
I don't understand- people aren't asking for Docker desktop developers to support old versions of its software in perpetuity; people are asking to forego an auto-update at their own risk. What burden do you think this places on the Docker desktop developers exactly?
That's how I understood it. It would be very entitled to say "Don't force me to update and support my old version until I'm ready". This move seems like the opposite of what we all expect: There's a new version, the one you are on is EOL, upgrade or beware. What was wrong with this, other than it didn't support their revenue goals?
There is a popular modern form of thought that developers should be the ones to decide which versions of their software are running sheets anywhere and what versions they are; that they are entitled to that level of control, and should exercise it because their users cannot be trusted to make an informed decision about running outdated and insecure software.
I think it's paternalistic and egotistical but the usual counterpoint is grandma getting a virus because Windows is unknowingly out of date. With developer tooling that holds a bit less water IMO.
Sure it's in their right to do, and we can't expect to get everything for free, but making "skip update" a paid feature? How tasteless is that, do we really want to defend that? You see that button as a free user and its a bit of a slap in the face, isn't it. It doesn't make me want to pay, it makes me think the company is completely out of touch. I'd rather uninstall and look for alternatives, then pay for skip updates.
> it makes me think the company is completely out of touch
As interest rates come up off the zero bound companies are increasingly going to have to learn how to make profits again. The culture this is out of touch with is not long for this world.
After reading your comment I think I agree with you. Most software nowadays requires you to update if you want it to keep working. You cannot play an online videogame without updating to the latest version. There is typically no way to use a previuse version of a website or web app.
We have gotten more entitled and now when we see something that doesn't exactly meet our liking then we cry about it.
Not surprising honestly , docker has had more 300M of investment and still has no decent stream of revenue to pay their 300+ employees of SV.
The entire industry knows it , the Docker devtools brought containers to the mass but anything beyond that is being taken by Cloud Vendors / Redhat etc...
The Open Container Initiative contributed massively to make Docker the standard for container but also for other initiatives to replace it....
I personally believe it will also be its death sentence, seeing how many competitions are coming to get a better / simpler container tool chains add to that a lack of leadership after the founder left with a big check from the fundraising it’s just a matter of time before Docker goes bankrupt.
I believe WSL2 and Apple's virtualization framework may eventually kill Docker desktop. Both provide enough underpinnings for an open source solution to match the "ease of use" thing that makes Docker Desktop popular. That leaves Docker Hub as their last revenue stream.
Docker is basically at its core a shell around cgroups/chroots and filesystems. An overengineered shell and a confusing cmdline (which got better to be fair)
There's no "technology" there per se (on Docker "core"). Docker containers and Dockerfiles maybe? Which got eaten by other orchestration technologies there?
> Which got eaten by other orchestration technologies there?
Exactly , Kubernetes wants to remove Docker , and the Docker orchestration layer « Docker Compose » is completely dead.
Again the founder has left the company with millions , there is no leadership whatsoever it’s a just a zombie company losing millions every year until it’ll declare bankruptcy.
Google / Redhat are very well aware of that that’s why they are trying to decouple their product ( Kubernetes/ Openshift ) from docker before it officially become deprecated .
This would be fine if Docker wasn't literally force-fed to me over the past six years. It would be fine if their updates didn't totally fuck up my development environment, or completely break it from time to time... it'd be okay if on MacOS you weren't forced into using the desktop application.
shrug In the end I don't particularly care, I still run things like a caveman using processes, systemd units, disk images, and plan for my resource usage. I just find it mighty frustrating and think its short-sighted. Anyone who gets burned by a Desktop update (which they will, this happened to me within this last two months) isn't going to think "oh if only I paid them! Duh! Silly me." Instead it's going to seem like extortion... "Oh no! We broke your development environment! Whoopsie! If you upgrade to pro you can revert and continue working immediately!" Docker was originally "magical" and each year it becomes increasingly less "magical" I can only hope it is worth it.
I'd probably pay if this is an issue for me, just like I pay for other stuff that has popups for as long as you don't pay (Sublime Text, Little Snitch, etc). You're only getting Docker for free because you help them by upgrading automatically.
In fact, it's pretty cool that the only requirement is to stay up to date. Some companies make you pay to get upgrades, which is less secure in a way.
If someone is using Docker professionally, maybe not a issue. I don't mind paying for software, and it could probably be expensed - although I am sure there's some cases where it isn't true or is more complicated.
No, what's galling about this is that Docker is used so widely. What about open source projects using Docker? Now you have to apply for an "Open Source Plan"? Great. How does that even work with contributors if they just want to install Docker to check out the project? If a project I was working on depended on Docker, I'm not sure if I'd rather spend time figuring out how to ditch Docker vs fill out their application.
In this case though I agree dockers move is a bit bait and switch but I see thing like Sublime differently. In the 90s my uncle paid for winzip and I, as a dumb teen started saying how dumb he was. He didn’t skip a beat and just said: ‘they gotta eat those people’. It always stuck with me. Now that I have income, I pay for software.
One of the very few open minded answers I've seen so far. Of course people will complain, specially in HN. Even though I agree Docker's communication and execution wasn't the best, I applaud them since they're trying to monetize their work in a different strategy than the standard "support plan". In the end, I really hope this ends up working for them since it'll ultimately be reflected in the quality of the product.
If you ever launch a Linux version I'll be happily be a paying customer.
If you use Golang, check out their newly introduced "embed" using which you can embed all your files into a single binary. I used to use Docker (and Kuernetes for a short while), got frustrated and switched to Buildah/Podman for quite some time, and then now have switched to using embed.
I have a Golang server with Flutter frontend interacting using GRPCWeb. Now I'm able to embed the Go server code, all the Flutter generated web code, generated Protobuf code, TLS certs, all the other resources, EVERYTHING into a SINGLE statically linked binary with no external dependences. I.e., you just run the executable and it just works. Of course it interacts with an external Redis binary but by itself it's just a single executable that can just be deployed with an scp to cloud, how much easier can you get? You do need your own orchestration mechanisms, but packaging wise it seems great.
You had me until you said TLS certs. As a SRE, I'm fully onboard with single executable deployments, but you should treat your binary as public information - don't include private material, inject it into the environment at runtime.
Part of that is about the possibility of leaking your key, but the other half is that you should be running exactly the same binary in production and staging, and you should have different keys for each. Recompiling can introduce behavioral changes (even in a well managed build environment like Golang's where dependencies are versioned through version control tags and cryptographic hashes of those tags)
Podman[0][1] is an alternative daemonless containerization software. In my line of work, Docker poses too many security risks and Podman is the approved alternative.
Podman supports Docker images, Dockerfiles, and Docker-compatible CLI interfaces. Simply use alias docker=podman and you’ll never know the difference.
> Simply use alias docker=podman and you’ll never know the difference.
Unless you use Docker Swarm, in which case you'll lose access to simple orchestration that's not overengineered, unlike Kubernetes which you'll now be forced to use.
Or unless you use software that depends on the Docker socket being available (such as for Portainer, a graphical management utility [1]), in which case you'll lose the ability to use such software.
Or maybe you're one of the countless folks who tried using Podman but ran into a variety of issues that still haven't been addressed in many cases [2].
Or maybe you use Docker Compose and now have just lost the ability to run simple single node orchestration with YAML files, because Podman Compose is oftentimes flawed as well [3].
That's not to say that what Podman is attempting to do shouldn't be applauded, yet claiming that exchanging one set of leaky abstractions for another set of leaky abstractions is painless and will work for all of the people out there simply isn't true. I don't see Podman being a backwards compatible alternative to Docker on an API level, it'll simply kill it off eventually by supporting the OCI standard for containers and being a Kubernetes runtime at the lower level. Lots of people will need to re-engineer their approach to running containers and lots of time will be necessary to migrate away from Docker.
I share the same experience. Docker requires a root daemon, for full capabilities. Podman claims it can do the same rootlessly, reality is it almost does it all, evil in the details. Podman is to be applauded yes, but fabulous tools have been coded that rely on the socket listener,so aliasing podman will not work with that.
I think Docker is a fascinating enginnering story, an amazing tool to simplify and give life to groupc, which got released to the wild and sat while seeing competition offer decent alternatives that got adoption. They could have become the de facto container runtime implementation, perhaps swarm the de facto orchestrator, had they actually kept their distance ahead of every other competing alternatives. They could have charged almost all they want for enterprise licensing of a brilliant runtime and even more for the orchestrator. They failed. Seeing they hired 300+ employees and didn't maintain their pioneership is a testament of their incapability to run a business.
The hope for docker to survive is that the open source community forks and improves what's now called moby. As a business they missed the boat.
Doesn’t look like it would be easy to replace docker desktop with this? The big convenience part is that you don’t need to manage your own VM to run things in.
Worrying in this thread how few people seem to realize that docker desktop is not a) just another word for ‘docker’ or b) just an app frontend for running docker’s daemon in the background.
People seem to forget: Docker is a Linux-only technology.
If you’re running a non-Linux desktop OS like MacOS or Windows you need access to a Linux system to run docker.
So docker desktop on MacOS runs a Linux VM for you under the hyperkit hypervisor hosting a Linux OS running containerd.
On windows the equivalent involves managing a dockerd running inside WSL.
So since we are talking here about an app that embeds an entire Linux OS image, the patching surface area is going to be considerable - it’s not just got to be updated whenever docker releases a new version. It’s actually a minimal Linux distribution.
This also means people suggesting ‘alternatives’ to using docker are missing the entire value that docker desktop brings to MacOS and Windows users.
That’s... a little bit of a stretch of what it means to be a ‘docker’ container. It’s more a ‘Windows container services’ image, which requires a host Windows OS to run...
But yes, this further gets to the confusion about what ‘docker’ is vs ‘docker desktop’. Docker desktop for MacOS is certainly not going to just magically make it so you can run “docker run -it microsoft-windows” to get a CMD prompt on your MacBook though (but with a Windows VM and the right environment variables set, maybe?)
So, this is a terrible UI for the feature, but there is an X button which hides the dialog. Apparently it used to be called "snooze", from this blog post [0]. All in all, it's really gross that they put an "upgrade to not update" logo on the button, but the actual behavior and the underlying reasons for it make sense. Supporting older versions is hard, if you are going to indefinitely ban a version, it's going to increase the burden of support on Docker, so they make it a pro feature.
It's a desktop app. There's absolutely no obligation for them to support anything. Server side, they can just deprecate APIs, and whatever chat/forum support they have can refuse to support outdated versions. They can even charge for it! This is how most companies go about it.
This is nothing more than desperation and lack of ideas on how to generate money, which is very unfortunate.
A more honest route would be just to charge for the app, charge for premium support, or come up with new Pro features by collaborating with the existing user base. This here is just lazy.
Or they could have done the same as many paid programs: charge money for updates. Instead they choose to do the opposite, which makes one wonder how they came to the conclusion that not updating is more desirable for their users.
I wonder if this was good intentions by some developers getting subverted by an unaligned leadership ethos? (panicked? too $ focused? not enough user advocacy? no idea!)
I can easily imagine a few meetings that went something like this:
1. Security engineer meetings: "Flipping to default-on for automatic updates has been a major win for ~billions of people to help them mitigate the steady stream of 0-days exploiting gnarly web browser internals. Docker adoption isn't at that level but still big, and the individuals are pretty important. We should try it for our community too!"
2. Sales & CEO: "A ha, amazing! We can turn this into a $ win too. We've been needing more $ and conversion triggers for our install base now that we sold the enterprise business. Anyone with docker desktop on for > 2w is effectively a qualified leading with this, and this might finally tip them over to paid! $5/mo is nothing and this is just annoying enough that it might do it! (And if a developer won't pay for that, they're a freeloader / 1% / ... who'd never pay anyways...)"
3. PMs + designers + marketing + other user advocates responsible for trialing & trust: "Wait a minute! For their core workflows, developers need to easily control the versions of their tools in their environment. Messing with that willy-nilly for system version #'s breaks brand trust for our paid conversions!"
4. Sales & CEO: "Maybe. Let's try it and see. Overruled in the name of business experiments, and we can reverse course if it's too damaging!"
That's the majority Hacker News kind of opinion "Sales or the CEO fucked it up for the engineers" but another likely explanation is that the main source of frustration (forced updates for everyone) came from the engineering side because most developers hate maintaining older versions. Then someone said "you can't do that to enterprise customers, they demand to pick their own versions" which resulted in this button for the paid version.
This is a desktop app, so there's no need for engineering to maintain older versions. They can just ask users to upgrade to the latest before opening support inquiries. They can even deprecate old web endpoints if they want, and again ask users to upgrade to continue using.
I'm agreeing with you here for the first part: that's another great well-meaning dev explanation.
The ball-dropping is sales/product/leadership not being aligned on user advocacy. "Our velocity & sales > breaking user environments" means either the former is overly prioritized, or the people making decisions are too far from users (developers) to understand their daily needs. Managing docker versions for dev/prod drift isn't "1% of devs 99% of the time" but "99% of devs 1% of the time", so it's a real miss.
In an alternate org where the user advocates lead might look more like:
* <reject early on the current feature plan proposal as user hostile and instead...>
* free: default to auto-update (or not)
* free: flip
* pay ("Pro"): one-click to switch to another version, both forwards & backwards
* pay ("Enterprise"): centrally managed update schedule, version tracking, audit logs, etc. for all devs in your org
Folks there are some of the best, so I'm sure most of this was considered, and thus it's an org/process problem
Readit News
This should be cross posted to r/BeggingChoosers.
All the code required for this to work was already there. They only spent developer time changing it to only be available to Pro users.
You can rationalise this all you want, but this is just hostile, desperate and lazy behaviour from a company that's too desperate to make money, but is has continuously proven to be unable to come up with better ideas for attracting paid users. As others have mentioned, they got millions in funding so far but still have no idea how to make money.
Had it been announced a month earlier people would be sure it was an April Fool's joke.
I remember when the user was in control of their own computer, not rando 3rd party companies. I issue a command to the computer, and the computer executes the command. If I want to update a piece of software, I update it. I guess this is a dinosaur mentality now.
This whole "allow the software to do whatever the developer's company wants or stop using the software" trend is pretty nasty.
I think you’re underestimating the cost for a business to support clients that do not upgrade to the latest version of your software.
You’re not paying for the software to “do nothing”, you’re paying for the cost of Docker having a wider variety of software versions to support.
Deleted Comment
Dead Comment
How can you say they are lazy about that?
People asked for the feature to be disabled. There was a lengthy discussion in GH [0] aptly named "Please don't upgrade docker without asking first" few months back regarding why this shouldn't happen (auto updates, that is).
Considering that the team that codes the software acknowledged they screwed up [1] having to pay for this I have to agree with the comment that says this amounts to ransomware. "Pay us or risk getting f*ked up by our updates".
[0] https://github.com/docker/roadmap/issues/183 [1] https://github.com/docker/roadmap/issues/183#issuecomment-74...
The solution to your problem is entirely in your hands, just hit that uninstall button.
To my mind, the decision here shouldn't have been to make people pay protection money to stop a new release breaking their setup. They could make the whole damn thing paid-for instead and I'd be happier with that.
There is clearly something missing in their development and QA process that causes this auto-updating to be so visible and painful. They could have kept the feature as-is and worked on making sure new releases were solid, while also having a mechanism to revert.
I have no problem with my browser updating itself that way, as I never notice if something broken and got rolled back in the canary stage.
To be honest, avoiding criticism by whining about entitlement adds no more to the conversation than pure entitlement itself. I can't see any purpose it serves other than to start a flame war.
It's like, if you beg your friend to let you give them a lift and don't show up, you can't turn around and call them a "choosey beggar" because the lift was supposed to be free.
The response in that thread isn't _remotely_ reasonable, of course you can't make a developer tool like this auto-update.
I think it's paternalistic and egotistical but the usual counterpoint is grandma getting a virus because Windows is unknowingly out of date. With developer tooling that holds a bit less water IMO.
As interest rates come up off the zero bound companies are increasingly going to have to learn how to make profits again. The culture this is out of touch with is not long for this world.
We have gotten more entitled and now when we see something that doesn't exactly meet our liking then we cry about it.
The entire industry knows it , the Docker devtools brought containers to the mass but anything beyond that is being taken by Cloud Vendors / Redhat etc...
The Open Container Initiative contributed massively to make Docker the standard for container but also for other initiatives to replace it....
I personally believe it will also be its death sentence, seeing how many competitions are coming to get a better / simpler container tool chains add to that a lack of leadership after the founder left with a big check from the fundraising it’s just a matter of time before Docker goes bankrupt.
Docker is basically at its core a shell around cgroups/chroots and filesystems. An overengineered shell and a confusing cmdline (which got better to be fair)
There's no "technology" there per se (on Docker "core"). Docker containers and Dockerfiles maybe? Which got eaten by other orchestration technologies there?
Exactly , Kubernetes wants to remove Docker , and the Docker orchestration layer « Docker Compose » is completely dead.
Again the founder has left the company with millions , there is no leadership whatsoever it’s a just a zombie company losing millions every year until it’ll declare bankruptcy.
Google / Redhat are very well aware of that that’s why they are trying to decouple their product ( Kubernetes/ Openshift ) from docker before it officially become deprecated .
[0]https://acloudguru.com/blog/engineering/kubernetes-is-deprec...
shrug In the end I don't particularly care, I still run things like a caveman using processes, systemd units, disk images, and plan for my resource usage. I just find it mighty frustrating and think its short-sighted. Anyone who gets burned by a Desktop update (which they will, this happened to me within this last two months) isn't going to think "oh if only I paid them! Duh! Silly me." Instead it's going to seem like extortion... "Oh no! We broke your development environment! Whoopsie! If you upgrade to pro you can revert and continue working immediately!" Docker was originally "magical" and each year it becomes increasingly less "magical" I can only hope it is worth it.
In fact, it's pretty cool that the only requirement is to stay up to date. Some companies make you pay to get upgrades, which is less secure in a way.
No, what's galling about this is that Docker is used so widely. What about open source projects using Docker? Now you have to apply for an "Open Source Plan"? Great. How does that even work with contributors if they just want to install Docker to check out the project? If a project I was working on depended on Docker, I'm not sure if I'd rather spend time figuring out how to ditch Docker vs fill out their application.
One of the very few open minded answers I've seen so far. Of course people will complain, specially in HN. Even though I agree Docker's communication and execution wasn't the best, I applaud them since they're trying to monetize their work in a different strategy than the standard "support plan". In the end, I really hope this ends up working for them since it'll ultimately be reflected in the quality of the product.
If you ever launch a Linux version I'll be happily be a paying customer.
I have a Golang server with Flutter frontend interacting using GRPCWeb. Now I'm able to embed the Go server code, all the Flutter generated web code, generated Protobuf code, TLS certs, all the other resources, EVERYTHING into a SINGLE statically linked binary with no external dependences. I.e., you just run the executable and it just works. Of course it interacts with an external Redis binary but by itself it's just a single executable that can just be deployed with an scp to cloud, how much easier can you get? You do need your own orchestration mechanisms, but packaging wise it seems great.
Anyone else tried this?
Part of that is about the possibility of leaking your key, but the other half is that you should be running exactly the same binary in production and staging, and you should have different keys for each. Recompiling can introduce behavioral changes (even in a well managed build environment like Golang's where dependencies are versioned through version control tags and cryptographic hashes of those tags)
Podman supports Docker images, Dockerfiles, and Docker-compatible CLI interfaces. Simply use alias docker=podman and you’ll never know the difference.
[0] https://podman.io/
[1] https://github.com/containers/podman
Unless you use Docker Swarm, in which case you'll lose access to simple orchestration that's not overengineered, unlike Kubernetes which you'll now be forced to use.
Or unless you use software that depends on the Docker socket being available (such as for Portainer, a graphical management utility [1]), in which case you'll lose the ability to use such software.
Or maybe you're one of the countless folks who tried using Podman but ran into a variety of issues that still haven't been addressed in many cases [2].
Or maybe you use Docker Compose and now have just lost the ability to run simple single node orchestration with YAML files, because Podman Compose is oftentimes flawed as well [3].
That's not to say that what Podman is attempting to do shouldn't be applauded, yet claiming that exchanging one set of leaky abstractions for another set of leaky abstractions is painless and will work for all of the people out there simply isn't true. I don't see Podman being a backwards compatible alternative to Docker on an API level, it'll simply kill it off eventually by supporting the OCI standard for containers and being a Kubernetes runtime at the lower level. Lots of people will need to re-engineer their approach to running containers and lots of time will be necessary to migrate away from Docker.
[1] https://www.portainer.io/
[2] https://github.com/containers/podman/issues
[3] https://github.com/containers/podman-compose/issues
I think Docker is a fascinating enginnering story, an amazing tool to simplify and give life to groupc, which got released to the wild and sat while seeing competition offer decent alternatives that got adoption. They could have become the de facto container runtime implementation, perhaps swarm the de facto orchestrator, had they actually kept their distance ahead of every other competing alternatives. They could have charged almost all they want for enterprise licensing of a brilliant runtime and even more for the orchestrator. They failed. Seeing they hired 300+ employees and didn't maintain their pioneership is a testament of their incapability to run a business.
The hope for docker to survive is that the open source community forks and improves what's now called moby. As a business they missed the boat.
- Someone relying on Docker only features like Docker compose
> Support for multiple container image formats, including OCI and Docker images.
Deleted Comment
People seem to forget: Docker is a Linux-only technology.
If you’re running a non-Linux desktop OS like MacOS or Windows you need access to a Linux system to run docker.
So docker desktop on MacOS runs a Linux VM for you under the hyperkit hypervisor hosting a Linux OS running containerd.
On windows the equivalent involves managing a dockerd running inside WSL.
So since we are talking here about an app that embeds an entire Linux OS image, the patching surface area is going to be considerable - it’s not just got to be updated whenever docker releases a new version. It’s actually a minimal Linux distribution.
This also means people suggesting ‘alternatives’ to using docker are missing the entire value that docker desktop brings to MacOS and Windows users.
As I understand it, this is not true - you _can_ run Windows containers.
https://hub.docker.com/_/microsoft-windows
But yes, this further gets to the confusion about what ‘docker’ is vs ‘docker desktop’. Docker desktop for MacOS is certainly not going to just magically make it so you can run “docker run -it microsoft-windows” to get a CMD prompt on your MacBook though (but with a Windows VM and the right environment variables set, maybe?)
[0] https://www.docker.com/blog/changing-how-updates-work-with-d...
It's a desktop app. There's absolutely no obligation for them to support anything. Server side, they can just deprecate APIs, and whatever chat/forum support they have can refuse to support outdated versions. They can even charge for it! This is how most companies go about it.
This is nothing more than desperation and lack of ideas on how to generate money, which is very unfortunate.
A more honest route would be just to charge for the app, charge for premium support, or come up with new Pro features by collaborating with the existing user base. This here is just lazy.
No one is forcing them to support older versions, this is a red herring.
I can easily imagine a few meetings that went something like this:
1. Security engineer meetings: "Flipping to default-on for automatic updates has been a major win for ~billions of people to help them mitigate the steady stream of 0-days exploiting gnarly web browser internals. Docker adoption isn't at that level but still big, and the individuals are pretty important. We should try it for our community too!"
2. Sales & CEO: "A ha, amazing! We can turn this into a $ win too. We've been needing more $ and conversion triggers for our install base now that we sold the enterprise business. Anyone with docker desktop on for > 2w is effectively a qualified leading with this, and this might finally tip them over to paid! $5/mo is nothing and this is just annoying enough that it might do it! (And if a developer won't pay for that, they're a freeloader / 1% / ... who'd never pay anyways...)"
3. PMs + designers + marketing + other user advocates responsible for trialing & trust: "Wait a minute! For their core workflows, developers need to easily control the versions of their tools in their environment. Messing with that willy-nilly for system version #'s breaks brand trust for our paid conversions!"
4. Sales & CEO: "Maybe. Let's try it and see. Overruled in the name of business experiments, and we can reverse course if it's too damaging!"
The ball-dropping is sales/product/leadership not being aligned on user advocacy. "Our velocity & sales > breaking user environments" means either the former is overly prioritized, or the people making decisions are too far from users (developers) to understand their daily needs. Managing docker versions for dev/prod drift isn't "1% of devs 99% of the time" but "99% of devs 1% of the time", so it's a real miss.
In an alternate org where the user advocates lead might look more like:
* <reject early on the current feature plan proposal as user hostile and instead...>
* free: default to auto-update (or not)
* free: flip
* pay ("Pro"): one-click to switch to another version, both forwards & backwards
* pay ("Enterprise"): centrally managed update schedule, version tracking, audit logs, etc. for all devs in your org
Folks there are some of the best, so I'm sure most of this was considered, and thus it's an org/process problem