My ideas on LSB
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
Reply to: