Fwd: LSB, LFS, and DBs

Gerard Beekmans gerard at linuxfromscratch.org
Tue Jun 13 09:37:10 PDT 2000

Before the alfs-discuss list was opened, preliminary discussions were
started on the lfs-admin list based on this email by Mark Stone. I'm not 
forwarding the replies from us. We all agree with his proposal and in a
nutshell our reply to this is: Let's make it happen

What Mark proposes below will be either implemented in the installation
tool under the ALFS project, or based on it but developed under a
different project. Please don't reply to this email on the lfs-discuss
list. Instead subscribe yourself to the alfs-discuss list and send your
replies to that list. So please make sure when you hit reply you change
the To: header.

----- Forwarded message from Mark Stone <mstone at valinux.com> -----

This week VA Linux Systems is sponsoring a meeting of the Linux Standard
Base committee, the most extensive working meeting that this group has had
so far. We're really hoping to breathe some new life into the LSB and hope
that it will accelerate its pace of activity in coming months. One action
we've supported is the establishment of the LSB as an official nonprofit
organization, so that it can receive funding and have paid staff.

We at VA feel a sense of urgency about all of this primarily because of
pressure on the Linux community from the big database companies, notably
Oracle, Informix, and IBM. Here's the tension:

What DB vendors want: they want a stable Linux as a target platform, a
Linux that changes rarely, and then only in response to some perceived
need of database vendors. At this point Linux should change instantly in a
way that they deem DB-appropriate. But above all, versions of the target
platform operating system should change *LESS* frequently than database
versions change. A reasonable time frame for version changes would be 12
to 18 months.

How the Linux world works: Red Hat's revenue depends on people needing or
desiring a new version of Red Hat frequently. Red Hat must also put out
new versions quickly because revenues from each version quickly get eaten
away by Red Hat clone vendors like CheapBytes and Walnut Creek CDROM. The
revision rate often exceeds the life cycle of proper engineering due
diligence, but Red Hat's bottom line demands that revision take precedence
over engineering. A typical time frame for version changes is every 6 to 9

Clearly there is a disconnect here, and one that hurts the Linux
community. Solaris and Windows 2000 will be perceived by companies
like Oracle as more desirable DB platforms until Linux stops presenting a
moving target. And if we can't demonstrate that Linux has the full support
of enterprise class database companies, then we in the Linux community

And indeed this is a symptom of a larger problem. The rest of the software
world is accustomed to operating system vendors who work more closely in
concert with application vendors. Elsewhere, needs of the application
vendors drive innovation in operating systems. In open source, innovation
in operating systems drives opportunity in application development. The
open source model is a fine model for building new applications, but
drives existing application vendors crazy.

The Linux Standard Base is an opportunity to solve the problem. It
provides a specification for a Linux common denominator, one that will
change slowly, and one that DB companies and other application vendors can
target and standardize on. The LSB also provides a standards body in which
vendors can participate, engage the open source community in discussion,
and have some input into future changes and future directions.

But the LSB itself does not provide a Linux system or Linux distribution.
That part of the equation still needs to be solved before application
vendors will be satisfied. Red Hat and other distribution vendors of
course could, and should do LSB-compliant releases. But we have no
assurance that they will. We also don't know that we want "standardized"
Linux to be in the hands of a particular vendor.

One alternative would be to work with Debian. Debian is a distribution,
but one without a commercial interest, so it is "vendor neutral". Debian
is an important option, and one VA has strongly supported: we've built a
Debian CD for retail distribution, and we employ two engineers full time
just to work on Debian. But Debian has its limitations. After all, if one
of the goals of standard Linux is to work closely and cooperatively with a
company like Oracle on providing a Linux that Oracle likes... well,
philosophically this just isn't a role that Debian is well suited for.
Mixing Oracle and Debian is a bit like mixing oil and vineager.

So the problem remains: where can we find an instantiation of the LSB
standards so that we can have a working, standards-compliant Linux to hand
to application vendors? 

Implicit in this dilemma is the problem of documentation. Even if Red Hat
were to put out an LSB-compliant Red Hat that they would maintain and
distribute for up to 18 months per revision, would it really help?
Application developers at a company like Oracle would still be handicapped
unless they know only that the Linux they were given was LSB-compliant,
but *why* and *how* it was LSB-compliant. That's a substantial
documentation problem that Red Hat has neither the time nor expertise to

I think you can see where I'm going with all of this. I firmly believe
that Linux from Scratch should continue as an autonomous and extremely
cool open source project. But I think there's an opportunity to spin off
from LFS an instantiation of the LSB that could be a working, documented,
vendor-neutral, standards-compliant Linux.

LFS isn't the only way one could go about this, but it is one way that
might be very successful. And -- no promises here -- it might be
successful in a way that would create funding, either through the LSB or
some other entity, for continued work on LFS.

I'm very curious what you all think of this. As the LSB meetings wrap up
this week, and as Gerard nears the point where he will require gainful
employment, there are decisions to be made, decisions that will impact the
future of the LSB and LFS. I have an approach I'd prefer, but before I go
advocating a particular approach to anyone, I'd like to have your


 Mark Stone                                         VA Linux Systems
 mstone at valinux.com                        Publisher, VA Media Group
 (408)542-5745          Editor-in-Chief, Journal of Linux Technology

Unsubscribe: email lfs-admin-request at linuxfromscratch.org and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject required)

----- End forwarded message -----

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Mail archive: http://www.pcrdallas.com/mail-archives/lfs-discuss
IRC access: server: irc.linuxfromscratch.org port: 6667 channel: #LFS
News Reader access: news.pcrdallas.com
Unsubscribe: email lfs-discuss-request at linuxfromscratch.org and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the lfs-dev mailing list