Posts in Category "Discussions"

AIR applications and root access on Linux

A number of users have tweeted, blogged and sent us emails – “It’s understandable for AIR itself to need root access during its installation (since it installs to /opt), but why do AIR applications need root access for installation, especially when I’m installing the application to a folder owned by me?”
The answer lies in the fact that AIR applications are similar to regular native applications – they install as native rpm/deb packages. This requires access to the rpm/deb system database (e.g. rpm database lock). And this is required even if the installation folder is chosen to be one that is owned by the current non-root user. In addition, with root privileges, it’s also possible to install applications to a location that is accessible to other users on the system.
However, do note that when they are launched, AIR applications run with the privileges of the user launching the application and not root. The primary executables of AIR applications (under the bin/ folder in the installation path) do not have the setuid bit set. You should not be worried about AIR applications running with root privileges, based on the fact that their installation required superuser access – the two are completely independent.

Why does AIR install only on rpm/deb based Linux distros?

AIR applications are not web applications running outside the browser, but are full-fledged desktop applications with their own windows and access to the filesystem, clipboard and other system resources.
Being desktop applications, they should also integrate well with the system’s package manager (instead of being simply extracted to a directory). On Windows, this corresponds to “Add/Remove Programs”. On Linux, this means the likes of Synaptic or Pirut. This makes it easy for users – since they use the system’s package manager to uninstall other applications, it should be no different for AIR applications. AIR also depends on the package manager for version management of applications (and of the runtime itself) and to ensure that required dependencies are fulfilled.
Since rpm and deb are the most popular package formats, we chose to focus on them. They have been widely adopted, are used in several popular Linux distributions and are not specific to a distro. Who knows which formats will be popular by the time the next version of AIR is released!
Though AIR’s installer is available as a self-extracting executable and AIR applications are distributed as .air files, both of these get installed on the system as native rpm/deb packages. We’re considering alternative distribution formats – If you have an idea or suggestion, please let us know.

Does the AIR Beta work for your Linux distribution?

Although the list of supported distributions (Ubuntu 7.10, Fedora 8, OpenSuSE 10.3) is small compared to the total number of Linux distros out there, we expect AIR to run fine on a lot more of them.
It is not possible for us to exhaustively test all features on all distributions – we depend on you for this feedback. To ensure that AIR runs on as many distributions as possible, implementation of AIR features is based on standard specifications (such as the FreeDesktop specs). More and more distributions, window managers and desktop environments now adhere to these.
It would also be great to have feedback about other devices that run Linux, such as OLPC XO, EEE PC and Samsung Q1U.
System requirements are listed as part of the release notes.
We’d like to know if the latest release on labs works for your favorite distribution – please go ahead and post the result in a comment below.

AIR apps and HTTP proxies on Linux

With the alpha build of AIR on Linux, setting up an HTTP proxy for use by AIR applications requires exporting environment variables AIR_PROXY_SERVER and AIR_PROXY_PORT with appropriate values.
We intend to do away with this and use something that’s standard on Linux. The problem is that there is no standard. GNOME and KDE use different mechanisms. Individual applications use their own mechanisms.
We’ve decided to use the current desktop environment’s proxy settings, with the option of having these overridden with an environment variable.
On KDE, proxy settings can be set using kcontrol (KDE Control Center). On GNOME, these can be set using gnome-network-preferences (or directly using gconf-editor). The following gconf keys are involved:
a) /system/proxy/mode – A non-‘none’ value indicates that a proxy has been set (recommended value = “manual”)
b) /system/http_proxy/host
c) /system/http_proxy/port
Most browsers too use these values to figure out system proxy settings.
These settings can be overridden with an environment variable http_proxy (with its value in the format http://hostname:port). This variable is the most common one used by applications on Linux. apt-get and wget, for instance, use it.
I’m looking forward to’s shared configuration system as one standard, desktop-agnostic mechanism for managing such per-user configuration settings. (It’s currently in the planning/requirements-gathering stage.)