On 16 Mar 2000, Daniel Quinlan wrote: > 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.
This is a major stance your taking, and I think you may regret it. By saying the LSB is in place to service only ISVs and the like, the LSB will essentially be seen by the Linux community as "A orginization trying to impose standards so that commercial software vendors can exploit Linux. The LSB has no basis in defining standards for Linux, but rather is an orginization that serves as mediator between the Big 3 Distributions and commercial software vendors." I am not trying to flame here. And I am definately not going to tell you where to guide the LSB if it's already been decided that only ISVs with deep pockets and Linux distributions with the highest sales figures will be calling the shots. Setting the LSB up as anything other than a basic standards orginization for the Linux community itself will cause a huge fallout in support. No one wants to see the standards revolve around only the parties who are making money off them (even if it is completely indirectly). So... I don't know, that's just plain scary to me. > 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. Well, that's something I can accept in consept, that it's just some core libraries. But, it sort of makes the point meaningless, doesn't it? Require X libraries, but not any form of X itself? > Also, including X in the specification does not add much work to the > spec. Stuart has already pointed this out. I never have argued the work that has been done. I feel it's been done fairly well. But, how far down the road are you looking at this project? By not seperating things into managable hunks, if one of the few people who know the inside scoop drops out, there will be almost no one in the community able or willing to step up and take on the job. > In addition, we are not targetting ultra-small embedded systems or > special cases. Yes, you are targeting "special cases." Specifically, commercial ISVs and the biggest of the big Linux distributions. You just made that point yourself. > 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. I totally agree with this. Although I know my last letter was written in haste, I understand that it's the "functionality" that the LSB defines, not the actual kernel version number, nor any app version number. This is exactly why the "test suite" is a brillant idea, and I fully support it. My point was, that since it's LSB version level compliance that your after, the issue isn't complicated by changing libraries or kernels. And therefore, the arguement that "levels" are too much added complexity because of constantly moving versions is muted. > 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. As it should be. Idenitfying compliance based on what the specs of todays standard hardware and useage of Linux is (in anyones opinion) is the type of short sighted thinking I am objecting to. > 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. Well.. That's potentially short sighted as well. In the evolution of software, continuing to hang on to legacy compliance will always decrease productivity, and increase bloat. If that was not the case, then there would be no issue when a new glibc came out... because it would encompass all of the old glibc. But, that is not the case. The fact remains, the libraries can co-exist, but do not (for good reason) always include identical and increased functionality of the older versions. For this reason, it would make much more sence to say that LSB v. 2.0 does NOT imply that the system is LSB v. 1.0 compliant. This would allow for evolution. And, there is no reason why a distribution can't just say "We have included everything nessessary to run software that requires LSB v. 1.0 and LSB v. 2.0" If you don't allow a new version of LSB to be free from the requirements of the old version, as you get to version 5 or 6 you will find that your unnessessarly bloated with outdated standards, and may actually find conflicts. (What if FHS changes even minorly? Then LSB v. 2 would have to specify that the path include both the old location and the new location for a file? Which, would then violate FHS, not comply to it.) You have to think these things through, and not just listen to what ISVs and the big distributions want. What they say they want is totally diffrent in some cases from what they actually need. They need a standard they can work with. The might say "we want X, we want backwards compatability" etc... But it's the job of the LSB to apply the logic to the issue of standardizing things, not to bend over for the people with deep pockets who are making unrealistic requests. > 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. Again, I strongly disagree. And, without provoking an argument, I would very much like to see a specific list of who these software vendors and distributions are that are asking this of the LSB. I consider Samsung a contender in the Linux market, they have fingers in places all over that would greatly benifit from a Linux standard. I doubt that they are demanding any such thing to help them market Yopy. Is Cobalt saying they need X for thier cube and Raq systems? I don't think the Linux Router Project would ever be asking that any part of X be included in a standard base set. But, I could easily see where they could accuse the LSB of being bloat to cater to commercial interests like Cisco, who would like to prevent Linux from scaling them right out of thier mindshare of the market. The case for the community to rebel against a LSB that only wants to cater to the commercial ISVs. And there will be infighting if the LSB only listens to the 3 or 4 distributions that sell a lot of "workstation" disks. I don't think anyone really wants to see that happen. I sure don't want to see it. And therefore, I don't think I will accept the argument that "they" want it as a reason for adapting it as a standard.
