Sure, there are, but they all have enough of a learning curve that they don't seem to take hold with the masses.
Nix, Guix, Bazel, Habit, and others, all solve this problem more elegantly. There are some big folks out there, quiet quietly using Nix to solve:
* reproducible builds
* shared remote/CI builds
* trivial cross-arch support
* minimal container images
* complete knowledge of all SW dependencies and what-is-live-where
* "image" signing and verification
I know docker and k8s well and it's kind of silly how much simpler the stack could be made if even 1% of the effort spent working around Docker were spent by folks investing in tools that are principally sound instead of just looking easy at first glance.
Miss me with the complaints about syntax. It's just like Rust. Any pain of learning is very quickly forgotten by the unbridled pace at which you can move. And besides, it's nothing compared to (looks at calendar) 5 years of "Top 10 Docker Pitfalls!" as everyone tries to pretend the teetering pile of Go is making their tech debt go away.
I never thought I'd come around to being someone wary of the word "container", as someone who sorta made it betting on them. There is so little care for actually managing and understanding the depth of one's software stack, well, we have this. (Pouring one out for yet another Dockerfile with apt-get commands in it.)
Docker provides a solution for balls of mud. You now have a more reproducible ball of mud!
Bazel and company require you to clean up your ball of mud first. So your payoff is further away (and can sometimes be theoretical)
Ultimately it’s less about Docker and more about tooling supporting reproducibility (apt but with version pinning please), but in the meantime Docker does get you somewhere and solve real problems without having to mess around with stuff too much.
And of course the “now you have a single file that you can run stuff with after building the image ”. I don’t believe stuff like Nix offers that
Can you generate a tar file that you can “just run“ (or something to that effect)? My impression was that Nix works more like a package installer, but deterministic
With the new (nominally experimental) CLI, use `nix bundle --bundler github:NixOS/bundlers#toArx` (or equivalently just `nix bundle`) to build a self-extracting shell script[1], `...#toDockerImage` to build a Docker image, etc.[2,3], though there’s no direct AppImage support that I can see (would be helpful to eliminate the startup overhead caused by self-extraction).
If you want a QEMU VM for a complete system rather than a set of files for a single application, use `nixos-rebuild build-vm`, though that is intended more for testing than for deployment.
The Docker bundler seems to be using more general Docker-compatible infrastructure in Nixpkgs[4].
There might be quicker ways to do this, but with one extra line a derivation exports a docker image which can in turn be turned to a tar with one more line.
Nix's image building is pretty neat. You can control how many layers you want, which I currently maximize so that docker pulls from AWS ECR are a lot faster
Uhm, can't get Nix to build a crossSystem on MacBook M1, it fails compiling cross GCC. I wouldn't say it's trivial. Maybe the Nix expressions look trivial, but getting them to actually evaluate is not.
> it's kind of silly how much simpler the stack could be made if even 1% of the effort spent working around Docker were spent by folks investing in tools that are principally sound instead of just looking easy at first glance.
This is the phrasing I was groping around for. Thank you
> Miss me with the complaints about syntax. It's just like Rust.
Yeah and it's competing against Dockerfiles, which I suppose in this analogy is like Python or bash with fewer footguns; syntax and parts of the functional paradigm are absolutely putting nix at a usability/onboarding disadvantage to docker.
Nix, Guix, Bazel, Habit, and others, all solve this problem more elegantly. There are some big folks out there, quiet quietly using Nix to solve:
* reproducible builds
* shared remote/CI builds
* trivial cross-arch support
* minimal container images
* complete knowledge of all SW dependencies and what-is-live-where
* "image" signing and verification
I know docker and k8s well and it's kind of silly how much simpler the stack could be made if even 1% of the effort spent working around Docker were spent by folks investing in tools that are principally sound instead of just looking easy at first glance.
Miss me with the complaints about syntax. It's just like Rust. Any pain of learning is very quickly forgotten by the unbridled pace at which you can move. And besides, it's nothing compared to (looks at calendar) 5 years of "Top 10 Docker Pitfalls!" as everyone tries to pretend the teetering pile of Go is making their tech debt go away.
I never thought I'd come around to being someone wary of the word "container", as someone who sorta made it betting on them. There is so little care for actually managing and understanding the depth of one's software stack, well, we have this. (Pouring one out for yet another Dockerfile with apt-get commands in it.)