/joh'liks/ n.,adj. 386BSD
Understanding the boundary between research and development with BSD, and where a balance between commercial efforts can be struck.
Lynne Greer Jolitz
"The time has come," the Walrus said, "To talk of many things: Of shoes--and ships--and sealing wax-- Of cabbages--and kings--And why the sea is boiling hot-- And whether pigs have wings." --Lewis Carroll At this point in our article series, the basic toolset for 386BSD development is in place, and we're ready to begin the job of porting the kernel program. (Or to use the mountain-climbing analogy we've followed until now, we've completed the preliminaries and are ready to begin scaling the peak.) With this in mind, it's a good time to pause and consider where we've been and where we are going. We've discovered over the course of this series that there is considerable confusion and debate among researchers, programmers, businesses, and other interests over the nature and role played in the computer industry by Berkeley UNIX in general and by 386BSD in particular. This is not surprising, given the direction of operating systems in the commercial sector such as AT&T's System V, Release 4, Apple's System 7, IBM/Microsoft OS/2, and others. As such, it has become crucial to differentiate these two sectors, examine the differing motivations and goals, and discuss some of the trends that will eventually tie these two worlds together. The most important thing to remember about Berkeley UNIX is that it is and will remain a "research" project. This means it is not designed with the needs of the commercial sector in mind -- the University of California is not a development shop such as the SCOs of the world. BSD provides, in essence, the opportunity for operating systems, applications, networks, and other areas to evolve beyond the current requirements of the commercial sector to produce the technology required for next stage efforts. This is a demand of research -- to get on with new work and not simply stagnate. Commercial operating systems releases have a far different agenda, however. While much of it is self-serving (such as ABI, which we think should actually stand for "AT&T Binary Intolerance"), there is a method to the madness. Commercial releases are tied to the past. In fact, the tie is so strong that even when there is a critical need to offload some past burdens, a company finds it politically impossible to do so. We are reminded of Fred Brooks's classic work, The Mythical Man-Month (Addison-Wesley, 1975), and his discussion of the infamous (but popular) IBM OS/360 operating system. This operating system grew bigger and bigger and bigger in order to meet the perceived demands of their customers. And as it grew bigger, the number of bugs grew as well (though not at the same rate). As Brooks reflects on this project, he pinpoints a key issue (page 122 - 123): Lehman and Belady have studied the history of successive releases in a large operating system. They find that the total number of modules increases linearly with release number, but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. Furthermore, machines change, configurations change, and user requirements change, so the system is not in fact usable forever. A brand-new, from-the-ground-up redesign is necessary. In sum, it might have been simpler to abandon further work on this titanic system (400K of assembler code, a princely sum at the time) and go on to new operating systems. Because of its research agenda, Berkeley UNIX is less concerned with issues such as ABI. Applications interfaces are quite properly handled outside the kernel, usually with a library. Eventually, antiquated or nonstandard interfaces are brought up to speed with newer technology, and programmers use the library less and less, until finally most delete it from their world. Researchers cannot afford to work with bloated kernels, stuffed full of arcane and inappropriate software. Research operating systems must be lean, mean computing machines. So, while everyone longs for the latest innovation, the BSD Maserati, not everyone feels comfortable with the incredible power it provides -- not everyone is a race car driver any more than everyone is an operating systems programmer. BSD provides the mechanism for tremendous new opportunities, but it doesn't have a lot of safety nets. You can just as easily crash and burn with BSD, and have no one to blame but yourself. Commercial systems vendors offer customers a nice, big, memory-guzzling Oldsmobile of an operating system ("This is your father's operating system") with all the same features everyone has seen since childhood. And when in doubt, more is added in the kernel until everyone is satisfied. Because they do not want to increase support overhead, vendors try to prevent "crash and burn" occurrences by making it so safe that you are protected from yourself (and, by the way, if you do circumvent the controls, you can't blame them--they tried to save you). At least, this is the intent: Give the customers what they want (within reason and while maintaining control) and try to minimize support headaches. We said in January that "because standards by accumulation just don't work, we strive in 386BSD to avoid such nonsense." This was not an idle statement, but a cornerstone of our specification. We are not the first to observe the problems that arise when bloated kernels become a mainstay of either research or commercial offerings (as Fred Brooks discussed in his book). In several current commercial offerings, the complexity has become so great that the kernels have become difficult to maintain and impossible to orient toward the future. Customers lose what they so desperately desire in an expensive commercial release, namely bug-free software and timely support. This trade-off for flexible and innovative systems is beginning, like OS/360, to sink under its own weight. It's ironic that this would happen to UNIX, which was predicated on the essentially "minimalist" work of Thompson and Ritchie. This problem is not restricted to the commercial sector, however. In fact, one reason many are less than enamored with MACH is that its "microkernel" is roughly comparable in size to the 386BSD kernel -- and yet it requires much more memory to be useful. The final question now becomes, "What do I use now?" For the user dependent on a proprietary database or accounting software, the answer is quite simple -- just continue using what you have been using. Unless there is a compelling reason to invest in new technology, you just disrupt your business and your workers for no good reason. Eventually, some aspects of Berkeley UNIX will be integrated into commercial (and other research) releases, but don't anticipate it soon. For those who must look to the future, however, such as applications, networking, and operating systems designers, Berkeley UNIX will continue to be a source of the innovative new technology required for new products and new functionality in a competitive world economy. Businesses and programmers should keep themselves current with these research trends, for ready incorporation in the commercial market. By the way, sometimes it's nice to drive a Maserati. Open Standards - Are they really "Open"? The headlong rush towards "open standards," an oxymoron worthy of the military, is no solution either, but merely an effort to mask the implicit control, development, and innovation of a proprietary object by a vested interest by calling it "open." The only open standard is one that has an openly accessible model or example of the standard itself. Just as a mathematical formula in physics is meaningless without example problems and solutions, a standard based on a proprietary object is also meaningless without code solutions which justify its worthiness --and the code answer book to this open standard should not be subject to ransom through the use of "licensing" fees and anticompetitive product controls. Such a standard must also be equally accessible to those developing proprietary and nonproprietary works. This not only mitigates the inherent competitive disadvantage for the small innovator, but is also a disincentive to the development of proprietary "copycat" standards alongside the open standard, in an attempt to undermine its use. In similar fashion, the true goal of the GPL is "free software", not "open source". Any attempt to reserve rights is seen as a prelude to making it no longer free, or making a sham of its free aspect. Which explains the conflict between "open source" and "free software" - the fear of "open source", like "open standards", being subvertable. Ironically, anything can be subverted. The point of doing open source or free software is to retain attribution - you do it for the fame of having done it. What if someone wishes to erase even that? Then, they could attempt to make similar software, and not attribute the indirectly derived work, attempting the "sin of omission"? Many in the press have remarked on this as a historical injustice. Berkeley Copyright License Recently, the trend at many universities and research institutions has been to permit access to university-developed code through simple copyright procedures which permit modification and redistribution with attribution. The copyright used by TeleMuse, for example, is similar to the University of California at Berkeley (UCB) copyright and is designed to be simple and direct; see Figure 1. Figure 1: The copyright used by TeleMuse in the 386BSD article series
/* Copyright (c) date, name-of-author. All rights reserved. * Written by name-of-author, date-written. * Redistribution and use in source and binary forms are freely permitted * provided that the above copyright notice and attribution and date of work * and this paragraph are duplicated in all such forms. * THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ According to Marshall Kirk McKusick, UCB CSRG Research Computer scientist and president of USENIX; "We have the capitalists with their copyright and the radicals with their copyleft. We are at the 'copycenter,' since we allow redistribution with credit to the authors. Our goal is to have as many people as possible use our software." In January of 1991, CMU adopted a variant of the UCB copyright for the MACH operating system. Copyright vs. Copyleft This different approach to copyright does not attempt to regulate the development and distribution of code as does the copyleft. Instead, software is made available with the full knowledge that it will be incorporated into many different projects. These projects, in turn, will ultimately enhance the international competitiveness of the computer industry itself, by allowing individuals and small businesses the same access to these development tools as large corporations. After all, it is the individual and small business which are the sources of innovation in our society. Anything less (including the copyleft) results in a competitive advantage only for large companies with a vested interest in the status quo. The Free Software Foundation deserves high praise for leading the fight against locked-up software. Some GNU packages, such as GCC and EMACS, have been used by small firms and research groups to develop innovative and unique software and products, which would not otherwise have been feasible for these economically strapped entities. Even 386BSD might not have been possible had we not been able to leverage other resources like GCC. However, as the climate in which the copyleft was developed has moderated, we hope that the FSF will moderate its stand as well, and at the very least permit unfettered discussion and analysis of the code in print. We have every confidence that there will continue to be a flow of new software back to the source from companies, individuals and research groups. It is time vested interest started offering innovative and competitive works and stopped preventing innovation through the "anticompetitive" use of copylefts, open standards, and licensing. Those who maintain a competitive advantage through the inappropriate use of these methods, instead of through true innovation, have done so at the cost of the competitiveness of the entire domestic computer industry.
tags |
|