But I think PDA manufacturers aren't interrested in putting linux in their PDA when windows is still the #1 OS for the PC market .
Yet Palm, despite living in a Windows world, is still quite atop of the pile when looking at the market share. The problem here is more synchronizing. Mr PHB wants to have a PDA that syncs with Outlook, or possibly Lotus Notes.. If he can do that, he's mostly happy (oh well, being able ot install some funky presentation tools makes it even better, but that's what basically PDAs are all about.
In other words - we not only need an OS, but the tools on the host OS - unless, of course, we manage to get a PDA/micro laptop out that's a 'real' computer with all apps Mr PHB needs on it's own. The oQo is actually a step into that direction, and I don't think that idea is so bad.
The 'Tools around the PDA' is actually what keeps Palm in place, despite it being not a Windows PDA.
If we have the fool-proof 'tools around the pda' that make synchronizing a breeze, on PC and Mac (and of course, Linux), we might win with a market share, and of course, more enthusiasts. These tools must work on any PIM software on the Z, hence there's certainly ONE place where differences in the implementation would be disastrous. That's why I'm pretty allergic to KoPi, KaPi and how they're called (the other is usability on 320x240 screens - IMO KaPI and KoPI have been built to be used on Tosa).
However, the unification of PIM formats will not happen without some miracle, at least at the current point. IntelliSync does not really work with the MicroKDE pims.
So currently we have three issues:
a) apps
synchronizing
c) kernel/base components (like glibc, libstdc++)
d) graphics toolchain/widgetset
As pointed out before, both are equally important. If we can sync correctly, Joe User might forget about the apps a little (unless they're games - but there we have LibSDL, and they're not too badly bound to a GUI toolkit, except for some commercial stuff).
Addressing the apps: There are a few cool things in QTopia, as well as Opie. When looking at ZSI, there are some worthy things . GPE also got a few interesting things.
So in order to have a few cool commercial games, we at least need to have part c) somehow fixed. Sorry folks for open source development, but I haven't seen killer games from there (apart from Sokoban, but that's for people that also like ABAP and COBOL ).
This now leads to the bitter fact without a stable c), we will not likely get a stable and dependend d), which will in turn create problems with a), and sooner or later with . If we get running like a champ (which partly also depends on a) - but can be realized with a library, it doesn't forcibly have to be built into the app), we can nail down c (to which we're more or less bound as long as we want SD/MMC compatibility), and of course, then comes again the original question of the poll - d). If we can decide on one Widget toolset, and every developer sticks with that decision, we might soon see some really, really cool apps, not forcibly open-source, though. What we all want are cool apps, and maybe even really useful apps. They come at a (non-monetary) price, though. In Japan, there are apps for the Z, and they mainly flourish over there because most Japanese Zaurus users probably use the Sharp ROM.
If we can get a-d together and make it work like it should, we stand a chance of having further HW, and maybe MickeyL and CoreDump hired by some company that develops Opie for a living.
However, I also suggest to read MickeyLs posting in
that threadfor some further thoughs on the whole debate. I'm not completely agreeing with him, but the he's got a point on that matter, and he's the developer.