![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/main.png)
|
|
|
Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise
news for all interests
 Sections: Main page Security Kernel Distributions On the Desktop Development Commerce Linux in the news Announcements Linux History Letters All in one big page
Other LWN stuff:
Archives/search
Recent features: Here is the permanent site for this page. See also: last week's LWN.
|
Leading items and editorialsA challenge for the free software community. One frequently-heard criticism of free software is that it lacks innovation. According to this claim, the free software development process can do well at reimplementing others' good ideas, but is not able to produce those good ideas itself. Free software advocates dismiss that criticism with plenty of counterexamples. But it still hurts a bit sometimes. There is currently an opportunity, however, for the community to show what it can do. A challenge which should be accepted if we want to remain in control of our computing future. That challenge, of course, is Microsoft's ".NET" initiative, and the HailStorm component in particular. HailStorm is Microsoft's bid to be the intermediary in authentication and business transactions across the net. If the company has its way, everybody will have a Microsoft "Passport," which will be required to be visible on the net. The protocols behind this system will be "open" (based on standards like XML and SOAP), but Microsoft will hold the copyrights and decide what is acceptable. It is interesting to note that these protocols have been explicitly designed to be independent of little details like which operating system you're running. Microsoft is saying, essentially, that, at this level of play, who owns the desktop is no longer important. Linux could yet conquer the desktop, but lose the net. Scattered responses have been seen across the community, including .NET implementations, talk of a free C# compiler, or a "dotGNU" framework. But these are catching-up actions. There is little new there; it is more an effort to keep up with what Microsoft is doing. That approach should be seen as a serious mistake. It is time for the free software community to take the lead. Doing so will require the presentation of an alternative proposal. What is needed is a compelling vision of how we will deal with each other on the net of the future. The community needs to design a framework which handles tasks like authentication and transactions, but which meets a number of goals that may not be high on Microsoft's agenda:
The success of the Internet is due to a great many things, but one aspect, in particular, was crucial: nobody's permission is required to place a new service or protocol in service on the net. Where would we be now if Tim Berners-Lee had been required to clear the World-Wide Web through a Microsoft-controlled standards process - and let Microsoft copyright the protocols too? Any vision of the net of the future must include the same openness to be acceptable. The free software community could generate that vision, but it is going to have to set itself to the task in a hurry. It is also, for better or for worse, going to need some serious corporate involvement. Companies are needed to help fund the development of a new set of network standards, make sure they meet corporate needs, and, frankly, to insure that it is all taken seriously. There should be no shortage of companies with an interest in a net that is nobody's proprietary platform. It is time for them to step up and help with the creation of a better alternative. The community needs to act here. Playing a catch-up role in the design of the net of the future is no way to assure freedom, or even a whole lot of fun. Large-scale architectural design is hard to do in the free development mode, but we need to figure out how to do it well. Either that, or accept the criticism that we can't really innovate. The Linux Standard Base, version 1.0, is out. The release happened with surprisingly little fanfare (none, actually) on June 29. We have since gotten an announcement of sorts from the Free Standards Group's Scott McNeil, but the group was clearly more focused on the work itself than publicity. This is, regardless, an important moment. The Linux Standard Base project was conceived in early 1998, with the proposal and call for participation coming out of a Linux Expo BOF at the end of May. Some of the conceptual roots, however, had some out a little earlier when Bruce Perens proposed a new Linux distribution which shared a number of goals with the LSB - in particular, an open, non-commercial reference implementation of the system known as Linux. The LSB was endorsed at the May 30, 1998 Linux International meeting. Its goals included: Rather than require uniformity among distributions, it will define only what is required to boot a system and run an application. The goal will be to build a reference platform quickly, within a two month time-frame, that will be open-source and available to the community. After that, work will begin on a paper standard, estimated to take approximately two years.
Those were optimistic times, of course; in reality, things didn't happen so quickly. Under Bruce Perens' leadership the project got off to a bit of a rocky start, with some serious differences of opinion over priorities - not everybody agreed with Bruce's desire to start with a reference implementation. Bruce's tenure as the leader of the LSB was relatively short, but the project seemed to languish for much longer. It is only in the last year that it appears to have gotten serious and finished out the task. Appearances do not tell the entire story, however. The LSB is a complicated specification, and much of the necessary background work was not immediately visible to outsiders. Other parts of the LSB, such as the Filesystem Hierarchy Standard (FHS), have been available for a long time and have already influenced the development of most distributions. The LSB may have taken longer than desired, unlike most other software projects, but the delays do not indicate a lack of effort or interest. The real purpose of the LSB was, and is, this: to allow the packaging of an application such that it would be installable on any compliant distribution. The vast number of Linux distributions is a great wealth for the user community, but it does present challenges for application vendors. The LSB should make it possible for vendors to support all compliant distributions with a single package. Application vendors like that sort of thing. To achieve this goal, the LSB describes many facilities which must be provided by compliant systems. These include specific library versions and commands, as well as filesystem layouts. In places, it has been necessary to work around entrenched differences between distributions. Thus, for example, there is no defined location for system initialization scripts; instead, a command install_initd which will put a script in the right place must be available. The LSB also envisions a larger role for the Linux Assigned Names and Numbers Authority (LANANA); until now, LANANA has essentially been H. Peter Anvin's work maintaining the device number list. The makeup and governance of LANANA is not clearly laid out. If it is going to take on other tasks (such as registering names of init scripts), its operation should probably be clarified before it has to take on a contentious decision. The key to the success of the LSB, of course, is the degree to which the distributors move their products into compliance. The signs here are good; much of the effort behind the LSB has been put in by the distributors in the first place. Most distributions are not all that far away from compliance, mainly thanks to the longer-term effect of the FHS. LSB-compliant distributions should be available in the near future. There has been a bit of grumbling from some Debian developers, mostly over the fact that the LSB specifies the RPM package format as the standard for application distribution. Debian, of course, does not use RPM. Complaints, however, are both late and unfounded. The decision to go with RPM was made back at the beginning, over three years ago. It does not require compliant systems to use RPM as their native package format; it is sufficient that RPM-packaged, LSB-compliant applications be installable. And, in this context, "RPM" does not mean the moving target that is Red Hat's current format; it is, instead, specified as a subset of the older, version 3 format as documented in Maximum RPM. The Debian alien tool should be more than up to the task. The full, formal rollout will happen at LinuxWorld this August. Between now and then, the LSB crew will be working to get the test suite and sample implementation in shape. No doubt there will be press conferences and photo opportunities as the commercial Linux world shows its unity behind this important standard. But the standard itself is available now. Strong congratulations are in order for all who have worked on the LSB for the last three years. This LWN.net weekly edition is one day early and, perhaps, a bit thin in spots due to the July 4 holiday in the U.S. and staff vacations. We'll be back to our regular publishing schedule next week. Inside this LWN.net weekly edition:
This Week's LWN was brought to you by:
|
July 4, 2001
|
Copyright © 2001
Eklektix, Inc., all rights reserved
Next: Security