As you might have noticed recently, several large companies have begun to take an interest in Linux. The Hewlett-Packard Company is one of these, the first official involvement being their announcement of Linux support for a line of PC Servers, announced in late January. Shortly thereafter, though not as a direct consequence, a group within H-P sponsored what they called "Linux Day at H-P Labs" which was held on February 9th of this year.
Interested people gathered from all over the corporation to the H-P Labs buildings in Palo Alto to hear from Bob Young, of Red Hat, and from Linus Torvalds himself. Jean Bozman from IDC also spoke, detailing the tremendous growth that Linux is experiencing.
The large conference room that was built for groups of 160 people failed to hold a standing-room-only crowd that spilled out into the hallway, so an overflow room had to be used, besides. Additionally, teleconferencing was used to bring the program to people who couldn't travel to the conference in person.
I was very interested in what Linus and Bob said and thought that I would pass along what I heard. Their comments were informative and filled in the history of how Linux came to be in its current position.
When Linus got the idea in 1991 to write what has become Linux, he had six month's experience with Unix. He liked it much more than other OSs, but there was a slight problem. Actually several hundred to over a thousand problems, those being the dollars it would cost to buy a commercial Unix he could use at home. At that time, all Unicies were priced for large institutions, not for individuals--especially not poor students. As a portion of the hardware cost, buying Unix for a PC doubled, at least, the cost of the platform. Linus began working on his OS to provide himself and others with a low-cost (free) Unix-like OS for personal use. After the initial release, interest snowballed and the number of contributors increased. As Linus put it, a lot of people put in a lot of work and he gets all the credit.
The people who contribute to Linux are motivated by personal satisfaction, not money. Many people do their best work for personal satisfaction. In a commercial setting, where the programmer is being paid to develop, his manager might not allow him to refine, count cycles, etc., like he can do on his own time. In many cases, it would not be viewed as cost effective to allow engineers that sort of time. Whether it's for personal satisfaction, a desire to impress others, or competition among kernel developers, a lot of craftsmanship goes into much of the code.
Linux benefits from a development staff so large that no company could afford it. And much of the work is so meticulous that, in a commercial setting, the cost would be too high to recapture the programmers' salaries. The absence of monetary concerns has created a product that is better than any company could afford to produce. The result of Linux being free is that it has good technology due to collaboration, and it is good for individuals to use and learn on.
Despite his desire for free software, he does not believe Open Source Software (OSS) should be the only way to license software. In his opinion, OSS is good for "black and white" technical issues or infrastructure.
It took two-and-a-half years between versions 2.0.0 and 2.2.0 of the kernel, but still there are criticisms that Linux releases too often, because of the 36 sub-releases of 2.0. Linus said that since the kernel developers mostly compile the kernel, other things that break get found by non-kernel developers. Releasing often allows these things to be found early. Within the first two weeks of the 2.2 release, there are already two patches. He went on to say that if what you have is working for you and there is no obvious reason to upgrade kernels, then don't.
Linus' wish list for future kernels:
1. parallel processing improvements (this seems to be a favorite topic for him. One of the major improvements from 2.0 to 2.2 is in the SMP capabilities),
2. a journaled file system [not because he thinks it is good, but there have been many requests], and
3. improvements for clustering (again parallelism).
In response to a question about porting Linux to PA-RISC, he said that a partial port has been done and appears to work, but there is not a lot of demand from end users. (It was unclear to me whether he was referring to the MkLinux port reported in Linux Journal #44 (see http://linuxgazette.net/issue44/2355.html), or some other work.)
When asked about types of programs for which kernel optimizations are considered, he mentioned that web applications (which spend 90% of their time in kernel-land), benefit far more than compilers, for example, which spend very little time in the kernel.
When asked what H-P could do to help Linux: "H-P can release specs." and "...stay away from legal problems with employees releasing under the GPL [on their own]."
Quotes from this talk:
"Operating systems shouldn't be as exciting as they [currently] are."
"2.2 doesn't do everything. It does everything you'd want to do."
"Set up a skunk works to develop a journaling file system within H-P. I dare you."
Talking about the increasing complexity of kernel code management: "[the] system is so complete that it is harder to add new features."
And, about how some companies deal with the GPL: "...more lawyers than engineers...a dark and awful place."
To make sure we remembered who he was, Bob Young set his red hat on the lectern at the beginning of his talk. He was also wearing red socks. Red must have become his favorite color. He had no slides saying that he saved such multimedia presentations for non-technicals�-like venture capitalists. Red Hat currently consists of about 100 engineers and marketing people in the hills of North Carolina where, according to Bob, salaries are low.
Bob made an analogy where he compared a "car" to a brand of car, and Linux to a brand of Linux, Red Hat. He considers Linux to consist of the kernel (the engine) and all the other programs, shells, and utilities that make it useful. He said that, although you could build your own car, we "usually" rely on a car maker to put all the parts together for us. So, in this way, we "usually" rely on Red Hat, Caldera, Debian, SUSe, etc. to assemble a useful distribution of Linux.
Bob's background was in leasing computers to large companies. In those days, once a company bought into a computer vendor's product, they were pretty much stuck with them, because one vendor's machines didn't work with any other's. He noticed that these companies didn't like that their second computers would cost much more than their first ones. This amounted to a loss of control in that the companies, once they had decided on a particular vendor's systems, were more or less stuck with them, unless they wanted to spend a lot of money and effort switching over completely to another vendor. The PC answered this loss of control by allowing companies to pick and choose PC components that all interoperated, mostly. Linux does for computer software what PCs did for hardware. Linux was intended to be Unix-like, differentiated by its licensing scheme. It has given control to the user that is not available from commercial OS vendors, including non-Unix flavors.
Red Hat started with FreeBSD (other free OS) while Caldera was pushing Linux. Bob wondered why Linux was getting to be so popular. When he found out why, he was waiting for some alternative hardware company like Next or Be to pick up on Linux. They didn't, so he did.
Bob said that Linux benefitted from Linus' relative isolation in Finland. If there had been a group of locals form as the main contributors, then any distant help over the internet would be more likely to be shut out, because the remote person wouldn't be there to discuss and defend ideas. With everyone having to work over the internet because of the distance, all ideas had equal chance. Having developed a way to work over the internet also encouraged a broader cooperative base.
He also explained that there are two types of programmers: those that write company-internal applications, and those that write commercial software; the latter are more likely to be Linux contributors, because of their mindset toward the end product, i.e., users versus sellers. He used an example to explain why cooperatively developed software is more likely to be better software than commercial software. Imagine a radio astronomer has an idea for software to help point his radio dish. He could develop it in isolation, then try to market it to the "three other" radio astronomers that might be interested in it. He would also be the only one to support it and fix any bugs found in it by the customer-users. The other way he could do it is to involve the others from the start in the development of the software. Bob's argument is that the software that would result from this collaborative effort would be better than what the commercial model would produce. Also, any bugs could be fixed by more people, and thus would be fixed faster. Bob calls this arrangement a "meritocracy". Linux benefits from being a meritocracy because the contributors do their work for the benefit of the code they themselves want to use. They also get credit among the development community.
Periodically, the Unix community undergoes unification, but between these times you see mostly division due to proprietary development from each of the vendors. When asked about the other Linux distributors, and the danger of the same divisions happening among them, Bob pointed out the expense of code forking. If one of the vendors forks the code, they then become the only ones who can maintain the code, which he believes would be very expensive. He estimates that code maintenance represents about 90% of the cost for a traditional commercial software vendor. Red Hat wants their developments to be adopted by Linus. In this way, Bob views all of the Linux distributors as partners.
Red Hat doesn't want to be in the shrink-wrap distribution business. They would rather make their money from support. Bob pointed out, though, that the harder they try to get out of that business, the more shrink-wrap they sell. Now they are quite a large software manufacturer.
Quotes from the talk:
"DOS is not an operating system; it is a bad collection of device drivers."
Question from the audience: "Is the browser part of the operating system?"--big laughs
In the afternoon session, a dozen presenters from within H-P spoke about Linux in their current projects or products. This is all pretty new stuff so I am not allowed to write about it in detail. However, I can give some general information about the areas in which Linux is finding place. This covers the spectrum from internal use only, to embedded Linux in full commercial products.
In the area of EDA (Electronic Design Automation) software H-P obtains some tools from EDA vendors, while other tools are written internally. One participant spoke about several internal EDA tools that had been ported to Linux.
Another story of porting internally written software to Linux was from a division that produces a commercial IC tester. Wanting to take advantage of the Intel platform, they had to decide between Linux and NT and found that the Linux port was much simpler and less expensive. Also, by purchasing a handful of proprietary libraries, they were able to make the user interface on the new platform appear the same as on the old.
Another couple of speakers shared their groups' use of embedded Linux in the rapid prototyping of products; one in the area of networked peripheral control, and the other in the area of telecommunications measurement.
There were also some strictly software products that have been or will soon be ported to Linux for general availability, including OpenMail, H-P Web JetAdmin, and Firehunter ISP management software (see http://www.hp.com for more information).
Finally, there is a group at H-P Labs porting Linux to IA-64. They demonstrated an emulator that can run the 64-bit code on a P133. A talk and paper will be given at Linux Expo in May.
One of the most important things I learned by attending Linux Day is that there is a lot of interest in Linux within H-P.