Show HN: FELF – AppImage-like single binaries without FUSE, root, or a runtime | Hacker News Reader

Show HN: FELF – AppImage-like single binaries without FUSE, root, or a runtime

github.com

4 pointsRucadi2 comments

Hello HN!

I've always had a bad time redistributing programs that use shared libraries, AppImage in my opinion does too much, and a container is an overkill - not always integrates smoothly.

I've moved to nix since long ago, but redistributing between nix and other distros or vice versa it's still a pain in the ass, more so if you want to run an alien app in nix or a nix app without the package manger in any other distro.

For that, with the help of Claude, I've implemented a format that deduces at pack-time all the shared libraries a program needs, puts them, together with its own glibc and a patched dynamic linker into a single executable.

This means that you don't actually need a runtime nor any special capability, it can run inside a FROM SCRATCH docker, alpine linux etc... And it also supports coreutils-like multiple programs accessible via symlinks, so it is a good fit for that purpose.

You can just use:

> felf pack $(which git) --output git.felf

and you'll have already a git binary that works everywhere, no matter which distro you are building this from. This only packs the binary and their dependencies.

Essentially, the effect is similar as if you LD_PRELOAD's all the libraries that it requires.

In the end, we have been fighting these demons since long long ago, chroots/docker/appimage/flatpack/nix etc...

So this xkcd applies: https://xkcd.com/927/

I'm happy to share the project, I hope it inspires new discoveries/tools in this regard!

Open articleView on HN

This is really beautiful from first glance.

I had built appseed[0] inspired by zapps.app (curious what you think about that)

and although, I could get some apps like bun and others to work statically using that. I struggled to make it work on things like OBS studio and it certainly had a lot of limitations with how it worked.

It had a different approach of working where instead of pushing everything into a single binary, you had the .so file outside in an external filesystem of binary, could something like this work within FELF as well theoretically (for de-duplication purposes perhaps)?

It seems that your experiment can work for almost every app including OBS and other complicated applications. I am rather really impressed by it and I will try to try it!

I wonder if games can now be FELF'd as well and we can have containerized games into single binaries maybe, where I can just "run" games.

What do you personally think could be the largest benefits of this approach and if there are any further things that you are pursuing in this area?

This is really impressive work and thank you for releasing it! Have a nice day :-D

[0]: https://github.com/serJaimeLannister/appseed

Your project seems cool! It's basically the same nix does on a derivation when packing a binary blob!

That's totally cool! It also how we always tried to fix the problem, the only nitpick there is that without bundling glibc-dynamic linker it won't work on systems with older glibc than your own.

And yes! I've tried complex programs like Krita, packaging and putting it on an empty ubuntu and it worked!

That's one of the reasons I added the "plugin" option, in the case of krita and other apps, the .so are loaded from the FS, and I wanted to ensure that I copied .SO files of the plugins that may have not been covered by the main binaries.

In a sense, FELF right now also serves a little as a "sandbox", in which you can decide if you want to be able to load arbitrary shared libraries or not at pack time.

Thanks a lot for the comments :D

Reply on news.ycombinator.com