Live data from Hacker News

AppImage: Linux apps that run anywhere

appimage.org

181–190 of 241 posts

Re: AppImage: Linux apps that run anywhere

#181
post #171

Earlier quoted context omitted.

This makes a mockery of shared libraries. The technical debt will accrue and run unfathomably deep. Security failures due to currency issues are simply the most obvious. The insoluble mystery bugs of mismatched dependencies will plague application developers that choose this distribution strategy.

Yay for hyperbole ;) Shared libraries are most useful when matched within a specific distribution's package/version chain. Tying a third-party distributed package to a given shared library, on the other hand, is less helpful than just supplying the expected, tested, and supported library upfront and still let knowledgeable operators do what they will on their chosen platform. No technical debt is accrued if the libs…

Your suggestion amounts to advocacy of tight coupling, which massively dilutes the long-term benefit of shared libraries and leads developers under pressure of expediency into a tangled thicket of anti-patterns. This is an illustration of how technical debt is accrued, and I've seen it umpteen times, never to the good.

Re: AppImage: Linux apps that run anywhere

#182
post #170

Earlier quoted context omitted.

Installers regularly install packages to system dir because it would be idiotic on a multi user system for each user to install different versions of Firefox to their home dir. It also serves to keep unprivileged users from installing software. You are free to install software to your home but it shouldn't be the default behavior

The overwhelming use case for desktop users is there's usually one user on the system.

Which is not a good reason to design anything based on that assumption it's extremely easy for a single user to use a multi user system but not the reverse.

Re: AppImage: Linux apps that run anywhere

#183
post #15

One of the best things about Linux systems is having this huge pool of apps that you update centrally that are guaranteed to work on your system. This is a backwards step, if anything.

This attitude is exactly why Linux has such a horrible, horrible packaging experience. Building cross-distro packages is awful. Teaching users how to install packages is awful. Installing custom apt sources or repos to get newer versions of packages is awful. And we're getting stuck up on some inconsequential thing like a library will be duplicated. Guess what, OSX has been doing it successfully for years.

The Linux community is missing the forest for the trees.

Re: AppImage: Linux apps that run anywhere

#184
post #3

As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application. Please pull over. I want off this ride. Why the hell are we regressing to shipping around hackily built binaries?

Good. Get off this ride. I'm asking why the hell we are still stuck with the current packaging schemes.

Re: AppImage: Linux apps that run anywhere

#185

Earlier quoted context omitted.

Ranking package managers by difficulty of creating packages (1-10, lowest to highest): 1. tarballs (slackware) 2. Ports (FreeBSD) 3. Portage (Gentoo, Calculate Linux) 4. pacman (Arch, Archbang, KaOS, Manjaro, Antergos) 5. building from source (Linux From Scratch, Most old installs eventually turn into this) 6. rpm (Redhat, Mandriva, Scientific Linux, UnitedLinux) 7. deb (Debian, Ubuntu, Mint/LMDE, Hanna Montana Linux…

Why would "building from source" be a difficult way to create a package? ISTM that if you have any software at all, it's already building from source? I understand that building from source is considered difficult for users, but here you seem to be talking about maintainers. Or do you mean setting up $#%&ing autotools? In that case I agree.

the dependency hell from building from source is slightly less of a purgatory than that coming from anything above it. That includes the headaches of autotools.

Re: AppImage: Linux apps that run anywhere

#186

Seems unnecessarily complicated. A script like this gets you 95% of the way there: mkdir AppDir mkdir AppDir/bin mkdir AppDir/data cp $INSTALLDIR/app AppDir/bin cp -r $INSTALLDIR/data AppDir cp `ldd AppDir/bin/app | grep -o '\W/[^ ]*'` AppDir/bin cat AppDir/app #!/bin/bash SCRIPT_PATH=$(dirname $(readlink -f $0)) $SCRIPT_PATH/bin/ld-*.so.2 --library-path $SCRIPT_PATH/bin $SCRIPT_PATH/bin/app $* EOF (Sometimes I wonde…

I think you meant "$@" rather than $*

(The quotes in "$@" are important.)

Also, your script will fall over if any of the paths have spaces in them, such as INSTALLDIR.

You should use lowercase for variable names like SCRIPT_PATH. Uppercase is for exported variables.

readlink -f $0 breaks on OS X. You must do both readlink -f $0 and readlink $0 in order for it to work everywhere.

Shell scripting isn't easy. It took a year to understand these nuances to the point that they're second-nature, and I'm still discovering new ones. Anything that improves this situation would be a welcome change in my opinion.

EDIT: cat<<'EOF' is necessary here. cat<<"EOF" will interpolate variables.

Re: AppImage: Linux apps that run anywhere

#187
post #149

Earlier quoted context omitted.

Ranking package managers by difficulty of creating packages (1-10, lowest to highest): 1. tarballs (slackware) 2. Ports (FreeBSD) 3. Portage (Gentoo, Calculate Linux) 4. pacman (Arch, Archbang, KaOS, Manjaro, Antergos) 5. building from source (Linux From Scratch, Most old installs eventually turn into this) 6. rpm (Redhat, Mandriva, Scientific Linux, UnitedLinux) 7. deb (Debian, Ubuntu, Mint/LMDE, Hanna Montana Linux…

The web of dependencies for both build and execution can be maddening. This is why apt-get and yum have won: they take care of finding and downloading those 3246536245 libraries which are absolutely essential for each stupid two-liner application out there. And when it comes to large software (which you probably don't manage on a chromebook), good luck downloading and compiling several GBs of KDE or GNOME source code…

running/building a full plasma 5.5 KDE 5.x current. Full install including most office apps (Libreoffice, etc), a bunch of emulators/games (free and proprietary - steam included), and other apps.

Intel haswell/sandy bridge chromebooks with custom hard drives. I think you're greatly overestimating how difficult it is to maintain all of this on Portage. I invite you to try a distribution that isn't Debian or Redhat-based. You might never go back.

Re: AppImage: Linux apps that run anywhere

#188

Earlier quoted context omitted.

What exactly was achieved in the backwards compatibility nightmare that is Gnome 3, for example? This: https://trac.transmissionbt.com/ticket/3685 All things UI in Linux distributions go through so much insane thrashing that very very few application developers want to bother. There are no tangible benefits to UI thrashing; people use systems for software , not window chrome!

Desktop Linux is definitely still maturing... I'm not up on the latest in Gnome-land and don't know the background on the issue you linked, but it looks like the benefit is that they get to stop maintaining a bunch of code for a UI feature they've decided isn't actually a good idea. That will make it easier for them to continue to build reliable software, as there will be less legacy code to consider when writing fut…

The only time you run into a WM issue is when you try to ape the OSX singular menubar.

As long as you go with the Windows thinking of having the menubar inside the relevant window, your UI will work across just about every WM out there.

I really don't see why the UI world is so hell bent on moving away from the menubar. That is unless they are stuck up on turning every UI into a touch UI...

Re: AppImage: Linux apps that run anywhere

#189

I believe the core problem here (that led to containerization, application images and alike) is that correct packaging for most distros is hard. There are tools like fpm or even checkinstall that can build simple good-enough-but-not-really packages, but I think maintaining a "proper" Debian packaging requires some pretty arcane knowledge that's spread around various pieces of documentation (and maybe I'm just stupid,…

One part of it is that every damn package manager out there (outside of perhaps Nix/Guix and Gobolinux) is hung up on having one canonical version of every lib package.

Meaning that the package manager balks at having lib 1.0 and 1.1 installed at the same time, even though ld can handle it just fine, unless you play sleight of hand with the package names (meaning that you get something like lib0 and lib1 for 1.0 and 1.1 respectively).

This in turn leads to a bunch of busy work regarding backporting fixes, maintaining manager specific patches, and recompiling whole dependency trees on minor updates.

Re: AppImage: Linux apps that run anywhere

#190

On my Linux Mint 17.3: 1. Downloaded the app, opened Nemo and double clicked on the app. Another Nemo window popped-up and the app didn't start. Opened terminal and checked permission to find that it wasn't executable. The point of the ease-of-use is kind of lost as user would be puzzled and give up. 2. How do I uninstall the app? Is it as simple as deleting the file? What if doing that leaves orphan files (that I do…

As to 1.) you downloaded the app (.appimage) and double clicked on it. Why? Nowhere in any documentation does it say that .appimages are executable out of the box. In fact this is a security feature that it doesn't. IN all placves that I have seen .appimages available there is a statement that says the user has to go into permissions and make the file executable before it will run. Makes sense since most malware is m…

> Nowhere in any documentation does it say that .appimages are executable out of the box.

Sure, but literally the first thing on the landing page is...

> As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application.

Post reply on HN