Re: [seul-edu] Re: Unified Front... blame server, meta-distro

[Leon Brooks <leon@brooks.fdns.net>]

On Thursday 25 April 2002 22:56, Stephen C. Daukas wrote:
>>> One reason why M$ has been so successful is that they have avoided the
>>> "religious" wars that existed in the UNIX community 20 years ago, and
>>> that exist in the Linux community today, to a lesser extent.

>> Wrong. M$ have had some pretty ferocious internal religious wars (e.g. NT
>> vs 9X), and even today people are plugging 95 into Athlons and being
>> amazed by how fast it is compred to ME or XP.

> That internal conflict was never perceived by the general public (the
> non-techies), nor even by most readers of PC Magazine!

Perhaps it should be. They did suffer from it, as the NT people more or less 
deliberately introduced 9X incompatibilities which still exist in XP.

>>> Everyone went with M$ because they didn't have to understand the
>>> technology to reach a decision

>> No, you're describing Apple customers.

> No I'm talking about M$!  Apple started out very well when they packaged
> what started as XEROX's Star GUI with Apple hardware, but Apple was
> overtaken by M$ because Apple rested on their laurels.  Granted, Apple
> eliminated the necessity to deal with hardware issues, but that wasn't
> enough because they were more expensive than Intel boxes at the initial
> purchase *and* you had to buy a new machine when they told you to
> (remember, Apple is a hardware company).

Sorry, but I still disagree. Even today you have to know a lot more about the 
hardware to get it to fly on Windows than on Mac.

> Eventually, they went
> with M$ so they wouldn't have the high development costs of supporting
> several UNIX flavors.

Almost a moot point nowadays, given so many crossplatform development 
libraries.

>>> - they just went with the market leader.

>> No, Microsoft simply told them to buy Microsoft often enough and loudly
>> enough, and followed it up by any means - fair or foul - of ensuring that
>> no choice was available.

> Hmmm...  ensuring no choice was available... Sounds like a market leader to
> me!  M$ were and are the market leader!

Still not jiving. Microsoft did this kind of thing long before they were 
market leaders in many fields. To wit, told people long, loud and often 
untruthfully that they had to buy Microsoft. Presented the situation as `no 
choice' even where several very attractice opportunities existed in The Real 
World.

>>> I think it is pretty clear that Star Office is the productivity app of
>>> choice, even though it has an occasional glitch with M$.  Beyond that,
>>> everyone seems to have their favorite browser, favorite email client,
>>> and so on.  Dare I bring up gnome versus KDE?  ;-)

>> This is actually an advantage. To understand this, you have to step out of
>> salesman's shoes for a brief moment, and ask what it is that Microsoft
>> *don't* give their clients, and the answer is `real choice'.

> But M$ became the market leader that way!

Linux won't. Linux will become market leader if people follow it, not because 
it bullies or cajoles people into falling in line behind it.

Linux has no mandate to be a market leader. Neither does Apache, for example, 
but it is anyway. Market is nearly irrelevant to the software per se (except 
that there must be *some* interest in it else it effectively becomes 
extinct).

> If anything, non-techies like to play it safe - choice is frightening!

Not choice, blame. They need somebody ELSE to blame if things go wrong. 
Remember that Microsoft still offer pseudo-choices, 2000 or XP, that kind of 
thing. Microsoft make a magnificent blame server because they're too big to 
hurt.

Linux, and open source in general have to succeed by getting it right instead, 
and I'd like to keep it that way. Sadly, Linux makes a neat blame-server 
anyway, for exactly the opposite reason to Microsoft - because it's often 
hard to find someone connected with a piece of software that's *worth* suing.

> I learned a great lesson from one of my brothers in this area:  He came to
> me with a question about purchasing computers many, many moons ago (when
> Apple looked like they were getting into trouble the first time).  After a
> lengthy discussion about the pros and cons of various technologies
> available, he asked me a simple question:  "which choice allows me to get
> my work done the easiest, cheapest way possible?"   I was disappointed that
> my various technical insights didn't seem to matter to him, but I learned
> something!

Yup. So if Linux is to dominate the market, it has to answer this question. 
Sadly, it often has to answer it in the long term, ie after the `me' in 
question has bloodied their nose on Microsoft and bled copious quantities of 
cash in support of the Beast.

>> I take your point that a standard package makes a good reference point,
>> but even Microsoft provide the appearence of choice. This is an important
>> marketing point, because the decision is beign transferred from `shall we
>> buy into this or not?' to `how shall we buy into this?' or perhaps more
>> accurately `which of these shall we buy into?'

> Agreed, but [t]he choice is still from one source - a comfort to many
> because of the inferences one can draw from that fact.

The one-source image is one major reason for the survival of many distros. In 
this case, the `one source' would be you, and the choices would be between 
pre-re-packaged distros.

> I think the way to go is to craft an ISO that doesn't actually care which
> Linux you have.

You're basically talking about creating a meta-distro like Mindi Linux, and 
that ain't easy. You might aim for that further down the track, but no way is 
it readily achievable up front. Even offering the same thing from various 
distros will involve *manually* tracking changes (splits, joins, additions, 
deletions) in packages more or less common across distros, and doing the work 
of each distributor in packaging (RPM, DPKG, tar-gzip or whatever) 
applications not supported by a particular distributor.

> I believe the LSB is the standard to follow, because it
> allows binary distributions of software to run on any Linux system of a
> given architecture, regardless of which distro is being used.

LSB is designed to solve on specific set of problems, which it does. However, 
LSB is not a silver bullet for cross-distro compatibility.

For example, some distros ship with AA's VM in their kernels, some with RvR's, 
and this will impact low-level stuff. Some ship with XFree86 3.3 and tools 
not yet ported to XFree86 4.2, and others don't. Some (SuSE) are shipping 
with KDE3 right now and others (Mandrake) only have it as an unsupported 
option. Mandrake ships with a whole bunch of libraries and development tools 
that RedHat does't (even down to Apache modules and the like).

What this means is that you have to test everything on all platforms, modify 
source for where the distro and LSB differ, or where LSB is vague and distros 
differ, hope future choices (e.g. VM to put in security-updated kernels) 
don't break anything (or arbitrate `repaired' updates yourself), provide and 
integrate missing modules and packages on those distros which don't have 
them, lots of non-trivial stuff.

The bottom line is that it would be no more work, and probably much less, to 
produce your own distro, based on one of the common ones (and the easiest 
would be Mandrake because all of the tools to do that ship with it), but at 
that point you've just killed choices again if you only stick with one.

I think there is a reasonable answer.

> (I think we
> should include source, where possible, as well.)

If we ain't got source, it shouldn't go in. Amongst other reasons, recompiles 
will often fix the compatibility issues hinted at above.

> Then, and of course some will tell me I'm optimistic, you make an effort to
> get vendors interested in it.  Let them run with an "educational bundle"
> and worry about all the business issues.

And of course, different `vendors' will react in diverse ways to different 
packages. Stuff that RedHat are happy with will raise hair at Debian. BTW, 
I'm not just whinging, I'm aiming at a point.

> OK, I'm going to ask a simple question.  If we provided a ISO of the top N
> educational apps, HOW-TOs, documentation, war stories, got permission to
> distribute Star/Open Office, perhaps more, whatever (what I referred to
> once as a package), would that be enough to get a district excited and
> successful, or must we also include a Linux distro?

OpenOffice.org (and you need to use the .org because there is an unrelated 
OpenOffice without the .org) is GPL. You don't need permission. StarOffice is 
not. OO 641d ships with Mandrake 8.2 and works very well.

> If the latter, then I'm right back to my previous statement - you have to
> choose one distro to run with, and you have to make it easy to run.

If it works on RedHat, it'll almost always work on Mandrake and SuSE 
unmodified. For the sake of better integration, a recompilation for those 
distros is almost certainly worthwhile. You will also not need to ship some 
stuff for particular distros, just let the distro itself deal with those 
parts, and pad the ISO out with other stuff.

> Only having briefly looked over some of the info I've learned about
> recently, would our ISO be suitable to bundle with the terminal server
> effort, or others out there?

Mandrake 9.0 will include LTSP. For distros that don't, it would be useful to 
include LTSP on their flavour of the distro.

My solution to all of the above complaint is to work with the GNU configure 
script. That way it doesn't *matter* whether the distro is LSB or not, and 
you'll have the added advantage of having stuff work on Solaris, HP-UX, *BSD 
and so on (-: even Windows, with CygWin :-).

There will be a short-sharp learning curve to get up to speed on what the 
configure script will do for you, and while you apply it to the first dozen 
or so apps that don't have it or aren't using it right. After that it will 
become reasonably routine. Even if an author refuses to use configure with 
their package, you can still easily maintain a patch-set which tracks their 
releases (or not, if that app turns out to be unpopular).

And if we do this, please, please document the processes and stick up HOWTOs 
(ie, HOWTO convert a project to configure, with examples; HOWTO cope with 
variations in distribution with configure; HOWTO semi-automatically produce 
packages for a heap of distros and so on).

The common parts of the script will include production of .spec files and the 
like for building RPMs, DPKGs, SlackWare tar-gzips and whatever else for 
various platforms and architectures. I'd like to think that a new release of 
distro will involve nothing more than having a server thrash around for a day 
or so recompiling everything, repackaging it and tacking together a spread of 
ISOs.

I don't think finding servers to distribute the ISOs from will be a big issue. 
In Oz, places like PlanetMirror, AARnet and practically any University would 
rush to help. Unlike Microsoft, we would be *delighted* with one-disk 
countries. (-:

Cheers; Leon