Actually I can agree with that!
Witness: Gnome software center "software & updates" OK but for absolute beginners in my opinion, and has a few glitches.
Synaptic (two thumbs up)
Gdebi (likewise)
(can you tell I run Xubuntu 16.04, which is as good a base as any to start from)

I haven't the faintest idea what they are

tl;dr


Okay, I read it. I use tumbleweed since about 2 years with practically no problems. So you might say, all these techniques are solutions for problems I don't have anyway.


As an aside, I have some doubts about the update policies for at least some packages (no criticism for your efforts intended).

No, I haven't used any of them.

I understand the justifications for them. I'm trying out a few snaps, flatpaks and appimages, to see if I can actually see any benefit or advantage as a user - in my case, not a programmer, but a user who mostly wants stuff to just work when I need to get things done, while liking to tinker from time to time.

I can see an advantage for the developers and maintainers. If truly cross platform, it potentially allows for focus on one version for all distros, freeing up time for other things.

A possible advantage for the user is you get the application exactly as the developer wrote it, if that's important for you.

But some questions and concerns before I'm ready to call these good for me, the user:

With these, will my device run more securely, less, or have equivalent security? This depends on so many things, I don't think there's a clear answer today.

Today they are significantly bigger than their package counterparts (deb, rpm...) Can they reduce this to at least close to package size? This is a disadvantage vs packages from the start. If I understand right, they carry more code to get the same job done. I don't believe that generally moves in the direction of improving security.

Will their usability or functionality be better? It's early days, but so far ones that have worked for me have been slow to start up, but then worked the same as their package versions (although some don't have everything the packages do.) I've dumped a couple that didn't work. When starting from the CLI I see errors and warnings that I don't understand. Since I haven't often started applications from the CLl, I don't know if I snaps/flatpaks/appimages generate the more errors/warnings than packages do, or if they are any more serious.

Will they replace deb, rpm... or will we just end up with more parallel sets of pkgs?

If they succeed and free up time for developers and maintainers, will that lead to better code and implementation, and more but better applications, or will that just turn into a noisy App Store mess - a million channels of sh*t on the TV to choose from?

One other thing - since these are supposed to update frequently, how much data are updates going to chew up?

If you have an unlimited data plan on a fast connection, no problem. If updates don't take much data, also no problem.

I know snaps work in Ubuntu 17.10; I have not tried any flatpacks; but I have been absolutely unable to get the one appimage I have tried to install and work. I'm interested in using Joplin; joplin-0.10.39-x86_64.AppImage simply refuses to behave as advertised on my system, Xubuntu 17.10 with the 4.13.0-21-generic kernel.Not sure what the heck I am doing wrong, but I would much prefer a .deb file!

I had to use appImage a few times, because there was no package to install (debian 9), for example etcher, and was hard to recompile/rebuild, like avidemux.

@brashley46

I got the Krita appimage to work, but I wanted to try Joplin after your note.

Here's how I got joplin-0.10.39-x86_64 to work on Ubuntu 17.10, just updated a few minutes ago so maybe a newer kernel than you're using. (Despite my list of distributions, I've stuck Ubuntu 17.10 and Mint 18.2 on my kids laptops, but they're not using them. I do have a look once in awhile,)

Instead of by GUI, I used the steps from appimage.org in the command line
One detail appimage.org left out - first, you have to get into the directory that your appimage is in
Then make it executable
$ chmod a+x Joplin-0.10.39-x86_64.AppImage
Then run
$ ./Joplin-0.10.39-x86_64.AppImage

No sudo needed.

In Ubuntu 17.10, I was asked if I wanted an icon on the desktop, which I chose.

After that, I was able open Joplin by clicking on the desktop icon, by clicking on the filename in Files, and from the command line.

I would never trust pre-packaged software which makes it ridiculously hard to see what's going on inside it.

tried that, and got bash: ./Joplin-0.10.39-x86_64.AppImage: cannot execute binary file: Exec format error
so much for that approach. Hmmm.

As far as I know you can unpack an appImage and check what is inside, it is not an issue (at least it is not ridiculously hard).
https://discourse.appimage.org/t/how...image-file/189

I've never run into that before, but a quick search brings up several possible causes and solutions. The most common occurrence looks to be trying to run a 64-bit executable on a 32-bit OS or machine, but there are others. The error isn't an appimage-specific one, Google told me it happens with other executables, but you'll have to dig into for yourself.

Yes I use Appimage for 'etcher' which I have found to be an excellent tool. I have experimented with Firefox and other apps more for interest than need. I can see a great future for such an approach and I hope work continues with these methods. I think, that done properly, Security can be increased.

i literally lol'd.
etcher is a frontend for dd, with a very, very fancy electron web ui.
the electron monstrosity is the only reason you need to run this as an app image.

i thought i needed etcher to install ubuntu on an ARM device, because everybody recommended that (and nothing else), only to find out that it does exactly the same as 'dd if=some.img of=/dev/something'...