Just a small example I encountered just recently: Look at the install page for docker. Curl, pipe to some random folder, mix in some sudo access, then finally can I "install" the docker package.
2. They are running their own apt repos already anyway! The thing the grandparent commenter is complaining about is part of normal apt usage. It's not a manual installation of some piece of Docker, just a normal part of configuring apt in order to install something that is, in fact, properly packaged.
But the version is fixed per Debian release, which means that by its EOL it will be obsolete ( it's Docker, not a database, having the latest and greatest is a huge bonus). The whole point of custom repositories is to ship independently of the OS release cycle.
I have high hopes for Flatpak and Nix.
snap info docker | tail vs. the Ubuntu one:
apt info docker.io 2>/dev/null | head -2That's the same as the version in the latest nixpkgs unstable:
nix search nixpkgs '^docker$' 15:41:11Also, afaict Nixpkgs doesn't expose any unit files for the Docker daemon, so it'd take a bit of monkeying around with a new package definition to expose the one from the Moby source so that you could use it on some random distro (or you could write your own). Nix doesn't currently have any system-wide module system for managing services on non-NixOS Linux, unfortunately.
EDIT: And being new, there facilities aren't as mature, userbase smaller, so not enough work is put into packaging the latest versions. Since they also take on the goal of sandboxing the barrier for entry might be higher.
But I think the main barrier to running Docker from Nix on non-NixOS is the lack of a systemd unit file or other init system configuration in Nixpkgs. Nixpkgs just doesn't have any facilities for that atm and afaict no one is working on them right now. There are definitely precursors to that functionality in:
• the NixOS module system, which provides exactly this functionality for NixOS, where the module system is in charge of configuring systemd
• home-manager, a module system like NixOS which adds support for systemd user services on non-NixOS: https://github.com/nix-community/home-manager
• nix-processmgmt, an experimental Nix framework for writing Nix expressions to describe services to be managed by a range of process managers that may or may not be PID 1 (which means the could be usable on non-NixOS): https://github.com/svanderburg/nix-processmgmt
• nix-darwin, a module system for macOS that provides some NixOS functionality, including managing services: https://github.com/LnL7/nix-darwin
The discussion on the service abstraction layer for Nixpkgs/NixOS is also very relevant. It shows that there has been interest in something like this for many years, but it's never quite come together: https://github.com/NixOS/nixpkgs/issues/26067
I wouldn't assume it's just around the corner or inevitable. It is a really exciting possibility, though, and the nix-processmgmt framework seems like something that could evolve into a service abstraction layer for Nixpkgs that could make facilities for managing services available in a uniform way even on non-NixOS Linux.
My best experiences with packaging on linux have been gentoo ebuilds & arch pkgbuilds. These keep the build model pretty straight forward if the goal is to "just build a package".
That said: creating a dpkg is not an impossible thing to do. It's just more painful than it needs to be
you mean this:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
in the section labeled ‘Add Docker’s official GPG key’, where you download a GPG keyring for Docker's apt repository and install it to /usr/share/keyring?
Really? That's a ‘random directory’?
"echo \ "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null"
But overall, that sentence you quote of mine was me trying to condense my general feel of the instructions in a bit of an exaggerated tone. Let's be honest, not all of the instructions there are super obvious if you're not comfortable with the Linux ecosystem. Most people will just copy paste everything on that page till docker works, ignoring the big fat warning saying "Always examine scripts downloaded from the internet before running them locally.".
If you're using Docker to develop applications for Linux servers, the bash builtin `echo` and `tee` are probably among the absolute minimum basics of the command line you ought to learn ASAP. And if you're gonna run Ubuntu at all, the format and use of `/etc/apt/sources.list.d/*` is part of your absolute minimum curriculum, too. I don't think the confusion of folks who are unwilling to do those things is a huge problem in this specific use case.
But you are right in general: it's unusual among desktop operating systems that in the Linux world, users are expected to know about how the configuration for the system is stored. And while I don't think that's necessarily a problem, it would be better if for extremely common use cases (like adding an external software source), users could always use tools (including command-line tools!) that didn't confront them with implementation details such as configuration file paths or lines to be appended to them and instead summarized what was to be done in human terms and asked them if they wanted to do it.
The Debian-based tooling is especially weak here, and especially at the moment, since `apt-key` has been deprecated for security reasons but there's no convenient tooling to replace it at the moment. :-\