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…
AppImage: Linux apps that run anywhere
181–190 of 241 posts
Re: AppImage: Linux apps that run anywhere
#182Earlier 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.
Re: AppImage: Linux apps that run anywhere
#183One 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.
The Linux community is missing the forest for the trees.
Re: AppImage: Linux apps that run anywhere
#184As 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?
Re: AppImage: Linux apps that run anywhere
#185Earlier 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.
Re: AppImage: Linux apps that run anywhere
#186Seems 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…
(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
#187Earlier 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…
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
#188Earlier 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…
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
#189I 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,…
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
#190On 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…
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.