Is this the best thing ever for Linux?

[VanillaMozilla]

Anyone know anything about this? He certainly nailed the problem.
http://portablelinuxapps.org/
White paper--documentation
Demo

[Omega X]

This looks somewhat similar to the universal binary system from OSX.

[VanillaMozilla]

It's been around a while. It looks like it has the potential for solving Linux's big problem, namely that most apps have to be laboriously packaged for each distro. As a result, there's too much work required to develop for Linux, and we get only old versions.

[Omega X]

It probably won't take off until distros start demanding them to be packaged in this manner.

[VanillaMozilla]

I may demand that they be packaged in this manner.

[Bluefang]

I doubt that many Linux distros would want to directly support this kind of packaging.

* Trusting the packager: The distros I'm familiar with have a very strict process by which packages make their way into the main repository. So even if distros did start using this package format, they would still probably repackage and evaluate everything before it made its way into the repository. We don't need to make it easier to distribute malware.

* Source vs. Binary: It's not exactly a secrete that the Linux community isn't a big fan of binary blobs, no matter where they come from. I don't think there will be much support for binary being the primary method to get software to distros. There's also the fact that many major distros build their packages from source, which allows them to maintain a set of patches that upstream hasn't yet, or wont, accept.

* Bundled library hell: One of the big things that many distro packagers spend time on is un-bundling libraries. How many copies of the same library do you want on your system? And what happens when a security vulnerability is exposed in that library? Do you wait for upstream to produce new packages? Or is is on the distro to repackage every version of every package with the vulnerable library? That's why the preferred modus operandi is to use system libraries whenever possible. Though, this is a trade between bundling hell and dependency hell.

This also doesn't answer the question of what the target base system is, since that is different for every distro. At this point, I'm not even sure you can make assumptions about what implementation and version of libc you can target. I don't know about you, but I don't want to see a repeat of the MSVC*.dll and MFC*.dll hell from Windows.

I could totally see this format being used by distros, as in this is what they package apps in to distribute to the user. However, I don't see this addressing many, if any, of the problems for the developer to get their app to the distro. To address that, I think you need to start talking about a unified source code distribution format, defining all of the build-time and run-time dependencies, build configurations, and not allowing automagic dependency handling.

[VanillaMozilla]

Thanks for your very clear explanation, Bluefang. The current system has some huge advantages that are very easy to get used to.

The problem comes when quite a few of the major programs have serious problems that might not be fixed for two or three distro versions. But then they might still be out of date, and some other program might be broken. So do I use distro version A with broken program X or distro version B with broken program Y?

It's no small matter either. Libre Office sometimes destroys text formatting in MS Word documents, so I can't rely on it for sharing documents. And every one of my video editors is badly broken, so I can't even use them.

What you described seems to be a fundamental contradiction between the MS/Apple model (unsatisfactory) and the Linux model (unsatisfactory for a different reason). There seems to be a huge fragmentation problem and duplication of effort that hinders the Linux model. And what if one program requires library version Y but another program requires library version Z?

There has to be a better way. Any ideas? I'm afraid I didn't fully understand your last paragraph.

[Bluefang]

The problem comes when quite a few of the major programs have serious problems that might not be fixed for two or three distro versions. But then they might still be out of date, and some other program might be broken. So do I use distro version A with broken program X or distro version B with broken program Y?

Yes, that is the flaw of a centralized distribution mechanism, as it does rely on the people maintaining the central repository. On the other hand, something I do not miss from Windows is needing to manually maintain and update every single individual program.

If support and update speed is something you're looking for, then stick with one of the corporate backed distributions like RHEL/Fedora, or another large and active project like Debian (jessie/sid).

What you described seems to be a fundamental contradiction between the MS/Apple model (unsatisfactory) and the Linux model (unsatisfactory for a different reason).

I would not say contradictory, they just follow a different approach. IMHO the MS/Apple approach is unsatisfactory for technical reasons. The Linux approach is unsatisfactory for management reasons.

If you actually take a closer look at Windows, MSI is the installer format natively supported by Windows. Most EXE based installers are actually 3rd party solutions. So, in that same vein, AppImage is very much the same, and there is absolutely nothing wrong with that.

My point was that AppImage is not a desirable, or likely to be accepted, format for getting software into a distro's package repository. If developers want to package their binaries in this format, and if users want to download and use it, that is their prerogative. But such a system is naturally going to have all the same problems of software distribution in Windows and OSX.

There seems to be a huge fragmentation problem and duplication of effort that hinders the Linux model.

Yes. Linux us heavily fragmented, which is hardly new. Each distro has its own agenda and target audience. If there is duplication of effort, it is self inflicted. There is an epidemic of NIH Syndrome. However, it's probably not as bad as you think, because many distros are based off of more established distros. For example, Linux Mint is based on Unbuntu, which is based on Debian.

[quote] And what if one program requires library version Y but another program requires library version Z?[/url]
That is why libraries are versioned. If two different pieces of software require different releases of the same library version, then the library is not being versioned correctly. Or one of the apps was written in a way that it depends on a bug in the library.

Code: Select all

lrwxrwxrwx   1 root root       22 Apr 13 19:52 libgailutil-3.so -> libgailutil-3.so.0.0.0
lrwxrwxrwx   1 root root       22 Apr 13 19:52 libgailutil-3.so.0 -> libgailutil-3.so.0.0.0
-rwxr-xr-x   1 root root    35376 Apr 13 19:52 libgailutil-3.so.0.0.0
lrwxrwxrwx   1 root root       21 Apr 13 19:47 libgailutil.so -> libgailutil.so.18.0.1
lrwxrwxrwx   1 root root       21 Apr 13 19:47 libgailutil.so.18 -> libgailutil.so.18.0.1
-rwxr-xr-x   1 root root    31248 Apr 13 19:47 libgailutil.so.18.0.1
lrwxrwxrwx   1 root root       21 Dec 28 15:06 libgdkmm-2.4.so -> libgdkmm-2.4.so.1.1.0
lrwxrwxrwx   1 root root       21 Dec 28 15:06 libgdkmm-2.4.so.1 -> libgdkmm-2.4.so.1.1.0
-rwxr-xr-x   1 root root   331888 Dec 28 15:06 libgdkmm-2.4.so.1.1.0
lrwxrwxrwx   1 root root       21 Mar  9 17:46 libgdkmm-3.0.so -> libgdkmm-3.0.so.1.1.0
lrwxrwxrwx   1 root root       21 Mar  9 17:46 libgdkmm-3.0.so.1 -> libgdkmm-3.0.so.1.1.0
-rwxr-xr-x   1 root root   290128 Mar  9 17:46 libgdkmm-3.0.so.1.1.0

[VanillaMozilla]

Yes, that is the flaw of a centralized distribution mechanism, as it does rely on the people maintaining the central repository. On the other hand, something I do not miss from Windows is needing to manually maintain and update every single individual program.

Yes, in Linux all this work is done centrally, laboriously, repetitively, and very, very slowly.

Big problem, with no solutions in sight.

[Bluefang]

Linux is built on the backs of contributors. If you have an issue with the speed of updates, you could always try contributing yourself. Or you can just use AppImages, if you can convince a developer to provide them.

This has been the Linux was for the past 20 years, and I don't see it as being a roadblock to the next 20. If you don't like your current distro, you can always switch to another. There's plenty to choose from. http://www.zegeniestudios.net/ldc/

Linux is built on the backs of contributors, so you could always try contributing yourself. Or you can just use AppImages, if you can convince a developer to provide them.

[VanillaMozilla]

Trying another conventional distro is not a likely solution, as the problem is system-wide.

I do contribute, by the way. I spend a lot of time writing good bug reports, and have had very good success with small projects. Fixing bugs is another matter, however, as the entry level is rather steep. The entry level to packaging apps also seems steep. Sometimes easier to compile the app yourself. I'm thinking it might be easier and more effective just to provide app images.

I like the idea of the appimages, as there are excellent programs that can't seem to get recent versions on the many Linux desktops.

Thanks for your thoughts, though.

[Omega X]

Yeah, but some developers don't see bug reports and feedback as "contributing". If you're not submitting code, you might as well be dead to them.

[VanillaMozilla]

I don't waste my time any more on projects like that. Some projects actually pay attention, and the developers seem grateful. Every one of my compiler bugs has been fixed. I've gotten quite a few bugs fixed within hours or days.

Most of these bugs were (1) previously unknown and (2) substantive. I'm a heck of a lot more productive that way than by struggling to fix some code that someone else wrote.

[lawlerskates]

I don't use linux anymore, but for me I always preferred linux package management to installing apps on windows or osx, its very nice to have every application automatically updated, and being able to install any application thats in the repositories with a quick command. Personally I'd rather not see the linux desktop adopting OSX-esq app bundles. I do have a mac, and I'm not the biggest fan of that aspect of it (its not bad though, for the most part preferable to the plethora of install wizards that you get with windows).

I think ubuntu's PPA system already does a good deal to address one of the bigger complaints with linux package management (being stuck with old versions of apps until the next distro version).

I do understand a lot of the concerns with the current state of linux package management though (such as the large duplication of effort that comes along with different distros using different package formats etc... which requires a lot of work done on packaging things for each specific distro.)

In any case, I don't see something like this taking off unless one of the major distros decides to adopt it.

[Grumpus]

Isn't this the initial concept with Debian?
You take a standard package for Debian with an XXXX_all.deb designation and plug it into any Debian based distribution and it works.
In some cases it's the name only which changes, rare, but it happens.
In some cases there is the minor connection issue with parts of the system but functional for the most part.