Alan Cox wrote: > > > No question that POSIX.4 is heap of stinking shit. The problem is that > > it's a *standardized* heap of stinking shit, and application writers > > want to be able to cleanly port their programs from other Unices to > > Linux. > > No argument. And thats why we should support it, and yes the libraries will > have to do a chunk of gunge work to emulate the flaws in it.
Stop. Is our goal in creating the LSB spec to determine the future direction of Linux? I realize that what we currently have isn't very clean, elegant or optimal. But should we be dealing with such design issues at this point in time for every item in the spec? Wouldn't that be better handled in the linux-kernel mailing list or some other forum that deals with the particular component in question? It seems that we lack a well-defined selection criteria for what should and shouldn't be in the spec as well what issues should and shouldn't be dealt with. There are several goals that may be in conflict as well, and we should prioritize them in order to create our selection criteria and meet our goal of releasing the spec in a timely manner (eg, for the LinuxExpo in February). According to the LSB web site (http://www.linuxbase.org), our mission statement reads: "The goal of the Linux Standard Base (LSB) is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant Linux system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.". In reviewing the mission statement, I enumerated and am hereby presenting a small list of goals I perceive being sought by the LSB, their rationale, and the means of testing whether we are meeting that goal or not (please edit and add additional goals as you see fit). I reserved comments on the merits of these goals until later, but here are the ones I noted: 1. Select the components/features/API of a model Linux system so application developers know what the target system will include, what the behavior will be, and how to package it so that it can be installed, executed, and removed from the system. Rationale: A single Linux model allows an ISV to know in advance how a conforming linux system will behave to (a) minimize issues in porting code from another platform, and (b) allow a package to perform the same way regardless of the linux distribution. Test Criteria: Are proposed components/features/API being selected? Are proposed components/features/API being rejected? 2. Develop the documentation for the components/features/API of the LSB as well as their respective behaviors. Rationale: The LSB spec must be presented to distribution implementors and ISVs in a format other than source code. Test Criteria: Is each component/feature/API documented clearly, completely and accurately? 3. Advance the state of the art in Linux by incorporating desired components/features/APIs into the LSB spec. Rationale: The world is a moving target, and we have competitors outside the Linux arena. To provide a compelling reason for the adoption of Linux we should take advantage of new ideas and technologies as well as target new markets and industries. Test Criteria: Is there a component/feature/API which would provide a clear improvement over the existing Linux environment? 4. Advance the development of applicatons for Linux by providing improved compatability with existing standards or platforms. Rationale: By providing ISVs with an execution environment which is compatible with an existing standard or platform we garner a greater number of applications or software solutions, providing users with greater incentive to adopt Linux and abandon their current platform. Test Criteria: Are there existing standards or platforms and does the model Linux system match their behavior? Given these goals, and please add/modify goals as needed, I'd like to suggest the following draft for the selection criteria for determining what should be included into the LSB spec, in decreasing order of importance: 1. Whatever currently exists in the Linux world in source code form and is redistributable via a GPL-like or BSD-like license. 2. Whatever is currently being actively developed in the Linux world which will conform to another existing standard and be available in source code form within six to twelve months after the finalization of the LSB spec and is redistributable via a GPL-like or BSD-like license. 3. Whatever is currently being actively developed in the Linux world which will advance the state of the art and be available in source code form within six to twelve months after the finalization of the LSB spec and is redistributable via a GPL-like or BSD-like license. My reasonings for the selection criteria and my views on the goals are as follows: 1. We need to develop a single model Linux system. One that can be adopted by the various distributions with little difficulty. This is the single greatest goal that we must achieve. Anything which interferes with this goal should automatically be eliminated. 2. We have to work with what we have. While we may have the skills necessary to develop the code to fulfill whatever wish list and whiz-bang feature we might desire, we most certainly will not have the extra time needed to do it in a timely manner after finalizing the spec. Therefore we should restrict the list of components/features/APIs considered for inclusion in the LSB spec to whatever we currently have. 3. We are not required to conform to any standard except our own. This includes the POSIX stuff. Yes, it would be nice to meet any or all other standards, but it isn't possible for LSB 1.0 to meet it at this time and there's no sense in pretending that it will. ISVs are more concerned with having multiple Linux distributions and the lack of a well-defined standard than in the existence of yet-another *NIX-like platform for which to target. We are not the standards body for POSIX. There is already a group for that. We are the __Linux__ Standards Base Organization. We are not a rubber-stamp for anyone else. If we meet POSIX, terrific. If not, let's just accept it for now. Hopefully the maintainers of the appropriate Linux portion will target POSIX in the future. 4. There's a lot of cool stuff that can be done to Linux. Let's leave it to be done. Let's not dictate that now. We can't tell how Linux will evolve over the next five years. Our job is to make a single Linux model for ISVs to target NOW, not worry about how the new jaw-enabled joystick will be supported. I came up with several really cool and excellent ideas at the NY meeting that got shot down by the group for a very good reason: THERE'S NO IMPLEMENTATION! No one else can see for themselves how it would work out! If someone believes in their idea, they'll implement it and let it face the scrutiny of the rest of the community. The bazaar development model allows several similar projects to develop simultaneously, competing for resources, ideas, attention, etc. based on their merits. Some make it. Some don't. Let some dreamer show us the possibilities. When he does we can either say, "Cool! We want that to be standard.", or "Yawn...Next!" 5. We need to eliminate from the spec prospects those items that are inferior to those of a like nature, or group their functions into a minimum requirements spec for its package. For example, there are multiple formats for distributing packages, multiple X window managers, multiple shells, etc. While it isn't always beneficial to lock users into a single system (eg, KDE vs. GNOME, or bash vs. csh), we should specify the minimum requirements and capabilities of such a system so that the interfaces and behavior are well-defined. > > Independent Software Vendors, so sorry, unlike every other Unix system > > on the planet, you have to use clone() and not the standardized POSIX > > interfaces. Now go away and stop bothering us? The problem is, they > > may do exactly that. > > We need to standardise clone(). We don't need to standardise on clone() but > not posix.4. Standardising clone "temporarily" as the IBM guy suggests is > not sane. Clone is a real working API. If you want to use clone its there > it works. If you want to use pthreads then clone is a piece of specification > you don't care about. Removing it in future is the error. > > > Do we say that we "almost but not quite" implement POSIX.4, and then > > list all of the ways that we don't quite match the spec? That won't > > make us a lot of friends in the application developer world (who will > > ask why can't we support all of POSIX.4), but it's at least honest. Returning to this topic, let me say that given the current state of affairs WRT to threads in Linux, we should standardize on clone(). If in the future we have something better we can adopt it then and render clone() obsolete. But for now, there is nothing as clearly defined. And given that pthreads doesn't conform to POSIX.4 we should keep it out of the spec lest we confuse those developers who would try to use it and then have to discover by trial and error all the little anomalies between Linux pthreads and POSIX.4 pthreads. It's better from a psychological standpoint to have a completely different interface rather than one almost alike. Ciao! Al Guerra
