pdaxrom now speedy...

[scoutme]

now that some speed problem are solved, we should compile a lot of stuff that didn't work properly before:

Gameboy Advance SDL emulator
Mame
dgen

any try?

[amrein]

Before, there is a few bugs to resolve. And a test of pdaXrom compiled with uclibc for even faster and smaller distro is certainly another step.

[scoutme]

ok, let's see those as final release requests

[CoreyC]

amrein's got the right idea...

You aren't going to see allot of user submitted ipks until the final version of the rom/sdk is out.  So many changes are being made to the rom right now that it would be a waste of time.

These guys are doing amazing things with the rom right now.  It is great that the development is as heavy as it is.  Let them continue working on the rom and use RC3 if you want to use most of the apps in the unstable feed.

[ikm]

amrein's got the right idea...

You aren't going to see allot of user submitted ipks until the final version of the rom/sdk is out.  So many changes are being made to the rom right now that it would be a waste of time.

These guys are doing amazing things with the rom right now.  It is great that the development is as heavy as it is.  Let them continue working on the rom and use RC3 if you want to use most of the apps in the unstable feed.

amrein got it all wrong. The development is infinite. It is over only when the project itself is dead. So, do you suggest waiting for its death? Sure, in the end, life is just a waste of time. Just don't waste it before it's over!

I say, do not use RC3. Switch to RC5. Help the developers by using what they produce, loot for the bugs, make suggestions as you see it.

You are going to see alot of user submitted ipks. And the RC3 unstable is no more.

[scoutme]

...ikm is an open source fighter

love that guy, once more

[amrein]

There is a place in the bible where they talk about people building their house on sand instead of rock... or putting the plough before the oxem...

The big questions are:  "how many time before pdaXrom fondation become enough concrete" and "how people can get involved to speed its maturation". If you think that all is already good for everyday developer use than I can understand why you already want to build on it.

Concider me as a bricklayer having issue with the fondation and you will understand my first comment.

[scoutme]

both of you have your reason... the fact is that everyone knows how much can he risk in his development contribution. Spending time to make not completely recoverable steps that make the evolving software more usable and enjoyable while developing is not bad, as it makes realize the potential of the product and keep the audience listening and desiring to contribute. On the other hand, everyone should not loose the perception of his concrete needs, time and resources limits. The time/energy used in developing, when the developing actor is a community, has to absolutely fit, not forcing, the individual space, in a way  that makes "healthy" the community.
For example, if Amrein needs a stable and not data-risking zaurus etc etc, he will have a different risking level and a more sightfull behaviour, if put in comparison with the one who use his zaurus in a geekish manner. And there are a lots of gray tones between.

So, simply, Ikm's not loosing his time, since lots of people enjoy his work and use pdaXrom - helping development - also for his contributes, and Amrein is not in debit with the development process, since he's helping us to focus on some long term tasks and he's trying to make his contribution fit his own equilibrium, so that he will surely contribute widely without having to surrender.

...ehm...

[ikm]

There is a place in the bible where they talk about people building their house on sand instead of rock... or putting the plough before the oxem...

The big questions are:  "how many time before pdaXrom fondation become enough concrete" and "how people can get involved to speed its maturation". If you think that all is already good for everyday developer use than I can understand why you already want to build on it.

Concider me as a bricklayer having issue with the fondation and you will understand my first comment.

If you develop, you know the state of affairs yourself. The only major change happened since 1.0.5 from the developer point of view is the VFP.

If you just want some mock philosophy, do not consider yourself a mere bricklayer. Be a god. That would be much more productive. And much more to the point. If you want to cooperate with the people seeking similar goals -- do so. If you want to seek metaphors instead -- it's your choice.

It is indent that rules everything. If you want, you seek possibilities, if you do not, you seek for justification.

[Zuber]

Might I suggest Yoda for your Avatar (Oh wise one)

[amrein]

scoutme I agree with you and this was what I wanted to say. You said it with better words.

btw, to continue my main post, here is two links to uclibc. They have built debian over it. OE already support uclibc. Have a look on packages size:

http://people.debian.org/~andersee/uwoody/main/binary-i386/
http://www.uclibc.org/

[amrein]

... and Amrein is not in debit with the development process, since he's helping us to focus on some long term tasks and he's trying to make his contribution fit his own equilibrium, so that he will surely contribute widely without having to surrender.

yes.

ikm, I already read a lot of posts from you and I know you are a great guy. As I said, if you think that most pdaXrom parts are Ok than I can understand why you said that people should now build extra ipk if they want to.

At present, as a pdaXrom user (and exclusively pdaXrom) I experienced many X11 freezes with RC3 and RC5. My device is not usable because of this. I need to pull out the battery when the freeze occur because the keyboard doesn't work and clicking event are no more catched by applications (the mouse continue to follow the stylus thougth).

I posted those issues in another thread. I tested during several days the command line and I have no issue when not running X11 (I use apm to suspend). Other bugs I found are mainly related to applications and not to the base system. Most are already in pdaXrom bug tracker and other are related.

If you now add the fact that I'm waiting also for uclibc into pdaXrom, you should be able to understand how I see the wall thing. With ulibc pdaXrom should become as fast as light.

[ikm]

scoutme I agree with you and this was what I wanted to say. You said it with better words.

btw, to continue my main post, here is two links to uclibc. They have built debian over it. OE already support uclibc. Have a look on packages size:

http://people.debian.org/~andersee/uwoody/main/binary-i386/
http://www.uclibc.org/

What is actually the point in using uclibc? You gain a small bit of additional flash space (as currently /lib/libc-2.2.5.so weights only 1.1M) for the hassle of recompiling everything and running into potential software incompatibilities and other problems here and there throughout the entire lifetime. While it may be nice for floppy routers or other space-hugry small embedded systems, are there any merits for Zaurus?

[amrein]

Smaller package and runs faster. The only way to see it is to test it.

Sure, you are rigth about the potential added bugs.

amrein got it all wrong. The development is infinite. It is over only when the project itself is dead. So, do you suggest waiting for its death? Sure, in the end, life is just a waste of time. Just don't waste it before it's over!

I say, do not use RC3. Switch to RC5. Help the developers by using what they produce, loot for the bugs, make suggestions as you see it.

You are going to see alot of user submitted ipks. And the RC3 unstable is no more.

I never said to not get involved into pdaXrom. I said that it is a good idea to focus on annoying remaining bugs before using man power on other tasks. Having RC5 on your Z, testing, reporting, patching... is logicaly part of my suggestion. You apparently misunderstood my post since the beginning because you wrongly interpreted other following posts.

It's hard to see something like "amrein is wrong" because I feel it like an injustice. I don't need to be a god nor to be crusify.

[ikm]

Yes. Most packages are 10 /20 / 30 % smaller and they run faster.

Of course, I can be wrong and I will admit it if someone show me the way to the truth.

I just don't understand why should they be smaller. The macros should be pretty much the same, otherwise all that is left is just plain function calls. Pretty much nothing changes.

And comparing the .deb sizes from the uwoody link you posted with the official debian stable, I don't see much difference, though I haven't compared them all, just a handful

They may run faster, though the uclibc FAQ says that uclibc is not optimised for speed, but for size.

From the FAQ:

"Some of the space savings in uClibc is obtained at the cost of performance, and some is due to sacrificing features. Much of it comes from aggressive refactoring of code to eliminate redundancy."

I would like to add that I personally had no actual practice using uclibc, so take this words with a grain of salt. I am just speculating with a common sense approach. If to talk about practice, when I built some floppy routers back then, I used a Debian PIC version of glibc with only needed functions left, which were determined automatically by a script which was checking every executable

p.s. And please, stop altering your comments all the way. Just decide what to say before you post. I am not sure what I am replying to.