2.2.13 build OOB?; need for some standardization here?

2.2.13 build OOB?; need for some standardization here?

[Kevin_Hendricks]

Hi,

I don't want to start a fight here but...

Isn't there any way to do more standardization among the different powerpc linux 
distributions (I know you want to differentiate your product to compete but..)

Right now, we have Debian ppc, Linux PPC, YellowDog Linux, TurboLinux, MkLinux 
DR1, etc all vying for the same user base.

This is making for the same support nightmare that already exists on x86 and 
something we should really try hard to avoid?

For example:

Look at the proliferation of kernels and versions of glibc "out-there":

kernels:
   - 2.2.6 with and without usb support
   - 2.2.6 with 1.1 and 1.1.6 usb versions
   - 2.2.10 with either the old usb (1.1. vs 1.1.6) or the new usb, 
   - 2.2.12 with Linus usb version
   - all of the above with and without mac-on-linux support
   - all of the above, with and without Anthony's Rage 128 XF68_FBDev driver
   
This is literally a nightmare for tracking down bug reports of keycode problems 
in the jdk, video driver problems, etc.

If on top of this we add glibc 2.1.2 vs glibc 2.1.1 (change in the semaphore 
definitions make them binary incompatible when trying to start up the jdk from a 
c app). (Not to mention the people stuck at glibc 1.99 under MkLinux waiting for 
DR1 to be official).


Then there is the whole question of where to get your kernel source from?  You 
can't seem to use the official kernel source trees for even the *stable* relases 
of 2.2.X.

Is there any chance 2.2.13 will actually build out of the box on PPC without 
having to add Paul's patches and/or getting it via rsync from Paul's tree.  
Maybe so this time since I noticed Paul's name under Alan Cox's pre-patch list 
of contributors.

Shouldn't the official *stable* kernel tree always build-out-of-the-box on each 
supported platform?  If so, why isn't this happening in general? 

To more unify this, should we have our own clone of Alan Cox to make 
"semi-official" updates to the "official" stable tree to make things more 
official for ppc.  

Is this a role for Paul?  (it is the role that Paul has filled for a very long 
time now, maybe it should be "official").  If so, then publize that being the 
one "true" source for "official" ppc kernel trees.

The lack of standards for Linux is driving the Blackdown x86 JDK porting crazy. 
Differnt default ulimits for thread stacks between SuSe, RedHat, and Debian, 
differnt glibc's, different versions of libraries, different install locations, 
etc.  

Up until now, the ppc camp has been pretty immune to all of this.  But now, the 
number of versions of things seems to be growing fast and I fear for the worst.  

Our user base is simply too small to keep that many different distributions 
around.  If we want, commercial software to be ported to LinuxPPC, we really 
need to have a unified user base.

Ideas here?

Comments?

Am I simply worrying too much?

Thanks,

Kevin

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA   
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Sriranga Veeraraghavan]

Hi,

See my comments inline.

> Then there is the whole question of where to get your kernel source from?  You 
> can't seem to use the official kernel source trees for even the *stable* relases 
> of 2.2.X.

I'm not sure about other people, but as of kernel version 2.2.12 I was
able to download and compile it using the source from ftp.kernel.org.
No special patches or rsync updates. I just download the bz2 file,
untar'ed it in /usr/src and did:

$ make mrproper ; make pmac_config ; make menu_config ; make dep ; make clean ; make

> Shouldn't the official *stable* kernel tree always build-out-of-the-box on each 
> supported platform?  If so, why isn't this happening in general? 

I'm sure this is the desired *goal* but it isn't true in reality. As
an example, when I was running sparc-linux the stable kernel rarely
compiled "out of the box". Eventually, I gave up and went back to
Solaris (its not that slow once you get rid of all that CDE crap and
just ssh into the box).
 
> The lack of standards for Linux is driving the Blackdown x86 JDK porting crazy. 
> Differnt default ulimits for thread stacks between SuSe, RedHat, and Debian, 
> differnt glibc's, different versions of libraries, different install locations, 
> etc.  

I mainly work on Solaris, and I have seen similar problems before
while trying to port Solaris code to HPUX and AIX which have
completely different conceptions of how things ought to work. In a
some cases we just ended up ditching the HPUX or the AIX port since it
was just too hard and we couldn't afford the time/machines to fully
support it.

One of the reasons (IMHO) that RH and RH based Linux versions are
popular is that they are closer to Solaris in the layout and
management of the system and in the development envrionment than other
versions of Linux. This makes porting easy: 'just type make'.

> Our user base is simply too small to keep that many different distributions 
> around.  If we want, commercial software to be ported to LinuxPPC, we really 
> need to have a unified user base.

Most companies will pick only one or two versions of an OS to
support. This is the only way that they can get any reasonable
development done. Unlike OSS, commercial software has committed
release dates and customer guarentees that cannot be met unless you
limit the scope of your project.

I see this is happening already. For example, most commercial products
for Linux are RH 5.0 or newer. I think that the closer the LinuxPPC
distributions come to RH for x86 the easier it will be to attract
commercial software. In the transition from LinuxPPC R4 to LinuxPPC
R5, I think that the linuxppc.com guys did a pretty good job.

Just my $0.02,

----ranga <ranga@soda.berkeley.edu>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Geert Uytterhoeven]

On Tue, 28 Sep 1999, Sriranga Veeraraghavan wrote:
> I see this is happening already. For example, most commercial products
> for Linux are RH 5.0 or newer. I think that the closer the LinuxPPC
> distributions come to RH for x86 the easier it will be to attract
> commercial software. In the transition from LinuxPPC R4 to LinuxPPC
> R5, I think that the linuxppc.com guys did a pretty good job.

Note that LinuxPPC is not identical to RH 5.0 on ia32.

If you want a distro that's the most identical on al architectures (and
supports the most architectures), then you have to go for Debian. There's no
other distro that runs on all my boxes (m68k, AXP and PPC).

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Sriranga Veeraraghavan]

> Note that LinuxPPC is not identical to RH 5.0 on ia32.

I realize that there are differences, but at this point it pretty
close; much better than when R4 first came out.

The problem with debian (for me) is that it is different from most
other versions of UNIX I have ever run across. I had it running for a
while on my IIci as a novelty.

----ranga <ranga@soda.berkeley.edu>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Hollis R Blanchard]

On Tue, 28 Sep 1999, Kevin_Hendricks wrote:
> 
> Isn't there any way to do more standardization among the different powerpc
> linux distributions (I know you want to differentiate your product to
> compete but..)
> 
> Right now, we have Debian ppc, Linux PPC, YellowDog Linux, TurboLinux,
> MkLinux DR1, etc all vying for the same user base.
> 
> This is making for the same support nightmare that already exists on x86 and
> something we should really try hard to avoid?
> 
> For example:
> 
> Look at the proliferation of kernels and versions of glibc "out-there":
> 
> kernels:
>    - 2.2.6 with and without usb support
>    - 2.2.6 with 1.1 and 1.1.6 usb versions
>    - 2.2.10 with either the old usb (1.1. vs 1.1.6) or the new usb, 
>    - 2.2.12 with Linus usb version
>    - all of the above with and without mac-on-linux support
>    - all of the above, with and without Anthony's Rage 128 XF68_FBDev driver

I don't think this has anything to do with distributions. People can install
whatever version of whatever software they want, regardless of their initial
distribution.

> This is literally a nightmare for tracking down bug reports of keycode
> problems in the jdk, video driver problems, etc.

True... One solution would be to reply to bug reports with "reproduce it in
kernel.org's 2.2.12 and we'll look at it." All of the kernel stuff you
mentioned is just part of kernel development, and I don't see how that can be
stopped.

> If on top of this we add glibc 2.1.2 vs glibc 2.1.1 (change in the semaphore
> definitions make them binary incompatible when trying to start up the jdk
> from a c app). (Not to mention the people stuck at glibc 1.99 under MkLinux
> waiting for DR1 to be official).

Pick a target. It should probably be the newest stable release of stuff, ie
kernel.org 2.2.12, glibc 2.1.2, XFree86 3.3.5.

I don't think anyone's worrying much about glibc 1.99 any more...

> Then there is the whole question of where to get your kernel source from?
> You can't seem to use the official kernel source trees for even the *stable*
> relases of 2.2.X.
> 
> Is there any chance 2.2.13 will actually build out of the box on PPC without
> having to add Paul's patches and/or getting it via rsync from Paul's tree.
> Maybe so this time since I noticed Paul's name under Alan Cox's pre-patch
> list of contributors.
> 
> Shouldn't the official *stable* kernel tree always build-out-of-the-box on
> each supported platform?  If so, why isn't this happening in general? 

That would be nice. Unfortunately, x86 people can't exactly test their changes
on PPC, and so more than once the "stable" branch doesn't work here. There
have been conversations about it.

> To more unify this, should we have our own clone of Alan Cox to make
> "semi-official" updates to the "official" stable tree to make things more
> official for ppc.  
> 
> Is this a role for Paul?  (it is the role that Paul has filled for a very
> long time now, maybe it should be "official").  If so, then publize that
> being the one "true" source for "official" ppc kernel trees.
> 
> The lack of standards for Linux is driving the Blackdown x86 JDK porting
> crazy.   Differnt default ulimits for thread stacks between SuSe, RedHat,
> and Debian, differnt glibc's, different versions of libraries, different
> install locations, etc.  
> 
> Up until now, the ppc camp has been pretty immune to all of this.  But now,
> the number of versions of things seems to be growing fast and I fear for the
> worst.  
> 
> Our user base is simply too small to keep that many different distributions
> around.  If we want, commercial software to be ported to LinuxPPC, we really
> need to have a unified user base.

Again, I don't think it has much to do with the distributions. TurboLinux and
early MkLinux (both with glibc 1.99) are very small. MkLinux w/ glibc2 is
limited to the x100 PowerMac users for the most part. Debian is pretty small
because of its installation procedure. I hope LinuxPPC R4 people have upgraded
by now, and LinuxPPC 1999 and YDL 1.1 are pretty damn close. I really don't
think there's that much of a division (aside from very small slices of the pie
chart here and there).

Summary: pick target versions of the packages you're worried about. Someone
else pointed out that Unix software vendors pick a few Unices to develop for.
Since you have finite resources (like commercial vendors), you should do the
same. I think you'll find that you can group a very large percentage of the
Linux/PPC userbase under the glibc 2.1.2 flag.

-Hollis


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Deirdre Saoirse]

On Tue, 28 Sep 1999, Kevin_Hendricks wrote:

> Isn't there any way to do more standardization among the different powerpc linux 
> distributions (I know you want to differentiate your product to compete but..)
> 
> Right now, we have Debian ppc, Linux PPC, YellowDog Linux, TurboLinux,
> MkLinux DR1, etc all vying for the same user base.

MkLinux and LinuxPPC are effectively identical except for kernel. The
file hierarchy is the same (Red Hat based).

Furthermore, SuSE has announced that it too will be interested in a
PowerPC port. There's a LOT of interest in PowerPC these days.

> This is literally a nightmare for tracking down bug reports of keycode problems 
> in the jdk, video driver problems, etc.

It is said that on the x86 kernel,  almost 50% of reported kernel bugs are
people running vmware.

> To more unify this, should we have our own clone of Alan Cox to make 
> "semi-official" updates to the "official" stable tree to make things more 
> official for ppc.  
> 
> Is this a role for Paul?  (it is the role that Paul has filled for a very long 
> time now, maybe it should be "official").  If so, then publize that being the 
> one "true" source for "official" ppc kernel trees.

I thought this already WAS Paul Mackerras.

> Am I simply worrying too much?

Yes. :)

-- 
Deirdre Saoirse, Systems Analyst, Linuxcare, Inc.
415.354.4878 x252 tel, 415.701.7457 fax
dsaoirse@linuxcare.com, http://www.linuxcare.com/
Linuxcare. At the center of Linux.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Kevin_Hendricks]

Hi,

>I don't think this has anything to do with distributions. People can install
>whatever version of whatever software they want, regardless of their initial
>distribution.

But Linux PPC and YellowDog linux ship with different kernel versions and 
different usb style support do they not.  Then there is the glibc stuff.  Both 
shipped with glibc 2.1.1 (versions) but the latest LinuxPPC uses (or has) glibc 
2.1.2 (which because of incompatibilities is a nightmare for jdk  using native 
threads).

>True... One solution would be to reply to bug reports with "reproduce it in
>kernel.org's 2.2.12 and we'll look at it." All of the kernel stuff you
>mentioned is just part of kernel development, and I don't see how that can be
>stopped.

I disagree.  I really think it would help to have one clearing house for the 
kernel source tree with all of the latest patches installed so that there are 
not awhole bunch of different incompatible versions flying around (the usb stuff 
for instance). 

I think we should either fix the way Linus and company decides when to release a 
stable version, or get our own "Alan Cox" to act as shepard over our own stable 
"ppc" kernel tree and make that person "official".

>Pick a target. It should probably be the newest stable release of stuff, ie
>kernel.org 2.2.12, glibc 2.1.2, XFree86 3.3.5.

Yes, that is what I have done.  Although I chose glibc 2.1.1 until the other 
distributions start shipping glibc 2.1.2.

But this just illustrates my point.  Everytime you force someone to support only 
a set subset of packages, you fragment the Linux/PPC user base even further.  
Since our base is so small to begin with, any fragmentation will have a very big 
impact. 

>I don't think anyone's worrying much about glibc 1.99 any more...

I do for my 8100 machine hanging around still running MkLinux DR3

>> Then there is the whole question of where to get your kernel source from?
>> You can't seem to use the official kernel source trees for even the *stable*
>> relases of 2.2.X.
>> 
>> Is there any chance 2.2.13 will actually build out of the box on PPC without
>> having to add Paul's patches and/or getting it via rsync from Paul's tree.
>> Maybe so this time since I noticed Paul's name under Alan Cox's pre-patch
>> list of contributors.
>> 
>> Shouldn't the official *stable* kernel tree always build-out-of-the-box on
>> each supported platform?  If so, why isn't this happening in general? 
>
>That would be nice. Unfortunately, x86 people can't exactly test their changes
>on PPC, and so more than once the "stable" branch doesn't work here. There
>have been conversations about it.
>

>Again, I don't think it has much to do with the distributions. TurboLinux and
>early MkLinux (both with glibc 1.99) are very small. MkLinux w/ glibc2 is
>limited to the x100 PowerMac users for the most part. Debian is pretty small
>because of its installation procedure. I hope LinuxPPC R4 people have upgraded
>by now, and LinuxPPC 1999 and YDL 1.1 are pretty damn close. I really don't
>think there's that much of a division (aside from very small slices of the pie
>chart here and there).
>
>Summary: pick target versions of the packages you're worried about. Someone
>else pointed out that Unix software vendors pick a few Unices to develop for.
>Since you have finite resources (like commercial vendors), you should do the
>same. I think you'll find that you can group a very large percentage of the
>Linux/PPC userbase under the glibc 2.1.2 flag.

And if everyone does that, we will just fragment things even further.  That is 
my whole point.  Before we diverge even farther, lets figure out someway to 
prevent the kind of support problems that plague x86 with all its versions / 
libraries / glibcs/ etc.

By the way, (my case in point) I don't think glibc 2.1.2 is that prevalent out 
there.  It only just shipped with Linux PPC Q3, Champion server 1.1 does not 
install it (which makes my point clearer I hope) and the other distributions 
afaik are shipping one version of glibc 2.1.1 or another.

So do I build for glibc 2.1.2, glibc 2.1.1, only one kernel version, only one 
distribution, what?  

That is what I think we *all* should avoid if possible.

My 2 cents.

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[David Edelsohn]

>>>>> Kevin Hendricks writes:

Kevin> I think we should either fix the way Linus and company decides when to release a 
Kevin> stable version, or get our own "Alan Cox" to act as shepard over our own stable 
Kevin> "ppc" kernel tree and make that person "official".

	I tend to agree with Kevin here.  The Linux core kernel developers
need to improve their release engineering process.  I realize that
Linux/PPC was on the fringe for a long time, and both Paul and Cort have
done a lot of excellent work these past few months adding functionality
and improving the overall design.  This rapid development makes it hard
for Linus and company to keep up.  However, x86 development should not
break PowerPC and other ports as much as I have seen.

	PowerPC and other architectures are becoming more important and
demonstrating the diversity of Linux.  The breakage and instability does
not cast a good light on bazaar-style development model and Linux when we
are trying to broaden the Linux market.

David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Michel Lanners]

Hi all,

On  28 Sep, this message from David Edelsohn echoed through cyberspace:
> Kevin> I think we should either fix the way Linus and company decides when to release a 
> Kevin> stable version, or get our own "Alan Cox" to act as shepard over our own stable 
> Kevin> "ppc" kernel tree and make that person "official".
> 
> 	I tend to agree with Kevin here.  The Linux core kernel developers
> need to improve their release engineering process.  I realize that
> Linux/PPC was on the fringe for a long time, and both Paul and Cort have
> done a lot of excellent work these past few months adding functionality
> and improving the overall design.  This rapid development makes it hard
> for Linus and company to keep up.  However, x86 development should not
> break PowerPC and other ports as much as I have seen.

I fully agree here. I think every Linux arch should have a single person
responsible for the port, and new releases of stable kernel versions
should get every arch maintainer's OK before release. That would at
least catch most of the 'doesn't compile on...' type of bugs.

However, I fear that Paul, the current PPC maintainer according to
kernel documentation, would need to spend even more time on Linux
than he currently does... which I'm not sure he is prepared to do.

> 	PowerPC and other architectures are becoming more important and
> demonstrating the diversity of Linux.  The breakage and instability does
> not cast a good light on bazaar-style development model and Linux when we
> are trying to broaden the Linux market.

Absolutely true. There are two main problems I see here: getting PPC
patches into the kernel, and checking that other people's work on the
kernel doesn't break anything PPC-specific. Both problems caused
headaches in the past...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.13 build OOB?; need for some standardization here?

[Benjamin Herrenschmidt]

On Wed, Sep 29, 1999, Paul Mackerras <paulus@linuxcare.com> wrote:


>I hope to set up an ftp server shortly where I will be able to
>distribute kernels without the restrictions that I have on
>ftp.samba.org.  It will probably be ftp.ozlabs.linuxcare.com or
>something like that.

Hi Paul, glad to hear from you again ;)

My 2 cents: could you make, on this server, some kind of "cleaning room"
for patches ? There are more and more patches floating around to fix
small details (yet another sound fix, a mouse fix, my own little fixes
here or there, etc...) which are quite scattered. I know Cort made
somthing similar on linuxppc.cs.nmt.edu, I don't know if it still exist
however. (I've been away from linuxppc dev. for some time too, I'm back
hacking only since we did that sleep stuff).

Regards,
Benjamin.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/