4 ms·

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

by ghotli 3y ago

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.

8organicbits 3y ago
> 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/
- ghotli 3y ago
  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.
  - 8organicbits 3y ago
    Agreed, dynamically linked binaries don't drop in well.
  - lloeki 3y ago
    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-dockerTools https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTool...
    - vacuity 3y ago
      So Nix keeps track of different versions of shared libraries?
      - sporeray 3y ago
        Yeah, each package/lib is stored in a unified directory by it's hash https://zero-to-nix.com/concepts/nix-store https://zero-to-nix.com/concepts/nix-store. Different variation different hash.
    - YoshiRulz 3y ago
      You've missed nix-bundle and pkgsStatic, which are much closer to the above idea re: copying to another machine.
nightowl_games 3y ago
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?

by ghotli 3y ago

8organicbits 3y ago

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

ghotli 3y ago
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.
- 8organicbits 3y ago
  Agreed, dynamically linked binaries don't drop in well.
- lloeki 3y ago
  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-dockerTools https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTool...
  - vacuity 3y ago
    So Nix keeps track of different versions of shared libraries?
    - sporeray 3y ago
      Yeah, each package/lib is stored in a unified directory by it's hash https://zero-to-nix.com/concepts/nix-store https://zero-to-nix.com/concepts/nix-store. Different variation different hash.
  - YoshiRulz 3y ago
    You've missed nix-bundle and pkgsStatic, which are much closer to the above idea re: copying to another machine.

nightowl_games 3y ago

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?