[Dianne Hackborn]

I am going to try to make some quick replies while I have a little time.

First, let's get this out of the way:

Originally Posted by Voice_of_Reason

Your buddy, Ms. Hackborn suddenly became silent (unusual for her ) when pressed for details on what Cobalt can really do IN PRACTICE rather than IN THEORY.

In an exchange along the lines of "does not", "does so", "does not", looking at who last spoke doesn't say anything about who is actually right.

I already replied to your question a long time ago, and the answer is still the same: Cobalt's multithreading and process support doesn't have any of the problems you keep alluding to. The only limitation is that applications running separately from the main application all share the same process, which I have been very upfront about. In practice, about the worst this means is that if you are, for example, using a web browser that makes use of the background process to remain running, if some other background thread crashes, the web browser will be killed as well and you will end up back in the Launcher. Note that the main application runs in its own process, so a crash in the current application won't disrupt other running applications.

Unless you are going to give actual information along with all of your claims about Cobalt's faults, there is nothing more I can contribute to this discussion. I have tried to be very clear about what is going on technically in order to explain how things work and what it means. From what I can see, you really know nothing about Cobalt, but are just making baseless accusations. If that's not the case, put up and post some actual detailed explanations of how you reach your conclusions.

Originally Posted by Voice_of_Reason

Hardware is slowly catching up to the intrinsic inefficiencies of PPC. On the other hand, hardware bypassed PalmOS way back in 2001. The writing has been on the wall for years, but only recently has Palm started planning for the future.

Well, we started Cobalt in 2001, with one of the key intents being to rearchitect the system to take advantage of the much more powerful hardware that was appearing on devices. I agree, though, that it was late -- Cobalt ideally should have been started a few years before that.

Anyway, on to better stuff...

Originally Posted by TadW

True, but that shouldn't be a problem anymore. The Palm V had 2MB Ram and Flash and didn't offer multitasking. The Tungsten T5 has a whopping 256 MB of total memory (which includes the user-accessible RAM and Flash), and still doesn't offer multitasking.

All I am saying is that as hardware develops and opens up to new possibilities, we shouldn't be arguing that software technology that dates back almost a decade is still preferable to newer technology.

When I joined PalmSource, even though I was trying to avoid being stuck in the desktop mentality, this is still something that caught me by surprise: the hardware in handheld devices does not evolve like it does on the desktop.

The difference is subtle, though, because it does evolve kind-of like the desktop, but only at the high end. The thing is, rather than the high end of today fairly rapidly becoming the mainstream of tomorrow, instead what happens is that the range of hardware capabilities spreads, and you can now take the older hardware and make cheaper/smaller devices.

Here's an example: when we started doing Cobalt, our reference board was a 200MHz Intel PXA250. We designed the system with that as our base target, with the assumption that if we could get by on the edge of reasonable performance on that board, we'd be in very good shape when we were done with development.

However, today we are working with a licensee whose hardware is slower than that PXA250 from four years ago. Huh?!? That was a surprise. It's not an insurmountable problem, but it does mean spending more time on more optimizations than we thought we'd need to do.

Here's something even better: I have talked with some device manufacturers who want to run a Cobalt or Linux class operating system on a 50 MHz ARM 7. The ARM 7 processor doesn't even have an MMU...

So though the T5 may have 256 MB of memory, we would like to still be able to run Cobalt on 16MB RAM + 16MB flash (our current minimum configuration), even when we move to Linux. For a lot of device manufacturers, especially when you are in the phone space, that is not very low-end. And now they want to have all kinds of 3G services and video conferencing and videos and mp3s and web browsers running on such a device. Fun!

Originally Posted by surur

BTW, I still have not see anybody address the disadvantages of Saved State vs multi-tasking yet. Isn't this what the whole thread is all about?

I think the key thing is that this isn't really an either/or question. For the kinds of things these devices are doing -- multimedia, all kinds of communications stuff, web browsing, etc -- multithreading and multiple running applications is required. That doesn't mean, however, that you should be forced to use it for things where it doesn't give any benefit, such as in your address book app.

From a user experience perspective, one thing that would be nice is if the applications the user interacts with could make use of one or the other approach in a way that matches what the user expects. That is, if an application wants to stay running, that is because it is actually doing something (such as playing an mp3), which the user knows about it doing, so they will naturally just think of it continuing to run while switching to other things. However, if it is something like an address book app, from a usability perspective it is a benefit to not have it stick around, because then you don't have to come up with some artificial way for the user to find out that it is still running and deal with it.

So to my mind what it gets down to is not a question of what basic functionality the operating system provides -- we know what that is, it's threads, and processes, and all the traditional OS stuff that has served us well for 30 years. The real challenge is how you take this standard functionality and present it to the user in a way that makes sense for a handheld device.

And I have to say, I feel pretty strongly that a good handheld user experience is not at all just a PC experience shrunk down, in the same way that the PC experience needed to be fundamentally different than minicomputers.