Hacker News Reader

Comment by nightowl_games | Hacker News Reader

Can someone explain a couple use cases for something like this?

I routinely get embedded linux devices at $dayjob that need my time and attention and they basically never have the tooling I need to get my job done. I'm a pro at looking at how Alpine builds a tool and then just making my own statically linked / minimal size tool to drop in place on the device. The allure of something like this is that I can just potentially grab a drop-in binary and get on with my day. I simply don't attempt to link to libraries already on the device since they're all built in wildly different ways, old tools, old compilers.

Hopefully that's helpful context. Overall since I did linux from scratch half a lifetime ago I've always wondered why something like Oasis hasn't gotten more traction. It's got some ambitious ideas in the README so maybe others have other nice use-cases atop all that. I just see small, statically linked and think 'oh boy if i never have to build my own tools again for some weird board'. If so, I'm here for it.

> grab a drop-in binary

This is a cool approach on Docker as well.

    FROM some:thing AS bins
    FROM debian:latest
    COPY --from=bins /bin/foo /bin/

Agreed, if the binary is statically linked. If you run `file` on the output from that and it shows 'dynamically linked' then you're playing games with porting over libraries, changing the library loading path, or just going full chroot like linux from scratch does with the bootstrapping part of the install. I find static binaries simplest to work with in that context but agreed I use that pattern too with docker and generally build ad-hoc tools within containers like that. If only these devices could run docker but I'm left to my own tooling to figure out per device.

Agreed, dynamically linked binaries don't drop in well.

In a way, that's what Nix sets out to do, isolating even dynamically linked libraries: if two derivations depend on the same shared lib derivation then it's reused, if not then they don't conflict. Each leaf derivation can be handled completely independently of the others, and independently of the original system†.

And then when Nix† is not an option at runtime, dockerTools†† can build a Docker image to do the minimisation+isolation.

That said, Nix might also be completely overkill in some scenarios where static linking would be just fine and very practical. The practical simplicity of a single binary should not be overlooked.

† nixpkgs is sufficient, a full nixos is not needed

†† https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTool...

So Nix keeps track of different versions of shared libraries?

Yeah, each package/lib is stored in a unified directory by it's hash https://zero-to-nix.com/concepts/nix-store. Different variation different hash.

You've missed nix-bundle and pkgsStatic, which are much closer to the above idea re: copying to another machine.

I still don't understand.

Is oasis the "drop in binary" you would use? Or do you use oasis to build the tool that you would use?

"The allure of something like this is I could potentially grab a drop in binary"

From where?

> Can someone explain a couple use cases for something like this?

At this point, it would be more useful if someone explained a couple of use cases for dynamic linking.

Plugins, unless you want to have one process per plugin.

Which in the days of running Kubernetes clusters on laptops maybe isn't a big deal.

You can still call dlopen from your static binary, if you really want to.

Sure lets go back to 1980's UNIX, it was such a great experience.

I tried to do this recently at $DAYJOB, but when you statically link a binary with musl, the dlopen() you get is a no-op:

https://github.com/bpowers/musl/blob/master/src/ldso/dlopen....

I tried to hack in a copy of the musl's dynamic loader (and also from old uclibc). But it took a few hours and my only result was segfaults.

Do you have any pointers on making this work?

Have you tried it with glibc? It's harder to build static binaries with it, but it's still possible, and it may work.

To debug your problem, do you have a minimal example at your fingertips to try? Just a "hello world" dynlib that is called from a static program that doesn't do anything else.

You miss UNIX developer experience until mid-1980's, before shared objects came to be.

Heh...rebuilding gcc on slackware to enable shared libs was an adventure - but that wasn't till the late 90s(??). I think I spent like a week bootstrapping the new gcc, rebuilding glibc and rebuilding all the stuff I used.

UNIX System V 4.0 was the one that kind of uniformized existing parallel solutions from UNIX variants, alongside ELF in the late 1980's.

yeah - I never had access to a 'real' unix. Closest I came was solaris and maybe Irix. Other then that, it's just been Linux. Keep meaning to give *BSD a try...

P.S. - oh! and I had friends that loved HP/UX - another one I never got to try

immutable images

Reply on news.ycombinator.com