Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux apps that run anywhere

appimage.org

Post reply on HN
Print view View original

81–90 of 117 posts

Re: Linux apps that run anywhere

#81

Post by pjmlp »

Annatar wrote: post #75
pjmlp wrote: post #57

Earlier quoted context omitted.

Because those providing the said technology cannot agree what it means to be a GNU/Linux OS, and we have limited time on our life to bother with thousand variants of it.

But you don't have limited time to re-invent the wheel over and over again by inventing new programming languages, learning new frameworks and re-implementing what already exists? How many headlines here were of the "why do it inefficiently? Because I can!" type? The limited time argument is a fallacy in this context.

A language package manager works everywhere, regadless of the OS.

Thankfully modern languages are mostly OS agnostic due to their rich runtimes and library eco-systems.

Re: Linux apps that run anywhere

#82

Post by flohofwoe »

earenndil wrote: post #54
kitotik wrote: post #33

Earlier quoted context omitted.

Isn’t cross platform/multi vendor development the cause? Static binaries are just a form of vertical integration.

The problem that's being solved is that vendors are incompatible, which could easily be solved if they were compatible. They all run a linux kernel. They all use ELF and x11 and opengl. If I compile 'hello, world' on one distro, I can drop it onto another random distro and it'll still work, but after a certain threshold of complexity, that stops working. It doesn't have to stop working.

Even a simple hello-world doesn't work across distros since it requires a specific version of glibc.

Re: Linux apps that run anywhere

#83

Post by nyanloutre »

tigrezno wrote: post #67
Pneumaticat wrote: post #20

FYI, AppImages do not run anywhere. There are a lot of issues with them in NixOS, since NixOS is all about having explicitly-linked dependencies, and AppImages still often have implicit dependencies that aren't in the image itself, since they are assumed to exist on the host system. See https://github.com/NixOS/nixpkgs/pull/51060 for an example.

but who really uses NixOS? a 0.001% of linux users?

How did you came up with that number ?

Re: Linux apps that run anywhere

#84

Post by ktpsns »

Pneumaticat wrote: post #20

FYI, AppImages do not run anywhere. There are a lot of issues with them in NixOS, since NixOS is all about having explicitly-linked dependencies, and AppImages still often have implicit dependencies that aren't in the image itself, since they are assumed to exist on the host system. See https://github.com/NixOS/nixpkgs/pull/51060 for an example.

Something you can do always on a Linux system as a user is to run the AppImage with

  LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" ./Your*.AppImage
and, before that, put all the missing dynamic libraries in the same path. That task might however be nontrivial due to (hiearchical/nested) dependencies (try "ldd *.so" to inspect it) of the so files itself. That's one of the reasons why we have package managers at the first place...

Re: Linux apps that run anywhere

#85

Post by ktpsns »

Wowfunhappy wrote: post #13
dorfsmay wrote: post #3

Anybody has strong feelings about AppImage vs Snap vs Flatpack (and any other similar ones)?

AppImage makes me nervous because they don't actually create promise cross distro compatibility—it depends on what libraries the developer decides to ship alongside the AppImage, and which they assume the distro has. This also raises questions about forwards compatibility with future OS releases. Snap and Flatpak, by contrast, have explicit systems in place to prevent this. Of the two, I much prefer Flatpak for being…

On the other hand, AppImages are dead easy. They do not assume any host infrastructure installed which is especially handy if you are lacking root on a shared system.

Re: Linux apps that run anywhere

#86

Post by cesarb »

sprash wrote: post #79
zurn wrote: post #74

Earlier quoted context omitted.

The static linking ship has sailed years ago for glibc based apps (no static linking support).

Always use musl for static linking. As a bonus you might get an even smaller binary than a dynamically linked glibc binary.

Keep in mind, however, that AFAIK musl won't respect /etc/nsswitch.conf, so if for instance the machine is configured to lookup users on ldap, a musl static linked program won't be able to correctly lookup users.

Re: Linux apps that run anywhere

#87

Post by progval »

stubish wrote: post #31
giancarlostoro wrote: post #2

You know if even Linus Torvalds likes it, you've done something right. I love the idea of solving the current approaches to installing / maintaining software on Linux. This is one approach I do like, but I still appreciate maintaining packages through a package manager. I would love to see a best of both worlds, packages like deb that can both run directly and be managed through the package manager, depending on how…

The quote doesn't say he liked it. The quote says it is 'just very cool'. Maybe I've dealt with too many out of context book blurbs and sound bites in my time, but a single dubious endorsement like that is worse than no endorsements.

Full quote: https://web.archive.org/web/20170914030116/https://plus.goog...

Re: Linux apps that run anywhere

#88

Post by oblio »

flukus wrote: post #65
oblio wrote: post #58

Earlier quoted context omitted.

With your logic, you've already lost. If you don't trust the developer of an application you already run, you're screwed in any scenario. Yours is not a realistic threat model.

Developers don't deserve that trust. It's not just threat model, developers are increasingly focusing on fast iteration and annoying users with constant and often unwanted updates, something debian saves users from, very few users care about always having the latest features and bugs or want to become beta testers. Not to mention the privacy shitshow from developers wanting telemetry or more nefarious reasons. Softwa…

Distributions in their current form are almost harmful. I like what they do, conceptually, but that model you're describing should only apply for the base system. I want Firefox to update ASAP, I want VLC to update ASAP.

The distribution model should only apply to libraries and base tools. And even those should be versioned so they can coexist easily and I'm easily able to install any app, from the ones that want GTK1 to the ones that want GTKLatest.

Re: Linux apps that run anywhere

#89

Post by hardwaresofton »

Conan_Kudo wrote: post #64
mickael-kerjean wrote: post #44

Earlier quoted context omitted.

In theory. In practise it's much faster to push for a fix to your users with a brand new fat binary than having to figure out the mess that is distributing your software on every possible Linux distribution (obligatory XKCD: https://xkcd.com/927/ ). Also shared libaries assumed your software will work on a different version of a library which is quite a bold assumption that may or may be true depending on the phase o…

> In theory. In practise it's much faster to push for a fix to your users with a brand new fat binary than having to figure out the mess that is distributing your software on every possible Linux distribution (obligatory XKCD: https://xkcd.com/927/ ). Electron seems to have disproved this. There are many Electron based applications that are broken with glibc >= 2.28 even though a fixed version of Electron has been ou…

Would you mind explaining more about this? I'm not sure I understand completely what you mean -- glibc is basically impossible to statically build and is linked. It's part of the reason why "static" builds don't really exist on debian and many other distributions. Correct me if I'm wrong but glibc just isn't portable -- this is why I mentioned having to go into alpine & build with musl libc. Seems like the electron project has chosen not to support it[0].

Another aspect worth considering is the software logistics/delivery problem -- it absolutely would be great to have dynamically linked software updates if:

1) Your software could always ensure to get the version it expects with the version it expects

2) It wasn't hard to distribute the software (AKA X > 5 providers are hard to package for)

Assuming I'm not completely misunderstanding your point, if the electron based applications you're discussing were truly fat binaries, nothing could break them, outside of CPU architecture level impropriety.

BTW, there are some systems like Nix & Guix that have solved #1 -- it's extremely easy to ensure that your program gets the exact version of some dependency.

[0]: https://github.com/electron/electron/issues/9662

Re: Linux apps that run anywhere

#90

Post by hardwaresofton »

mickael-kerjean wrote: post #44
pknopf wrote: post #29

Earlier quoted context omitted.

What if another heartbleed happens? Wouldn't it be better to update a single shared library?

In theory. In practise it's much faster to push for a fix to your users with a brand new fat binary than having to figure out the mess that is distributing your software on every possible Linux distribution (obligatory XKCD: https://xkcd.com/927/ ). Also shared libaries assumed your software will work on a different version of a library which is quite a bold assumption that may or may be true depending on the phase o…

I agree with this -- I also think it's much easier to check for vulnerabilities this way.

It's a bit of a stretch but I think we're moving towards a more micro-kernel approach across the board -- trying to move more and more code/libs into the software artifacts we run (in part making them bigger, like with containers/AppImage/snaps/flatpak).

I'm no security expert, but I think it's much easier to maintain the security of barebones systems + fat binaries than big systems with smaller binaries. Running programs that are supposedly self-sufficient (i.e. will never need to dynamically link) is easier to reason about and secure.

Also, there's the current renaissance in virtual machines and sandboxing tech (nemu, firecracker, gvisor, etc) which are being currently used for containers and cloud stuff but can usher in a huge level of security for the typical user as well.

Post reply on HN