AAAH! Thank you so much for spotting that mistake! I've corrected the post.

I have tried AppImages, as have many others who dislike them. They simply cause problems and aren't as configurable or extensible as building from source or even using package formats like DEB and RPM. If Windows users can't adjust to packaging formats or building from source, then they can stick with their OS - it doesn't matter to me if somebody else ruins their computer with spyware. I really don't understand why people care about making Linux worse to convince Microsoft fans to like it.

2 members found this post helpful.

For software like that (as well as for some software that actually does appear in the distribution's repositories) I compile from sources (under "/opt/app/src/app-name"), specifying when running "configure" an install path under "/opt/app/app-name". The sticky point is that anyone using using those applications needs to source a small script in their profile that I write that updates their PATH and anything else they need in their environment. Small downside, IMHO. Secure? I assume so or there'd be a huge outcry on the 'Net from P.O.ed users. Just because it comes from a distribution's repositories is no guarantee that there aren't security problem in that code.

HTH...

1 members found this post helpful.

Wherever you get the source/package from, make sure its a trusted source.

It can be a .deb - but only if it's compatible with your system.
For example, installing a Ubuntu .deb on Debian may well cause problems - and possibly vice versa.
Read your systems documentation about installing foreign packages.

If you have the alien package installed, it's probably reasonably safe to install .rpm etc packages.
Compiling from source is always safe - provided it came from a trusted source.

But a package from your repository has been tested for compatibility and will receive security fixes and possible updates.

Compiling from source is not nescessarily "safe". It can ruin your dependencies just as easy as with alien debs.

Can only agree with you, Mike. Instead of looking at the technical way things work, we should be looking to the business side of things.

If you look at the trends in the desktop and mobile space, you see the emergence of app stores. And in those app stores you can now mostly find software with in-app purchases. The Ubuntu software repository is an example of the beginning of a similar thing in Linux.

Whatever the underlying technology people just want software to work and to play nice with the desktop environment. That is all most individual end users (and for that matter me myself) long for.

Funnily enough, software is most likely to work and play nice with the DE if it is compiled and optimized for your specific hardware - so not an AppImage.

2 members found this post helpful.

Oh man this is such a mess.. If some common ground could be found to converge on, it would mean so much energy not wasted on divergent platforms. Wasted energy becomes frustration, irony and antisocial behaviour. I work in health care so I know (yes, I know, irony there as well). Or do I miss the point completely??

@ andigena:-

I don't know where you get the impression that running an AppImage will interfere with & 'mess up' your system. A correctly-built one is 'read-only', contains everything required for it to run, and will be designed to run in /tmp for the duration.....and to the best of my knowledge, nothing installed to /tmp will last for more than the life of a session anyway. At power-off, the contents thereof will disappear into cyberspace.....

(*shrug*)


Mike.

I don't know where you got the impression that that's what I think.
Which is precisely why they have issues. Blender's Snap package is an ideal example of the problem with the read-only type universal packaging formats, although it isn't an AppImage. It makes it impossible to use the standard method for adding plugins (a very important part of Blender's functionality). It's absurd.

Why are there (apparently) two/three kinds of "universal" things?
Snap and appimage and Flatpack - I might have spelt those wrong as I would never use any of them.

As an example, Snap appears to offer GIMP (version 2.10.0) as a low,low installed size of 209.1MB.
Currently, my installed GIMP - version 2.8.18-1+deb9u1(oldstable) appears as an installed size of 16.7MB.

So that's quite a bit of bloat isn't it?
Of course, my current GIMP has quite a few dependencies - but I can trust a proper package manager to handle all this stuff.

BTW How do these these "universal" images deal with security fixes - or don't they bother?

@ andigena/Jeremy:-

I'm not saying that these 'portable', use-anywhere formats are suitable for all kinds of applications. I'll be the first to admit that they're not. The example you give - for Blender - is a prime example of an application where this sort of thing is anything but ideal. The GIMP is probably another. However, I still stick by what I said about the way a correctly-assembled package is intended to work.

Unfortunately, there's several 'packagers' out there who simply re-pack .debs & .rpms, with the result that the AppImage is still clamouring for a bunch of system dependencies which your package manager may or may not be able to satisfy.

AppImages offered by the major projects are pretty well guaranteed to work with as many Linux systems, in all their varied permutations, as possible. Out of the 'independents' - operating from platforms such as AppImageHub & BinTray.com - two of the best 'names' to watch out for are probono & AJSlye. These guys keep to the true 'spirit' of the AppImage format, often tracking down an application's source code, then re-compiling it to work with an older glibc & dependencies, before packaging it with absolutely everything required for it to run with as many different combinations of hardware as you can imagine, and thus making it accessible to the largest number of users. I admit, doing this does often result in some pretty humungous packages, but then this format is pretty well aimed at users with fairly modern hardware, with large amounts of RAM and no 'caps' on their ISP's downloads/bandwidth.

------------------------

@ Jeremy:-

As far as security patches/'fixes' are concerned, you simply delete the old AppImage & download and use the newer version. See my comment above about being mainly for users who are unconcerned about bandwidth.

'Snaps' are Canonical's 'baby'. FlatPaks are the preferred variant from the RedHat 'stable'. The AppImage format is, by & large, independent. Competition, you see.....

---------------------------

The following is from the top of appimage.org's home webpage, and gives an insight into the mindset of the people involved in this packaging method:-

Hence, why these things, by their very nature, have to be totally self-contained.....even though that does often result in the AppImage installing to /tmp copies of stuff that may already exist elsewhere on your system. And to many individuals, that's just pointless.


Mike.

In other words - its for someone who wants it to work like Windows, even though they don't understand why that's a really bad idea?

1 members found this post helpful.

Pretty much, yes, I would say. Which is why I predicted that Linux 'stalwarts' would be raining down fire & brimstone upon my head for daring to even mention such a concept.....

The world is changing, and the majority of folks want life as easy as possible. That's one of MyCrudSoft's biggest 'legacies' to the global tech community, I'm sorry to say.....though these things work, as stated above, really well for us in 'Puppyland'. Far more Linux users these days are 'silver surfers' than you may believe, and for myself (pushing 60), though I still love Linux, I no longer have the energy & enthusiasm to simply 'prat about' with the system purely for its own sake. For me, the focus has shifted from the system as an end in itself, to simply 'using' the system, in as easy & fuss-free a way as I can make possible.

For me, AppImages are ideal. I don't ask, much less expect anybody else to have to like them.


Mike.

1 members found this post helpful.