Hello folks! Well, you know about opinions... everybody's got one so... here's mine.
LSB is a good idea. LSB is expanding in scope at an alarming rate and is trying to do too much! I'm a veteran of quite a few software design projects in which I was the head analyst and I'm a big advocate of defining the scope of the project. I follow a system's development life cycle that works well for me. My methodology goes something like this: First, you define exactly what the problem is. Then, you analyse what is available at the time to solve the problem. Next, you brainstorm ideas to better solve the problem. Next, you reevaluate your scope to see if you are getting outside it. Next, you simplify your best ideas from the brainstorming session. Next, you implement some of the simplified solutions. Next, you choose the idea/s that meet all the criteria for the solution and are the most efficient etc... Next, you reevaluate the scope of the project *again* to make sure you are still in scope... if the scope is too large, you pare it back no matter how painful that may be. Getting out of scope is easy and can effectively kill a project dead. Personally, I think the scope of LSB, as it stands today, is too large; it will be way into the year 2005 before the specification is done and by that time... it will be obsolete and unneccessary! We need a *basic* specification now that addresses the most potent problems. Hey, the FHS is a great idea! It is the very important first step of LSB but we must go farther... but not too far. My preliminary analysis of the situation is as follows: Problems: Linux has no standard component location organization. Such a situation makes it difficult for 3rd party software vendors to make installation scripts and know where to put program components. Hey! We've got FHS so this is mostly done. Linux has many different versions of libc. Such a situation makes it difficut for 3rd party software vendors to provide software that works on the majority of the distributions AND makes it hard on users because installations frequently fail - causing frustration. This is a MAJOR PROBLEM. Linux has no stadardized program installation method. This is a minor problem but one, that if addressed in a competant manner, will make it easier for users and ISVs alike. Linux has no standard GUI. <duck> I know this is a touchy subject but... it must be addressed. We should not make requirements but only recommendations. Recommendations like: Linux should have some sort of GUI/Desktop, the desktop should have a root menu that includes minimum functionality like a run function, configuration menu, information menu, program menu, shutdown menu. Most WindowManagers already have these functions or some version therof. All other things could go undefined or unspecified. This way, the user would at least be able to go from one WindowManager to another and be able to use the root menu at the very least. My ideas of what the scope of LSB should be and possible solutions to the problems: Maximize the compatability with other standards. Require POSIX, UNIX98?, SUS compatability. Most of the standardization work is already done for us. Provide for a minimum set of functionality. Define that certain interfaces are required. Runtime libraries such as libc, libc++, PERL, TCL are not too much to ask. User tools like a standard text editor (even if a new one must be written) and included as standard fare, linuxconf, isapnptools, a standardized init script format or mutually agreed to addendum script. Standard locations for libraries, programs (I agree with Robert Current when it comes to OS and Userspace tools and library locations) and source code; such standardization and forethought will make for a more robust OS. Provide for an example install mechanism. A simple ncurses example install script would make things standard at least AND leave the door open for 3rd party ISVs like InstallShield to make graphical and advanced interfaces. Provide for interface contracts. Choose a version of libc and stick with it for a particular LSB version. Have all new versions be backward compatible with the previous version so that programs compiled within a major library version number would work without recompile on any subsequent minor revision of the same major version. i.e.: If program was compiled under glibc2.0 then it would still run unmodified on glibc2.2.3. If the glibc must be radically changed, then change the major number and keep it as a development version (otherwise, limit to a particular revision of glibc). I want to say that *I* enjoy the rapid advancement of LINUX. I want it to continue! However, we must have a subset of LINUX that is stable and unchanging for the masses. I want to live in a world where I can go to work and see UNIX on my desktop - a simplifed and productive world. Codifex Maximus
