5 ms·

>For me personally, the security aspect isn't even the reason I dislike curl | bash installers. There's no standard behaviour for curl|sh, and it re-introduces

>For me personally, the security aspect isn't even the reason I dislike curl | bash installers. There's no standard behaviour for curl|sh, and it re-introduces many problems that were solved by package managers decades ago. Every time I've seen it used, curl | bash is simply a way to deal with the fact that the users all have different package managers (often with outdated software) and quite complicated workflows to get stuff set up with them because there were problems that the package manager didn't solve. >Docker solved this problem. Ironic. Docker is one of those applications. And they used to ask for it to be installed with a curl pipe. They seem to have replaced it with what is effectively a script executed with human hands. Not really an improvement.

kenny_r 11y ago
I was genuinly confused with regards to your last point. There's a section on their website[0] there are installation instructions for various distributions using repositories and package managers. In other words, the right(tm) way of doing software distribution on Linux. But then on a different part of their website I found the curl | sh instructions you allude to[1]. Bizarre that they still support that installation method. To make matters worse, the big orange "Get Started" call to action button actually leads to the curl|sh installation instructions. In light of that I certainly can't blame you for not knowing about the proper distribution packages. [0] https://docs.docker.com/engine/installation/ https://docs.docker.com/engine/installation/ [1] https://docs.docker.com/linux/step_one/ https://docs.docker.com/linux/step_one/
- crdoconnor 11y ago
  That curled script actually installs the 'proper' distribution packages. It has a lot of clever stuff to figure out which environment it's running on and then does whatever commands are necessary - including, e.g., adding keys so that the external repos where docker is hosted are trusted. Point being that even if you install "the right way" on linux using package managers it's still a multi-step complicated process that benefits from being automated in a bash script.
  - kenny_r 11y ago
    Thanks, that explains a lot. It's really a shame that you have to wrap the best practices aproach in a bad practice in order to make it convenient. > Point being that even if you install "the right way" on linux using package managers it's still a multi-step complicated process that benefits from being automated in a bash script. Right, because distributions want different things than software authors. If you're a Debian/Ubuntu/RHEL maintainer, you want stable, tested versions of software that you can vouch for and support for several years. If you're the maintainer of an application, in this case Docker, you want your users to run the latest and greatest version of your software. You can't just demand that each distro just ships the latest and greatest version of your software. So if you're Docker you end up having to do the following for each distro: * package the software for that distro * sign that package * serve your your own repository containing that package * ask your users to add the repository * ask your users to trust the signature And then finally your users can install the package. That's one of the reasons I like running Arch Linux on my workstation. The desires of the software authors, distro maintainers and users align. Docker Inc: "Hey wouldn't it be cool if your users could install the latest stable version of Docker?" Arch Linux maintainers: "Yeah, it would. We'll keep the latest version in the repo and our users can just `sudo pacman -S docker`" Docker Inc: "Cool." Arch Linux users: "Cool."
    - crdoconnor 11y ago
      Arch is far from stable enough to use on servers, hence why it's almost never used on servers.
      - kenny_r 11y ago
        I don't disagree. You rarely see curl|sh installers for server stuff though. I think the topic at hand mostly concerns workstations.
    - cyphar 11y ago
      You should try openSUSE Tumbleweed. It actually is faster at releasing new packages than Arch in some cases, and has much more testing and stability from my experience. But it should be noted there are good reasons to want stable software especially with Docker (which is something I actually maintain for SUSE systems) -- there's been a lot of very invasive architectural changes in the last 3 or 4 releases. And all of them cause issues and aren't backwards compatible or correctly handled in terms of how to migrate with minimal downtime.

kenny_r 11y ago

I was genuinly confused with regards to your last point. There's a section on their website[0] there are installation instructions for various distributions using repositories and package managers. In other words, the right(tm) way of doing software distribution on Linux. But then on a different part of their website I found the curl | sh instructions you allude to[1]. Bizarre that they still support that installation method. To make matters worse, the big orange "Get Started" call to action button actually leads to the curl|sh installation instructions. In light of that I certainly can't blame you for not knowing about the proper distribution packages. [0] https://docs.docker.com/engine/installation/ https://docs.docker.com/engine/installation/ [1] https://docs.docker.com/linux/step_one/ https://docs.docker.com/linux/step_one/

crdoconnor 11y ago
That curled script actually installs the 'proper' distribution packages. It has a lot of clever stuff to figure out which environment it's running on and then does whatever commands are necessary - including, e.g., adding keys so that the external repos where docker is hosted are trusted. Point being that even if you install "the right way" on linux using package managers it's still a multi-step complicated process that benefits from being automated in a bash script.
- kenny_r 11y ago
  Thanks, that explains a lot. It's really a shame that you have to wrap the best practices aproach in a bad practice in order to make it convenient. > Point being that even if you install "the right way" on linux using package managers it's still a multi-step complicated process that benefits from being automated in a bash script. Right, because distributions want different things than software authors. If you're a Debian/Ubuntu/RHEL maintainer, you want stable, tested versions of software that you can vouch for and support for several years. If you're the maintainer of an application, in this case Docker, you want your users to run the latest and greatest version of your software. You can't just demand that each distro just ships the latest and greatest version of your software. So if you're Docker you end up having to do the following for each distro: * package the software for that distro * sign that package * serve your your own repository containing that package * ask your users to add the repository * ask your users to trust the signature And then finally your users can install the package. That's one of the reasons I like running Arch Linux on my workstation. The desires of the software authors, distro maintainers and users align. Docker Inc: "Hey wouldn't it be cool if your users could install the latest stable version of Docker?" Arch Linux maintainers: "Yeah, it would. We'll keep the latest version in the repo and our users can just `sudo pacman -S docker`" Docker Inc: "Cool." Arch Linux users: "Cool."
  - crdoconnor 11y ago
    Arch is far from stable enough to use on servers, hence why it's almost never used on servers.
    - kenny_r 11y ago
      I don't disagree. You rarely see curl|sh installers for server stuff though. I think the topic at hand mostly concerns workstations.
  - cyphar 11y ago
    You should try openSUSE Tumbleweed. It actually is faster at releasing new packages than Arch in some cases, and has much more testing and stability from my experience. But it should be noted there are good reasons to want stable software especially with Docker (which is something I actually maintain for SUSE systems) -- there's been a lot of very invasive architectural changes in the last 3 or 4 releases. And all of them cause issues and aren't backwards compatible or correctly handled in terms of how to migrate with minimal downtime.