Comment by forrestthewoods

> I’m arguing that the prevalence of Docker is strong evidence that the “Linux model” has fundamentally failed.

That is a very silly argument considering that Docker is built on primitives that Linux exposes. All Docker does is make them accessible via a friendly UI, and adds some nice abstractions on top such as images.

It's also silly because there is no single "Linux model". There are many different ways of running applications on Linux, depending on the environment, security requirements, user preference, and so on. The user is free to simply compile software on their own if they wish. This versatility is a strength, not a weakness.

Your argument seems to be against package managers as a whole, so I'm not sure why you're attacking Linux. There are many ecosystems where dependencies are not vendored and a package manager is useful, viceversa, or even both.

There are very few objectively bad design decisions in computing. They're mostly tradeoffs. Choosing a package manager vs vendoring is one such scenario. So we can argue endlessly about it, or we can save ourselves some time and agree that both approaches have their merits and detriments.

> Many people disagree with that claim and think that TheLinuxModel is good actually. However I point that these people almost definitely make extensive use of Docker

You've got the wrong audience here. Nix people are neither big fans of "the Linux model" (because Nix is founded in part on a critique of the FHS, a core part and source of major problems with "the Linux model") nor rely heavily on Docker to ship dependencies. But if by "the Linux model" you just mean not promising a stable kernel ABI, pulling an OS together from disparate open-source projects, and key libraries not promising eternal API stability, it might have some relevance to Nixers...

> I also dont think that deploying a program should be much more complicated than sharing an uncompressed zip file. Docker adds a lot of crusting. Packaging images/zips/deployments should be near instantaneous.

Your sense of "packaging" conflates two different things. One aspect of packaging is specifying dependencies and how software gets built in the first place in a very general way. This is the hard part of packaging for cohesive software distributions such as have package managers. (This is generally not really done on platforms like Windows, at least not in a unified or easily interrogable format.) This is what an RPM spec does, what the definition of a Nix package does, etc.

The other part is getting built artifacts, in whatever format you have them, into a deployable format. I would call this something like "packing" (like packing an archive) rather than "packaging" (which involves writing some kind of code specifying dependencies and build steps).

If you've done the first step well— by, for instance, writing and building a Nix package— the second step is indeed trivial and "damn near instantaneous". This is true whether you're deploying with `nix-copy-closure`/`nix copy`, which literally just copy files[1][2], or creating a Docker image, where you can just stream the same files to an archive in seconds[3].

And the same packaging model which enables hermetic deployments, like Docker but without requiring the use of containers at all, does still allow keeping only a single copy of common dependencies and patching them in place.[4]

--

1: https://nix.dev/manual/nix/2.30/command-ref/nix-copy-closure...

2: https://nix.dev/manual/nix/2.30/command-ref/new-cli/nix3-cop...

3: https://github.com/nlewo/nix2container

4: https://guix.gnu.org/blog/2020/grafts-continued/