User: Password:
|
|
Subscribe / Log in / New account

Leading items

The birth of the open source enterprise stack

June 26, 2006

This article was contributed by Glyn Moody

For the first ten years of its life, free software was largely a hacker's tool. All the early programs – Emacs, GCC, Perl, Linux – were written by coders for coders (usually themselves). It was the rapid uptake of the Internet by business in the mid-1990s that led to free software being used by companies, not just their employees.

The unplanned nature of this move online meant that computer departments were often asked to create a Web presence without being allocated extra funds. Free software was the obvious solution. The ready availability of GNU/Linux and Apache, whose first official release had appeared in December 1995, meant both were soon found in many companies, but generally unofficially. Software engineers knew it was easier simply to install the code than to go through formal approval processes that were bound to be skeptical of this new kind of software. The same was true for Samba, which allowed IT departments to add low-cost file and print servers to Windows networks.

At this stage, then, free software was on the periphery of companies, providing non-critical functions, and often invisibly as far as management was concerned. Gradually, though, word got out about the reliability and attractive price-performance characteristics of free software in general, and GNU/Linux in particular.

Similarly, software suppliers were discovering that their engineers were not only using free software but sometimes had even ported major proprietary software packages to GNU/Linux on their own initiative – as happened with Software AG's Adabas D database, which shipped in 1996 as part of the Caldera Solutions CD. This fact, together with the growing use of GNU/Linux within companies, prompted the release in 1998 of official ports of the main enterprise-level databases: those from Oracle and Informix in July, and IBM's in December. It was a significant moment in the rise of open source in companies: free software was now countenanced officially, and started to play a mission-critical role.

At the same time, free software began to provide more complex business solutions through the deployment of what came to be termed the LAMP stack: GNU/Linux, Apache, MySQL and Perl/PHP/Python - the term “LAMP” was coined in 1998 by Michael Kunze in the German c't magazine. The stack represented a more sophisticated version of the approach based around the earlier Common Gateway Interface, which was used to interface Web servers with external applications like databases.

MySQL had first appeared in 1995. As well as representing an important breakthrough for open source application software in the enterprise, it also brought with it a new business model. In the beginning, the copyright for open source code had either been assigned to the Free Software Foundation to allow more effective enforcement of the GNU GPL, or remained with the various individual coders who had contributed. In the case of the MySQL code, though, it is the software house MySQL AB, which was created around the software, that owns all the copyrights.

Because of this, MySQL AB is able to employ a dual-licensing policy, offering its database under the GNU GPL or a commercial license. Some have seen this development as a threat to the core ethos of the open source world, because it raises the specter of a new, more subtle kind of vendor lock-in. Although the most popular, MySQL is by no means the only free database program: others include Firebird, Ingres and PostgreSQL.

The early years of the 21st century were ones of steady gains for free software within the enterprise. In the wake of the dotcom crash, which saw first-generation open source companies like Linuxcare, TurboLinux and VA Linux scaling back their operations dramatically, there were relatively few venture capitalists or IT start-ups that were willing to take a chance on new areas of free software. But corporate use of GNU/Linux in particular flourished, as the free operating system was increasingly used to save money by allowing companies to move from expensive proprietary hardware running Unix to commodity systems based on Intel processors.

One open source company that did appear during this time was Gluecode. It offered a commercial version of Apache Geronimo, the J2EE server project of the Apache Foundation. This was an important development, because it moved open source closer to the heart of the enterprise. Gluecode received a validation of sorts in 2005, when IBM bought the company, and added the open source product to its WebSphere Application Server line as a “Community Edition”.

IBM presumably preferred to cannibalize its own sales rather than see another increasingly-popular open source middleware company, JBoss, do the same. The JBoss project began in 1999, and, like MySQL, introduced a novel business approach to working with open source. It effectively commissions code for free software projects by hiring their top coders, thereby adding an element of commercial direction to the open source development process that was hitherto lacking. Also like MySQL, JBoss the company generally retains the copyright in the JBoss code. The JBoss way received its own vote of confidence when the company was acquired in April 2006 for $350 million by Red Hat, after being courted by Oracle, which has been on something of an open source spending spree.

The acquisition of Gluecode and JBoss, and Oracle's interest in the latter, firmly establishes middleware as the new hotspot for enterprise open source. Alongside IBM's WebSphere Application Server Community Edition and JBoss, there are several other free programs, including Enhydra, JOnAS and WSO2 Tungsten. Together, they represent a key piece in the creation of an open source enterprise stack, with GNU/Linux as the foundation.

It is here, rather than on the desktop, that free software's next big gains are likely to take place, and a subsequent feature will explore the surprising richness of the upper layers of the emerging open source enterprise stack, in areas such as systems management, customer relationship management, business intelligence, enterprise content management, enterprise resource planning and communications.

Glyn Moody writes about open source at opendotdotdot.

Comments (31 posted)

Interview: Jim Gettys (Part I)

Jim Gettys has a long history at the interesting edge of computing development; his past projects include MIT's Project Athena and the X Window System. Currently, Jim is working on the One Laptop Per Child project, which seeks to distribute low-cost, Linux-based systems by the millions to children in the developing world.

Jim was kind enough to take what must have been a considerable amount of time to answer our questions on this project. What follows is the first part of the interview.

LWN: Could you briefly describe your role with the OLPC project?

Vice President of Software: in short, I worry about systems software from one end of the project to the other and relations with the free and open source software community.

The educational software and content are the province of others: Nicholas Negroponte (the OLPC chairman), Walter Bender, Seymour Papert, Alan Kay, and others, who have decades of experience in education of children with computers, often in the developing world.

I also don't worry about how the bits get from machine to machine: Michail Bletsas is our Chief Connectivity Officer. Mary Lou Jepsen is our CTO, and responsible for our novel display technology, and Mark Foster is V.P. of Engineering and chief hardware architect. Quanta Computers, founded by Barry Lam, who make almost 1/3 of the laptops of the world, are building the OLPC machine.

It appears that few people appreciate the extent to which this project is pushing the leading edge of free software development.

Our hardware is novel to meet the needs of children in the developing world; much of the software we need to build in the short term are driven by this novelty. We expect many of our innovations will appear in conventional laptops over the coming years. In this case, Linux will be leading rather than following the industry.

What are the features one would want for school-aged children, grades K-12? A large fraction of such children are in parts of the developing world where electricity is not available at home, or often even at school, so for many children, a computer with low power consumption, potentially human-powered, is a necessity, not a convenience.

Teaching may not even be inside, and certainly when children are at home, they often will not be inside where conventional LCD screens are usable. Children usually walk to and from school every day; weather is unpredictable, rain, dirt and dust are commonplace. And cost is a major consideration, if we are to bring computers and their great power to help children learn, to children everywhere.

Much more about the hardware can be found in our wiki.

Consider the power management issues, application slimming, system (non-)management improvements, mesh networking, application checkpointing, pervasive IPv6, localization problems, etc. Every one of these goals should benefit users who will never see an OLPC system. How many of these goals do you think you will be able to achieve by launch time?

Some of these items are all-or-nothing: others are suitable to incremental progress. Let's take them one at a time.

Power management: We are doing at least two, if not three, true innovations in this area:

  • The Marvell wireless chip, which has an ARM 9 and 92K of RAM, can forward packets in the mesh network while the processor is suspended to RAM. This capability has been demonstrated in the lab, and Michail Bletsas is confident of the outcome; in fact, it was an actual demonstration that convinced us to use Marvell. Other wireless vendors lack this capability. Our current estimate is that in this mode, the wireless chip can be forwarding packets and the system consuming less than a half a watt. We want there to be as little incentive to defeat wireless as possible, so this is a key innovation: if children aren't confident there will be power when they need it, they might work to defeat the mesh.

  • The display can be on while the processor is suspended, saving power. In some modes, we expect to be suspending the CPU whenever it is idle, even for times as low as a second or two. Since our display is also novel and consumes much less power than conventional LCD's, even the Geode's low power consumption would have otherwise dominated total energy use.

  • Look around you the next time you sit in a conference room. How many of you are actively using your machine at any given instant? How much of the time are you just reading the screen? In many modes of use, once the screen power consumption has been solved (as it is in our display), the remaining major power consumption is the processor, power supply and motherboard components. By making suspend/resume unnoticeable, we can save most of the remaining power used in the system.

Mark Foster described his novel extremely fast suspend/resume software technique at the Linux Power Management Summit this spring. Whether we will need to implement it on our hardware to reach our goals of < 200ms suspend/resume cycles awaits some laboratory tests (an iPAQ can already suspend and resume in a subsecond period), but I expect we may need to implement this technique. Any performance work *must* be preceded by measurement to be useful: spending time optimizing the wrong code is a waste. Of course, the faster suspend/resume can be made to work, the more aggressive we can about suspending and saving power. This is an example of an area where incremental improvement (once basic capabilities) is possible.

We are also planning to dynamically change the refresh rate of the screen depending on screen activity; as I've seen this capability in graphics chips for cell phones, I won't claim this as full innovative, though it will be new for the X Window System or window systems on laptops.

It is hard to predict how long similar hardware capabilities will take to reach conventional hardware; but by showing it is possible, we know it will happen and the software support required be useful to everyone.

There are also a number of places where changes in Linux and the desktop environment can help. For example, the tickless patches currently being worked on obviate the need for the CPU to wake up 100 times a second; the more of the time a processor is fully idle, the more power saved. Another example are places where the desktop environments are polling periodically to find out changes in the system: notification systems are much more efficient, and allow the system to be idle more of the time.

Out of memory behavior needs serious work: the current OOM killer's policies are by current necessity very poor. Nokia has been experimenting with more useful policies, exploiting information at the user environment level, that can improve this behavior by informing the kernel which processes are the most vital and which can be shot.

Application slimming: There seems to be a common fallacy among programmers that using memory is good: on current hardware it is often much faster to recompute values than to have to reference memory to get a precomputed value. A full cache miss can be hundreds of cycles, and hundreds of times the power consumption of an instruction that hits in the first level cache. Making things smaller almost always makes them faster (and lower power). Similarly, it can be much faster to redraw an area of the screen than to copy a saved image from RAM to a screen buffer. Many programmer's presumptions are now completely incorrect and we need to reeducate ourselves.

Sometimes we may just choose alternative applications. Of course, this may not be what some application writers would like, and the solution they can take is obvious. We have a large set of software to choose from: this is one of open source's great strengths.

Federico Mena-Quintera and others have been doing some very nice work identifying and fixing some of the gratuitous memory usage.

A large part of this task is raising people's consciousness that we've become very sloppy on memory usage, and often there is low hanging fruit making things use less memory (and execute faster and use less power as a result). Sometimes it is poor design of memory usage, and sometimes it is out and out bugs leaking memory. On our class of a system, leaks are of really serious concern: we don't want to be paging to our limited size flash.

In fact, much of the performance unpredictability of today's free desktop can be attributed to the fact that several of our major applications are wasting/leaking memory and driving even systems with half a gigabyte of memory or more to paging quite quickly. Some of these applications we care about, and some we don't: OpenOffice is just not the right tool for someone learning to read and write, and we'll be perfectly happy to use other tools. Some other major offenders need fixing (and work has started): e.g. Firefox (Gecko), which, when using tabs, has been hemorrhaging memory, which can force you to paging quite quickly. Between evolution-data-server and Firefox alone, many people's desktops exhibit unpredictable performance soon after boot due to paging; fixing these problems will benefit all.

Tools: The memory usage display tools we have today are very misleading to naive (and even journeyman) programmers, often leading them to massively wrong conclusions.

My biggest personal frustration (given my history with X) are people saying: "X is bloated". The reality is: a) X maps all the frame buffer and/or register space into its address space, so measurement of virtual address spaced used is completely misleading: X may be actually consuming only a very small amount of your DRAM, despite a virtual size of a hundred megabytes, and b) X does what its told: many applications seem to think that storing pixmaps in the X server (and often forgetting about them entirely) is a good strategy, whereas retransmitting or repainting the pixmap may be both faster and use less memory. Once in a while there is a memory leak in X (generally in the graphics drivers): but almost always the problem are leaks in applications, which often forget the pixmaps they were using.

RAM in the X server is just as much RAM of your program, though it is in a different address space. People forget that the X Window System was developed on systems with 2 meg of RAM, and works today on 16 megabyte iPAQ handhelds.

We need better tools; some are beginning to appear. OLPC is sponsoring a Google Summer of Code student, Eduardo Silva, from Chile, who is working on a new tool called Memphis to help with this problem.

Work done on memory consumption will benefit everyone: not everyone in the world has a 2ghz laptop with a gig or two of RAM...

System (non-)management improvements: I think there are two, mostly separable areas here: 1) the kid's laptop, on which we want to focus primarily on making "easy to fix", rather than "hard to break", so interested children can learn computing. And by working hard to automate backup, we'd like the restore of a laptop to be dead simple if there is some problem. By using LinuxBIOS, we expect to be able to boot and reinstall via the network easily. Requiring cables and/or USB keys for restore are costly and complicate logistics greatly.

2) the school servers need to be "hard to break" as well as "easy to fix", and remotely manageable, as finding expertise a remote school of 10 children and one teacher is very unlikely. This is one of the factors driving us to IPv6 (much more below), since NATed IPv4 islands cannot be easily remotely diagnosed or updated automatically without expertise on the ground, which will often be rare in our deployment areas.

I've recently become impressed by technology developed for and by PlanetLab that Dave Reed brought to my attention. It is worth everyone's careful look. See (www.planet-lab.org).

Mesh networking: Pulling wires and having access points are very expensive and requires expertise, neither of which may be available; and we want kids to be able to work together anytime they meet up, even under a tree 3 kilometers from nowhere.

MIT Roofnet and other projects have shown the feasibility of mesh networking, where one machine forwards packets on behalf of others. Michail Bletsas is OLPC's expert in this area, and has a lot of first hand experience. In radio quiet areas, quite long links become feasible; in urban areas much shorter links are only feasible, but the density of machines is likely much higher.

Our system is interesting in a number of ways beyond mesh software:

  • it has antennae that can be rotated up above the top of the machine and are more efficient than what you find in a conventional laptop; this should roughly increase the footprint of each machine by a factor of four (in area).

  • the Marvell wireless chip we are using can operate autonomously. So it can forward packets in the mesh even if the processor is suspended to RAM! This should cut power consumption for an unused laptop to well under one watt (current estimate is about .5 watts), while still providing support to other machines in the mesh.

One of the challenges that the community can help later this year is to help learn which techniques work best when the nodes of the mesh are mobile machines. There are a number of routing protocols possible (some of which should become power aware; not all machines may need to bother to forward packets all the time), and which will work best in what circumstances should be fun to learn.

Application checkpointing: 128 megabytes of memory is enough to run (almost) any open source application; there are a few exceptions, but few that are of educational interest for young children. It isn't enough, on a system where paging needs to be avoided, to run arbitrary numbers of the larger applications at the same time.

In addition to the community working on dieting our environment (and making it run faster as a result), application check-pointing could help the user's experience greatly. When memory runs low, idle applications not currently in use could save their state and be restarted later at the same point. We see some of this being done in Maemo on the Nokia 770; the conventions for this need freedesktop codification and implementation in applications.

Pervasive IPv6: In the developed world, we do not have a shortage of IPv4 addresses at this time. We got to the Internet first, and grabbed enough "land" that we don't yet feel the pain felt in other parts of the world.

We see differently from where we sit. IPv6 to us is clearly essential on a number of grounds:

  1. address space, and not wanting a flag day conversion that would be very difficult. There are good arguments that we have effectively exhausted the IPv4 address space, and that even conservation measures cannot change the situation by more than a year or two. In the developing world the situation is already dire. In some places, entire universities are hidden behind a single routable IPv4 address, and in others, NAT's are as much as 5 levels deep.

    Vint Cerf told us that part of this problem is artificial: some cultures are so worried about losing face if they were turned down that they have not been asking for addresses, even though they would have been granted. And part of it is very real indeed: Brazil is planning a deployment of 100,000,000 IP TV sets, for example; this cannot be done using IPv4. And we hope to be deploying at such scale within a few years as well. Since the cliff is already visible and we'd just as soon not fall off it; it hurts so bad when you hit the bottom.

  2. it is impossible to diagnose problems if you can't observe them. Initially, in many parts of the world, we have to presume limited expertise is available on the ground, so local diagnosis could easily become the limiting factor for deployment. If the school networks are fragmented by NAT's, remote diagnosis becomes much more complicated.

  3. Building collaborative applications (or almost any new network application) has become extremely difficult due to the extensive deployment of NATs in the Internet: Skype is one of the few applications, that by standing on its head in many ways, has succeeded in (usually) working despite this disaster. Building such applications becomes radically easier if we go back to the end to end principles of the Internet. NAT has made it very difficult to deploy new applications.

Given tunneling technology (and 6to4, when routable addresses are available), in concert with the IPv6 deployment that has begun in many parts of the world, we can again have a clean end-to-end network, in which kids anywhere can share with their peers all over the world.

So our judgment is that he time has really come, and (almost) all applications are finally ready.

Localization problems: According to the Ethnologue web site, there are 347 languages with more than one million speakers in the world, that covers 94% of the world's population. We already see localization in open source systems for languages with fewer speakers - one million speakers. If we continue along the current path of localization, we're going to find ourselves with a real problem within several years.

While I expect the current mechanisms and processes might get us through the first round of deployments, the year after, this problem will become more acute. As a community, we need to recognize this approaching problem and rise to the challenge. I wrote in more detail in my blog.

Are you getting the needed level of assistance from the community in reaching these goals?

It has been hard for people to help on the base hardware support, though as the first few boards were distributed over the last month this has been changing: this is about to change in a big way with our developer's program.

We are distributing almost 500 bare mother boards to enable people to help on drivers, power management, code optimization (which not only makes things faster, but reduces power consumption), mesh network experimentation, etc. And there will be further opportunities later in the program during beta test later this year.

What do you most urgently need help with at this time?

Power management is one key problem. And it can be subtle and indirect: slow code, or bloated code, also wastes power.

The memory consumption problems, and how to manage low memory situations is also key. It would help greatly if applications would bother to be able to checkpoint their state and restart exactly where they left off.

Let's take one of those goals: paring down applications so that they fit into the OLPC's memory. This is clearly an activity which benefits everybody - bloated applications are slow applications. Are you making progress in putting the needed tools on a diet?

There are only a few things we are doing ourselves at this instant; the responsibility for these problems is distributed among a myriad of projects.

We have a simple principle everyone should be aware of: if your application is bloated, it's much less likely people will be able to use it on the machine. There are usually alternatives for any particular piece of software. Given the healthy competition in free software, there is only a much smaller subset of software that we care about to the point of fixing it ourselves. If you want your software to be usable, please make it so: and everyone will benefit with leaner, faster applications, not only OLPC.

How are the upstream communities responding to debloating patches?

In most areas, we're still pedal to the metal on basic problems like device drivers, and finishing up LinuxBIOS + Linux as boot loader so that we can support installation over the (mesh) network. Ron Minnich and Ollie Lo of LANL and the LinuxBIOS community are rising to the challenge.

Often, rather than patches, it is helping people understand there are problems that need to be fixed. Chris Blizzard, who is on the board of the Mozilla corporation, now works on OLPC (he's in charge of the Red Hat team), and the Firefox team are finally aware they have a serious problem and test cases are being generated. Chris says some progress has already been made. Much more is needed, and there are viable alternatives we could use if Firefox does not come through. But we think they probably will by the time we will ship in volume.

Many thanks to Jim Gettys for taking the time to answer these questions. The second part of the interview will appear next week.

Comments (27 posted)

LWN schedule for next week

The LWN staff has decided to take some time off for the U.S. Independence Day holiday on July 4. As a result in the weekly edition will be published late on July 6. We apologize for any inconvenience.

Comments (2 posted)

Page editor: Rebecca Sobol
Next page: Security>>


Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds