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/

[1] https://docs.docker.com/linux/step_one/

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.

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."

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.

Arch is far from stable enough to use on servers, hence why it's almost never used on servers.

I don't disagree.

You rarely see curl|sh installers for server stuff though. I think the topic at hand mostly concerns workstations.