Comment by ghotli | Hacker News Reader

Comment by ghotli | Hacker News Reader

Parent Full thread

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.

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...

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

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.

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

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?

Reply on news.ycombinator.com