Roles for distributions

Roles for distributions

[Kevin B. Hendricks]

Hi,

Since I am already on my soapbox, there is one other important issue this
body could address.

Why aren't the current PPC linux distributions putting full time developers
on key projects?

Right now without Franz Sirl ppc would be complete shit when it comes to
tools and things.  He not only keeps up gcc for powerpc, without his help
glibc-2.2 and binutils would not be working at all.

Where are all the distribution developers???????????

Why don't SuSE, YellowDogLinux, LinuxPPC, etc have anyone regularly
contributing to the toolchains (checking builds, reporting and fixing bugs,
etc)?  We (ppc) should have somebody with commit priviledges on gdb,
binutils, and glibc 2.2 helping and supporting things (and GeoffK doesn't
count since he is simply too busy).

In SuSE's defense, their x86 developers are shouldering most if not all of
the work for glibc 2.2.  Same goes for redhat.  But no one is supporting
ppc basically but Franz.

And what about the other key projects: mozilla, helix/gnome, KDE, galeon,
apache, etc?

Seriously, if the toolchain stops working for ppc (gcc, gdb, glibc, etc) we
are sunk...period.

Gary Thomas used to help with these things but I haven't seen a post from
him in a long time.

This is something we really need to fix if we are ever going to be in the
big leagues.

Again my 2 cents,

Kevin

(and I do try to help out with glibc and things when I have time).


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

Re: Roles for distributions

[Ariel Rios]

"Kevin B. Hendricks" wrote:

>
>
> And what about the other key projects: mozilla, helix/gnome, KDE, galeon,
> apache, etc?
>

I don't work with any linuxppc distro but I have been developing gnome in my
imac for some time now.
Currently I'm working to get bonobo, evolution and nautilus to work properly
under PPC.

Be sure you'll always have a gnome inside ppc

ariel


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

Re: Roles for distributions

[Dan Malek]

"Kevin B. Hendricks" wrote:

> Why aren't the current PPC linux distributions putting full time developers
> on key projects?

So, do you actually _pay_ for any of these distributions and their
available support or subscriptions, or are you just one of the slackers
the expects someone else to pay for your free software?

All of the distributions you mention will support you.....well,
maybe not any more....


	-- Dan

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

Re: Roles for distributions

[Hendricks, Kevin]

Hi Dan,

>So, do you actually _pay_ for any of these distributions and their
>available support or subscriptions, or are you just one of the slackers
>the expects someone else to pay for your free software?
>
>All of the distributions you mention will support you.....well,
>maybe not any more....


That is a nasty thing to say... And unfotunately you picked on the wrong
person.

I have bought and paid for LinuxPPC 1999, YellowDog 1.1 and YellowDog 1.2
and SuSE 6.4 (I have also been given copies for free of YellowDog Linuxppc,
and SuSE 6.4).  I bought the packages to help support the movement.

The reason I was given them for free was that I have helped with
development since the oringal MkLinux came along.  I have been involved in
porting the JDK (and I am again part of Blackdown), fixing kernel bugs,
fixing glibc bugs, helping test gdb, submitted fixes to mozilla, wrote the
intial frame buffer support for rage128 for XF 3.9.17 (with help from
others), hacked in usb mouse support in Xpmac, made fixes for Rage 128 and
Mach 64 acceleration in Xpmac, etc.

I strongly feel that any user / developer should give back to the community
for what he uses.  I do constantly.  If you still don't believe me check
out the dev mailing list archive, my java site, the glibc mailing lists,
the mozilla bug reports (with patches) etc as far back at the original
MkLinux release.

I expect a full apology now.


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: Roles for distributions

[Dan Malek]

"Hendricks, Kevin" wrote:

> That is a nasty thing to say... And unfotunately you picked on the wrong
> person.

Oh yeah....and one of the first things I read on Monday morning is you
being nasty to people working hard creating distributions.  There are
lots of us that work hard to make all of this happen, from fixing a
little bug, to creating the packages anyone can use, to creating
complete distribtions.

If you don't like the way some of these folks are creating distibutions
or supporting them, you should start by contacting them and expressing
your suggestions.  A blanket "everyone is screwing up" statement isn't
terribly helpful.

> The reason I was given them for free was that I have helped with
> development since the oringal MkLinux came along.

You are not a unique individual in this regard.  Although for for
someone that has worked in this community for so long, I would have
expected something a little constructive.

> I expect a full apology now.

I happen to be one of those full time employees you pissed off, and then
after spending 12 hours a day working on a distribution I spend six more
working on software you will see tomorrow.....seven days a week.  I
had better get one from you.

I hope your day gets better.


	-- Dan

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

Re: Roles for distributions

[Hendricks, Kevin]

Hi Dan,

>Oh yeah....and one of the first things I read on Monday morning is you
>being nasty to people working hard creating distributions.  There are
>lots of us that work hard to make all of this happen, from fixing a
>little bug, to creating the packages anyone can use, to creating
>complete distribtions.
>
>If you don't like the way some of these folks are creating distibutions
>or supporting them, you should start by contacting them and expressing
>your suggestions.  A blanket "everyone is screwing up" statement isn't
>terribly helpful.

I guess I won't get my apology.  ;-)

Since this seems to be personal, this will be my last posting to the list
on this subject.  If you want to continue this argument, please do so
off-line.

>You are not a unique individual in this regard.  Although for for
>someone that has worked in this community for so long, I would have
>expected something a little constructive.

It was constructive, you read it as an attack.  Both Dan Burcaw and Olaf
responed to my mail and they did not view it that way.  In fact, they both
responded that they agreed but due to limitations (i.e. budgets) there was
not alot they could do but that they would try.

>I happen to be one of those full time employees you pissed off, and then
>after spending 12 hours a day working on a distribution I spend six more
>working on software you will see tomorrow.....seven days a week.

If you remember, I never accused anyone of not working hard or
contributing.   You are the only one that has done that.

> I had better get one from you.

So I get personally attacked by you and I owe you an apology. Is that correct?

My wife is right, I do give too much time for free to ppc.  We fight about
it constantly.  Things certainly have changed over the last 20 years.

I should just retire, it simply isn't worth it since this is how my
contributions are viewed by you and others.

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: Roles for distributions

[Daniel Jacobowitz]

Kevin, with due respect, I don't see how you can post something like
this and NOT expect to get flamed hard in return.  I'm going to try not
to, though.

On Sun, Sep 10, 2000 at 03:52:16PM -0400, Kevin B. Hendricks wrote:
> Why aren't the current PPC linux distributions putting full time developers
> on key projects?

Because no one can afford to.  The PPC linux market, while growing, is
small.  LinuxPPC, Inc. makes what contribution they can, in the form of
supporting existing volunteers; I'm sure some of the other
distributions do the same.

> Why don't SuSE, YellowDogLinux, LinuxPPC, etc have anyone regularly
> contributing to the toolchains (checking builds, reporting and fixing bugs,
> etc)?  We (ppc) should have somebody with commit priviledges on gdb,
> binutils, and glibc 2.2 helping and supporting things (and GeoffK doesn't
> count since he is simply too busy).

It takes a tremendous amount of experience, as I'm sure you're aware,
to contribute usefully to the toolchain.  There aren't very many people
who can do it.  Most of those who can have full time jobs doing it, in
areas that pay their bills - that some of them have the time to do it
volunteer is a miracle.

> And what about the other key projects: mozilla, helix/gnome, KDE, galeon,
> apache, etc?

I wonder why you put apache here... Apache needed almost no fixes for
powerpc; the last batch I recall were glibc 2.1 / db2 related, and
several of us got them fixed about two years ago.

There are volunteers working on all of the above.  No one can afford to
pay anyone to.

> (and I do try to help out with glibc and things when I have time).

And that is all we can ask of anyone.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: Roles for distributions

[Hendricks, Kevin]

Hi Daniel,

At 11:17 -0400 9/11/00, Daniel Jacobowitz wrote:
>Kevin, with due respect, I don't see how you can post something like
>this and NOT expect to get flamed hard in return.  I'm going to try not
>to, though.

I will say this publicly once more.  I NEVER in *any* way implied or stated
that *people* at distributions were not working hard or don't contribute
enough.

The only things in the entire system with any financial resources at all
are the distributions and many distributions do have people working on the
toolchain and things.

I was trying to say that Franz needs help and I was trying to goad the
distributions into providing some more help (at least someone with glibc
checkin privledges would be nice).

>Because no one can afford to.  The PPC linux market, while growing, is
>small.  LinuxPPC, Inc. makes what contribution they can, in the form of
>supporting existing volunteers; I'm sure some of the other
>distributions do the same.

Yes, that is exactly what Dan Burcaw and Olaf said.  Even someone part-time
would be a big help.

>It takes a tremendous amount of experience, as I'm sure you're aware,
>to contribute usefully to the toolchain.

There has to be someone there who can at least make builds, file bug
reports, and point out when things are broken.  Even that would be a big
help.  I filed a make check report with the glibc maintainers and basicaly
got back a "we are not interested, fix it yourself if you want it fixed".
That generally doesn't happen if someone from ppc is contributing in some
way to the project.  Luckily, some of the other glibc developers chimed in
to rephrase the reply.

>> And what about the other key projects: mozilla, helix/gnome, KDE, galeon,
>> apache, etc?
>
>I wonder why you put apache here... Apache needed almost no fixes for
>powerpc; the last batch I recall were glibc 2.1 / db2 related, and
>several of us got them fixed about two years ago.

Just to make sure it stayed that way.  I have been told that apache does
have volunteers helping out there and it is no worry.  The list was not
meant to be exhaustive, just to represent some important projects we might
want to get involved in.  My main focus was and continues to be the
toolchain.

>There are volunteers working on all of the above.  No one can afford to
>pay anyone to.

That I understand now.  But if the distributions have no money to do this
than no-one does.

>> (and I do try to help out with glibc and things when I have time).
>
>And that is all we can ask of anyone.

You are right!

So why does this deserve a personal attack on me not buying distributions
and not contributing time?  Nothing I have said or done is personal and I
have just now received from someone something that could be easily be
construed as a personal threat.   How's that for fun?!

You gotta love it!

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: Roles for distributions

[Hendricks, Kevin]

Hi David,

>	Kevin, I think that your initial message was much more hostile
>than necessary.  It did not come across as PowerPC Linux volunteers need
>more help.  Instead of attacking everyone who had a negative reaction to
>your original note, maybe you should consider that it was phrased poorly.
>You have jumped down my throat enough times when I came across differently
>than I had intended.
>
>David

Yes, you are absolutely correct.  Hindsight is 20/20.

I still don't read my note as "hostile" to distribution individuals or
developers but enough people have and continue to do so.  That means what I
meant to say and what they read are not the same thing.

Unfortunately, empiricial evidence is nice but after the fact! ;-)  I just
don't like things becoming personal and still don't.  It just isn't needed.

I tried to correct my "error" by saying that it was never my intent to
imply or state that individuals do not contribute enough.  It was to say
the toolchain is important and we are basically down to Franz and he
doesn't even have glibc checkin privleges.

I still think the distributions could free up someone even part time now
that Gary Thomas has gone away and should. They are the only ones making
any money and the only ones that have the financial resources.  The rest of
us just volunteer our time.

Thanks for pointing that out.

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: Roles for distributions

[Hollis R Blanchard]

On Mon, 11 Sep 2000, Daniel Jacobowitz wrote:
>
> On Sun, Sep 10, 2000 at 03:52:16PM -0400, Kevin B. Hendricks wrote:
> > Why aren't the current PPC linux distributions putting full time developers
> > on key projects?
>
> Kevin, with due respect, I don't see how you can post something like
> this and NOT expect to get flamed hard in return.

I don't see this at all. It's a simple question. And as Daniel explained, a
simple answer - there's not enough money. Nothing to flame about there...

And given that Hendricks has done a hell of a lot more than most users put
together, clearly the "freeloader" attack was just ridiculous.

I work for YDL, so you'd think I should be all offended... but I'm not and I
really don't see the fuss. If there was more money around, clearly hiring a
fulltime hacker to take care of little things like glibc and the toolchain
would be a good plan. But there isn't, so that hasn't happened. That's all.

-Hollis


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

Re: Roles for distributions

[David A. Gatwood]

On Mon, 11 Sep 2000, Hollis R Blanchard wrote:

> I work for YDL, so you'd think I should be all offended... but I'm not
> and I really don't see the fuss. If there was more money around, clearly
> hiring a fulltime hacker to take care of little things like glibc and
> the toolchain would be a good plan. But there isn't, so that hasn't
> happened. That's all.

Any possibility that the various distros could pool resources and hire one
among them?  :-)  Just a wild idea.


David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


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

Re: Roles for distributions

[Hendricks, Kevin]

Hi,

>> There has to be someone there who can at least make builds, file bug
>> reports, and point out when things are broken.  Even that would be a big
>> help.  I filed a make check report with the glibc maintainers and basicaly
>> got back a "we are not interested, fix it yourself if you want it fixed".
>> That generally doesn't happen if someone from ppc is contributing in some
>> way to the project.  Luckily, some of the other glibc developers chimed in
>> to rephrase the reply.
>
>Well, first of all, that's not a general project thing - that's Ulrich
>Drepper's attitude problem.
>
>Secondly, bug reports filed by someone who can just make and make check
>are not terribly useful - no one really has time to dig.  We need
>people who can file bug reports with analysis, and not many people can.

Here is the only point I disagree with.  As a volunteer, I don't even know
if a project needs my help.  The only reason I started testing glibc 2.2
was that there was some noises that it was nearing release and almost every
time glibc comes out it breaks something for native threads which are
really needed by the jdk.

If people regularly do builds, and do "make check" then errors will appear
near in time to recent patches and things (sort of like Linus's only give
me small patches approach) that can tell the maintainers that something is
amiss.  That makes any bugs much easier to find.  My last glibc 2.1.3 patch
was found by doing regular builds to compare different glibc releases and
it was easy to see that Ulrich's post 2.1.3 release breakage was the
culprit.

I can't help fix things if I don't know its broken.  That is why people
doing regular builds, even if that aren't as skilled as Dan, or David, or
Gary or Franz would surely help.

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: Roles for distributions

[Gary Thomas]

On 11-Sep-2000 Hendricks, Kevin wrote:
>
> Hi David,
>
>>      Kevin, I think that your initial message was much more hostile
>>than necessary.  It did not come across as PowerPC Linux volunteers need
>>more help.  Instead of attacking everyone who had a negative reaction to
>>your original note, maybe you should consider that it was phrased poorly.
>>You have jumped down my throat enough times when I came across differently
>>than I had intended.
>>
>>David
>
> Yes, you are absolutely correct.  Hindsight is 20/20.
>
> I still don't read my note as "hostile" to distribution individuals or
> developers but enough people have and continue to do so.  That means what I
> meant to say and what they read are not the same thing.
>
> Unfortunately, empiricial evidence is nice but after the fact! ;-)  I just
> don't like things becoming personal and still don't.  It just isn't needed.
>
> I tried to correct my "error" by saying that it was never my intent to
> imply or state that individuals do not contribute enough.  It was to say
> the toolchain is important and we are basically down to Franz and he
> doesn't even have glibc checkin privleges.
>
> I still think the distributions could free up someone even part time now
> that Gary Thomas has gone away and should. They are the only ones making
> any money and the only ones that have the financial resources.  The rest of
> us just volunteer our time.
>

To [mis]quote Mark Twain, "the tale of my departure is greatly exagerated".

Yes, I have been silent, but not ignorant.  I read these lists constantly,
and try and keep up.  Although I do not currently have the capacity [mostly
time] to contribute much, I am ever watching and kibitzing.

I fully understand the plight all of us face.  Linux on the PowerPC is a
force.  It should be a larger force.  But for the lack of corporate resources
and commitments, it will remain only a force.  This will change, I fervently
hope.  IBM has recently made some good movement in this direction.  Red Hat
also has a number of projects which involve Linux on PowerPC.  I do what
I can constantly to push this.  I know that real work is also taking place
at a number of other sites.

Today, there is no single entity out there that can support everything that's
required for Linux on PowerPC.  Many companies and certainly individuals work
at it.  None should be faulted for their efforts, nor for their inability to
apply more resources to efforts we probably all agree are worthwhile.

Bickering and back-stabbing [no stone throwing by me] are bad for all.

Remember, we are in this together, competitors and friends alike.  Let's
act that way and make Linux on PowerPC a huge force in the world :-)

--
Gary Thomas - gdt@linuxppc.org - gthomas@redhat.com


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

Re: Roles for distributions

[Hendricks, Kevin]

Actually,

This was all a big conspiracy by myself, Dan, Daniel, and David just to see
if we could get you to respond!!!!!    ;-)

Glad to hear you are not gone!

Kevin


>To [mis]quote Mark Twain, "the tale of my departure is greatly exagerated".
>
>Yes, I have been silent, but not ignorant.  I read these lists constantly,
>and try and keep up.  Although I do not currently have the capacity [mostly
>time] to contribute much, I am ever watching and kibitzing.

--
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: Roles for distributions

[Todd Lipcon]

Note that I'm replying to the original note rather than the long tirade of
resultant flames :)

Anyway- I am a fairly decent C, C++, and Java programmer. I'd love to be
able to contribute to the Linux/PPC effort, however I don't even know
where to start. Most of the projects that are large enough to actually
need patches to run correctly on PPC are so large that they are inherently
intimidating to one not familiar with the source. Do any of you veteran
hackers have suggestions for the contribution-newbie? What projects are in
the largest need of help, and how can someone who has never seen their
source get into the flow of helping out?

Thanks "oodles",
-Todd

+---------------------------------------------------------------+
| Perl CGI scripting                    email tlipcon@csoft.net |
| Web Design                            email tlipcon@csoft.net |
|        My Current Projects:                                   |
| NewsWire				www.squirrelsw.com	|
| JavaGroove				www.squirrelsw.com	|
+---------------------------------------------------------------+

On Sun, 10 Sep 2000, Kevin B. Hendricks wrote:

>
> Hi,
>
> Since I am already on my soapbox, there is one other important issue this
> body could address.
>
> Why aren't the current PPC linux distributions putting full time developers
> on key projects?
>
> Right now without Franz Sirl ppc would be complete shit when it comes to
> tools and things.  He not only keeps up gcc for powerpc, without his help
> glibc-2.2 and binutils would not be working at all.
>
> Where are all the distribution developers???????????
>
> Why don't SuSE, YellowDogLinux, LinuxPPC, etc have anyone regularly
> contributing to the toolchains (checking builds, reporting and fixing bugs,
> etc)?  We (ppc) should have somebody with commit priviledges on gdb,
> binutils, and glibc 2.2 helping and supporting things (and GeoffK doesn't
> count since he is simply too busy).
>
> In SuSE's defense, their x86 developers are shouldering most if not all of
> the work for glibc 2.2.  Same goes for redhat.  But no one is supporting
> ppc basically but Franz.
>
> And what about the other key projects: mozilla, helix/gnome, KDE, galeon,
> apache, etc?
>
> Seriously, if the toolchain stops working for ppc (gcc, gdb, glibc, etc) we
> are sunk...period.
>
> Gary Thomas used to help with these things but I haven't seen a post from
> him in a long time.
>
> This is something we really need to fix if we are ever going to be in the
> big leagues.
>
> Again my 2 cents,
>
> Kevin
>
> (and I do try to help out with glibc and things when I have time).
>
>
>
>


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

Re: Roles for distributions

[Dan Foster]

Hot Diggety! Todd Lipcon was rumored to have wrote:
>
> Anyway- I am a fairly decent C, C++, and Java programmer. I'd love to be
> able to contribute to the Linux/PPC effort, however I don't even know
> where to start. Most of the projects that are large enough to actually
> need patches to run correctly on PPC are so large that they are inherently
> intimidating to one not familiar with the source. Do any of you veteran
> hackers have suggestions for the contribution-newbie? What projects are in
> the largest need of help, and how can someone who has never seen their
> source get into the flow of helping out?

Suggestion.... learn the kernel before you tackle arch-specific issues.

Alessandro Rubini's book (_Linux Device Drivers_, wasn't it?) is *excellent*
for a nice introduction to the kernel from a kernel programmer's perspective.

Also look through any UNIX OS textbooks. I love my copy of the Vahalia book
because it covers all areas of the UNIX kernel well, and treats us to a case
by case comparison of how several different UNIX OSes handles it. Digital UNIX,
AIX, FreeBSD, Solaris, ...

Then, usually very helpful to also just read (and re-read and re-read even
more) various kernel source files... a couple key directories. It may be
about 110 MB uncompressed, but sheer majority of that is for device drivers.
The actual kernel core stuff is *MUCH* smaller.

Try writing some kernel modules, like ones in the Rubini book, even if they're
'dummy modules', just so you get a feel for things.

Then when you're feeling more comfortable with the UNIX kernel itself -
then start digging into all the files in arch/ppc/* as well as read
linuxppc-dev (or the online archives) to get an appreciation of arch-specific
issues.

Endianness is one *big* one - lots of times, people in x86 world will release
drivers that assumes the x86 endianness without thinking to use macros that
will automagically ensure correct byte order for whatever platform you use.
This issue bites the other platforms, too.

Then of course, we have the PPC hardware stuff. OpenFirmware docs are *great*
to read... looking at how the boot loader does it will tell you a thousand
things about how things actually *happen* in the dark ages before a kernel is
booted. It's a little work, but you can usually eventually manage to dig up
hardware tech docs for various chips, so that one knows how to manipulate them.
For example, the Motorola web site has PDF files on the CPU and the memory
controller (ie MPC106 aka "Grackle").

IMO, if you can understand a boot loader, you've probably taught yourself a lot
of the concepts needed to understand hardware at a low level, and how/why
the kernel is structured the way it does for the arch-specific stuff. It's also
(IMO) one of the most interesting pieces of software, too.

And so on... lots of stuff that you can indeed do. I've been doing all of
the above (why dispense advice if one doesn't take one's own advice, eh?) for
a while now and it's been a rather pleasant, interesting, and fun journey
into the innards of Linux for the PowerPC family.

-Dan

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

Re: Roles for distributions

[Franz Sirl]

At 21:04 11.09.00, Hendricks, Kevin wrote:
>If people regularly do builds, and do "make check" then errors will appear
>near in time to recent patches and things (sort of like Linus's only give
>me small patches approach) that can tell the maintainers that something is
>amiss.  That makes any bugs much easier to find.  My last glibc 2.1.3 patch
>was found by doing regular builds to compare different glibc releases and
>it was easy to see that Ulrich's post 2.1.3 release breakage was the
>culprit.
>
>I can't help fix things if I don't know its broken.  That is why people
>doing regular builds, even if that aren't as skilled as Dan, or David, or
>Gary or Franz would surely help.

Actually the really time consuming part is hunting down the bugs, but
regular builds certainly help to narrow down the time a bug happened "it
passed all the tests yesterday, but today it fails test XYZ". I doing
nearly daily builds of the GCC mainline, and sporadic builds of binutils
(which usually remains stable for Linux/PPC currently) and glibc (where the
2.1 branch is more or less dead, and the 2.2 stuff slowly reaches stability).

Bug hunting is usually quite easy for bugs during "make check", the really
nasty stuff are things like "program XYZ doesn't behave like before if run
on glibc-2.2", especially if a lot of large shared libraries are involved.
Eg. I have now spent 3 or 4 evenings trying to track down the "gdm doesn't
work on a xf4 compiled against glibc-2.2 headers" reported by Jack, easily
reproducible with the gtk+ "tree" example running as root. Still I didn't
get to far tracking the bug down, cause I'm wading in megabytes of xf4 and
gtk+ code, I nearly know nothing about :-(. It "feels" like a bug in
glibc's str*/mem* macros/functions, but I haven't got to a point where I
can observe the bug and act on it.
_That_ is the most annoying part where some help is most welcome :-).
Unfortunately it requires quite some knowledge :-( and the ability to cope
with using beta software for main components like glibc.

Franz.


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

Re: Roles for distributions

[Todd Lipcon]

Wow, thanks man- that was quite a bit of advice :) I'll get to reading
some of those things. I've actually written a little patch for the
mouse-button-emulation so it worked the way I like and an ip_masq
module... other than that, I'm kernel-clue-less :) I'll go play with it
right now...

*bong as it goes reboot!*

-Todd

+---------------------------------------------------------------+
| Perl CGI scripting                    email tlipcon@csoft.net |
| Web Design                            email tlipcon@csoft.net |
|        My Current Projects:                                   |
| NewsWire				www.squirrelsw.com	|
| JavaGroove				www.squirrelsw.com	|
+---------------------------------------------------------------+

On Mon, 11 Sep 2000, Dan Foster wrote:

>
> Hot Diggety! Todd Lipcon was rumored to have wrote:
> >
> > Anyway- I am a fairly decent C, C++, and Java programmer. I'd love to be
> > able to contribute to the Linux/PPC effort, however I don't even know
> > where to start. Most of the projects that are large enough to actually
> > need patches to run correctly on PPC are so large that they are inherently
> > intimidating to one not familiar with the source. Do any of you veteran
> > hackers have suggestions for the contribution-newbie? What projects are in
> > the largest need of help, and how can someone who has never seen their
> > source get into the flow of helping out?
>
> Suggestion.... learn the kernel before you tackle arch-specific issues.
>
> Alessandro Rubini's book (_Linux Device Drivers_, wasn't it?) is *excellent*
> for a nice introduction to the kernel from a kernel programmer's perspective.
>
> Also look through any UNIX OS textbooks. I love my copy of the Vahalia book
> because it covers all areas of the UNIX kernel well, and treats us to a case
> by case comparison of how several different UNIX OSes handles it. Digital UNIX,
> AIX, FreeBSD, Solaris, ...
>
> Then, usually very helpful to also just read (and re-read and re-read even
> more) various kernel source files... a couple key directories. It may be
> about 110 MB uncompressed, but sheer majority of that is for device drivers.
> The actual kernel core stuff is *MUCH* smaller.
>
> Try writing some kernel modules, like ones in the Rubini book, even if they're
> 'dummy modules', just so you get a feel for things.
>
> Then when you're feeling more comfortable with the UNIX kernel itself -
> then start digging into all the files in arch/ppc/* as well as read
> linuxppc-dev (or the online archives) to get an appreciation of arch-specific
> issues.
>
> Endianness is one *big* one - lots of times, people in x86 world will release
> drivers that assumes the x86 endianness without thinking to use macros that
> will automagically ensure correct byte order for whatever platform you use.
> This issue bites the other platforms, too.
>
> Then of course, we have the PPC hardware stuff. OpenFirmware docs are *great*
> to read... looking at how the boot loader does it will tell you a thousand
> things about how things actually *happen* in the dark ages before a kernel is
> booted. It's a little work, but you can usually eventually manage to dig up
> hardware tech docs for various chips, so that one knows how to manipulate them.
> For example, the Motorola web site has PDF files on the CPU and the memory
> controller (ie MPC106 aka "Grackle").
>
> IMO, if you can understand a boot loader, you've probably taught yourself a lot
> of the concepts needed to understand hardware at a low level, and how/why
> the kernel is structured the way it does for the arch-specific stuff. It's also
> (IMO) one of the most interesting pieces of software, too.
>
> And so on... lots of stuff that you can indeed do. I've been doing all of
> the above (why dispense advice if one doesn't take one's own advice, eh?) for
> a while now and it's been a rather pleasant, interesting, and fun journey
> into the innards of Linux for the PowerPC family.
>
> -Dan
>
>
>


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

Re: Roles for distributions

[Michel Dänzer]

Todd Lipcon wrote:

> Anyway- I am a fairly decent C, C++, and Java programmer. I'd love to be
> able to contribute to the Linux/PPC effort, however I don't even know
> where to start. Most of the projects that are large enough to actually
> need patches to run correctly on PPC are so large that they are inherently
> intimidating to one not familiar with the source.

Don't let yourself be scared off by the size of something. In every project no
matter how big (provided that they were designed sensibly at least to some
degree ;), there are small, self-contained problems which can be solved rather
easy and quickly.

I think it's better to pick something which doesn't work and you would like it
to, then start digging into it instead of looking for 'the right one which
needs help the most' where you aren't in it with your heart and soul. :)


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: Roles for distributions

[Geert Uytterhoeven]

On Mon, 11 Sep 2000, Todd Lipcon wrote:
> Anyway- I am a fairly decent C, C++, and Java programmer. I'd love to be
> able to contribute to the Linux/PPC effort, however I don't even know
> where to start. Most of the projects that are large enough to actually
> need patches to run correctly on PPC are so large that they are inherently
> intimidating to one not familiar with the source. Do any of you veteran
> hackers have suggestions for the contribution-newbie? What projects are in
> the largest need of help, and how can someone who has never seen their
> source get into the flow of helping out?

Actually it's quite simple :-)

When you find out something doesn't work, you start brainwashing yourself that
you _will_ fix the problem. To obtain this goal, all possible tools and
methods you can imagine[*] are allowed and even strongly encouraged (using a
debugger, adding debug code, using a serial terminal, disassembling, ...).

I can guarantee you that it will feel _very_ good when you finally nail the
bug (the longer it takes and the harder it was, the better it feels :-). And
you'll learn a lot while investigating the problem and studying the system
you're fixing. But still, the more you learn, the more you'll realize that
there's lots of stuff left that you don't understand :-)

I wish you good luck!! And don't forget we all started as innocent babies not
knowing anything about e.g. Linux internals...

Gr{oetje,eeting}s,

						Geert

[*] Ever dumped stack frames by flashing the screen in 8 colors (each color
    contains 8 bit of information)? I did last week :-)
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: Roles for distributions

[Sriranga Veeraraghavan]

> "Kevin B. Hendricks" wrote:
>
> > Why aren't the current PPC linux distributions putting full time developers
> > on key projects?
>
> So, do you actually _pay_ for any of these distributions and their
> available support or subscriptions, or are you just one of the slackers
> the expects someone else to pay for your free software?

<rant>

Uh, I think that you are picking on the wrong person. Kevin Hendricks
is one of the most devoted developers of Linux for the PPC platform.
He has been instrumental in the developement of the JDK for LinuxPPC
and has contributed heavily to Xpmac and XFree development on PPC.

I don't know if Kevin buys his distro's, but as someone who has bought
every LinuxPPC release from R3 forward along with YDL Champion Server
and SusePPC (at a big discount), I think that Kevin's remarks are not
unfounded. If LinuxPPC is to stay viable, then the distributions ought
to at least participate in the development of the tools.

That said, I understand that LinuxPPC is understaffed at the moment
given certain unfortunate occurances in the life of Jason Haas (get
well soon!).

</rant>

> All of the distributions you mention will support you.....well,
> maybe not any more....

I have never need much support from a vendor, and I don't really
expect any support from LinuxPPC, but everytime I have dealt with
them, they have been extermely friendly and helpful.

I hope that doesn't change because of a single rant email...

----ranga

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

Re: Roles for distributions

[Graham Stoney]

Michel =?iso-8859-1?Q?D=E4nzer?= writes:
> I think it's better to pick something which doesn't work and you would like it
> to, then start digging into it instead of looking for 'the right one which
> needs help the most' where you aren't in it with your heart and soul. :)

This is good advice, but it's only half the problem -- and it's the relatively
easy half at that.  I found that kernel profiling for ppc in v2.2 didn't work
for me (didn't work at all in fact), so I fixed it and published the patch all
over the place, including at:
    http://members.nbci.com/greyhams/linux/patches/2.2/profile.patch

However, the intractible part is getting my fix into the official sources.
I'm not working for a distribution; maybe it would be easier if I was.
I'm just a user who doesn't want to have to keep reapplying my patches every
time I get a new release, and would like to fix stuff properly so the next
guy who comes along has an easier time than I did.  It's not at all clear how
to get fixes in even once you've dug up the solution.

Regards,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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

Getting patches in (was: Re: Roles for distributions)

[Michel Lanners]

Hi all,

On  12 Sep, this message from Graham Stoney echoed through cyberspace:
>> I think it's better to pick something which doesn't work and you would like it
>> to, then start digging into it instead of looking for 'the right one which
>> needs help the most' where you aren't in it with your heart and soul. :)
>
> This is good advice, but it's only half the problem -- and it's the relatively
> easy half at that.  I found that kernel profiling for ppc in v2.2 didn't work
> for me (didn't work at all in fact), so I fixed it and published the patch all
> over the place, including at:
>     http://members.nbci.com/greyhams/linux/patches/2.2/profile.patch
>
> However, the intractible part is getting my fix into the official sources.

I found this to be a major pain as well.

> I'm not working for a distribution; maybe it would be easier if I was.
> I'm just a user who doesn't want to have to keep reapplying my patches every
> time I get a new release, and would like to fix stuff properly so the next
> guy who comes along has an easier time than I did.  It's not at all clear how
> to get fixes in even once you've dug up the solution.

I agree that this seems to be a major problem of the PPC Linux port at
this time. It is not clear at all how the flow of patches from user
contribution, to PPC kernel tree, to Linus' tree is happening... and
unfortunately, too often, it just isn't happening.

I've sent lots of patches to those people I thought were 'platform
maintainers', only to notice weeks or months later, that a few kernel
releases later they were not in there. Patches just disappeared into the
void, no reaction at all. _That_ is frustrating. If patches are refused
for some reason, then fine, I've not done my homework, let me try again.
But without any reaction, I haven't even gotten that chance.

Anyway, the best advice I can give you right now is:

- post patches here
- post patches on sourceforge to the ppclinux project
- send patches to Paul Mackerras (PowerMac stuff), or Cort Dougan
  (general PPC stuff), but don't expect any reaction. It does help,
  though, sometimes.

At the moment, BenH is actively tracking the patches on sourceforge. I
do jope others will follow his example, and I also hope that more people
will use sourceforge. Try it out, it's really esay ;-)

Cheers (I mean it ;-)

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: Getting patches in (was: Re: Roles for distributions)

[Jeff Garzik]

Michel Lanners wrote:
> I agree that this seems to be a major problem of the PPC Linux port at
> this time. It is not clear at all how the flow of patches from user
> contribution, to PPC kernel tree, to Linus' tree is happening... and
> unfortunately, too often, it just isn't happening.

Cort posted the following on linux-kernel, this past Thursday.   (Cort
quoted with ">", Till Straumann quoted with "}")

> } Can somebody please tell me, who is currently maintaining
> } arch/ppc?
> }
> } The link
> }
> } http://www.ppc.kernel.org/
> }
> } in the MAINTAINERS file is dead.
> }
> } Regards, Till
>
> It's unmaintained right now.  The www.ppc.kernel.org site is gone.
> Take a look at www.fsmlabs.com/linuxppcbk.html for the PPC tree.
> -

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

Re: Getting patches in (was: Re: Roles for distributions)

[Benjamin Herrenschmidt]

>I agree that this seems to be a major problem of the PPC Linux port at
>this time. It is not clear at all how the flow of patches from user
>contribution, to PPC kernel tree, to Linus' tree is happening... and
>unfortunately, too often, it just isn't happening.
>
>I've sent lots of patches to those people I thought were 'platfor
>maintainers', only to notice weeks or months later, that a few kernel
>releases later they were not in there. Patches just disappeared into the
>void, no reaction at all. _That_ is frustrating. If patches are refused
>for some reason, then fine, I've not done my homework, let me try again.
>But without any reaction, I haven't even gotten that chance.

That problem is not specific to the PPC port, how many times patches are
sent to Linus without an answer, but without anything happening neither.

The fact is that there are about 4 or 5 people from this list who can
feed things in the main PPC tree (Paul, Cort, Geert, Dan, me, I may be
missing others) and Linus/Alan usally get patches from Paul or Cort. Now
that Cort is "away", we rely mostly on Paul to push patches to Linus.

The latest batch of PPC patches sent by Paul, AFAIK, didn't appear in
Linus test8 (was it rejected ? I don't know)

That's one of the reasons why we have this sourceforge site now. Pleast
post your patches there. They may or may not get merged, but at least
they will be available in a central position and won't be forgotten.

>At the moment, BenH is actively tracking the patches on sourceforge. I
>do jope others will follow his example, and I also hope that more people
>will use sourceforge. Try it out, it's really esay ;-)

Well, a bit less actively for now, I want things to stabilize a bit and
get merged with Linus before feeding the tree with new patches (and I
have my own patches waiting too). Don't worry if you don't see anything
happening on the sourceforge site for the upcoming days, that doesn't
mean it's dead.

Ben.


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

Re: Roles for distributions

[mberglund]

On Tue, 12 Sep 2000, Graham Stoney wrote:

>
> Michel =?iso-8859-1?Q?D=E4nzer?= writes:
> > I think it's better to pick something which doesn't work and you would like it
> > to, then start digging into it instead of looking for 'the right one which
> > needs help the most' where you aren't in it with your heart and soul. :)
>
> This is good advice, but it's only half the problem -- and it's the relatively
> easy half at that.  I found that kernel profiling for ppc in v2.2 didn't work
> for me (didn't work at all in fact), so I fixed it and published the patch all
> over the place, including at:
>     http://members.nbci.com/greyhams/linux/patches/2.2/profile.patch
>
> However, the intractible part is getting my fix into the official sources.
> I'm not working for a distribution; maybe it would be easier if I was.
> I'm just a user who doesn't want to have to keep reapplying my patches every
> time I get a new release, and would like to fix stuff properly so the next
> guy who comes along has an easier time than I did.  It's not at all clear how
> to get fixes in even once you've dug up the solution.

You guys are discussing some of the issues our group (of two) would like
to rectify. This is an on-going problem, and I think part of it has to do
with the fact that there is not a "non-commercial" distribution going. We
have been working on a system which offers a bunch of admin functionality
that the commercial guys will probably never do, because it will take
revenue away from them. These guys are not going to implement any idea
that might cause them a little damage, even if the idea is good. At
apachecon in orlando last year a SUSE rep said that the kind of update we
were suggesting would cause cd sales to go down, so there was "no way" it
would ever get implemented. To easy to do updates over the web.

If we can get this thing off the ground it will serve as a central place
for many of the patches and system ideas that people would like to see in
some of the other distros, but without the problem of sending a little
patch to Linus or Alan, here and there. We can get our acts together as a
group, and the submit more complete, better tested stuff, and this is only
in the kernel. Imagine how nice it would be to keep the userland software
in sync with the system changes. some of the distro's do a good job of it,
but why can't a group of individuals do it like FreeBSD does?

It just seems to me that a group of people who actually care about the
system can write a better system than most of the paid professionals out
there (not to knock the paid professionals).

Just a thought,
Matt
matt@fxp.org


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

Re: Getting patches in (was: Re: Roles for distributions)

[Dan Malek]

Benjamin Herrenschmidt wrote:

> That problem is not specific to the PPC port, how many times patches are
> sent to Linus without an answer, but without anything happening neither.

This is sometimes the problem we even have with patches.  Although I will
put them in, they don't make it into the Linus tree.  Other times,
Linus will pick up part of a patch because it is generically a
good thing, and then we have to re-work what is left in the PPC port.

> The latest batch of PPC patches sent by Paul, AFAIK, didn't appear in
> Linus test8 (was it rejected ? I don't know)

I had breakfast with Cort this morning.  One of the major issues on
the table is creating a stable 2.4 release.  There are lots of patches
sitting in limbo right now, and unless they can be proven to fix a
specific stability bug, they may not make into the first real 2.4.


> That's one of the reasons why we have this sourceforge site now. Pleast
> post your patches there. They may or may not get merged, but at least
> they will be available in a central position and won't be forgotten.

Many of us have been talking about a single point for posting patches.
There are several challenges to updating the sources, aside from adapting
them to the Linus tree.  I get lots of patches from people.  Some I
can deal with directly and some require the knowledge of others.  Among
the list of people Ben mentioned, we sometimes have to work together.
One of the greatest challenges of the PowerPC port is the different
processors and different board types.  This is unlike any other port.
When someone sends me a patch for the MPC823, I have to test this with
other MPC8xx processors as well as desktop/notebook PowerPC systems.
This is very tedious, and although it may look obvious to the originator
of the patch that it won't affect anything else, I have broken the tree
enough times to know I had better check everything.  It seems patches
come from several people for a common feature area, because of dicussions
on the mailing lists.  When we get these, they have to be merged and
sorted out.  Maintaining the source trees (of any kind) is a very time
consuming processes, and while it may have taken only a day or less to
make the code update work on one particular platform of interest, it
will take me days to merge it with all of the other patches, resync
against the  source trees, test on a variety of platforms and ensure the
update went smoothly.  There is nothing worse than making a 2AM update,
to return later in the morning faced with an inbox full of bitch
messages :-).

Hopefully, posting patches in a common place will allow people to see
what others have done, and some of this merging/testing can be done
earlier in the cycle.  This would be a great help.  Also, updates that
are generally useful to lots of people have a higher priority and are
more likely to find their way quickly into the source trees.  Something
that is unique to an individual, requires lots of code changes, or
adversely affects others will find it very slow.  Smaller, more frequent
patches are good :-).


> Well, a bit less actively for now, I want things to stabilize a bit and
> get merged with Linus before feeding the tree with new patches (and I
> have my own patches waiting too).

There are lots of patches waiting.  Cort and I discussed some solutions
to having both a stable tree and a single place to apply patches for
further testing.  He is going to discuss some BK features with Larry
(not new ones, just if certain combinations of existing ones) that will
help us do this.

> ..... Don't worry if you don't see anything
> happening on the sourceforge site for the upcoming days, that doesn't
> mean it's dead.

Or anywhere else....as I said there are lots of patches pending, waiting
for the stable 2.4 to happen and 2.5 to open up.



	-- Dan

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

Re: Roles for distributions

[Michael Schmitz]

> > However, the intractible part is getting my fix into the official sources.
> > I'm not working for a distribution; maybe it would be easier if I was.
> > I'm just a user who doesn't want to have to keep reapplying my patches every
> > time I get a new release, and would like to fix stuff properly so the next
> > guy who comes along has an easier time than I did.  It's not at all clear how
> > to get fixes in even once you've dug up the solution.
>
> You guys are discussing some of the issues our group (of two) would like
> to rectify. This is an on-going problem, and I think part of it has to do
> with the fact that there is not a "non-commercial" distribution going. We

Please clarify. I thought Debian qualifies as a non-commercial
distribution?

I don't think any of this really is about commercial vs. volunteer
interests. Rather mainstream vs. oddball architecture issues.

	Michael


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

Re: Roles for distributions

[mberglund]

On Tue, 12 Sep 2000, Michael Schmitz wrote:

> > > However, the intractible part is getting my fix into the official sources.
> > > I'm not working for a distribution; maybe it would be easier if I was.
> > > I'm just a user who doesn't want to have to keep reapplying my patches every
> > > time I get a new release, and would like to fix stuff properly so the next
> > > guy who comes along has an easier time than I did.  It's not at all clear how
> > > to get fixes in even once you've dug up the solution.
> >
> > You guys are discussing some of the issues our group (of two) would like
> > to rectify. This is an on-going problem, and I think part of it has to do
> > with the fact that there is not a "non-commercial" distribution going. We
>
> Please clarify. I thought Debian qualifies as a non-commercial
> distribution?

Yes. I conceed that debian is a non-profit organization. I would argue
that there is a great many things about them that are 'commercial-like'. I
have always wondered why one of the Linux distro's has not taken a look at
the BSD method of system updates. Each one, (I have asked four, with SUSE
being the most blatant) has said no. I am forced to believe that this is
amoney issue. I will also conceed that I have NOT asked Debian, but I am
not sure I like thier gpl-centric way of doing things.

Don't misunderstand, I do respect (and even believe in) the gpl, for
ceratin situations. But I will not limit myself to only this type of
software.


> I don't think any of this really is about commercial vs. volunteer
> interests. Rather mainstream vs. oddball architecture issues.

I would argue that it is both. No doubt, ppc gets a short stick compared
to intel. So does S390, and probably ARM.

But the OS's have yet to be built with some of the features that a small
group of us would like. The only answer I can see is to do the work
myself, and hope some of you guys will come along. The commercial
guys(specificly SUSE, slack, Redhat, and Corel) don't want to talk about
what we want to do. And it's a shame, because it will make updating
systems one hell of a lot easier than they are now.

It also seems like the lost art of making an OS the SAME from platform to
platform is just that, LOST. This is another lofty goal in the project.

I mean, it is hard enough to learn a new hardware platform, without having
to learn a new version of linux(or unix, for that matter). And even redhat
has not been able to make thier distro the same from platform to platform.

I'm of my soapbox now. If you get it, I hope you'll help with what we are
doing.

Later,
Matt

Unix is best described as an old, sturdy tree.
It is well structured, always growing, and has passed the test of time.


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

Re: Roles for distributions

[Geert Uytterhoeven]

On Tue, 12 Sep 2000, mberglund wrote:
> It also seems like the lost art of making an OS the SAME from platform to
> platform is just that, LOST. This is another lofty goal in the project.
>
> I mean, it is hard enough to learn a new hardware platform, without having
> to learn a new version of linux(or unix, for that matter). And even redhat
> has not been able to make thier distro the same from platform to platform.

With Debian being the only distribution that runs on all my boxes, I still
have to find the differences among Debian on the different platforms that are
not caused by actual differences in the hardware configuration.

FYI, I have experience with Debian on ia32, m68k, PPC, AXP and even MIPSEL.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: Roles for distributions

[Daniel Jacobowitz]

[CC list trimmed - that was silly]

<asbestos suit.  Again.>

On Tue, Sep 12, 2000 at 05:36:31PM -0400, mberglund wrote:
> Yes. I conceed that debian is a non-profit organization. I would argue
> that there is a great many things about them that are 'commercial-like'. I
> have always wondered why one of the Linux distro's has not taken a look at
> the BSD method of system updates. Each one, (I have asked four, with SUSE
> being the most blatant) has said no. I am forced to believe that this is
> amoney issue. I will also conceed that I have NOT asked Debian, but I am
> not sure I like thier gpl-centric way of doing things.
>
> Don't misunderstand, I do respect (and even believe in) the gpl, for
> ceratin situations. But I will not limit myself to only this type of
> software.

I don't understand you.  Debian does not have a GPL-centric way of
doing things - we have a definition of free software, which includes
BSD licences as much as it includes the GPL!

And what do you mean by "the BSD method of system updates"?  The "I
feel like rebuilding it all myself" method?  This has been argued to
death, and if you really do want to do it with Debian it is not
terribly difficult to do, but I fail to see it as a good idea.

> It also seems like the lost art of making an OS the SAME from platform to
> platform is just that, LOST. This is another lofty goal in the project.

The only ways in which Linux differs from platform to platform support
additional features or unavoidable differences - you aren't proposing
anything like a common endianness, or a common integer size, I hope?
As convenient as they may be, you cripple multiple architectures for
the sake of a few.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: Getting patches in (was: Re: Roles for distributions)

[Daniel Jacobowitz]

On Tue, Sep 12, 2000 at 02:49:06AM -0400, Jeff Garzik wrote:
>
> Michel Lanners wrote:
> > I agree that this seems to be a major problem of the PPC Linux port at
> > this time. It is not clear at all how the flow of patches from user
> > contribution, to PPC kernel tree, to Linus' tree is happening... and
> > unfortunately, too often, it just isn't happening.
>
> Cort posted the following on linux-kernel, this past Thursday.   (Cort
> quoted with ">", Till Straumann quoted with "}")
>
> > } Can somebody please tell me, who is currently maintaining
> > } arch/ppc?
> > }
> > } The link
> > }
> > } http://www.ppc.kernel.org/
> > }
> > } in the MAINTAINERS file is dead.
> > }
> > } Regards, Till
> >
> > It's unmaintained right now.  The www.ppc.kernel.org site is gone.
> > Take a look at www.fsmlabs.com/linuxppcbk.html for the PPC tree.

Is someone planning to step up and take over, then, officially?  Or is
Cort going to be back?

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: Getting patches in (was: Re: Roles for distributions)

[Paul Mackerras]

Benjamin Herrenschmidt writes:

> The latest batch of PPC patches sent by Paul, AFAIK, didn't appear in
> Linus test8 (was it rejected ? I don't know)

I sent a couple of patches to Linus plus several patches to the
maintainers of other parts of the kernel (ide, usb, fb drivers etc.)
No reply from Linus and the patches didn't go in.  That's pretty
standard. :-(

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

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

Re: Roles for distributions

[Michel Dänzer]

mberglund wrote:

> > > It also seems like the lost art of making an OS the SAME from platform
> > > to platform is just that, LOST. This is another lofty goal in the
> > > project.
> > >
> > > I mean, it is hard enough to learn a new hardware platform, without
> > > having to learn a new version of linux(or unix, for that matter). And
> > > even redhat has not been able to make thier distro the same from
> > > platform to platform.
> >
> > With Debian being the only distribution that runs on all my boxes, I still
> > have to find the differences among Debian on the different platforms that
> > are not caused by actual differences in the hardware configuration.
>
> Well, the way you phrased this helps my point(and I am assuming that is
> what you intended). This is exactly one of the big beefs my little band
> has with the linux population right now. We hope to fix help fix it, want
> to help?

Please elaborate on this, I'm curious how you intend to fix the hardware
differences. ;)


> And if debian is perfect across all the platforms, great! The update
> system is still not what we want. And if you try the other, you might be
> suprised at how much you may like it. Go plop FreeBSD on a system ,and
> wait a few weeks, and then do an update. They have a _good_ idea. All I am
> saying is lets try to use it. There is not ONE good reason that I have
> found not to make the attempt.

I currently have no box to play with, but I also find the concept interesting.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

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

Re: Roles for distributions

[mberglund]

On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:

> On Tue, 12 Sep 2000, mberglund wrote:
> > It also seems like the lost art of making an OS the SAME from platform to
> > platform is just that, LOST. This is another lofty goal in the project.
> >
> > I mean, it is hard enough to learn a new hardware platform, without having
> > to learn a new version of linux(or unix, for that matter). And even redhat
> > has not been able to make thier distro the same from platform to platform.
>
> With Debian being the only distribution that runs on all my boxes, I still
> have to find the differences among Debian on the different platforms that are
> not caused by actual differences in the hardware configuration.

Well, the way you phrased this helps my point(and I am assuming that is
what you intended). This is exactly one of the big beefs my little band
has with the linux population right now. We hope to fix help fix it, want
to help?

And if debian is perfect across all the platforms, great! The update
system is still not what we want. And if you try the other, you might be
suprised at how much you may like it. Go plop FreeBSD on a system ,and
wait a few weeks, and then do an update. They have a _good_ idea. All I am
saying is lets try to use it. There is not ONE good reason that I have
found not to make the attempt. And we have a working system. No boot disks
yet, but a working system.

> FYI, I have experience with Debian on ia32, m68k, PPC, AXP and even MIPSEL.

Ohhh, Alpha!! Can I have one? :>

I only have experience with ia32, PPC, m86k, and S390 on hercules(with
a real S390 on the way). I have tried all of the major distributions and
some of the smaller ones. Rock has some good ideas, but it seems that they
are trying to use shell scripts for almost everything instead of the
make(8) system. Why not use a tool that is far more standard, and designed
for the purpose?

If you guys have some interesting ideas, we want to hear them. The
darkstar project can be found at darkstar.fxp.org. There is a _lot_ of
work to be done, and frankly, I am not the guy to do alot of it. There's a
buddy of mine who is far better programmer than I and has done much of the
work already. We need help. Get on the mailing lists, if you'd like.

The goals are straight forward, the mechanism is working. We need more
competent hands. And when Chris and I are satisfied, you'll get commit
privlidges directly to the tree. This is NOT simply a kernel project, but
an OS project. Keep that in mind.

Later,
Matt

Unix is best described as an old, sturdy tree.
It is well structured, always growing, and has passed the test of time.


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

Re: Roles for distributions

[mberglund]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2311 bytes --]


On Wed, 13 Sep 2000, Michel [iso-8859-1] Dänzer wrote:

> mberglund wrote:
>
> > > > It also seems like the lost art of making an OS the SAME from platform
> > > > to platform is just that, LOST. This is another lofty goal in the
> > > > project.
> > > >
> > > > I mean, it is hard enough to learn a new hardware platform, without
> > > > having to learn a new version of linux(or unix, for that matter). And
> > > > even redhat has not been able to make thier distro the same from
> > > > platform to platform.
> > >
> > > With Debian being the only distribution that runs on all my boxes, I still
> > > have to find the differences among Debian on the different platforms that
> > > are not caused by actual differences in the hardware configuration.
> >
> > Well, the way you phrased this helps my point(and I am assuming that is
> > what you intended). This is exactly one of the big beefs my little band
> > has with the linux population right now. We hope to fix help fix it, want
> > to help?
>
> Please elaborate on this, I'm curious how you intend to fix the hardware
> differences. ;)

HarHar. :) The hardware differences, thenselves, cannot be fixed,
obviously. But when one goes to use a tool, this tool should, _act_ the
same on each platform, taking in to account the hardware differences.

A not-so-good example could be the kernel debugger. Please, PLEASE, do not
remind me about the debate that just raged across l-k about this. The kmon
debugger is one such critter, used by the ppc(and others?) folks. The kdb
is used by the Intel folks.

WHY ARE THESE NOT BEING MERGED??? The same tool, the same functions, a
developer on one system could then move to the other with little or no
difficulty using the debugger. Whoa.... no learning curve for the
tools? Damn, what an Idea? Thank the NetBSD folks. Its theres. And it
_does_ make some sense(to me anyway).

> I currently have no box to play with, but I also find the concept interesting.

If you are willing to work. We may be able to help you with that
problem. But it would be difficult to test your stuff, but do you do
remote work?

Later,
Matt

Unix is best described as an old, sturdy tree.
It is well structured, always growing, and has passed the test of time.


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