25 ms·

Linux apps that run anywhere

89 points by devaroop 7y ago

giancarlostoro 7y ago
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 you choose to run them.
- stubish 7y ago
  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.
  - progval 7y ago
    Full quote: https://web.archive.org/web/20170914030116/https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS https://web.archive.org/web/20170914030116/https://plus.goog...
    - stubish 7y ago
      Would suggest "This is just very cool [...] works very well" to avoid people like me reading through the lines ;)
dorfsmay 7y ago
Anybody has strong feelings about AppImage vs Snap vs Flatpack (and any other similar ones)?
- sandov 7y ago
  I like the concept of AppImage much more than Snap and Flatpak. I fully embrace the idea of decentralized distribution of applications, as opposed to the way package managers work (central repository mantained by the distro) I believe the operating system should only be concerned about the base software and present a sane interface so that the user can then install the specific programs they need, the OS should not care about how or where the user gets those programs. Appimage is the only project I know that respects that idea. Snap and Flatpak are centralized AFAIK (or are unnecessarily hard to use in a decentralized manner).
  - viraptor 7y ago
    If you haven't seen it yet, you may find Fedora Silverblue interesting.
    - sandov 7y ago
      I'll take a look at it. Thanks for the suggestion.
  - Wowfunhappy 7y ago
    Flatpak's can be distributed as standalone ".flatpak" bundles that can be installed offline. I'm not sure why this isn't promoted more.
  - deviantfero 7y ago
    How is this different from windows? I think this is good for dependency heavy apps, such as krita, but you should still try to keep things as centralized as possible, makes updates easier and painless
    - sandov 7y ago
      it's not fundamentally different. The practical difference is that the ecosystem of Linux applications is composed almost entirely of open source software. Consequently, installing something you downloaded from the web is much less dangerous than installing a closed source program on Window, provided that you trust the website. I agree that the centralized scheme is easier to use in the 80% of cases. i.e. when: (1) The package you want is in the repos, and ... (2) The version of the package you want is in the repos. But, when those 2 conditions are not met, installing software is usually harder than on Windows. Additionally, I don't like the very nature of centralized things, even if they are managed by the good guys.
im_down_w_otp 7y ago
One of the issues I've had with things distributed as Snaps or Flatpaks is that they tend not to pickup the settings and preferences that I've configured on my workstation. For example, if I've setup themes, fonts, scaling factors, custom keyboard shortcuts, etc., they tend not to be available/utilized by the applications which are distributed in these bundling formats. For the most part, that's why I avoid using them. I assume, but don't actually know, that this also true of AppImage. Can anybody who knows better confirm, or deny, that?
- viraptor 7y ago
  Just from reading the docs, it looks like your settings will be respected. By default it doesn't look like there's any sandboxing / namespaces happening. Haven't tried it in practice though.
- zaarn 7y ago
  Not any better than Flatpak or Snap in my experience, since Appimage applications have to (technically) ship their own libraries for everything.
- pushpop 7y ago
  Honestly, I would much prefer using a package manager than manually installing packages. Using a package manager means you only have one place to look for the package (searching in a browser for software can be so error prone for inexperienced users. Not to mention more disruptive and time consuming). Using a package manager means you only have one place for upgrade installers (3rd party updaters are a plague on Windows) and having everything updated through a centralised package manager means you’re less likely to overlook upgrading a package, which is better for your overall system security. My biggest gripe with OSX is that the default way of installing software is via manual downloading. Sure OSX has the AppStore, but that’s mostly garbage. Homebrew is a hell of a lot better but it’s frustrating that I have to install a 3rd party package manager on a modern OS. I get your rant about shared libraries but you can get around those problems surprisingly easily (eg you can ship your SOs in the package directory like you might with DLLs in Windows. Or you could just statistically compile your binaries and do away without the SO problem entirely). Problems with SOs are something you’d expect a junior Linux sysadmin to learn so any developer or maintainer worth their salt should have already figured this out.
voodootrucker 7y ago
What people use it for at the top, what it does in the middle, and how it works at the bottom, buried in a video - typical modern sites (except this one at least has the video). What I would like to see: 1. Problem statement 2. How this solves it 3. Usage guide 4. Source code link 5. No appeal to authority of who's using it
- satori99 7y ago
  > and how it works at the bottom, buried in a video A video that plays for 12 minutes before it explains the bit about using an ELF header which mounts a disk image payload using FUSE.
- beatgammit 7y ago
  Eh, I think 5 is important because it shows that there's a vested interest in keeping the project going. I absolutely do make decisions on what to use based on who is using it because switching to something else after a project dies is a royal pain, and I don't have the time to maintain it myself (though I can certainly submit patches here and there).
Annatar 7y ago
"No need to install". This is every system administrator's nightmare: users running arbitrary executables bypassing operating system packaging. Come time to upgrade or reinstall what can happen? If there are security updates which are needed to the program, what could happen, since this is statically linked? This is the pinnacle of destructive lazyness and amateurism in IT: as a developer it is one's job to master every operating system packaging format for the target platform one develops for. OS packaging is a tool invented for developers, not a tool meant to be subverted at every turn and opportunity like this.
- viraptor 7y ago
  I don't believe this is really a problem for administrators. Reasonable multi-user hosts will have both home and tmp mounted no-exec and will not allow fuse - appimage will not work. This solution will work just fine of personal machines though. I'd rather native packages were distributed too, but if the choice is this or nothing... why disappoint people?
- pjmlp 7y ago
  Any savy UNIX admin will be able to prevent new executables to run under user accounts.
  - Annatar 7y ago
    But it won't solve the problem of developers' unwillingness to learn how to make operating system packages now will it? I don't get it: people like that will sink and waste hundreds of hours learning useless garbage like Puppet, Ansible, Chef, Docker or Kubernetes without batting an eyelash or even thinking twice about it, but they'll argue and fight back like hell come time to deliver their software as clean OS packages because they don't want to learn the technology. Technology which exists for them first and foremost: OS packaging is meant to be a developer's tool and best friend.
    - pjmlp 7y ago
      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.
Pneumaticat 7y ago
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 https://github.com/NixOS/nixpkgs/pull/51060 for an example.
- allset_ 7y ago
  It also requires FUSE to work, which may not be available.
- tigrezno 7y ago
  but who really uses NixOS? a 0.001% of linux users?
  - nyanloutre 7y ago
    How did you came up with that number ?
  - majewsky 7y ago
    In my circle, roughly 30%.
  - anderspitman 7y ago
    There are dozens of us.
- sjellis 7y ago
  Yeah, AppImages are not really comparable to snap and Flatpak, which both address this issue by managing shared sets of libraries as well as applications. Flatpak calls these sets of libraries "runtimes", and snap calls them "base snaps". The metadata for each application declares one runtime or base snap that it uses. This ability to easily provide different userlands to different applications is one of the critical advantages of these new application formats.
- ktpsns 7y ago
hardwaresofton 7y ago
Video introduction to AppImage (linked on the AppImage website): https://www.youtube.com/watch?v=mVVP77jC8Fc https://www.youtube.com/watch?v=mVVP77jC8Fc Also, a side point -- is it wrong to want people to spend more energy on building fat binaries? To me they are the ultimate in portability (by definition), and investing in projects like musl libc and distributions like alpine, languages like go and rust that build portable static binaries is so much more accessible to me as a developer. All the approaches to portable apps seem to just be hacking around the problem but I wonder if we should instead be pouring energy into making fully static binaries easier to build, then trying to optimize them to get them smaller.
- pknopf 7y ago
  What if another heartbleed happens? Wouldn't it be better to update a single shared library?
  - mickael-kerjean 7y ago
    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/ 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 of the moon
    - Conan_Kudo 7y ago
      > 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/ 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 out for it for nearly a year. Fat binaries (or fat binpacks) are a failure.
earenndil 7y ago
It makes me really sad that this is necessary. Unix has a concept of shared libraries. And somehow it managed to get ruined so irrevocably that there's no going back. This—this was a solved problem! It really was. It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability. And now shared libraries are completely useless. I struggle to name a single useful c library that's useful as a system-wide shared library nowadays. Libc/m doesn't really count because it's part of the language, and libz is small enough that everyone who needs it statically links it. Everything else is neither ubiquitous nor stable enough to be used. HOW DID THIS HAPPEN?
- kitotik 7y ago
  Isn’t cross platform/multi vendor development the cause? Static binaries are just a form of vertical integration.
  - earenndil 7y ago
    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.
    - flohofwoe 7y ago
      Even a simple hello-world doesn't work across distros since it requires a specific version of glibc.
      - earenndil 7y ago
        The glibc version tagging has to do with specific symbols; hello world just uses printf which is there since forever. (Actually the compiler probably optimizes it down to a syscall but.)
baroffoos 7y ago
What is the difference between appimage and just a binary marked as executable?
- osrec 7y ago
  It's supposed to contain all its dependencies.
opan 7y ago
I'd rather see people use Guix or Nix when their native package manager doesn't have something.
sprash 7y ago
If you want portable apps just make one fully staticly compiled binary. This is the worst of all worlds. No security updates for used libraries and no performance gain that comes with static linking.
- zurn 7y ago
  The static linking ship has sailed years ago for glibc based apps (no static linking support).
  - sprash 7y ago
    Always use musl for static linking. As a bonus you might get an even smaller binary than a dynamically linked glibc binary.
    - cesarb 7y ago
      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.
      - beatgammit 7y ago
        There are certainly cases where you need the features of glibc over musl, but those are pretty rare IMO, and you can always implement a missing piece yourself if using musl saves you enough in maintenance overhead.
hpaavola 7y ago
"To run an AppImage, simply: Make it executable $ chmod a+x Subsurface.AppImage and run! $ ./Subsurface.AppImage That was easy, wasn't it?" No. How about click/double click the app icon in your menu/desktop/the folder where you downloaded it into?
- IloveHN84 7y ago
  You need .desktop files in /use/share/apps
  - hpaavola 7y ago
    I, as a user, do not need any files in /usr/share/apps. The system might need. And I don't want to deal with those. All other major operating systems (can) work like this; download something > click it > it works. No need to launch terminal, set executable permissions and type the name of file.
shmerl 7y ago
Don't forget about trade-offs. Such kind of bundled packages have worse security than distro packaged method, where dependencies are getting patches and fixes. Because most developers won't ever bother patching their bundled dependencies. So know what you are paying with.
jhoh 7y ago
This website just makes me angry: - Fixed social media share buttons that cover the text on mobile - It auto-translates to German even though my system language is set to English (seems like they use geolocation for this which is bad practise) - Center aligned text that is annoying to read
Lowkeyloki 7y ago
What I'm disappointed about with AppImage is that it doesn't deal with differing architectures as far as I can tell. Which would really help me right now as I had to send my laptop to Dell for repairs and I'm now using just my Android phone and my Raspberry Pi 3B+ as a desktop. And compiling stuff on the Pi is SO SLOW!
TBF-RnD 7y ago
Come on guys, I see a lot of negativity here but we can have the cake and eat it. Look at the following imaginary but likely scenario. A promising coder creates an app in C using cmake or whatever. For a veteran linux user to use git and compile is not a problem. Our up and comming coder want to reach out to a wider audience however so instead of creating X packages he provides an appimage. All of the sudden all the fedora, debian and ubuntu guys etcetera can run it without the hassle. Now imagine if the project turns out to be a silver bullet for some really important problem. What will happen, the maintainers for the bigger distros will simply download the code and there will be maintainers that steps up and maintains the software for the repos. Voila, the best of two worlds. ... and if the project doesn't become a huge mainstream access users now can get it via source or appimage . As far as commercial projects are concerned they will operate according to different dynamics. But who cares we want open source solutions for our linux systems anyway.
zurn 7y ago
Does it work on Android? For cli apps running under adb, at least?
znpy 7y ago
Every app packaging its own shared library and runtime because someone didn't want to deal with packaging software. I foresee someone in five years complaining about how much RAM linux on the desktop uses. And somebody else blaming it on shared libraries not actually being shared because all the "apps" load their own snowflake library. So multiple copies of glibc, multiple copies of gtk, multiple copies of everything. RIP RAM AND WALLET.

89 points by devaroop 7y ago

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 you choose to run them.

stubish 7y ago
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.
- progval 7y ago
  Full quote: https://web.archive.org/web/20170914030116/https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS https://web.archive.org/web/20170914030116/https://plus.goog...
  - stubish 7y ago
    Would suggest "This is just very cool [...] works very well" to avoid people like me reading through the lines ;)

dorfsmay 7y ago

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

sandov 7y ago
I like the concept of AppImage much more than Snap and Flatpak. I fully embrace the idea of decentralized distribution of applications, as opposed to the way package managers work (central repository mantained by the distro) I believe the operating system should only be concerned about the base software and present a sane interface so that the user can then install the specific programs they need, the OS should not care about how or where the user gets those programs. Appimage is the only project I know that respects that idea. Snap and Flatpak are centralized AFAIK (or are unnecessarily hard to use in a decentralized manner).
- viraptor 7y ago
  If you haven't seen it yet, you may find Fedora Silverblue interesting.
  - sandov 7y ago
    I'll take a look at it. Thanks for the suggestion.
- Wowfunhappy 7y ago
  Flatpak's can be distributed as standalone ".flatpak" bundles that can be installed offline. I'm not sure why this isn't promoted more.
- deviantfero 7y ago
  How is this different from windows? I think this is good for dependency heavy apps, such as krita, but you should still try to keep things as centralized as possible, makes updates easier and painless
  - sandov 7y ago
    it's not fundamentally different. The practical difference is that the ecosystem of Linux applications is composed almost entirely of open source software. Consequently, installing something you downloaded from the web is much less dangerous than installing a closed source program on Window, provided that you trust the website. I agree that the centralized scheme is easier to use in the 80% of cases. i.e. when: (1) The package you want is in the repos, and ... (2) The version of the package you want is in the repos. But, when those 2 conditions are not met, installing software is usually harder than on Windows. Additionally, I don't like the very nature of centralized things, even if they are managed by the good guys.

im_down_w_otp 7y ago

One of the issues I've had with things distributed as Snaps or Flatpaks is that they tend not to pickup the settings and preferences that I've configured on my workstation. For example, if I've setup themes, fonts, scaling factors, custom keyboard shortcuts, etc., they tend not to be available/utilized by the applications which are distributed in these bundling formats. For the most part, that's why I avoid using them. I assume, but don't actually know, that this also true of AppImage. Can anybody who knows better confirm, or deny, that?

viraptor 7y ago
Just from reading the docs, it looks like your settings will be respected. By default it doesn't look like there's any sandboxing / namespaces happening. Haven't tried it in practice though.
zaarn 7y ago
Not any better than Flatpak or Snap in my experience, since Appimage applications have to (technically) ship their own libraries for everything.
pushpop 7y ago
Honestly, I would much prefer using a package manager than manually installing packages. Using a package manager means you only have one place to look for the package (searching in a browser for software can be so error prone for inexperienced users. Not to mention more disruptive and time consuming). Using a package manager means you only have one place for upgrade installers (3rd party updaters are a plague on Windows) and having everything updated through a centralised package manager means you’re less likely to overlook upgrading a package, which is better for your overall system security. My biggest gripe with OSX is that the default way of installing software is via manual downloading. Sure OSX has the AppStore, but that’s mostly garbage. Homebrew is a hell of a lot better but it’s frustrating that I have to install a 3rd party package manager on a modern OS. I get your rant about shared libraries but you can get around those problems surprisingly easily (eg you can ship your SOs in the package directory like you might with DLLs in Windows. Or you could just statistically compile your binaries and do away without the SO problem entirely). Problems with SOs are something you’d expect a junior Linux sysadmin to learn so any developer or maintainer worth their salt should have already figured this out.

voodootrucker 7y ago

What people use it for at the top, what it does in the middle, and how it works at the bottom, buried in a video - typical modern sites (except this one at least has the video). What I would like to see: 1. Problem statement 2. How this solves it 3. Usage guide 4. Source code link 5. No appeal to authority of who's using it

satori99 7y ago
> and how it works at the bottom, buried in a video A video that plays for 12 minutes before it explains the bit about using an ELF header which mounts a disk image payload using FUSE.
beatgammit 7y ago
Eh, I think 5 is important because it shows that there's a vested interest in keeping the project going. I absolutely do make decisions on what to use based on who is using it because switching to something else after a project dies is a royal pain, and I don't have the time to maintain it myself (though I can certainly submit patches here and there).

Annatar 7y ago

"No need to install". This is every system administrator's nightmare: users running arbitrary executables bypassing operating system packaging. Come time to upgrade or reinstall what can happen? If there are security updates which are needed to the program, what could happen, since this is statically linked? This is the pinnacle of destructive lazyness and amateurism in IT: as a developer it is one's job to master every operating system packaging format for the target platform one develops for. OS packaging is a tool invented for developers, not a tool meant to be subverted at every turn and opportunity like this.

viraptor 7y ago
I don't believe this is really a problem for administrators. Reasonable multi-user hosts will have both home and tmp mounted no-exec and will not allow fuse - appimage will not work. This solution will work just fine of personal machines though. I'd rather native packages were distributed too, but if the choice is this or nothing... why disappoint people?
pjmlp 7y ago
Any savy UNIX admin will be able to prevent new executables to run under user accounts.
- Annatar 7y ago
  But it won't solve the problem of developers' unwillingness to learn how to make operating system packages now will it? I don't get it: people like that will sink and waste hundreds of hours learning useless garbage like Puppet, Ansible, Chef, Docker or Kubernetes without batting an eyelash or even thinking twice about it, but they'll argue and fight back like hell come time to deliver their software as clean OS packages because they don't want to learn the technology. Technology which exists for them first and foremost: OS packaging is meant to be a developer's tool and best friend.
  - pjmlp 7y ago
    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.

Pneumaticat 7y ago

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 https://github.com/NixOS/nixpkgs/pull/51060 for an example.

allset_ 7y ago
It also requires FUSE to work, which may not be available.
tigrezno 7y ago
but who really uses NixOS? a 0.001% of linux users?
- nyanloutre 7y ago
  How did you came up with that number ?
- majewsky 7y ago
  In my circle, roughly 30%.
- anderspitman 7y ago
  There are dozens of us.
sjellis 7y ago
Yeah, AppImages are not really comparable to snap and Flatpak, which both address this issue by managing shared sets of libraries as well as applications. Flatpak calls these sets of libraries "runtimes", and snap calls them "base snaps". The metadata for each application declares one runtime or base snap that it uses. This ability to easily provide different userlands to different applications is one of the critical advantages of these new application formats.
ktpsns 7y ago

hardwaresofton 7y ago

Video introduction to AppImage (linked on the AppImage website): https://www.youtube.com/watch?v=mVVP77jC8Fc https://www.youtube.com/watch?v=mVVP77jC8Fc Also, a side point -- is it wrong to want people to spend more energy on building fat binaries? To me they are the ultimate in portability (by definition), and investing in projects like musl libc and distributions like alpine, languages like go and rust that build portable static binaries is so much more accessible to me as a developer. All the approaches to portable apps seem to just be hacking around the problem but I wonder if we should instead be pouring energy into making fully static binaries easier to build, then trying to optimize them to get them smaller.

pknopf 7y ago
What if another heartbleed happens? Wouldn't it be better to update a single shared library?
- mickael-kerjean 7y ago
  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/ 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 of the moon
  - Conan_Kudo 7y ago
    > 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/ 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 out for it for nearly a year. Fat binaries (or fat binpacks) are a failure.

earenndil 7y ago

It makes me really sad that this is necessary. Unix has a concept of shared libraries. And somehow it managed to get ruined so irrevocably that there's no going back. This—this was a solved problem! It really was. It was solved, and then we unsolved it when we decided that 'move fast and break things' was more important than ABI stability. And now shared libraries are completely useless. I struggle to name a single useful c library that's useful as a system-wide shared library nowadays. Libc/m doesn't really count because it's part of the language, and libz is small enough that everyone who needs it statically links it. Everything else is neither ubiquitous nor stable enough to be used. HOW DID THIS HAPPEN?

kitotik 7y ago
Isn’t cross platform/multi vendor development the cause? Static binaries are just a form of vertical integration.
- earenndil 7y ago
  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.
  - flohofwoe 7y ago
    Even a simple hello-world doesn't work across distros since it requires a specific version of glibc.
    - earenndil 7y ago
      The glibc version tagging has to do with specific symbols; hello world just uses printf which is there since forever. (Actually the compiler probably optimizes it down to a syscall but.)

baroffoos 7y ago

What is the difference between appimage and just a binary marked as executable?

osrec 7y ago
It's supposed to contain all its dependencies.

opan 7y ago

I'd rather see people use Guix or Nix when their native package manager doesn't have something.

sprash 7y ago

If you want portable apps just make one fully staticly compiled binary. This is the worst of all worlds. No security updates for used libraries and no performance gain that comes with static linking.

zurn 7y ago
The static linking ship has sailed years ago for glibc based apps (no static linking support).
- sprash 7y ago
  Always use musl for static linking. As a bonus you might get an even smaller binary than a dynamically linked glibc binary.
  - cesarb 7y ago
    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.
    - beatgammit 7y ago
      There are certainly cases where you need the features of glibc over musl, but those are pretty rare IMO, and you can always implement a missing piece yourself if using musl saves you enough in maintenance overhead.

hpaavola 7y ago

"To run an AppImage, simply: Make it executable $ chmod a+x Subsurface.AppImage and run! $ ./Subsurface.AppImage That was easy, wasn't it?" No. How about click/double click the app icon in your menu/desktop/the folder where you downloaded it into?

IloveHN84 7y ago
You need .desktop files in /use/share/apps
- hpaavola 7y ago
  I, as a user, do not need any files in /usr/share/apps. The system might need. And I don't want to deal with those. All other major operating systems (can) work like this; download something > click it > it works. No need to launch terminal, set executable permissions and type the name of file.

shmerl 7y ago

Don't forget about trade-offs. Such kind of bundled packages have worse security than distro packaged method, where dependencies are getting patches and fixes. Because most developers won't ever bother patching their bundled dependencies. So know what you are paying with.

jhoh 7y ago

This website just makes me angry: - Fixed social media share buttons that cover the text on mobile - It auto-translates to German even though my system language is set to English (seems like they use geolocation for this which is bad practise) - Center aligned text that is annoying to read

Lowkeyloki 7y ago

What I'm disappointed about with AppImage is that it doesn't deal with differing architectures as far as I can tell. Which would really help me right now as I had to send my laptop to Dell for repairs and I'm now using just my Android phone and my Raspberry Pi 3B+ as a desktop. And compiling stuff on the Pi is SO SLOW!

TBF-RnD 7y ago

Come on guys, I see a lot of negativity here but we can have the cake and eat it. Look at the following imaginary but likely scenario. A promising coder creates an app in C using cmake or whatever. For a veteran linux user to use git and compile is not a problem. Our up and comming coder want to reach out to a wider audience however so instead of creating X packages he provides an appimage. All of the sudden all the fedora, debian and ubuntu guys etcetera can run it without the hassle. Now imagine if the project turns out to be a silver bullet for some really important problem. What will happen, the maintainers for the bigger distros will simply download the code and there will be maintainers that steps up and maintains the software for the repos. Voila, the best of two worlds. ... and if the project doesn't become a huge mainstream access users now can get it via source or appimage . As far as commercial projects are concerned they will operate according to different dynamics. But who cares we want open source solutions for our linux systems anyway.

zurn 7y ago

Does it work on Android? For cli apps running under adb, at least?

znpy 7y ago

Every app packaging its own shared library and runtime because someone didn't want to deal with packaging software. I foresee someone in five years complaining about how much RAM linux on the desktop uses. And somebody else blaming it on shared libraries not actually being shared because all the "apps" load their own snowflake library. So multiple copies of glibc, multiple copies of gtk, multiple copies of everything. RIP RAM AND WALLET.