6 ms·

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

ekianjo 3y ago
immutable images
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?
pjmlp 3y ago
You miss UNIX developer experience until mid-1980's, before shared objects came to be.
- mech422 3y ago
  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.
  - pjmlp 3y ago
    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.
    - mech422 3y ago
      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
enriquto 3y ago
> 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.
- pjmlp 3y ago
  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.
  - enriquto 3y ago
    You can still call dlopen from your static binary, if you really want to.
    - pjmlp 3y ago
      Sure lets go back to 1980's UNIX, it was such a great experience.
    - mappu 3y ago
      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.c 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?
      - enriquto 3y ago
        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.

immutable images

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?

pjmlp 3y ago

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

mech422 3y ago
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.
- pjmlp 3y ago
  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.
  - mech422 3y ago
    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

enriquto 3y ago

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

pjmlp 3y ago
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.
- enriquto 3y ago
  You can still call dlopen from your static binary, if you really want to.
  - pjmlp 3y ago
    Sure lets go back to 1980's UNIX, it was such a great experience.
  - mappu 3y ago
    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.c 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?
    - enriquto 3y ago
      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.