Robert W. Current Jr. Ph.D. <[EMAIL PROTECTED]> writes: > Again, I say, X is not an essential part of Linux. That in itself > is the enough reason to say it should not be part of "a standard > base."
A lot of stuff is not essential to run Linux. That doesn't mean that common applications won't need those things. The goal of the LSB is to guarantee that third-party applications can run on any LSB-compliant Linux distribution. Since a large number of third-party applications use X libraries, they need to be included. We are continuing to survey applications to see what facilities are being used, how often, and which could be practically excluded. X is not one of them. The alternatives to putting X in LSB 1.0 are to put X in an optional layer or to have applications ship with X libraries. Both alternatives were rejected by the distributions, software vendors, and developers who have participated. The people who will implement the LSB don't want to have to worry about layers of the LSB. It's enough that we'll have to worry about future versions of the LSB (which will only add features, not remove them). This does not prevent people from shipping software without X. You don't have to use every feature in the LSB to have an LSB-compliant application. This does not mean you have to configure X on any machines, it does not mean you have to include any X servers, applications, documentation, or fonts. We're talking about the core X libraries. Calling the inclusion of X "big and bloated" or talking about whether or not a server is configured to include X is disingenuous. Also, including X in the specification does not add much work to the spec. Stuart has already pointed this out. In addition, we are not targetting ultra-small embedded systems or special cases. We are targetting the common cases: servers, desktops, workstations, etc. (However, even small devices like thin clients and notebooks still include X.) > Again, this will have to be carefully addressed from the point of > vocabulary, because "Level 2 compliance" will only be part of a > moving target spec, that will likely also need to include "versions" > as libs and kernels update. The kernel is not defined by the LSB. The goal is to have all of the functionality used by LSB applications is presented through glibc or another library, an application, etc. That way, changes can happen in the kernel without affecting LSB applications. Another goal is to have LSB applications continue to run 5 or 10 years from now. That can't happen if the specification is a moving target. Yes, there will be an LSB 2.0 and it will include more than LSB 1.0 did and LSB 2.0 applications won't run on LSB 1.0 systems, but LSB 1.0 applications *will* run on LSB 2.0 systems. Philip Rackus <[EMAIL PROTECTED]> writes: > If everyone agrees that eventually the goal of the LSB is to define > different level of standards, how much extra time would it take to define a > base spec (without X) called ..say LSB 1.0, and the spec including X called > LSB 1.1 ? In this scenario 1.0 would basically be a subset of the 1.1 - so > a distribution that is 1.1 certified would by default be 1.0 certified as > well. I think it's fair to say that it would talk us longer to finish if we took that approach. One final note: after we're done the LSB, we *could* issue a "micro-LSB" standard which could drop X windows. It's not a very high priority for any software vendors or distributios, though. Dan
