3 ms·

It must be something in the air. I find flatpak, appimage, snap etc underwhelming. The go reimplementation¹ of appimage looks promising, but it would be nicer i

It must be something in the air. I find flatpak, appimage, snap etc underwhelming. The go reimplementation¹ of appimage looks promising, but it would be nicer if one could more easily link Linux applications statically. Another idea would be to build a "meta-libc", MIT licensed, which exports a glibc compatible interface but called musl or whatever else libc under the hood for implementation. This is slightly complicated by the fact that musl does not export any version define or symbol. Or just fork musl and start adding glibc-isms to it... 1: https://github.com/probonopd/go-appimage https://github.com/probonopd/go-appimage

Y_Y 2y ago
I'm with you, if what you're saying is that containerized applications are a cop-out. On the other hand, they have their uses. For example Valve seems to have a hard time packaging Steam (being a weird 32bit web browser with DRM), but the flatpak (produced independently) works nicely, and because it's closed source it's your best option. (Also I think it's too kind to include Snap with the others, I find it uniquely objectionable since it's neither convenient nor functional.) edit: clarify that the Steam flatpak is not made by Valve
- ELFfBtiN1yLzonf 2y ago
  > their flatpak Steam flatpak was not created by and is not supported by Valve. It's an unofficial project, and flathub says as much (I'm assuming you mean the flathub package): https://flathub.org/apps/com.valvesoftware.Steam https://flathub.org/apps/com.valvesoftware.Steam > Unverified https://github.com/flathub/com.valvesoftware.Steam https://github.com/flathub/com.valvesoftware.Steam
ELFfBtiN1yLzonf 2y ago
A user-friendly wrapper around nix would be much more functional (in all meanings of the word) and interesting than any of those solutions. Unfortunately, the world is moving in the opposite direction.
- eigenspace 2y ago
  What makes you say the world is moving in the opposite direction?
  - Brian_K_White 2y ago
    nix answers the question of how to ship an app and have it run on different systems that aren't all identical to the developers, by shipping a thorough recipe for how to construct the app and everything the app depends on in it's environment, and uses essentially a bunch of symlinks so that that app sees the environment it needs. The rest of the world is adopting docker, flatpak, snap, appimage, etc which all just ship a whole os along with the app. Nix is reinventing one aspect of SCO Unix but better, and flatpak/appimage/snap are reinventing static binaries but grossly worse.
    - ruthmarx 2y ago
      Is having a bunch of symlinks and a giant config file really that much better than shipping the libraries an app needs to run with the app itself?
      - actionfromafar 2y ago
        Now, if something can pull everything from a Nix conf into a docker... that'd be useful. :-D Not something anyone dreamed of I guess.
        mastax 2y ago
        Is this what you were thinking of or something else? https://nix.dev/tutorials/nixos/building-and-running-docker-images.html https://nix.dev/tutorials/nixos/building-and-running-docker-...
        actionfromafar 2y ago
        I'll be darned. Cool.
jmclnx 2y ago
> I find flatpak, appimage, snap etc underwhelming Same here, in fact at home I avoid these like the plague. Work was a different story on RHEL :( But if people what to see a great sandbox type setup, look at OpenBSD's pledge(2) and unveil(2). Easy to implement plus you do not eat up disk space with duplicate copies of everything.

Y_Y 2y ago

I'm with you, if what you're saying is that containerized applications are a cop-out. On the other hand, they have their uses. For example Valve seems to have a hard time packaging Steam (being a weird 32bit web browser with DRM), but the flatpak (produced independently) works nicely, and because it's closed source it's your best option. (Also I think it's too kind to include Snap with the others, I find it uniquely objectionable since it's neither convenient nor functional.) edit: clarify that the Steam flatpak is not made by Valve

ELFfBtiN1yLzonf 2y ago
> their flatpak Steam flatpak was not created by and is not supported by Valve. It's an unofficial project, and flathub says as much (I'm assuming you mean the flathub package): https://flathub.org/apps/com.valvesoftware.Steam https://flathub.org/apps/com.valvesoftware.Steam > Unverified https://github.com/flathub/com.valvesoftware.Steam https://github.com/flathub/com.valvesoftware.Steam

ELFfBtiN1yLzonf 2y ago

A user-friendly wrapper around nix would be much more functional (in all meanings of the word) and interesting than any of those solutions. Unfortunately, the world is moving in the opposite direction.

eigenspace 2y ago
What makes you say the world is moving in the opposite direction?
- Brian_K_White 2y ago
  nix answers the question of how to ship an app and have it run on different systems that aren't all identical to the developers, by shipping a thorough recipe for how to construct the app and everything the app depends on in it's environment, and uses essentially a bunch of symlinks so that that app sees the environment it needs. The rest of the world is adopting docker, flatpak, snap, appimage, etc which all just ship a whole os along with the app. Nix is reinventing one aspect of SCO Unix but better, and flatpak/appimage/snap are reinventing static binaries but grossly worse.
  - ruthmarx 2y ago
    Is having a bunch of symlinks and a giant config file really that much better than shipping the libraries an app needs to run with the app itself?
    - actionfromafar 2y ago
      Now, if something can pull everything from a Nix conf into a docker... that'd be useful. :-D Not something anyone dreamed of I guess.
      - mastax 2y ago
        Is this what you were thinking of or something else? https://nix.dev/tutorials/nixos/building-and-running-docker-images.html https://nix.dev/tutorials/nixos/building-and-running-docker-...
        actionfromafar 2y ago
        I'll be darned. Cool.

jmclnx 2y ago

> I find flatpak, appimage, snap etc underwhelming Same here, in fact at home I avoid these like the plague. Work was a different story on RHEL :( But if people what to see a great sandbox type setup, look at OpenBSD's pledge(2) and unveil(2). Easy to implement plus you do not eat up disk space with duplicate copies of everything.