Re: LSB (USB being still vaporware for the most part...) (was Re: A better ICQ client for Java)

["Robert G. Brown" <bob@xxxxxxx>]

>>The console application being discussed here is available at:
>>     ftp://micq.ml.org/pub/micq
>>      http://pages.infinit.net/fairoff/licq 
>>Licq for X-windows, micq for the console. Doesn't that make perfect sense? :)
>The X name makes me think of lice, probably from playing Moria too much.
Amusing. I have other associations, but that's for another time ;)

>>>above site regarding the Linux Standard Distribution is a good read.
>>Thought provoking stuff. However, I am somewhat suspicious of his motives.
>I agree with all your salient points. 
Swell.

>...it's more productive to focus upon what we have in common....
Quite so; this is a point that may need to be made to Mr. Young. Th evolution 
of a common library standard is the keystone of LSB.

>> I'd say that as this LSB debate continues (and I reccomend all the editorials
>> in this series) beware of those who do not write favorably about the need to
>> perform some standardization and consolidation. Another agendas are at work.
>> I remain suspecious of market leaders, they become defenders of the status
>> quo very quickly.

>Everyone has their own agenda;
Ian, please. Of course everyone has their own agenda, that's not the point. 
The point IS that when we're talking about standards, one comes to accomdate
a personal agenda with the needs of the community. When one's personal agenda 
comes first and always first, one never really gives anything back, and is 
not acting with any community spirit at all.

>for the most part, Redhat has cooperated well with others, recognizing that 
>this is the best way to better their reputation in the community and reap 
>real, long-term profits instead of flash-in-the-pan upgrade schemes and
>marketing hype. 
In some ways, every vendor has to cooperate. Red Hat has even attempted to 
lead, and has built up some followers (e.g, SuSE uses .rpm's for their
distribution packaging), recall that rpm stands for Red hat Package Manager.

However, as the market grows and changes, we would expect diffeences to arise
in how each vendor approaches the market. Two years ago, RHS did not have near-
ly the market share they have now, and we know that companies change their be-
havior as they become market share leaders.

The price of freedom is vigilence.

>I see the LSB as a way to keep vendors honest; after all, who would pay for
>something when there is a superior alternative available for free?
Oh, you mean like all those Win95/98 "consumers"? IMO, you, Robert Young, and 
yours truly wouldagree on the answer to THIS question! :)

>>>BTOW, right now I recommend the SuSE distribution for anyone deciding to go
>>>with a commercial distribution. The upcoming release looks like more of a
>>>Windows-killer than Redhat.
>>Can you be more specific? We had a presentation on SuSE about 8 weeks ago,
>>and moving there is double edged, since there are base-level incompatibilities
>>between the reviewers first install (RH Linux 5.0) and SuSE. This is EXACTLY
>>the issue that Young's editorial addresses, and IMO its the most serious
>>problem facing Linux right now. If all the software in the SuSE and RHS 
>>packages were actually interoperable, that would be powerful magic indeed.
>I spoke too hastily again. I rephrase, "I recommend SuSE for anyone wanting
>the easiest, friendlest, install-it-and-go package, especially someone who
>is new to Linux." 
I like the first part of what you've said best... You spoke too hastily.
IMO you are STILL speaking too hastily, still making too many assumptions,
to wit...
>Assuming one has decided on a commercial distribution
>rather than a 100% open source one, of course. 

Followed with another example:
>The incompatibility issues
>are real, but will not be a problem for the majority of people approaching
>Linux for the first time, and that's how I've been viewing all Linux stuff
>lately -- ...
But why? These things have a life-cycle. We can't only consider what's going
to be useful today, but also what provides for a good migration path later.
The notion that you're buying into a migration path, not only good solutions,
but expansion, is a driving force behind commerical software. This is a power-
ful sell in profeesional circles; the vendor will not only be there today,
but also tomorrow, and next year. A lot of the resistance to Linux is based 
on that confidence.

And now perhaps it's clear the you're only speaking for yourself, based on
little or no market-wide experience....
>I know all the alternatives available to me if I want to run some
>sort of Linux, depending on what I want to do, 


>....but newbies will primarily
>be concerned with a friendly, ready-to-use system.
How do you know what people want? I try not to label folks so easily; we all
bring different levels of skill and knowledge to the table. Lemme tellya, I've
been in this industry longer than you've been alive, and I STILL don't know
what the next user really needs until I talk to 'em. Also, it's amazing what
clicks in people's heads, what makes sense, and what doesn't.

Perhaps you know "all" this stuff; I'm still learning!

>Us geeks are just a lot more demanding about the details -- the mainstream is 
>demanding in terms of "black box" magic. "Here's my money, now make it go."
But how do you know the next new subscriber, new mailer, isn't interested in
the details, too? When I came to Linux, I had over 5 years experience
in developing large applications on Unix systems. I didn't expect either a 
"black box" or the inheritance of the knowledge of a kernel hacker, but I
found my own way. Others need to as well, and we can help.

>(Although I recognize that others may have more difficulties in this area,
>Linux compatibility has never been an issue for me.
Perhaps precisely because you have not yet thought through the lifecycle
issues, simply have not yet mixed distrubtions enough to catch them. I've
seen them in commercial software a long time ago, and I've seen this in
some Linux executables rather recently.

In vertical, single vendor markets (Microsoft on Intel, Sun on Sparc, MVS
on IBM mainframes) standards exist by declaration, 'cuz the one (or domi-
nant) vendor calls the shots, and they are going to ensure standardization,
if only to minimize overhead. In the GNU/Linux world, we have lots of other
problems, since all of the issues that get hashed out on the in-house vendor
network are handled over the 'net, in public.

Read the other editorials. The one editorial form the market leader is the 
only one to throw even a little cold water on the idea.  Everyone else is 
fairly gung-ho about LSB, and suspicous cuss that I am, I can't help but
wonder about who may benefit from not cooperating with broad standards.

I've seen IBM do it, in the 70's and 80's, on mainframes. I saw HP do this
with printers and instrumentation. I've seen MS do this with GUI's and 
file systems. Hmmm....

                                                           Regards,
                                                            ---> RGB <---