Whoa... have you ever used gentoo???

I have.. built and ran a few servers with it. I very much dislike gentoo.. man it's a pain >.>.

Whatever performance gain LAMP gave me by spending the 52 minutes compiling every single piece of the LAMP platform.. did not outweigh that my debian servers were done in 10 minutes.

And as you listed... that's 11 different packages that need to be maintained for every app, and 11 different re-compiles every time it changes.

Android gets around this, with a cost. That's all I'm saying.

When it comes to these devices, the normal user doesn't want to have to recompile their stuff to work. That's why having just one person responsible for it in Android, and only one copy of it, makes it a bit more "user friendly" so to speak.

How many threads around here from users pointing to debian software and wanting it on their N900.. but have to wait for one of us with the know how to do it first?

Alas, there is a good chance they will repeat the same mistake all over again.

I've used Gentoo, and I prefer Debian. Spiking your server's CPU because you want to quickly update vim is stupid. Not to mention all the ridiculous waiting.

But that wasn't the point. The point was that even with Gentoo, it's not a significant problem, and many people use it. Recompiling is not difficult.

But Debian users don't have to care either. The package manager does everything. So the maintainers have to build each update 11 times. So what? I'm 99% sure that's automated, and the extra waiting and testing is insignificant compared to testing the patch itself.

The cost of recompiling is so small we might as well not care.

But Maemo is "only" a stripped down and reoptimized Debian. If the N900 ran the full Debian with Maemo as an addon, it would actually be that simple. It's not the recompiling that's the problem.

And even with all that, modifying Debian packages to work under Maemo on ARM, Solaris on Sparc, or BSD on a toaster is a piece of cake compared to porting absolutely anything to Android. Internal Android compatibility means nothing in this context.

Sort of.. it's only that simple because debian has already ported them to 11 different hardware profiles. Again.. a pain.

For Android, there would just be one package for all 11 hardware profiles. As soon as you update the main package, all 11 hardware profiles are updated as well. That's all.

I don't know if those 11 profile targets are "automated".. that would be kind of difficult.. considering they would either need 1 of each type of the hardware, or several vm's/emulators like scratchbox/qemu running and compile against them all.

Theoretically scripts could help automate this kind of thing.. but still - it's a real PITA. I was one that ported KDE4 to the N810 before there were proper ARM deb's available for it.

Really.. it sucked. Horrifically.

This is _exactly_ what the PalmOS5 engineers once said to us*. Guess what? PalmOS died even before a new architecture other than ARM appeared in the pipeline. And this was before ARM positioned itself as the smartphone architecture of choice.

Guess what? Android will be dead and most of its applications will be useless by the time the first non-ARM phone appears.

Part of the reason for that is that most of the useful apps will use the NDK no matter whatever Google says, since C it's still the most portable and efficient, specially for GL apps.

*The irony is that some PalmOS engineers now work in Google Android...

I won't argue speculation of where Android will or won't be... it doesn't negate the fact of how it's designed to work.

It's a good theory... so far un-used or tested it looks like though.. I'm going through android phone processors and they are all ARM to this point that I can find. So ultimately, doesn't matter at this moment in time.

However, if what this guy says is right... we could be in for a small pain in the Maemo community.

Apps developed specifically for ARM Maemo will start needing at least 2 packages each.

I might be missing the point, but... the autobuilder already (routinely and by default) builds ARM AND X86 versions of packages.

Oh.. well.. OK.

Why? What purpose does x86 packages serve? Especially now that MADDE will run software directly to an N900... and they plan to have a Virtual Device working too.

X86 packages are the ones you are running in the SDK (to which MADDE, combined with an emulator, will, potentially, in time, be an alternative to).

Well, ok.. I figured you'd just everything through the emulator or scratchbox. Guess I was mistaken - looking through the repo's I do see 2 packages per software.

But now lets say we get Maemo Intel Atom devices.. this will eliminate the need for scratchbox for development for the Atom devices. They would be straight x86 packages. So a developer writes himself some software or utility and puts it into the maemo repositories. Why would he care or bother to compile it for Arm? Who else would do this for the arm guys? Is a -src package required from dev's to upload to Maemo repo's?

Would it be a requirement for a developer to make both ARM and x86 packages even if he just cares about the x86 platform? Will we have dedicated "ARM Package maintainers" and "x86 package maintainers" that will take an app and port it for us?

Now.. those with Atoms have access to XYZ software in "maemo-extras" but not the ARM/N900 users. Confuzzling =-\. Same for the other way around if MADDE gets to the point you say.. no longer requiring x86 packages for the ARM's.

Anyway.. it's not that I particularly care.. I'm sure someone, somewhere, will grab the x86 or ARM package and recompile it for the other if someone requests it and the developer doesn't want to.. or I'll do it myself (assuming open source, and i want it).. This was just what I was talking about. Different packages, different hardware.