Dockerized apps are typically just as transparent, so that's a bit of a non-argument IMO.
Their main advantages are portability, reproducibility, and security.
For example: https://hub.docker.com/layers/library/mysql/latest/images/sh...
"ADD file:e15c235506d8dd134e69d458a7c0afefef1522e9d0cfb28e3538760ddf032785" isn't much help in installing MySQL on a bare metal server.
It's also not something commonly done (I've never seen a project do it), but you can also just push around a very simple base image like a plain Debian image and then move around an image's runtime filesystem through `docker export` as .tar.gz which could have been crafted by someone who started an interactive shell session and just manually performed some install steps without recording what was being done. It's still technically a containerized system but it does obscure or omit a lot of the value proposition.
(And will this stuff even still run on chips 10-20 years from now anyway? Is there maybe a practical limit to reproducibility?)
NixOS Con Paris had a talk running a decade+ old version of Firefox, complete with Flash.
Personally, I've never once ran into an issue where updating Debian packages in a Docker image impacted my daily life. I'm sure there's some anecdotes and greater than zero potential for it but it just doesn't seem like a major issue anywhere. Docker and Dockerfiles are a practical and low-friction means of getting install steps documented and it's generally a step up over what is normally done. I'm not going to let perfect be the enemy of good and will gladly deal with a Dockerfile that updates its packages first over a markdown file that does nothing.
Well, I have been running NixOS systems for nearly a decade, and now have it deployed across 3 cpu archs in 3 continents. :) Tailscale also uses NixOS in prod, etc.
Not to mention, NixOS means: no docker hub/repo, all you need is a dumb blob store, no container signing, no complicated tooling for BOM or source provination, or tooling for version dep analysis. Much of the entire Golang/K8s devops-startup-chasing/adjacent ecosystem is obliviated by first-order Nix features. You don't have to think about container bloat, or container optimization, storage on nodes is cheaper; it's really hard to name an area that isn't strictly better other than "yes, you have to learn more than running an imperative bash script and capturing the tar filesystem". But, maybe there's good reasons for that. I've personally also sheparded probably half a dozen or more users into full-time contributors, so I know it's not impossible.
When Tvix hits with their NAR alternative, a number of other benefits are just going to start appearing for Nix users that try to adopt it. Much, much faster path downloads, significantly more on-disk de-duplication "for free", much better options for potential P2P replication, etc.
No it doesn't. Just read the Dockerfile, it's self documenting and contains all the build steps.
If you don't want to run docker you can read the Dockerfile as it will contain all of the build step. Then you can enter everything yourself manually.
However, where did you find the steps to install this with Docker? I can't find it.
There is a docker-compose file at the root of the repository, which gets you most of the way there. But the above link will undoubtably be more helpful.
As I prefer using OpenBSD for self-hosting (and I speculate that if more self-hosters learned OpenBSD, they likely would also prefer it), I am acutely aware of not only how Docker has gradually taken over nearly all new FOSS projects, but also how many people involved in FOSS projects generally assume GNU / Linux as a prerequisite to all FOSS projects.
I feel like Docker-based installs are closer to binary, closed-source installs than they are to open-source, compile-or-build-from-source ones in how much they hide how the program works and limits where and how you can run the application. I'd love to hear points for against this, because I think this may also just be me yelling at a cloud like an old man now a days.
Edited for clarity.