Is the Agenda VR3 Linux PDA Dead?

An Anonymous Coward writes: "LinuxDevices.com has published a news item about the uncertain future of Agenda Computing and their VR3 linux PDA. According to the article, some members of the Agenda developer community are continuing work on current projects, but many have switched to other projects such as the Sharp Zaurus. Apparently there is an Agenda Germany office which is still shipping the VR3s (including to the U.S.) and which has said that they are continuing VR3 development -- but's not clear whether that means software or device development. Looks like another cool linux device has bitten the dust. Sigh."

Comments

Why are people surprised?

[not-quite-rite]

How was this groundbreakingly different, and what did it offer over any other PDAs.

Any product that tries to cash in on the "Linux is cool" will find that people are looking for substance, not gimmicks.

I doubt there were many people that considered it a serious player in the world of PDAs.

I am not saying this to start trouble, I believe it just needs to be said.

Re:Why are people surprised?

[trampel]

As far as I know, it is the **only** PDA offering a full X Server. While causing somewhat more overhead, it makes porting software much easier - heck, you even can use it as an X Terminal!

While "Linux is cool" shouldn't be the main seller, there are connectivity aspects that simply blast other OS's away. For instance, when I got my Agenda plus Ethernet interface, it was lacking dhcp capabilities. However, I was able to compile and run dhcpcd out of the box - try that with a Palm or Windows CE based device.

Then, the software useability for basic PDA features is actually very decent in the recent releases.

Nothing to do with LINUX

[SerpentMage]

I think this has nothing to with LINUX. And the GPL is good because how often has it happened that good code was lost because the company went under.

The problem with palmtops is that I have tried and tried to use them. But what I keep going back to is the smallest leanest notebook possible. And many other people think the same way. A Palmtop is in many ways a "toy".

Re:Nothing to do with LINUX

[dr_labrat]

I know what you mean...
I recently dusted off my libretto 50...

Runs linux like a charm :)

Re:Severe Usability Problem - possible solution?

[Dr. Manhattan]

The biggest problem with marketing Linux-based PDAs is the miniscule software catalogue.

Some people have looked into porting POSE (the Palm OS Emulator) to the Zaurus and other Linux handhelds, so that it could run Palm apps. Unfortunately, POSE needs a Palm ROM image, and those are not freely redistributable. You'd need to have a Palm anyway to get it to work. And the speed would likely be atrocious on a 200MHz ARM chip. It's not full speed even on my K6-II 500MHz.

I had a different idea. The Palm SDK's are available, and there's prc-tools and such for Linux. Why not create an emulation layer for the Palm API, like Wine emulates the Windows API on Linux?

The Palm API is better-documented, and much simpler. It'd probably be fairly easy to get to at least Palm OS 2.0 or so. Then you could recompile Palm apps for a Linux PDA. There would be a speed hit due to redirection, but the underlying processor is much faster; overall I'd think there would be a speed boost.

You'd still need to recompile, but there are lots of open-source Palm apps, and lots more developed with Linux; the developers might have good motivation to quickly port their app to a new platform.

I think the endianess is the same, so that's not a problem. To be legally safe there might need to be a clean-room effort, I'm not sure yet, but this'd be a way to get a lot of apps for, e.g., the Zaurus, and quickly.

Re:Not a total dead loss ...

[Jay Carlson]

Yeah, the VR3 is a fun lab for exploring the pressures on embedded Linux devices. For instance, 8M is not quite enough memory for the software that people want to run on the device. So we want to cut down memory usage, but before we can do that, we have to understand what exactly memory usage is.

That's a difficult issue. Take a program that has no heap/stack usage. How much memory does it use while running?

One 4k page, containing either the current instruction, or the target address the current instruction is loading. All the other pages can be dropped by the kernel VM system, and demand-loaded back in when needed. Plus whatever kernel overhead there is to support the task and memory maps.

OK, clearly that's not a useful answer. Any real app that's really eating only one page is thrashing so hard that it won't get anything useful done in a timely manner. But it does get you thinking about what the nature of memory usage is, and possible ways to reduce it.

eXecute In Place support is one strategy. When you build VR3 compressed rom images, you can flag some files as sticky. Through the magic of VM, those uncompressed files are mapped directly into processes, and their code really does run from ROM---no copy in RAM needed. But VR3 ROM is slower than RAM, and you use up more ROM space this way. VR3 hackers have spent a lot of time exploring the tradeoffs here. But there are plenty of other strategies, and some that go deeper into the build process.

For instance, it would be nice if each code page had as much useful stuff on it as possible. If you have a short "hot" function, a long bunch of rare exception handling, and then another short "hot" function, you have to keep the exception handling code paged in even though you're not using it much. It would be better to reorder the hot functions so that they share a page.

You can do some of this with gprof's function reordering profiles and some linker scripts, but I haven't gotten around to trying this on the VR3. I think that some of the approaches to small-device tailoring do require the deep, system-wide approaches the parent article describes.

Here's why agenda got it's butt kicked

[Ukab the Great]

• It had a risc processor that was almost four times as a fast as a palm's cisc processor, but responded to user-generated events almost three times as slow. This is probably do to the fact that the linux kernel does not prioritize handling UI events whereas PalmOS does. It is probably also due the fact that PalmOS doesn't try to do serious multi-tasking because something like a PDA really doesn't require it except for a few limited daemon-type things (e.g. alarms, timers, etc). Sure, if it does serious multi-tasking, geeks can run apache on it. But then you have to ask yourself who you're really marketing the product to.
• The Agenda did not remotely have any serious human factors involved in the hardware design. Most likely they said "we'll design the hardware first, and worry about the interface later on". You can clearly see this from the strangely placed buttons and the ultra-slippery metal stylus that is ultra-hard to get a good grip on. Any UI person worth his salt will tell you that you should always come up with how the person is supposed to interface with the software/device before you ever write code/manufacture it. On a PDA, usability issues are amplified several thousand times: On a sit-down desktop, you might have half a day to navigate a poorly designed interface. With a PDA, you might have 20 seconds to get down a damned important phone number.
  
  The Palm, on the other hand, was invented after the designer carried a block of wood around in his pocket for a month, pondering what the PDA should act like. Agenda Computing could have used a good block of wood.
  
  
• The user interface was badly designed. The calendar on the agenda was nowhere near as good or as clean as the palm's. And where the palm had a global area for looking over the applications (i.e. home), Agenda made it into an application called Launchpad. File managers should have the feel of being a global entity, not an application that has to be started.
• Agenda's web site really didn't contain a whole lot of information that was helpful and only contained a few pieces of documentation here and there. There seemed to be this attitude of "if you want help or support or information, check out the agenda community". When you're a company, you just can't say that. Also, Agenda should have put all the developer community apps on their web site. People don't have the patience to follow links.
• Agenda prevented reselling, but did not provide things of as great a quality as a reseller might (if at all). For example, if someone were allowed to beef up the consumer IR software, to add a whole bunch of IR codes for various consumer devices, and make it generally easier to use and then sell it as the Ultimate Universal Remote, people would have gotten a kickass remote and Agenda Computing would have still made money of the hardware, which was their original business model anyways
• Agenda couldn't really decide who their target market was: end-users who wanted an organizer or linux geeks with a lot of patience and a love for futzing who wanted a cool toy. You always have to know who your market is if you want to succeed in any kind of business.