Code to an imaginary number

The user experience that we wanted to create with the LINA installer has always been the same — native installers for user’s operating systems that were indistinguishable from the installers they were used to using.

But the architecture has changed dramatically. When we originally begin coding the installer, I personally imagined that it could only be available as a service. The program LINA Package (”lina-package”) would take the univeral Linux binary, the XML file, and the image files and send them to the service on our site.

The service on our site would then send those files to a group of machines (a Windows machine, a Mac OS X machine, and a Linux machine) to create the native installers. This was fairly complicated and would have required significance maintenance and possibly significant network traffic.

The first change we made was to work on making it possible to generate the installers on Linux so that the service would not require the Windows and Mac OS X machines. To accomplish this, we created installer templates for each operating system that comprised:

• a Mac OS X Template DMG that contained a Templated Mac OS X pkg file
• a self-extracting Windows installer using NSIS

The key to making this work was several small insights - like creating the proprietary .bom file in the preflight script on Mac OS X - and great Open Source programs like NSIS that enable us to make Windows installers on Linux.

About halfway through the coding process, it became clear that - if the service only required a Linux machine, then it didn’t need to be a service at all. LINA, after all, can run Linux programs on any operating system. Since the Installer Service was a collection of Linux programs, resources, and kernel modules, that meant that if it was converted into a LINA binary, it would be able to run cross-platform on any operating system.

And that is how the complex network of Windows, Mac OS X, and Linux machine that defined the LINA installer service became the LINA Package (”lina-package”) binary that can run on any end-users operating system. Instead of providing access to a network of computers, we can simply send user’s a universal cross-platform Linux binary that can generate installers for any platform.

What I find so beautiful about this is it’s illustration of the power of the LINA platform. In many ways, LINA Package is the first program written specifically for LINA and it solves problems in a way that are practically impossible on the JAVA and .NET platforms. In particular, it integrates several resources that normally cannot run cross-platform including:

• Linux kernel modules to mount the HFS+ DMG partition
• The NSIS program as a native Linux C program
• Tools like tar and gunzip that are part of the LINA Package universal binary but invisible to the end user
• User space in which all of these programs can run and interact.

LINA enabled us to convert our initial requirements from a network of different operating systems to a single binary. The code is in our repository and can be found in the directories src/toolkit/lina-tools/lina-package, templates/installer, and src/libraries.

Our goal on UNIX is to make the experience of installing software the best experience of all three operating systems. It’s possible for us to do this because there is no standard way to install third-party software on UNIX today. Among the possibilities we are considering to make the experience first in class are:

• Adding a table of contents to the left sidebar that let a user know where they are in the install process as in Mac OS X.
• Creating a KDE and console frontend in addition to the current GTK frontend.
• Considering whether to use an approach to the Mac OS X DMG approach which allows for branding and including other items like the Readme and the License before an install starts.
• Making the software available before an install in the user’s native package system (currently the software is integrated into the native package system after the install)

For now, the experience as checked into our source code repository can be improved and we will be working on it. It begins, as with Windows and Mac OS X, with a welcome screen. We have simplified the process by enabling a one-click install for Open Source programs.

If a user checks the box that says “I have read and agree to the license” and clicks the “One-Click Install” button, the Open Source software will be automatically installed with defaults with no more requirements for user interaction. The overwhelming number of users in my experience install software without changing any defaults and Open Source software do not require click-through licenses (commercial products can disable one-click installs).

If the user chooses the Advanced install, then they are guided through an install process that is similar to the one that they experience on Windows (the lack of a Mac OS X like sidebar is painful). The next screen is a license screen:

The next screen is the destination screen which is horribly ugly and needs to be reworked:

This is followed by a progress bar screen:

The installation is then finished and the user is presented with typical Window’s choices of perusing the README or launching the software.

Unlike other cross-platform UNIX installers, we are building ours to cooperate fully with the underlying package management system. We have initially focused on the DPKG and RPM package systems that are used in the overwhelming majority of Linux operating systems. This way, if a user is running Ubuntu’s Synaptic or RedHat’s Pirut software management frontends, they can manage and uninstall the software as easily as they do with native packages on their systems.

The installer code has been merged in the repository and an announcement will be put up on the openlina.org site soon. Continuing from our previous discussion, the lina installer program - which is renamed to lina-package in the source code repository - generates native installers for platforms that LINA runs on. In addition to the Mac OS X experience discussed in the last post, we have worked hard to make the installer provide a beautiful Windows’ experience.

On Windows, the generated installer has the standard look and feel of a Windows installer beginning with the Welcome screen.

The splash image, the license text in the following screenshot, product name, etc. come from the same six image files and XML file from the previous post.

In contrast to the Mac OS X experience, the user can specify where the universal Linux binary can run (LINA binaries are relocatable) because Windows users expect to be able to specify the location of their software.

In addition, the Windows installer created by lina-package integrates natively with the Windows Software system. If an end user goes to the Control Panel and selects the “Programs and Features” control, the user will see WordPress is installed.

If a user double-clicks on the name in the “Program and Features” control, then the uninstaller is launched as expected.

The Windows experience is completely different than the Mac OS X experience because in both cases we are meeting user’s expectations on the operating system.

The installer code is about to be merged into the LINA repository. We’ve focusing very strongly on making the user experience beautiful and the developer work minimal. Today, most Open Source projects are distributed in source form like the directory below of WordPress.

WordPress is a joy to use once it is installed. Installing WordPress, though, is no task for mere mortals — it involves configuring web servers, databases, and other programs. It’s far too difficult for someone who simply wants to use blogging software — a blogger wanting to write about dogs should not have to know how to configure databases.

We are working to change the experience of both developing and using Open Source software. To create a universal LINA binary, a developer only has to run a single command. To use the new installer framework, she only has to combine this binary with a single XML file and six PNG files.

From this minimal amount of work, we then automagically generate native installers, with a focus on beauty and simplicity. For Mac OS X, for example, we convert license.txt to License.rtf, readme.html to ReadMe.rtf, rename the “User Guide” and setup the background image for the DMG.

This provides a best in class experience for Mac OS X users who are used to installing software from DMG’s with background images, ReadMe.rtf, User Guide.pdf, and License.rtf. Here’s an example of a DMG automatically generated from the LINA binary, pictures, and install file.

Next, we use the minimal information in the XML file to create a native Mac OS X installer for WordPress by editing several files like WordPress.info, Info.plist, Description.plist, Archive.pax.gz, and several other files. The result is a native Mac OS X installer:

On the user’s end, there’s no need to figure out databases, web servers, or programming languages. Simply download a DMG and double-click on the installer to install the software. On the developer’s end, there’s no need to learn how to create Mac OS X installer packages, we handle all of the details. We’ll be checking in the code either today or tomorrow as well as the code for Windows and Linux installers.

UPDATE: Changed installer code to rename the DMG (and associated files) to WordPress.pkg. The image has also been updated. We should also provide an option to replace the background Mac OS X installer image.

In the 0.72 release, we are focusing on releasing easy to use LINA and LINA application installers for our existing supported operating systems. In the 0.73 release, we hope to significantly expand the number of operating systems we support. Currently, we’re looking at the following:

 

 

 

Windows

• Windows 2000
• Windows 2003
• Windows XP
• Windows Vista

 

 

Mac

• Mac OS X 10.3 PPC
• Mac OS X 10.4 X86/PPC
• Mac OS X 10.5 X86/PPC

 

 

UNIX

• Solaris 10 X86
• Solaris 10 Sparc
• NetBSD
• OpenBSD
• FreeBSD
• AIX 6.0

 

 

 

Linux (RPM based)

• RHEL 4, 5
• CentOS
• PCLinuxOS
• Fedora 7/8
• OpenSuse 10.2/10.3
• OpenSuse Server

 

 

Linux Debian Based

• Ubuntu 6.06/7.10
• Kubuntu (latest)
• Debian 3.1, 4.0

The benefit of the testbed build system that is almost complete is that it will make supporting new operating systems trivially since it is designed to scale.

We just merged the first part of the LINA library back into the lina repository. The reorganized library has been rewritten to include several productivity features for programmers including

• Qt style signals and slots - replaces the old event system
• Java like garbage collection - using shared pointers
  
• Presentation-abstraction-view programming model - replaces model-view-controller
• Containers - lists, vectors, etc., in their own namespace
• Functional programming - map and bind
• Better organized namespaces -in place of a prefix naming system like “q” or “l”
• Lorax code processor and generator

The differences between the libraries can be seen through examination of the image program (samples/gui/image) which uses the old library, and a simple calculator program (samples/gui/calculator) which uses the new.

We are still transitioning quite a bit of code from the old library to the new library so code will continue to be merged in. We will also be adding in code to create cross-platform management consoles, higher level abstractions, and several features only possible on the LINA platform after the merge is complete.

Tomorrow, we’re going to be performing our first test of our testbed software. Testbed creates a distributed build of LINA for several different operating systems.

The code behind Testbed is intentionally simple with a master python script, a build script, a script to send results, two shell scripts to automate key exchange, and a star topology.

Testbed works by sending a virtual disk image of an operating system that we are testing to one of the remote computers in the testbed network. The host computer then boots the virtual disk using a virtual machine to start up the foreign operating system that we are testing. Next, the build script is sent to the foreign virtual operating system and LINA is built on that operating system.

Although simple, the appeal of Testbed is it’s ability to automate our builds and tests. It will enable us to scalably support new operating systems and radically increase our productivity in debugging LINA in new and existing environments.

We released the source to LINA a little over a week ago, a major milestone for both our project and our company. For those who have been following, there is now:

• a GIT repository
• a RoadMap
• User and developer forums
• Bug Database
• Wikis
• Technoloy Overview
• Howtos

The Roadmap enables members of the community to track releases and participate in the direction of LINA. Each release is on a short two to three week development schedule. The next three releases are:

• Release 0.71 - fixing build bugs on different platforms, adding checkpoints during the build, and fixing a few remaining bugs from our transition to native Windows binaries
• Release 0.72 - improving the tools used by developers to create LINA packages (we can make them radically simpler - essentially automatic - if we make them a smarter in analyzing installs).
• Release 0.73 - a subset of the LINA APIs and developer binaries for easy installs on Windows, Mac OS X, and Linux

0.73 is the critical release for us - it’s the point at which we will have LINA to a state that the larger Open Source community can easily use LINA to create universal binaries of their programs for every platform.

We’re going to be opening up our source code repository in the next three days under a GPL/commercial license. In the meantime, I have a new member of my family: Frog.

I adopted Frog from the Bay Area Pet Fair, a wonderful annual event in which dozens of adoption agencies bring the animals they have up for adoption. I spent time with several dogs there and Frog was a sweet, smart, amazing dog that stood out. I named him “Frog” because he is very sweet, has webbed feet, and a frog-like nature towards water.

His webbed feet (which go to the top of his toes like a frog or duck) are standard on Catahoula Leopard Dogs. Catahoulas are descended from Spanish war dogs and the Red Wolves of North America. They have merle coats like Australian Shepard and when they have blue eyes, eighty percent of the time they are deaf.

I wasn’t planning on adopting a deaf dog, but Frog mercilessly stole my heart as I spent time with him. He’s still a puppy, but there’s a gentle, open, and protective side to him. There’s also a somewhat wild side, perhaps because he wasn’t treated well at his previous home and was a stray when he escaped. I’m working to tame that wild side and researching the ins and outs of raising a deaf dog, including sign language.

Frog is adjusting well to his new home. As an example, this is his bed which we carefully picked out together after considering several different options.

And this is where he really sleeps (I decided to let him because it’s nice to have him next to me when I read).

This was my second time to Portland and I still find myself wanting to move there every time that I visit. Portland has a great culture, an amazing public transportation system downtown, and of course Powell’s.

Powell’s is like Amazon’s in the flesh. It’s the size of an entire city block and four stories tall. Laid out like an amusement park for book lovers, I could get lost in Powell’s for hours.

I was not able to attend many sessions at OSCON this year, but I did manage to see the State of the Onion in person which I have wanted to see for years.

I bumped in to Larry Wall later at a party and he’s as nice and quirky as he seems on stage. It was fun picking his brain on language design, since he brings such a different perspective to programming.

Aside from the State of the Onion and practicing our presentation, we spent most of our time at our booth, answering questions about LINA, putting our booth’s sticker on the contest sheet, and raffling off our LINA mugs.

We met developers who wanted to run their Open Source applications on Windows, businesses that wanted to reach the Windows market, and dozens of people who just wanted a sticker for the contest.

Saill and I also gave a presentation on LINA - Cross-platform Linux Binaries on Thursday. Saill shined as she explained what LINA was and how we had implemented its internals.

I focused on the future of LINA. As the first cross-platform Virtual Operating System, LINA opens up many possibilities in programming. We’ll post the updated presentation sometime later this week for those who were unable to attend.