Specification Of "new" Linux Handhelds

[kahm]

I should come with 2 plugs and 2 cables.
 Have you thought about my MDA comment?

sod the USB. just give us full-speed firewire!

A USB controller is built into the PXA270 series chip from Intel, and is therefor basically available for "free". Firewire would require an extra chip, which means extra circuitry, a larger motherboard, and extra power drain.

Besides - where am I going to get a Firewire keyboard and mouse?  

[wavetossed]

Why should they build WiFi, Bluetooth or GPRS into the device when all of these are already available as add-on cards?

The idea of having 2 CF slots is a good one since that allows people to configure a device with a comms card (modem, ethernet, wifi, bluetooth, GPRS) of their choice as well as a hard drive if they want one. And if they need to copy files from CF cards from their camera, they can remove the comms to do the copy. There should be no extra chipcount to add a 2nd CF port.

Full SDIO is a good idea as is full USB host support.

But why bother with this RFP in the first place? This is not how manufacturers evolve their products. Sharp has shown a steady progression of features from model to model. It is a nice modular device that can be expanded in many ways. The main failing of Sharp is that they don't do enough to encourage the 3rd party add-on market. After all Sharp could sell bundles of Zaurus with wifi card or GPRS card with minimal hassle by just taping the card box to the zaurus box. A lot simpler than engineering it into the device and then losing sales because not everyone wants to pay for the unneeded comms capability.

[kahm]

Why should they build WiFi, Bluetooth or GPRS into the device when all of these are already available as add-on cards?

The idea of having 2 CF slots is a good one since that allows people to configure a device with a comms card (modem, ethernet, wifi, bluetooth, GPRS) of their choice as well as a hard drive if they want one. And if they need to copy files from CF cards from their camera, they can remove the comms to do the copy. There should be no extra chipcount to add a 2nd CF port.

Full SDIO is a good idea as is full USB host support.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=74625\"][{POST_SNAPBACK}][/a][/div]

This is precisely the reason that Sharp doesn't build wireless into the Japanese Z's in the first place. They have a number of commonly available and moderately priced cellular wireless cards.

For me, built in Wi-Fi would mean no more giant antenna sticking out of the side of my Z while I'm trying to type. No more seperate card that I have to tote around and could lose. No more swapping cards to switch from storage to connectivity. Now that I have my 3000, I can deal with it a little better because of the internal storage, but it is still a little annoying.

If you check the differences between the C1000 and C3000 motherboards, the C1000 is missing 1 or 2 chips in addition to the CF connector, so there is an additional chip count.

Regardless of all that, though, built in <something>, if done right, takes less space and less power than arbitrary add-on cards.

And full SDIO is problematic as it is covered by the same intellectual property issues as full SD support is - hence the Z's are stuck with the binary only SD module from Sharp. This goes against the full openess requirement.

[tg]

Why should they build WiFi, Bluetooth or GPRS into the device when all of these are already available as add-on cards?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=74625\"][{POST_SNAPBACK}][/a][/div]

Becase external cards likely spend battery power even more quickly than if everything is integrated. Also, to have 2 CF slots you will have to again somewhat increase the size of the device which may not be what we all want. Third, if SD cards of larger sizes were coming up more quickly I would not mind it as much to waiste the CF slot for some other device. But since the largest available SD card you can buy is still only 1GB (ok 2GB was announced but good luck finding one for reasonable price) I hate waisting the CF slot for anything else other than CF memory or microdrive.

[ev1l]

Why should they build WiFi, Bluetooth or GPRS into the device when all of these are already available as add-on cards?

Old discussion, but I thought I'd comment:
The reasons are actually multiple:
 - Force the device maker to semi-decently integrate the software to support the radio's.
(don't agree? look at the Z's level of bluetooth support and integration)
 - Integrated design are usually less power-hungry.
 - Integrated design are usually smaller (Look at how most Wifi cards stick out of a CF slot)

Look at your sentence: BT, Wifi and GPRS cannot be realisticly integrated in a modular PDA. You'd need too many slots, the cards would offer different levels of functionality (some wifi cards can sniff, some can't, etc), they'd stick out, killing the looks and pocketability, and the software stack probably wouldn't support much functionality at all.

[eji]

Oh yeah, one last thing: if the MDA Mk 4 ran Linux, I would have ditched my Z a long time ago.
The specs are pretty much perfect: built-in QWERTY keyboard, UMTS, large touch screen, 1.3 megapixel digital camera, 128MB of RAM, 520MHz Intel XScale processor, WiFi, and Bluetooth.
To me, trying to produce a new handheld is just not a productive way to go about it. The manufacturer of the MDA wants to stay an OEM, so getting hardware specs shouldn't cause any trouble.
Write drivers, port a decent version of OZ with Qtopia on top, perfect phone ahoy.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=74115\"][{POST_SNAPBACK}][/a][/div]

Ditching the Z for an MDA IV?  I'm honestly thinking about doing just that. I'd like to see what price they finally decide upon: if I think I can claim about 90% of it back by selling my 6000 and all the extra kit, it's history. The MDA IV has got everything I was looking for when I was first in the market for a PDA eight months ago.

I really, really don't want to run Windows, but at least I'll finally be able to do something as simple as easily sync my PIM data from desktop to PDA. If there were a Linux PDA that promised the same compatibility, I'd switch in a heartbeat. Which is why I was checking this thread to begin with.

[azalin]

If the following changes would be made to a C1000/C3100 like machine:

1) Front lit display like the 6000 so you can view it in the bright sun.
2) More normal RAM (256 Mb would be ok, 512 Mb would be ideal).
3) Microphone so you can use VoIP.
4) Internal (empty) CF or SD card slot that the user can put storage in while keeping 1 external slot open for connectivity and one for swapping files around. A small bootloader in a ROM/NAND loads the OS from that internal card. I'd rather have a swappable card like that for the OS instead of soldered-on NAND that you cannot replace if it wears out.
(WiFi doesn't need to be included, because wifi standards evolve and a card is more flexible, but if it is it should be atleast 802.11g (or i?), also if WiFi is included it should be open in information so drivers can be written easily)

... if atleast the top two would be implemented then I would likely upgrade, not before.

[Mickeyl]

All the nice hardware won't buy us anything if the Zaurus developer situation stays the same. We need many more developers to make inherently complicated tasks seem easy for the casual user.

Don't get me wrong, I'd really love to have the features of the SL6000 in a clamshell design, but it won't make the software much more usable and in the end... it's the software that matters.

[tg]

All the nice hardware won't buy us anything if the Zaurus developer situation stays the same. We need many more developers to make inherently complicated tasks seem easy for the casual user.

Don't get me wrong, I'd really love to have the features of the SL6000 in a clamshell design, but it won't make the software much more usable and in the end... it's the software that matters.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=85115\"][{POST_SNAPBACK}][/a][/div]

I agree about software being key but if hardware is higher end sofware would be easier. For example, what are two common complaints about software everyone expects to find working out of the box?

1. Firefox (takes something like 60 seconds to load on pdaX and/or Oz - at least that's what I read recently)

2. No good mail package

If you have 256Meg ram and fastest intel mobile CPU you would probably be able to run firefox without painful delay in loading, would be able to run full fledged mail sofware (whatever is ported), and would not have to clutter forums teaching newbies how to set up swap files to run basics like browser,mail,ko/ka/om/pi etc - just these essentials running smoothly would go a long way towards mainstream acceptance of zaurus (in my opinion this would especially help OZ and pdaXrom).

[omro]

1. Firefox (takes something like 60 seconds to load on pdaX and/or Oz - at least that's what I read recently)

Surely firefox's speed problems are firefox related more than hardware related? Throwing better hardware at poorly coded (I'm being generic here, not meaning firefox per se) software seems to be the microsoft approach to improving speed of apps.

I've seen Apple OS X.1 and OS X.3 on the same powerbook and X.3 was SO much faster on the same machine, proving that better coding, not hardware was definitely key there.

[dhns]

[1. Firefox (takes something like 60 seconds to load on pdaX and/or Oz - at least that's what I read recently)

2. No good mail package
...

just these essentials running smoothly would go a long way towards mainstream acceptance of zaurus (in my opinion this would especially help OZ and pdaXrom).
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

That are targets of the QuantumSTEP system - which tries to follow the Macintosh approach keep it simple, smooth, nice, simply working (although we still have to go a long way and probably will always be a little behind Apple).

As recently posted to the Mac forum ([a href=\"https://www.oesf.org/forums/index.php?showforum=63]https://www.oesf.org/forums/index.php?showforum=63[/url]), we are now focussing on a full Mail client (which is almost working on MacOS X but needs some more tweaking in the Zaurus GUI libraries to be compatible). And, we are looking for someone to port WebKit.framework which is the basis of the Safari browser.

With these main building blocks (together with an address book and a calendar) you will get a working, Mac-like system on the Zaurus.

Speed is an issue, we know. And we have to admit that the current builds of QuantumSTEP are painfully slow. But some reasons have been identified and can be solved. The main proof is that an Apple Powerbook with 400MHz PowerPC is approx. 10-20 times as fast as a 400MHz ARM Zaurus for the same Objective-C source code. So, there is enough potential for optimizations in the libraries.

-- hns

QuantumSTEP project
http://www.quantum-step.com

[speculatrix]

Speed is an issue, we know. And we have to admit that the current builds of QuantumSTEP are painfully slow. But some reasons have been identified and can be solved. The main proof is that an Apple Powerbook with 400MHz PowerPC is approx. 10-20 times as fast as a 400MHz ARM Zaurus for the same Objective-C source code. So, there is enough potential for optimizations in the libraries.

with respect, the powerpc is a very different beast to the arm. Arm truly IS a reduced instruction set (risc) processor, and gets a lot less done per clock than powerpc which has all manner of out-of-order execution pipelining logic.

arm is very much geared to power saving, powerpc isn't! Otherwise, Apple would have used the powerpc or derivative in the Newton!

that said, a good compiler should be able to shrink the performance gap between arm and ppc. lets face it, the good old amiga ran a fully GUI multitasking OS in 512K memory (half rom, half ram) with an 8MHz 68000!

[tg]

1. Firefox (takes something like 60 seconds to load on pdaX and/or Oz - at least that's what I read recently)

Surely firefox's speed problems are firefox related more than hardware related? Throwing better hardware at poorly coded (I'm being generic here, not meaning firefox per se) software seems to be the microsoft approach to improving speed of apps.

I've seen Apple OS X.1 and OS X.3 on the same powerbook and X.3 was SO much faster on the same machine, proving that better coding, not hardware was definitely key there.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=85178\"][{POST_SNAPBACK}][/a][/div]

I have a powerbook and after I installed Tiger it feels like I bought a brand new machine. So in principle I agree with you that efficient software will take care of slower hardware. But the unfortunate Zaurus reality is that there is no Apple to write the software and number of developers that are woring on Z (as Mickeyl and others have repeatedly pointed out) is just too small. Given that, if you can get faster processor and more ram and firefox is responsive does it really matter that it's bloated (ok it does but it's possible to live with it). Between two solutions of better and more efficient software and Sharp just putting in a better (existing) processor and more RAM my money is on Sharp still solving this problem long before software is improved - no matter how slow Sharp is and how much we are all pissed about lack of features on high end clam models there is still nothing else better out there - or else we would not be on these forums, would we?

[dhns]

with respect, the powerpc is a very different beast to the arm. Arm truly IS a reduced instruction set (risc) processor, and gets a lot less done per clock than powerpc which has all manner of out-of-order execution pipelining logic.

arm is very much geared to power saving, powerpc isn't! Otherwise, Apple would have used the powerpc or derivative in the Newton!

Ok, that is a good point. A 400MHz PowerPC G4 has a full FPU (not to speak about AltiVec) while an ARM processor has to usw a floating point library. And the new one with gcc 3.4 is IMHO not yet in use on the Zaurus.
And, secondly, an Apple has an additional GPU to do most of the windows and rendering. Has also to be done on the ARM in the Zaurus.

that said, a good compiler should be able to shrink the performance gap between arm and ppc. lets face it, the good old amiga ran a fully GUI multitasking OS in 512K memory (half rom, half ram) with an 8MHz 68000!

Yes, that is essentially my main point - improving algorithms (the inner loops wasting too much time - and missing caching algorithms) can have a large effect. And we have not really touched that in the QuantumSTEP project because we based on an older GNUstep system.

But that one has its roots in the NextStep system which also did run an 68040 with 16 or 32MHz (do not remember).

From all that I conjecture that most time is wasted in handling string comparisons and conversions. And, the QuantumSTEP runtime system is based on an old X11 server that requires a separate ztsd daemon to properly debounce and translate the Zaurus touch screen events (which comes into process priority conflict with everything else slowing down dramatically). Maybe something to replace by X/Qt which is unfortunately too much in Japanese for my language level...

So, there is plenty of room for software improvements (btw. the AppKit and Foundation libraries of QuantumSTEP are open source, LGPL).

-- hns

[ev1l]

Surely firefox's speed problems are firefox related more than hardware related? Throwing better hardware at poorly coded (I'm being generic here, not meaning firefox per se) software seems to be the microsoft approach to improving speed of apps.

The heavy UI (XUL) is only one of the problems. When your host CPU does 1 floating point operation per week, desktop and multimedia apps are never going to be very fun to use.