It goes by the name of LINA, and after four years of development , it is due for release later next month. Building off a concept similar to Java, LINA aims to provide open-source developers the ability to compile applications that will run on all of Windows, MacOS X, and various Unix systems. Additionally, it promises to do so using each OS' own interface libraries -- so a Linux application on Windows doesn't look out of place -- and runs them within their own contained environment to ensure they don't play up.
This is, of course, somewhat of a holy grail and raises all sorts of questions -- like just how easy is it to use, how does it perform, and what changes if any need to be made to Linux applications to run on the Lina platform.
While we won't know until the next month when the product is released, we did fire off a bunch of questions to LINA developer Nile Geisinger, and got these answers:
How are Linux applications for LINA built?
Applications are recompiled using our versions of standard Linux libraries. Developers and maintainers can include a simple script to automatically build a LINA binary every time they make a release of their project.
What exactly is in a LINA executable?
Our Linux executables are bundled in zip files that contain configuration files and native executables for each platform.
What if you want to alter the ini files of an app, do you make changes directly to the files within the zip, or is it more complex than that?
Good question. The user can edit files that they normally would edit. For example, if they install Apache, they can modify their httpd.conf file in the same way they normally would.
What happens if applications depend on, for eg, a glibc library version that Lina doesn't support?
In cases where an application depends upon a specific version of a library like glibc, they can statically link the libraries they need into their application without waiting for a new release of LINA.
Do you already have a repository of applications compiled for Lina ready to go, and if so which ones?
We do not have a repository, but we will have several demos that will be revealed upon release.
Is the 'secure and stable execution platform' a function of the host OS or Lina? For eg -- permissions, is Lina enforcing access permissions or relying on those set by the OS?
Applications only have access to resources of the user's operating system that LINA enables them to have access to. In addition to the OS enforcing permissions, LINA has been architected so that it can also enforce access permissions on an application by application basis. We plan on providing developers with tools that allow them to specify these permissions in the future.
Are OpenGL applications supported as well?
We are not supporting OpenGL in the short-term. Given the interest, though, we expect OpenGL support will emerge fairly quickly.
Speed -- how fast is it compared to a native application?
There is a 2X performance hit for running applications in LINA. In the short-term, there is also an additional performance hit for GUI applications. This additional performance hit will be eliminated when we optimize the mechanism by which we make operating system calls.
Lina is dual-licensed under the GPLv2 and a commercial license. What does the commercial license entail?
We are currently working out the details of the commercial license.
Finally, one other question -- where do you class LINA in the line between interpreters and bytecode, and virtualisation? It appears to be taking from each, so how would you describe it?
Nope, you're right. LINA is borrowing from several existing categories that are normally quite separate from one another.
It all sounds rather intriguing, so you can be sure we'll check it out when it's released. For more on LINA check out the homepage at www.openlina.com and the demonstration videos . We're told LINA is due for release 'mid-july' and will initially provide the Lina framework for Windows XP/200/Vista, MacOS X, Fedora, OpenSuse and Ubuntu.