Linked by David Adams on Fri 16th Jul 2010 19:43 UTC, submitted by broomfighter
Linux "The Portable Linux Apps project brings the ideal of "1 app, 1 file" to Linux. Applications are able to run on all major distributions irrespective of their packaging systems - everything the application needs to run is packaged up inside of it. There are no folders to extract, dependencies to install or commands to enter: "Just download, make executable, and run!"" A follow-up article describes how it works, and how to transform debian packages into AppImages. The packages don't include libraries, so the system won't need to update the same library in each individual app.
Thread beginning with comment 433818
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Nice!
by tupp on Sat 17th Jul 2010 05:31 UTC in reply to "RE[4]: Nice!"
tupp
Member since:
2006-11-12

As the parent you replied to rather clearly said: it's difficult to install versions newer than what's available in the repos! As such your apt-get won't help you a bit.

Sidux is Debain Sid -- latest versions. Plus one can use many other cutting edge Debian repos with Sidux. The other distros that I mentioned also put the latest versions in the repos. There are other distros that do likewise.

Furthermore, most of the Linux repo packages are modified and updated way more frequently than their Windows and OS-X counterparts.

Reply Parent Score: 3

RE[6]: Nice!
by superstoned on Sat 17th Jul 2010 10:11 in reply to "RE[5]: Nice!"
superstoned Member since:
2005-07-07

Dude. You just don't want to get it. How about someone who wants to install 3.0 and sidux has 3.2?

Package managers rock - but you loose flexibility in what you can install, period. My repositories don't offer the last year of OO.o installations - only the latest. openSUSE and Ubuntu offer these user repositories, which might help, but if it doesn't you're out of luck.

Either way I agree with what was said before: nothing new here, move along - klik did that years and years ago and nobody cared then either.

For this to work properly you need to have a heavy base of libs installed - all of the Gnome and KDE libs by default at the very least (and all their dependencies includion optional ones). If you do it like that, yes, this works - generally speaking. You could define a stable API and ABI for it through LSB and only update it every 3 years, demand backwards compatibility. The Gnome and KDE communities would provide it, everyone else probably wouldn't, so you'd quickly have to depend on outdated libs - and you're screwed.

IOW it simply doesn't work unless all libs provide EXCELLENT backwards compatibility and the ability to keep older versions installed next to the new ones.

Reply Parent Score: 4

RE[7]: Nice!
by tupp on Sat 17th Jul 2010 12:38 in reply to "RE[6]: Nice!"
tupp Member since:
2006-11-12

Dude. You just don't want to get it. How about someone who wants to install 3.0 and sidux has 3.2?

Are you the Dell spokesman?

There are about a dozen different ways to do that within Sidux and within most Debian-based distros. Many of these methods use a GUI.

The same capabilities exist with other package managers used in other distros.


My repositories don't offer the last year of OO.o installations - only the latest. openSUSE and Ubuntu offer these user repositories, which might help, but if it doesn't you're out of luck.

Hint: Use the distro that offers what you want.

Again, you are not necessarily "out of luck" if the package version that you want is not in your default repository. There are several easy ways to install the latest version or an earlier version of a package, with many distros.


Either way I agree with what was said before: nothing new here, move along - klik did that years and years ago and nobody cared then either.

So did DOS, Windows 3.1, Gobolinux, Zero Install, etc. By the way, none of these systems preclude the use of a package manager to retrieve/install their packages.


For this to work properly you need to have a heavy base of libs installed - all of the Gnome and KDE libs by default at the very least (and all their dependencies includion optional ones). If you do it like that, yes, this works - generally speaking.

Yes. And such a scenario requires no more resources than the "self-contained" package systems.

However, you don't really need the "optional" dependencies and you only need Gnome/KDE libs if you have applications that need those libs. So, in this sense, one could operate with fewer resources than those required for a system that is designed around completely self-contained packages.


IOW it simply doesn't work unless all libs provide EXCELLENT backwards compatibility and the ability to keep older versions installed next to the new ones.

"Dude," when I used to multi-boot, I would run applications from the other distros (some compiled years before) located on other partitions, with very few problems.

Reply Parent Score: 2