Roles for distributions

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/

"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/

"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/

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/

"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/

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/

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/

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/

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/

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/

Hi all,

On  12 Sep, this message from Graham Stoney echoed through cyberspace:

quoted

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/

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/

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/

On Tue, 12 Sep 2000, Graham Stoney wrote:

Michel =?iso-8859-1?Q?D=E4nzer?= writes:

quoted

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/

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/

quoted

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/

On Tue, 12 Sep 2000, Michael Schmitz wrote:

quoted

quoted

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/

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/

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/

mberglund wrote:

quoted

quoted

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/

On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:

On Tue, 12 Sep 2000, mberglund wrote:

quoted

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/

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

mberglund wrote:

quoted

quoted

quoted

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/