6 ms·

It looks like they've listened and decided to add a prompt before updating: https://github.com/docker/roadmap/issues/183#issuecomment-797412882 https://github.c

by aftbit 6y ago

It looks like they've listened and decided to add a prompt before updating: https://github.com/docker/roadmap/issues/183#issuecomment-797412882 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 6y ago
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/ https://sparkle-project.org/
- thih9 6y ago
  It looks like this is the framework used by Docker Desktop too [1]. Perhaps they enabled auto updates by default? (I wouldn't know, I don't have any experience with Mac projects.) [1]: https://github.com/docker/roadmap/issues/183#issuecomment-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...
  - yellowapple 6y ago
    Yeah, the problem is that Docker Desktop apparently downloads updates automatically in the background, and Sparkle by default apparently wants to kick off the install as soon as the download finishes. 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 :)
- haswell 6y ago
  Interestingly, they appear to be using Sparkle [0]. 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-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...
  - saagarjha 6y ago
    Yeah, Sparkle’s workflow is a bit weird like that. I think most developers just patch it to not do that but never contribute their code back :(
  - eyelidlessness 6y ago
    I’ve only had the pleasure/pain of using Sparkle once, but it’s definitely not as simple to use as “every other app” might suggest. At least coming from the perspective of “I’ve only ever released one Mac app to the public.” I mean it wasn’t as complicated as modern web build tools, but it definitely needed some finesse.
xxpor 6y ago
>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 6y ago
  Do you have a reference for your final example?
  - tim-- 6y ago
    I think the grandparent is referring to this? https://lwn.net/Articles/845535/ https://lwn.net/Articles/845535/
- wmf 6y ago
  Something like PPAs is the sweet spot since it uses the package manager but is under developer control. It's a shame that Mac and Windows don't have something like that.
- rkeene2 6y ago
  If my project, AppFS [0], more widely adopted then packaging would be trivial for all distributions. And updates would be automatic or not depending on user preference. [0] https://appfs.rkeene.org/ https://appfs.rkeene.org/
gugagore 6y ago
> 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 6y ago
  > 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.
- saghm 6y ago
  Those language-specific package managers do not auto-update the packages you have installed with them; I'm don't follow how you go from the premise that there are many different package managers out there to the conclusion that auto-updates are a "better experience".
  - gugagore 6y ago
    > Those language-specific package managers do not auto-update the packages you have installed with them 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-install-a-new-package-without-update-or-add-packages-described-on-p 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.
kzrdude 6y ago
Look over to the snap store on Ubuntu, and it's hard to stop updates there too, they just update when they want.
anonymousab 6y ago
> why not just use a system-wide package manager? 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.
- eyelidlessness 6y ago
  Well for what it’s worth I vastly prefer that attitude as someone who has to manage different dependencies on different projects. Sometimes it’s not up to me when one project is using Foo@13.0 and another is using Foo@27.0. Package managers which isolate that to the project or to some environment are a lot easier to manage than the system-level package managers which require you to roll that isolation yourself. Edit: and I can’t help pointing out the irony of this being a consideration on a thread about Docker.
  - McTossOut 6y ago
    / irony I guess it took to the middle of the thread.
eyelidlessness 6y ago
Well even the package manager managing it can be disastrous. I have definitely lost critical days of work because `brew install` upgraded, and broke, things completely unrelated to what I was installing.

by aftbit 6y ago

wlesieutre 6y ago

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/ https://sparkle-project.org/

thih9 6y ago
It looks like this is the framework used by Docker Desktop too [1]. Perhaps they enabled auto updates by default? (I wouldn't know, I don't have any experience with Mac projects.) [1]: https://github.com/docker/roadmap/issues/183#issuecomment-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...
- yellowapple 6y ago
  Yeah, the problem is that Docker Desktop apparently downloads updates automatically in the background, and Sparkle by default apparently wants to kick off the install as soon as the download finishes. 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 :)
haswell 6y ago
Interestingly, they appear to be using Sparkle [0]. 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-797412882 https://github.com/docker/roadmap/issues/183#issuecomment-79...
- saagarjha 6y ago
  Yeah, Sparkle’s workflow is a bit weird like that. I think most developers just patch it to not do that but never contribute their code back :(
- eyelidlessness 6y ago
  I’ve only had the pleasure/pain of using Sparkle once, but it’s definitely not as simple to use as “every other app” might suggest. At least coming from the perspective of “I’ve only ever released one Mac app to the public.” I mean it wasn’t as complicated as modern web build tools, but it definitely needed some finesse.

xxpor 6y ago

>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 6y ago
Do you have a reference for your final example?
- tim-- 6y ago
  I think the grandparent is referring to this? https://lwn.net/Articles/845535/ https://lwn.net/Articles/845535/
wmf 6y ago
Something like PPAs is the sweet spot since it uses the package manager but is under developer control. It's a shame that Mac and Windows don't have something like that.
rkeene2 6y ago
If my project, AppFS [0], more widely adopted then packaging would be trivial for all distributions. And updates would be automatic or not depending on user preference. [0] https://appfs.rkeene.org/ https://appfs.rkeene.org/

gugagore 6y ago

> 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 6y ago
> 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.
saghm 6y ago
Those language-specific package managers do not auto-update the packages you have installed with them; I'm don't follow how you go from the premise that there are many different package managers out there to the conclusion that auto-updates are a "better experience".
- gugagore 6y ago
  > Those language-specific package managers do not auto-update the packages you have installed with them 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-install-a-new-package-without-update-or-add-packages-described-on-p 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.

kzrdude 6y ago

Look over to the snap store on Ubuntu, and it's hard to stop updates there too, they just update when they want.

anonymousab 6y ago

> why not just use a system-wide package manager? 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.

eyelidlessness 6y ago
Well for what it’s worth I vastly prefer that attitude as someone who has to manage different dependencies on different projects. Sometimes it’s not up to me when one project is using Foo@13.0 and another is using Foo@27.0. Package managers which isolate that to the project or to some environment are a lot easier to manage than the system-level package managers which require you to roll that isolation yourself. Edit: and I can’t help pointing out the irony of this being a consideration on a thread about Docker.
- McTossOut 6y ago
  / irony I guess it took to the middle of the thread.

eyelidlessness 6y ago

Well even the package manager managing it can be disastrous. I have definitely lost critical days of work because `brew install` upgraded, and broke, things completely unrelated to what I was installing.