Personally, I just ship every user a small Chromebook that runs my software so I can guarantee the environment is the same every time.

(I get your point, but docker has made distribution way easier in a lot of ways, and you accept sole tradeoffs for that convenience)

You can have convenience and reliability with fewer tradeoffs!

That's basically what a docker image does in a more formalized, isolated, and repeatable fashion.

In most scenarios it is definitely good-enough but even in just my own personal experiences over a decade I need to asterisk all three of your listed benefits.

True. But Docker comes with a lot of complexity. And it comes with a meaningful performance hit on macOS and Windows. And it doesn't work at all on Android/iOS.

It's so sad that running software on Linux is so wildly complicated and unreliable than things like Docker had to be invented. :(

For most uses wsl2 on windows is pretty close to a bare metal instalation

https://www.phoronix.com/review/windows11-wsl2-zen4

wsl2 runs under the windows hypervisor as a vm, but so does windows since windows 11. So there should not be much performance issues from running stuff in windows vs wsl2. The major bottleneck is if you need to move files from and to the windows vm to the Linux vm

My interest in running Linux binaries on Windows is zero. I run native windows binaries. Why would I want to run via WSL2 when I can do it natively?

Why people constantly insist on adding unnecessary layers of abstraction is beyond me.

Nobody is forcing you to use anything I just wanted to underline that the performance hit you mentioned is not really there, as we are in a public forum there is value to keep things factual.

As for why to do it, if you develop on server apps Linux is the standard (as an example redis does not have a windows native version), and I say this as a developer of Windows based microsevices on the cloud, my company is actively looking to migrate to Linux due to lack of tooling in the windows space (and also licence cost of windows server), like it or not that is the way it goes. If you don't need it great for you, but for other of us those layers are life saver

I think that's the right way to do it from the software distributor's side, but most software distributors don't do it like you.

So, from a consumer's point of view, if you want to use their software, then docker is the lesser evil compared to all the others. Notably, it's much better than binaries with dynamic libraries that don't come included in the bundle itself.

As a user, I'd rather use a container then figure out how to run a binary. The onboarding process is typically so much easier, and most enterprise folks already have container infrastructure in place. For big customers, getting a Kubernetes namespace can have significantly less friction than a VM these days.

> then figure out how to run a binary

It should never be more complicated than "run the binary". Running programs shouldn't require infrastructure or VMs or Docker images. Deploying a program should be, and can be, as simple as sharing a zip file, extracting, and running.

It's not that hard!

> better than binaries with dynamic libraries that don't come included in the bundle itself.

Binaries should always include the dynamic libraries they require. Docker is one way to include them. But you can also just include them the vanilla way. Works great! Very easy and reliable.

I'm sorry but this doesn't work. Over the last 10 years so I was fucked over by countless "software that includes all its dependencies" that stopped working when I upgraded some other totally irrelevant software because "well duh it obviously uses system libC" or whatever. Examples: critical .AppImage binaries stopping working after random system upgrades. Nothing runs on my computer is ever fully isolated, not even Docker. So, any isolation guarantee I get is guarantee I'll take. You claim today that your software is isolated, but I don't know if 3 years down the road I'll upgrade my freaking text editor and your program will stop working because that one library from 1987 has to be exactly version A.X but my text editor upgraded it to A.Y. Thanks but no thanks.

> your program will stop working because that one library from 1987 has to be exactly version A.X but my text editor upgraded it to A.Y.

Perhaps you misunderstand. This issue is fully solved by including dependencies and not relying on anything in the system path. Programs should not touch the system path. If a program requires library A.Y then it should include and use A.Y. But it should not touch the system path and thus should not impact any other program. Nor will it be impacted by other programs wanting A.Z.

It's often literally not possible to ship everything. You wouldn't want to spin up a second X11 (or Wayland) server, for example, because you can't have two of them talk to the same video card device at the same time usefully.

The number of things that can't be shipped is extremely small. And I don't think that Docker is a silver bullet for Wayland vs X11 issues? Although I'm not sure about the fine details as I don't have a ton of experience there. Shouldn't you be using an abstraction that can automatically support which ever is available?

I tend to ship code that needs to run on Linux + macOS + Windows + Android. So Docker is a total non-option. And it's totally fine! Very easy in fact.

It's the same thing everywhere — there are some dependencies you can't ship. On Linux, you can't ship the window server (because you need to share it with all of the other apps also running). On mac, you can't ship Core Foundation. On Windows, kernel32.dll etc. I assume Android is similar — I haven't tried figuring out what a purely static app on Android would be, since I think the bootstrap is Dalvik…

It's literally impossible to _not_ depend on the system path.

Let me rephrase. If a dependency can be bundled then it should be bundled.

The "Linux Way" is to depend on a bunch of random garbage pooped by lord knows bullshit script into one of several global search paths. This is bad, stupid, and wrong. Programs should include as many of their dependencies as is possible.

The number of dependencies that a program can not deploy and must assume are provided by the system are extremely minimal and special case. It's a short and static list.

In general no script or program should add libraries into the global search paths. On Windows user programs do not add random crap to System32. On Linux the existence of /usr/lib is an abomination that should not exist.

Is that better? I'm fairly certain you understand what I'm trying to say.

I know that the Linux way is not perfect, but I don't know how companies can't do better than the distro maintainers. Most repositories packages are driven by some kind of build scripts. I don't expect it would be that hard of a job to create one for your software for the most popular ones. Anyone using obscure distros are familiar enough with Linux to do container or chroot environments. I like the fact that my environment is a complete one, not siloes where the developer is more than happy to let the software lingers. At least macOS force developers to upgrade, Microsoft's backward compatibility's promise is keeping so much crust around in the system.

On some projects and teams, more than usually expected, this is more than fine.