, the other day. When I was running LPS Linux from a USB Stick.
only has a few Apps and Firefox on in it, as it comes. So, I wanted a few Apps to use when running this Live OS. But, none of them would Run, at all. I figured that it was something to do with the Security Settings in LPS. Since, it is aimed at Web Security. Then later on... I Copied my Downloaded Apps from my USB Stick to my Fedora 14 OS. But, still no go. But, then I noticed, in the Error Messages when I tried to run the Apps. That they were all saying that the "so in so... Directory could not be found". And over the years I have learned that this sometimes happens in Linux when you Directory name has more than one word and has Spaces in the name. This can also happen in Windows OS's with "Portable Apps" that are not "Installed", and run from the "exe" file. I have noticed this in Operating Systems, from Windows 3.11 and on to my present OS, Fedora 14 Linux. So, I renamed my files and replaced all Spaces with a Dash "-" (without the quotes). That fixed the problem!:) I also replaced all of the Dots "." in the file names with Dash "-" too. Because my OS was using all of the Characters after the last Dot "." (in the files with Dots), as the file extensions. There were no file extensions in the files as Downloaded them. This didn't hurt anything, the Apps still ran just fine. But I just wanted to head off any confusion on my part later on after I have slept for a night;) Note, that Gimp, Thunderbird, Filezilla, Putty and VLC all ran ok. But not all normal features (that I tried) worked in them all. VLC wouldn't play ".flv" Video Files. But it would play, ".ogv", "mp4", ".wmv" files just fine. I guess all of the Plug-ins are not there. Gimp would not Open up any type of Image file that I tried ("jpg", "png" etc). Thunderbird opened up with all of my Present E-mails that are on my System, just as if it was installed. I'm guessing it would open to the Setup Screen, if there were no Thunderbird Configuration files found on a New or Live System. Filezilla and Putty worked normally, as if they were installed on the System. But, I also tried MPlayer and ffmpeg and they did Nothing. I got No Errors and the Apps Did Not Open and Run. I don't think that ffmpeg is supposed to run on it's own as a GUI App anyway though. It doesn't on my Fedora 14 System, anyway. It works like a Plug-in for other Apps like VLC, MPlayer and some Video Editors. That's why I downloaded it, in case it would help VLC and MPlayer Play and Convert Videos. Anyway, that's my Experience with "Portable Linux Apps" form
. Here's more info on "Portable Linux Apps"...
AppImageKit Documentation
Describes the AppImage file format and AppImageKit tools
Version 1.0
Copyright © 2005-10 Simon Peter
Table of Contents
Motivation .........................................................................................................................
Format overview ................................................................................................................
The AppImageKit ...............................................................................................................
Creating AppImages ...........................................................................................................
Contributing ......................................................................................................................
Acknowledgements .............................................................................................................
The AppImage format is a standardized format for packaging applications in a way that allows them to
run on target systems without further modification. This document describes the AppImage format.
This document is not a formal specification, since the AppImage format is not frozen yet but in the process
of being specified more formally. However, this document is intended to describe the philosophy being
the AppImage format and the concrete implementation.
The AppImageKit contains a concrete implementation of the AppImage format and provides tools for
conveniently handling AppImages.
Contributors are encouraged to comment on this document and propose formal format descriptions.
Motivation
Historically, UNIX and Linux systems have made it easy to procure source code, however they have made
it comparably difficult to use ready-made software in binary form. Especially the Free Software and GNU
movements stress the fact that everyone should be free to get the source code. This mode of operation
has worked well as long as the user base of these operating systems was largely comprised of technically
advanced users. With the widespread adoption of easy-to-use desktop operating systems such as Ubuntu,
the user base became less technically-minded and more application-centric.
Package mangers were introduced to mitigate the complexities of dealing with source code by providing
libraries of precompiled packages from repositories maintained by distributors or third parties. However,
the introduction of package mangers did not drastically reduce complexities or provide robustness - they
merely stacked a management layer on top of an already complex system, effectively preventing the user
from manipulating installed software directly.
Other systems, most prominently Windows and the legacy Macintosh operating system, have made it
relatively simple for independent software publishers (ISPs) to distribute software and for end-users to
procure and install software from said ISPs, without any instances (such as distributors or AppStores)
between the two parties.
With the introduction of Mac OS X, arguably the first UNIX-based operating system with widespread
mass adoption to a non-technical user base, Apple blended traditional UNIX aspects (such as maintaining
a traditional file-system hierarchy, including /bin, /usr, /lib directories) with common "desktop" approaches
(such as "installing" an application by dragging it to the hard disk). While Apple uses a package manager-
1
AppImageKit Documentation
like approach for managing the base operating system and its updates, it does not do so for the user
applications.
Open Source operating systems, such as the most prominent Linux distributions, mostly use package
mangers for everything. While this is perceived superior to Windows and the Mac by many Linux
enthusiasts, it also creates a number of disadvantages:
1.
Centralization Some organization decides what is "in" a distribution and what is not. By definition,
software "in" a distribution is easier to install and manage that software that is not.
2.
Duplication of effort In traditional systems, each application is compiled specifically for each target
operating system. This means that one piece of software has to be compiled many, many times on
many, many systems using much, much power and time
3.
Need to be online Most package managers are created with connected computers in the mind, making
it really cumbersome to "just fetch an app" on an online system, and copy it over to another system
that is not connected to the Internet.
A critical distinction between the approach known from Windows and the Mac and the one known from
UNIX and Linux is the "platform": While Windows and the Mac are seen as platforms to run software on,
most Linux distributions see themselves as the system that includes the applications.
While this leads to a number of advantages that have been frequently reiterated, it also poses a significant
number of challenges:
1.
No recent apps on mature operating systems In most distributions, you get only the version that
was recent at the time when the distribution was created. For example, if you use Ubuntu Gutsy then
you are stuck forever with the software that was recent at the time when Ubuntu Gutsy was compiled.
Even if Firefox might have progressed by several versions in the meantime, you cannot get more
recent apps than what was available back when the distribution was put together. That is like if you'd
get only software from 2001 when you use Windows XP.
In the traditional model, the user has to decide: Either use a mature base operating system but be
locked out of recent apps (e.g., using Ubuntu LTE), or be forced to update the base operating system
to the latest bleeding edge version in order to get the recent apps (e.g., using Debian Sid).
This situation is clearly not optimal, since the common desktop user would prefer to hardly touch the
base operating system (maybe update it every other year or so) but always get the latest apps.
2.
No way to use multiple versions in parallel Most package managers do not allow you to have more
than one version of an app installed in parallel. Hence you have no way to simply try out the latest
version of an app without running the risk that it might not be easy to switch back to the older version,
especially if the older version is no longer available in your distribution (e.g, old versions get removed
from Debian Sid as soon as a newer version appears). This is especially annoying if you would simply
like to try out a few things before you decide whether to use the old or the new version.
3.
Not easy to move an app from one machine to another If you've used an app on one machine and
decide that you would like to use the same app either under a different base operating system (say,
you want to use OpenOffice on Fedora after having used it on Ubuntu) or if you would simply take
the app from one machine to another (say from the desktop computer to the netbook), you have to
download and install the app again (if you did not keep around the installation files and if the two
operating systems don't share the exact same package format - both of which is rather unlikely).
The AppImage format has been created with specific objectives in mind.
1.
Be Simple AppImage is intended to be a very simple format that is easy to understand, create, and
manage.
2
AppImageKit Documentation
2.
Maintain binary compatibility AppImage is a format for binary software distribution. Software
packaged as AppImage is intended to be as binary-compatible as possible with as many systems as
possible. The need for (re-)compilation of software should be greatly reduced.
3.
Be distribution-agostic An AppImage should run on all base operating systems (distributions) that
it was created for (and later versions). For example, you could target Ubuntu 9.10, openSUSE 11.2,
and Fedora 13 (and later versions) at the same time, without having to create and maintain separate
packages for each target system.
4.
Remove the need for installation AppImages contain the app in a format that allows it to run directly
from the archive, without having to be installed first. This is comparable to a Live CD. Before Live
CDs, operating systems had to be installed first before they could be used.
5.
Keep apps compressed all the time Since the application remains packaged all the time, it is
never uncompressed on the hard disk. The computer uncompresses the application on-the-fly while
accessing it. Since decompression is faster than reading from hard disk on most systems, this has a
speed advantage in addition to saving space. Also, the time needed for installation is entirely removed.
6.
Allow to put apps anywhere AppImages are "relocatable", this allowing the user to store and
execute them from any location (including CD-ROMs, DVDs, removable disks, USB sticks).
7.
Make applications read-only Since AppImages are read-only by design, the user can be reasonably
sure that an app does not modify itself during operation.
8.
Do not require recompilation AppImages must be possible to create from already-existing binaries,
without the need for recompilation. This greatly speeds up the AppImage creation process, since no
compiler is usually involved. It also allows third parties to package closed-source applications as
AppImages.
9.
Keep base operating system untouched Since AppImages are intended to run on plain systems
that have not been specially prepared by an administrator, AppImages may not require any unusual
preparation of the base operating system. Hence, they cannot rely on special kernel patches, kernel
modules, or any applications that do not come with the targeted distributions by default.
10. Do not require root Since AppImages are intended to be run by end users, they should not require
an administrative account (root) to be installed or used. They may, however, be installed by an
administrator (e.g., in multi-user scenarios) if so desired.
The key idea of the AppImage format is "one app = one file". Every AppImage contains an app and all
the files the app needs to run. In other words, each AppImage has no dependencies other what is included
in the targeted base operating system(s). While it would theoretically be possible to create rpm or deb
packages in the same way, it is hardly ever done. In contrast, doing so is strongly encouraged when dealing
with AppImages and is the default use case of the AppImage format.
In short: An AppImage is for an app what a Live CD is for an operating system.
Format overview
An AppImage is an ISO 9660 file with zisofs compression containing a minimal AppDir (a directory that
contains the app and all the files that it requires to run which are not part of the targeted base operating
systems) and a tiny runtime executable embedded into its header. Hence, an AppImage is both an ISO
9660 file (that you can mount and examine) and an ELF executable (that you can execute).
When you execute an AppImage, the tiny embedded runtime mounts the ISO file, and executes the app
contained therein.
Download the Full PDF here...
http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf
Download Portable Linux Apps... http://portablelinuxapps.org/ 
No comments:
Post a Comment