This article ties together a number of exciting ideas in the Free/Open Source (FOSS) community, to suggest a new direction for the Linux distribution. Many of these ideas are also applicable to BSD-based systems.
Although there are several mature, high quality distributions available, Linux has had a very hard time breaking through in certain markets, such as the desktop. In addition, the internet, which has already dramatically transformed the environment for other content-creating industries, may now alter the established methods for software packaging and installation.
The activities around Web 2.0 are giving rise to Software as a Service (SaaS). For example, Google claims that more than 100,000 small businesses, as well as a few large ones, have signed up for Google Apps. Of course, Microsoft is trying to build its own SaaS offering, Windows Live. Meanwhile, many categories of Web applications are already mature, including email, social networking, and e-commerce. The next step is the Web OS; a race that, in the end, may go to a startup company.
As I hope to demonstrate in this article, FOSS tools are the right technology to define the post-PC software era, and not merely as a backend platform for someone else's proprietary SaaS suite. Today's typical Linux distribution, however, follows a design that resembles a legacy Unix system with a Windows-style front end bolted on. This is a competitor to products such as Vista, which may actually be the last of its kind, even for Microsoft. It would be unfortunate indeed to suddenly find ourselves stuck with yesterday's business model.
It is important to realize that the current approach to packaging FOSS is not the only possibility. The FOSS universe is by far the most diverse codebase in the world, and a capacity for diversity is the key to resilience as well as innovation. This is true in ecosystems, economies, investment portfolios, and even the skills of an individual. So, let us see how we can rearrange the traditional Linux distribution, to meet the challenge of the emerging new era.
The central purpose of this article is to try and start a genuinely fruitful discussion on the future of the Linux (or *BSD) distribution, a discussion which may help inform the direction of existing projects, and perhaps spawn new ones. Please continue this discussion by contributing ideas, references to other articles, and especially links to anything that includes actual code (even tiny examples).
Above all, I hope we treat this as an opportunity for shared exploration, not a contest about who is the "smartest guy in the room." This is a matter of proper governance (see the "A Note on Governance" section below), which is perhaps of equal importance to the future of FOSS as actual running code.
Here is a list of topics covered in the article.
In addition, two appendices cover important supplementary topics for Linux distribution developers and SaaS providers. The first concerns packaging, hosting and delivery of Linux distributions. The second proposes a strategy to deal with the costly (and environmentally damaging) waste resulting from large server farms.
Now, let us begin our (re)exploration of the Linux distribution.
Before you can build for the future, you must take care of the past. Years ago, a wonderful toolset evolved around Unix. awk, sed, find and others, used together in shell scripts, could accomplish a great deal of work very quickly. Compare this approach to writing everything in C!
Today, however, the state of the art has advanced considerably. High-level languages (of which Perl, Python, and Ruby are the most popular) are far more capable than the old patchwork of small tools bound together with shell scripts. They incorporate elegant programming constructs, supply comprehensive standard libraries, and support rapidly growing communities of extension projects.
Yet, system administration is still tied to the shell and the old toolset, despite the astounding advantages of moving to a modern high-level language. Programming with such languages is faster and less error prone. The code is much more reusable, portable and upgradeable. Developers can write readable programs, which makes collaboration easier. Likewise, finding and training developers is a simpler task. Customizing server farms, clusters, corporate desktop rollouts and even novice tinkering all benefit.
Any one of Perl, Python, or Ruby (as well as a few others) could become the primary system administration tool, displacing the shell. In my experience, however, Python's highly readable, compact and consistent syntax makes it the ideal choice for this sort of work.
Many well-known Linux distributions already use Python in their key tools. Red Hat's Anaconda installer, and Gentoo's Portage package manager are two examples. Ubuntu (the top distribution for the last 12 months, according to DistroWatch) "... prefers the community to contribute work in Python."
The next logical step is to create a complete system administration environment using a high-level language. In large measure, this project is already underway. A relatively recent, highly rated (see review links on DistroWatch) distribution, Pardus, uses Python across many of its core tools. The Pardus team, recognizing that "High Thoughts Must Have High Language", has even written a new init framework in Python. Here is how they explain their choice.
Among the high level languages, Python seemed to be the best choice, since we already use it in many places like package build scripts, package manager, control panel modules, and installer program YALI. Python has small and has clean source codes. Standard library is full of useful modules. Learning curve is easy, most of the developers in our team picked up the language in a few days without prior experience.
Certainly, there exists a requirement for backwards compatibility with the old shell-based code. It is not difficult, however, to make these legacy tools available as optional packages, to ease the transition to the new system. Even here, augmentation with high-level languages provides significant benefits. The IPython project is an interactive Python shell that also retains much traditional shell functionality. In addition, IPython supports the Matplotlib graphing package.
Figure 1 shows an example of what IPython and Matplotlib can do. in about nine lines of code, excluding comments. Each circular patch on the graph represents a single process, larger patches indicate greater virtual memory size (
vsz format specifier to the
ps command). Percent CPU (
%cpu) use is on the vertical axis; you can see that most processes are using little CPU. More red color in a patch indicates a process whose resident size uses a greater percentage of the machine's memory (
Figure 1: Graph of process CPU and memory use, generated with IPython and Matplotlib
To generate a graph simiar to Figure 1 on your system, download the IPython log and replay it with
ipython -pylab -p pysh -logplay <filename>. It is beyond the scope of this article to cover installation of IPython and related tools, but this should not be difficult. Your distribution may also have packages available already.
Even basic system administration tasks, using the simplest of traditional commands, benefit from supplementation with a high-level language.
If the network is the computer then the browser should be your desktop.
There is definite enthusiasm for Firefox as a platform. The Web is already an essential tool, just about everyone has a browser open all the time. The browser is our interface for doing research, catching up on email, booking an airline ticket, and performing banking transactions. As mentioned at the beginning of this article, many SaaS applications are now mature, and more are on the way. Online tools can even handle photo editing. In fact, SaaS may already fulfill all the needs of some users.
Of course, there are still security problems to resolve, and skepticism if a SaaS-only solution is generally possible, or desirable (including in established areas such as email). The desktop application is far from dead.
Firefox, however, with its tabbed interface and long list of powerful extensions, makes even the wilderness of the Web seem like home. Could it not do the same for local applications? What if Firefox became a portal that mashed up plain web sites, remote SaaS applications, and local programs with each other? Is this the real future of the Web OS?
During the writing of this article, a discussion arose on the
mozilla.dev.planning list, about building a Mozilla-based operating system layer. The discussion mentioned many alternatives, including earlier projects that had similar goals (such as Symphony OS and Penzilla Desktop), the use of XUL (Mozilla's XML-based user interface language) to produce a graphical desktop environment, and running Ajax applications offline. Of course, some of these ideas are already close to reality: Firefox 3.0 will support offline Ajax execution and DOM storage.
Surprisingly, even currently mature technology is nearly sufficient to make Firefox the primary user interface. The browser itself can perform the role of an X window manager (see below); its tabs provide an elegant alternative to traditional windows. After all, if users are spending more and more time on the Web, what could be more natural than just opening another tab to use an application, even if that application happens to be local. In fact, Mac OS X has a tool "which extends the tab browsing experience to the Desktop." The Ion X window manager also uses this approach.
Figure 2 shows Firefox running without a window manager. The tabs work as expected, and even dialog boxes are largely usable. For now, a minimalist window manager (blackbox or ratpoison, for example) would improve some functionality, such as the dialog boxes.
Figure 2: Firefox without a window manager; the "Preferences" dialog box is functional, despite the lack of a window frame
The next step is to integrate native applications with the browser. Virtual Network Computing (VNC) is the most mature option. Figure 3 shows a default Ubuntu 6.06 LTS (Dapper Drake) desktop, running inside Firefox using the TightVNC Java applet. This is a common approach for remote system access, but here everything is on the local machine. Firefox is running without a window manager, like in Figure 2. Note that Sun's Java is not yet fully open, but Sun is committed to FOSS licensing.
Figure 3: Firefox, showing a standard GNOME desktop using the TightVNC Java applet
Of course, a Firefox tab is ideally suited to focus on just one application. Figure 4 shows OpenOffice, running with the ratpoison window manager. The VNC-based integration with Firefox is nearly identical to that in Figure 3. If Firefox included some window manager features, it could control applications directly.
Figure 4: Firefox, showing OpenOffice using the TightVNC Java applet.
You can download the source code (a short shell script) for the Firefox examples above. The comments provide further directions. Installation is beyond the scope of this article, but your Linux distribution should provide sufficient packages to allow you to experiment. Note that generally, X windows offers many capabilities for combining multiple desktops.
A window manager designed specifically for the VNC-based integration illustrated here could replace or augment any window management facilities built directly into Firefox. With multiple tabs open to the same desktop, such a window manager could automatically launch and maximize the desired application, depending on which Firefox tab the user selects.
It should be relatively straightforward to complete the required command path. After all, a VNC applet running inside a tab can already operate a window manager, via the VNC server. This design would allow the browser to control multiple remote applications, as well as local programs.
The specialized window manager could also maintain support for a traditional desktop view (as shown in Figure 3), or a tool similar to Skippy could provide this functionality. In addition, a compositing feature could generate window controls in the form of transparent HUD-style overlays (such as those used in aircraft) instead of traditional window decoration. The idea is not to compete with Compiz or Beryl for visual sophistication, but to provide a very compact interface, which focuses the user's attention on a just a single underlying task. Firefox itself would be the desktop environment, coordinating multiple tasks.
There are also alternatives to VNC (in various stages of development) for integrating X-based applications with Firefox. The WeirdX Java-based X server is one possibility. The WeirdMind project integrates WeirdX with the MindTerm SSH client (also in Java), giving encrypted shell and X access via the browser. Unfortunately, this project only supports the SSH1 protocol, and there are no recent updates.
The NoMachine NX Server (which won the Linux Journal/LinuxWorld 2006 award for best integration solution) offers fast remote X access. There is a FOSS version of the product (FreeNX) but the Java applet required to integrate with the browser is proprietary. The Univ-RX project is developing a FOSS Java applet that should work with FreeNX.
In summary, a complete Firefox desktop is perhaps not ready today, but with some work on integrating the components, it should be possible to produce one quickly. This would be an important step toward a consistent interface between web applications and traditional local programs. It also translates well to future portable devices, where a tabbed interface would ease navigation and make efficient use of the smaller screen space. Since the web browser will almost certainly be a central part of such devices, it is a good choice for implementing the overall user environment.
Overall, the Firefox desktop should encourage a move toward mashup suites of online and installed code, instead of monolithic, standalone software of either type. Now, the distinction between local and remote applications really begins to disappear.
The logical conclusion of the above refactorings may well be the Web OS. It would, however, be a free (FOSS) Web OS, not a proprietary one. This, in turn, is what may finally allow broad adoption of the technology. If only a few large suppliers offer such services, then the Web OS must overcome the steep reluctance of customers to give up control of their data, reluctance which may have doomed Microsoft's Hailstorm, and could yet harm Google Apps. The free Web OS, however, supports many more options for deployment, to better suit the needs of different users.
For example, ISPs know Linux well. The have provided managed hosting on this platform for awhile; some are now adding virtual private servers as well. For them to offer the Web OS, reached via the route described here, is not much more difficult than installing another Linux distribution. Many small and medium organizations may get better personal service from a local, trusted ISP than from a large supplier.
Similar arguments apply inside the corporate datacenter. With generic Linux boxes running a free Web OS, organizations can get most of the benefits, while retaining full control of their data.
Of course, products from large suppliers, such as Windows Live and Google Apps, will continue to have an important role. They will, however, be part of a diverse Web OS universe, a fact that may ultimately make them more successful than if they stood alone.
How will the free Web OS work? To fully understand any Web OS, you must consider at least the client machine, in addition to the server to which it connects. From the client's perspective, it is possible to use software in three major ways:
Variations include downloading local code in binary form or compiling it from source (the approach used by Gentoo), and online code designed for multiple browsers or a single browser (such as Firefox 3.0).
Clearly, a pure Web OS is impossible; a kernel must run wholly on the client, for example. The exact mixture of components, however, can be very flexible in a free Web OS. This should allow multiple system flavors to emerge. In the future, it may even be possible to just go to a trusted site, and start using any application right in the browser, even if some (or all) of the components will be installed locally at first launch.
Advanced users may choose to run more software on their workstations, and assemble suites of online components on their own. Other users may choose a single Web OS provider, and run that provider's set of applications. Just like it is readily possible to switch ISPs today, a competitive Web OS environment will allow customers to select services from different vendors, piece by piece.
As mentioned earlier, it is my hope that the arguments presented here will create a discussion, from which genuine improvements will emerge. To this end, it is necessary to mention a few important things about project governance and the nature of debate.
Governance is a critical topic to the world at large, and FOSS is no exception. In a recent interview, Debian's founder argued that process paralysis is hurting the distribution. Also, members of the Subversion team gave an entire Google talk about dealing with "poisonous people" on a project. Sometimes, online discussion can even degenerate into something far more serious, such as the threats made against Kathy Sierra. Tim O'Reilly has proposed a blogger's code of conduct in response to that incident.
Proper governance, however, needs a sound philosophy, a model, in order to function. Of course, nothing could be accomplished without the community's desire for fairness and justice, but the model is also essential. The community is the musician, the model is the instrument. Interacting with others based on the wrong set of assumptions will lead to problems, including process paralysis, the emergence of "poisonous people", or worse.
When considering FOSS governance and online discussions, such as the future of the Linux distribution, the notion of a scientific inquiry is particularly suitable. Just like FOSS emerged from the academic world to transform other areas (including business), so the basic practices of science can inform projects outside the realm of research.
Here are the best parts of the scientific approach.
Note that the common FOSS practice of encouraging patches from newcomers is an example of the scientific approach. New ideas are welcome, but it is important to show something that actually works.
The recognition of the value of negative results is in contrast to the prevailing strategy of blaming individuals for failure. The latter approach is actually of limited corrective value, and often leads to the kind of hostile situations cited at the beginning of this section. The Aviation Safety Reporting System (ASRS) offers a striking example of the value of learning from mistakes. Operated by NASA, the ASRS encourages detailed, penalty-free reporting of errors in the field of aviation, then anonymizes and publishes the results. The idea has clear interdisciplinary potential. Kim Vicente's book, The Human Factor, describes how hospitals which adopted ASRS-style techniques in place of traditional focus on individual guilt saw medical errors decline 90 percent.
If we adopt the spirit of scientific inquiry, then the resulting discussion has a chance to stimulate the emergence of a new type of platform. The subject will likely turn out to be much deeper than the familiar "Linux on the Desktop" or even "Linux for the Enterprise" debates. After all, the vastness and openness of the FOSS codebase is good for more than just following the existing trends. It can also uncover new trails.
This section highlights some of the items referenced in the article, and provides supplementary materials. The URLs are fully specified in the text, so that they show up on any printed copies.
The Pardus Linux distribution has published a number of articles about their work. In particular, "Speeding up Linux: One step further with Pardus" offers many insights (http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.html). Also important is "Python in Pardus", which details the team's experience with the language (http://www.pardus.org.tr/eng/projects/comar/PythonInPardus.html).
The IPython documentation is necessary for anyone wishing to use this tool for system administration (http://ipython.scipy.org/moin/Documentation). The section "IPython as a system shell" is particularly relevant (http://ipython.scipy.org/doc/manual/node12.html). A helpful note on this topic can also be found at http://brianray.chipy.org/Python/IPythonShell.html
If you wish to use Matplotlib together with IPython (as shown in the article) the project homepage includes a reference to the plotting commands; scroll until you reach it (http://matplotlib.sourceforge.net/). You may also benefit from their tutorial (http://matplotlib.sourceforge.net/tutorial.html).
The O'Reilly Network article "A New Visualization for Web Server Logs" also contains interesting information on high-level languages and visualization for system administration (http://www.linuxdevcenter.com/pub/a/sysadmin/2007/02/02/3d-logfile-visualization.html). It describes an approach using Gnuplot and Perl.
mozilla.dev.planning discussion of the Mozilla OS offers lots of insightful ideas (http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/296edcea6c1fbe63/93aab2685aefdde7#93aab2685aefdde7). Also valuable is the Firefox 3.0 overview from PC Magazine, "Inside Firefox 3.0, Alpha 3: Gran Paradiso" (http://www.pcmag.com/article2/0%2C1895%2C2109401%2C00.asp).
A fascinating experience with using SaaS for everything (list of applications included) is available at http://www.lifehack.org/articles/technology/firefox-os-why-my-hard-drive-software-are-obsolete.html
For an excellent introduction to experimenting with X windows, see the Linux Journal column, "Cooking with Linux--Can't Get Enough Desktops!" (http://www.linuxjournal.com/article/7298).
On the issue of governance, read the "Call for a Blogger's Code of Conduct" (http://radar.oreilly.com/archives/2007/03/call_for_a_blog_1.html). Most importantly, the widespread strategy of blaming individuals is the most likely cause of hostility on FOSS projects and online discussions. Kim Vicente's book, The Human Factor, provides a fascinating account of the ASRS approach, which delivers far superior results (http://www.amazon.com/gp/product/0415970644/).
The packaging and delivery of Linux distributions is a difficult problem today. Current distributions are expensive and complicated to host, due to their size. Last year, Mepis faced this problem. The highly regarded distribution (number five on DistroWatch over the past 12 months at the time of writing) violated the GPL by not hosting the source code for every binary which it included.
Of course, Mepis was not trying to hide anything (the complete source code was readily available elsewhere) but it was still contrary to the GPL. The fault here is not with Mepis or the FSF. It lies in the fact that existing hosting, mirroring, packaging and delivery systems (which have served us well in the past) are beginning to show their age. Now is the time to consider what comes next.
As mentioned at the beginning of this article, diversity is the strength of FOSS. It should be easier for new distributions to get started. At the same time, having lots of identical, and nearly identical, programs floating around on the internet is wasteful and confusing. Which version is the canonical one, released by the project's authors? How do the available variants differ from one another?
What if the package management utilities were to download only the canonical project sources, via BitTorrent? These utilities could then use patches to "personalize" the code for a particular distribution. This approach is similar to how Gentoo works today.
Using BitTorrent in the package manager shields the user from having deal with torrents directly. It also makes it possible to create a package-level repository of torrent seeds, which many distributions could share.
For source distributions, the seeds would derive directly from the released code for each project. For binary distributions, perhaps the Linux Standard Base (LSB), which has made binary compatibility between distributions its goal, could operate the required seed repository.
Such a "FOSS seed bank" would consume minimal resources. Downloading via BitTorrent makes far better use of the network than the traditional host-and-mirror approach. In fact, the need for mirroring should decline significantly.
In general, we should pay more attention to the location and flow of FOSS code across the global internet. Better organization of the entire distributed FOSS codebase, with clearly visible lineage information between projects, would allow everyone to use this vast universe of resources much more effectively.
Google already offers Code Search, and a microformat for licenses also exists. Perhaps a few microformats, and a suitable search engine, would be the first step.
Environmental concerns closely follow the emergence of the Web OS. Such services will require more machines at the datacenter. Even today, however, electricity consumption of large server farms is a serious problem, for the environment as well as the bottom line.
Disposal of computer equipment (e-waste) is also an issue. These unwanted machines contain many poisonous substances, and various governments are implementing new taxes to deal with the resulting toxic garbage.
Of course, there is evidence that FOSS, which requires fewer computing resources and less frequent upgrades, is already friendlier to the environment. What is needed is a specific effort towards green software, in parallel to the movement towards the Web OS. Programs which emphasize efficient use of computer resources (memory, CPU, disk, and bandwidth) delay obsolescence, while requiring fewer machines in the first place. This, in turn, reduces e-waste and electricity consumption. Saving computing resources translates directly into preservation of actual physical resources.
Nor are kernel changes, or virtualization alone sufficient to create green software. First of all, developers of such system-level software must already consider resource conservation, otherwise the resulting platform would be impractical for running application code. Therefore, rethinking resource use at the application level would likely uncover many more unrealized efficiency gains. Also, virtualization, which provides a great efficiency benefit by consolidating underutilized hardware, may actually hurt performance under peak loads.
The Linux distribution, however, is more than just a kernel, or system-level tools. It includes thousands of applications, assembled into entire environments. A "SaaS Ready" distribution can provide built-in examples, frameworks, network protocols, and benchmarking suites (complete with GUIs) to guide developers in writing more efficient applications. In turn, careful attention to conservation at the application level should reduce resource requirements (particularly electricity) that would hamper the adoption of SaaS and the emergence of the Web OS.
George Belotsky is a software architect who has done extensive work on high-performance internet servers, as well as hard real-time and embedded systems.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.