Hacker News Reader

There are several issues here which tends to get mixed up a lot.

Yes, a dpkg is built for a distribution, and not only that but a specific version of a distribution. So they tend to get re-built a lot. But this is something buildhosts do. What you upload is the package source.

If you want to distribute a package to work on "Linux" in general, then you can't build it for a specific distribution. Then you bundle all the shared libraries and other dependencies. (Or make a static build, but for various reasons this is less common.) Do not try to rely on the naming scheme of openssl, or anything else really. This is what most games do, and the firefox tarball, and most other commercical software for Linux.

There are of course downsides to this. You have to build a new package if your openssl has a security issue, for example. But that's how most software is distributed on most other operating systems, including Windows. This is also how Docker images are built.

The alternative is to build packages for a specific distribution and release, and as stated above, that takes a bit of integration work.

There are issues with both alternatives, but they should not be confused.

> Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl.

That's not an accurate description of the main motivation for Docker. It's a nice secondary benefit, sure.

What is it then? It’s not a good security isolation tool. It’s not great at resource use isolation. Containers are bulkier than packages.

It used to be completely free hosting, that's one thing that was great about it. Same thing made Sourceforge so completely dominant that it took many years for projects to move off it even after more suitable alternatives were made available.

But the main use case was probably convenience. It's a very quick way for Mac and Windows users to get a small Linux VM up and running, and utilize the copious amount of software written for it.

These days it's mostly standard, for better or worse. There are a handful vendor independent ways to distribute software but this works with most cloud vendors. Is it good? Probably not, but few industry standards are.

To some degree "there can be a ton of different versions of things" only applies to core OS packages. You mention Mac. but what version of python ships with macOS? What if I need a version other than what ships by default?

At a certain point you need to start defining the environment regardless of OS, and docker works as a tool that handles environment definition for literally any program (same thing works for ruby, java, python, etc). It handles more complex environment definition than packages, but is lighter than a VM. It's a middle ground, which is a great compromise for some cases and not for others.

Varying use cases and lots of flexibility is also the reason why linux is never going to just standardize the ecosystem and say "ok, there is only 1 openSSL package now." Some people see the ability to have a version of linux that is completely bonkers in versioning as a strength, akin to how some places have old windows 95 computers they still run because newer versions don't work properly. On linux, you could have old 1995 packages from a specific app, but the rest modern secure packages.

Not to be contradictory but my understanding was, that absolutely is the main motivation.

It was to solve the age old "it runs on my machine".

Open to being wrong but when docker hit the scene I remember that being touted left and right.

> If the Linux ecosystem could get its act together, standardize, and consolidate all the totally needless and pointless distribution fragmentation we could challenge this.

Maybe, but that will never happen because the ecosystem got here by being open enough that people could be dissatisfied with existing stuff and make their own thing, and to a remarkable degree things are intercompatible. It's always been like this; just because there are 20 people working on distro A and 20 people working on distro B doesn't mean combining them would get 40 people working on distro AB. (In practice, attempting it would probably result in the creation of distros C-F as dissidents forked off.)

> Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl.

I think I agree with you; part of the problem is that people treat "Linux" as an OS, when it's a piece that's used by many OSs that appear similar in some ways.

> Apple macOS is the only OS you can ship software for without statically linking or bundling everything and be reasonably sure it will work… as long as you are not going back more than two or three versions.

...but then by the same exact logic as the previous point, I think this falls apart; macOS isn't the only OS you can target as a stable system. In fact, I would argue that there are a lot of OSs where you can target version N and have your software work on N+1, N+2, and likely even more extreme removes. Last I looked, for example, Google's GCP SDK shipped a .deb that was built against Ubuntu 16.04 specifically because that let them build a single package that worked on everything from that version forward. I have personally transplanted programs from RHEL 5 to (CentOS) 7 and they just worked. Within a single OS, this is perfectly doable.

I have feeling whole Docker (or application containers) took of when "non Linux people" (read: developers) tried to be sys admins too and failed.

Best thing after sliced bread is apps/software packed in single GO binary. Runs everywhere, you only need to rsync/scp it to million of other places and it "acts" (usually) as normal Linux program/daemon

That’s true but IMHO that’s an indictment if Linux not them. It’s 2023 and there is no reason system administration should be this hard unless you are doing very unusual things.

The Go approach is just static linking. Rust often does the same though it’s not always the default like in Go, and you can do the same with C and C++ for all but libc with a bit of makefile hacking.

Statically linking the world is the alternative approach to containers.

One problem with SysAdmin stuff is that, like crypto, we keep telling folk it's too hard and just out-source. While I think don't roll your own crypto makes sense - we've done a dis-service to the trade to discourage self-hosting and other methods to practice the craft. Don't run your own infra, use AWS. Don't host your own email it's too hard, just use a provider. Etc. Then a decade later...hey, how come nobody is good at SysAdmin?

Most of the "don't do X it's too hard" is just $corp who wants to sell their preferred solution trying to convince you to buy their SaaS equivalent of a Bash script.