No, Docker really isn't what you think it is.

Docker isolates processes, and provides a convenient platform independent way to deliver stand alone applications, complete with software defined networking and file system abstraction, at the expense of shipping the whole tech stack, including everything plus the kitchen sink like full blown web servers.

Thus a .DEB package which otherwise would be 10MB ends up being a Docker image often weighing over 100MB.

And pray tell what's Docker's solution to software updates? Well, it's periodic builds that force downstream dependencies and users to re-download payloads of well over 100MB a pop.

And you advocate this as an alternative to shared libraries?

Who in their ri

But in a world where native applications worked on any kernel >= the one it was built on, you'd rapidly find out that bin-packing the webserver and webcrawler into a finite list of SKUs (which is where all this container mania originated) via namespaces and cgroups are really not problems that most Docker users have, and there are much simpler ways to get two versions of `node.js` looking at two different sets of libraries.

Because you can't reliably know what devilry just stomped all over your `/usr/lib/x86_64/...` or whatever, you kind of have to eat that 100MB image if you want software that worked on Tuesday to still work on Friday.

It's a sad state of affairs, but This Too Will Pass. Getting the word out that the reason Docker saves your ass on reproducibility is emulation of static linking behind the FSF's back will accelerate that process.

Can you expand on this? It’s an interesting perspective I haven’t heard before.

I get the gist but even without a Dockerfile, a container image is much less opaque and much more deterministic than a binary with a statically linked library where the compiler might inline entire functions and perform optimizations across module boundaries with LTO. It’s not as simple as setting LD_LIBRARY_PATH but it’s not like trying to reverse the information lost during compilation.

Bundling dependecies is essentially static linking that doesn't violate the GPL. Static linking means all dependencies are compiled into the binary. Modern technology like docker, appimages, snaps, etc. all emulate that by creating a static image with all the dependencies and then dynamically linking to those specific libraries. So now we have a secondary linker and loader on top of the operating system's.

But power corrupts, and once you've got everyone linking to your `libc`, the temptation to get some combination of lazy around standards compliance at best, and seduced by what amounts to proprietary vendor API lock-in to push your politics in at least some cases seemingly becomes overwhelming. Add in LLVM kicking your ass from here to FreeBSD with Stallman freaking the fuck out about `gcc`'s plunging relevance and there's understandable but still not acceptable instinct to go further into incompatible-by-design. People on here routinely lose their shit because NVIDIA or whoever makes it a nightmare to interoperate, and I don't like it either, but vendor lock-in is vendor lock-in.

`emacs` talks to the LSP servers via JSON for Christ's sake, which only makes it about 100x laggier, but you can see why they did it, because just like Docker even RMS can't convince anyone that What We Went With is "linking". God bless the VSCode people for accepting the performance penalty so that the rest of us can come to the party, they could have muscled LSP out of the way IMO and didn't. So `rust-analyzer` gets to shovel megabytes of JSON around and Docker gets to (figuratively) tarball a bunch of `.so` files so that `ldd` can "dynamically" link them.

The thing is, this way lies irrelevance. Even the GNU userland is pretty optional these days. Is Alpine, as I've taken to calling it, "GNU plus Linux"? Is NixOS? What are we putting up with this shit for? Bash?

And now we have this "hybrid linking" thing: static image containing dynamically linked libraries.

Hermetic builds (Bazel, Nix, etc.) are in some sense orthogonal to packaging and delivery via e.g. a Docker container.

It's true that it takes great care to get bit-for-bit identical output from a C/C++ toolchain, and it's also true that very subtle things can send the compiler and linker into a tailspin of "now I inline this and now I don't have room to inline that and now other optimization passes do something different" and whoa, my program just got a lot faster or slower, yikes. I forget the title now, but there was a great Strange Loop talk about how if you do good statistics on repeated builds or even just stuff more or less into `argv` that the difference between `-O2` and `-O3` doesn't hold up (on either `gcc` or `clang`).

But whether the final executable is delivered to the target system via Docker or `scp` doesn't change any of that. If you want identical builds the Bazel and Nix people have a high-investment/high-return sales pitch they'd like you to hear :).

And it's also true (as another commenter pointed out) that it's at least a little bit reductionist of me to say "Docker gives you static linking". Docker does a zillion things, and for the people using the other stuff, more power to them if it's working well.

I would contend that most of them (especially since QEMU emulating x86_64 on your Intel Mac or vice versa isn't really a great story anymore) are not the real selling point though: you already had `virtualenv` and `nvm` and `rustup` and just countless ways to isolate/reproduce everything except the contents of your friendly neighborhood `/usr/lib/...`. If the native compiled code underpinning all of this stuff had all it's symbols linked in, and your kernel is the same or newer, you could use a tarball (and I've worked places where we did just that)!

`git` was probably the tool that really sold everyone on: I want a goddamned cryptographic hash of everything in the thing, otherwise I Don't Trust Like That. We don't accept mystery meat from our source code anymore, why we feel any differently about what actually runs is Stockholm's syndrome IMHO.

Isn't that the world we live? Linux kernel has a stable binary interface. Problems almost always arise in user space.

Yeah. I've had some success just dropping all that user space stuff and targeting Linux directly with system calls. I boot up Linux straight into my program. Not viable for every use case but it's amazing when the system is small.

I've seen other people commenting here on HN saying they're using the same approach in production so it's defenitely not my invention. Hopefully they'll see this thread and reply.

I published some of my work in the form of a liblinux that I use to make system calls:

https://github.com/matheusmoreira/liblinux

I'm not developing it anymore though because I found out the kernel itself has a superior nolibc library:

https://github.com/torvalds/linux/tree/master/tools/include/...

It used to be a single header but it looks like they've recently organized it into a proper project!

I wonder if it will become some kind of official kernel library at some point. I asked Greg Kroah-Hartman about this and he mentioned there was once a klibc:

https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...

The quote about "glibc maintainers being non-helpful" slayed me. I guess at least some of the kernel people aren't exactly thrilled about the tireless efforts of the GNU project to gatekeep, take credit for, be obstructionist around, and otherwise subsume Linux into The GNU Operating System.

I hate that it's gotten to the point where I'm the "anti-GNU" guy, I never wanted that, but they need some fresh blood in the leadership or something.

Nice idea. I think a kernel libc in the form of a vDSO would unnecessarily force compilers to use the C ABI though. The Linux system call interface is really unique in how it's not only stable but language-agnostic and it would be a shame to lose that.

I think compilers are the right place for system calls. The programming language should have a system_call keyword that makes the compiler emit the syscall instruction with the parameters in the right registers. It was my intention to eventually create that language, liblinux was something of a prelude... Then I ran out of free time. :)

Then it turned out smarter people than me have gone much farther than I did:

https://news.ycombinator.com/item?id=28283632

Really cool stuff.

> The quote about "glibc maintainers being non-helpful" slayed me.

> I guess at least some of the kernel people aren't exactly thrilled about the tireless efforts of the GNU project to gatekeep, take credit for, be obstructionist around, and otherwise subsume Linux into The GNU Operating System.

I understand what you mean. I think it's really weird how often I get glibc manual pages when I look up Linux kernel documentation. I look up some system call and get glibc wrappers instead. Aren't they separate projects?

In the first AMA someone asked Greg whether glibc was blessed by the kernel:

https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroah...

He said no, but it still seems like the official libc of Linux.

I also get systemd manuals when I look up Linux init system documentation. I expected to read about what the kernel itself expects from PID 1, information useful for making my own system. Turns out it's just a process like any other, it just needs to bring up the system by doing things like mounting procfs and sysfs.

Linux should be its own thing. It's only "GNU/Linux" because of POSIX which says an operating system has to have binaries like cp, mv, etc. Things don't have to be that way. POSIX is just paper.

> I hate that it's gotten to the point where I'm the "anti-GNU" guy, I never wanted that, but they need some fresh blood in the leadership or something.

I think it was a quote from Lennart Poettering that inspired me to start dropping this "standard" GNU stuff. I think he wrote something like "read TLPI and ignore all the POSIX stuff". So I did and I discovered a really nice system that actually turned out to be easier and more fun to program with than dealing with C libraries. No global state anywhere!

GNU is just a POSIX compliant user space. It doesn't have to be that way... Wouldn't it be cool if some awesome person made a pure Lisp user space? A pure Rust user space? It doesn't have to be the same old POSIX tools... Linux enables that. We can trash the entire user space and start fresh if we want. We can't do that on Windows, Mac, the BSDs.

    ./nginx.bin

People go to ridiculous lengths just to avoid the shared library mess, and it only makes the argument against shared libraries stronger.