If you've followed any of the discussions comparing Pocket PC and PalmOS devices, you know that the three topics almost guaranteed to come up are:

Pocket PC is more like a PC vs PalmOS is easier to use for a handheld
Pocket PC has better hardware and multimedia vs PalmOS is just as good
Pocket PC has multitasking vs Handhelds don't need that kind of multitasking

These points will continue to be debated ad infinitum, and to be honest it's a lot of fun! But today I want to give a perspective on the third item that I don't think has really been discussed much.

As you probably know, I recently moved from a Toshiba Pocket PC to a Treo 650, and I really like it. But I found myself wishing it had multitasking like the Pocket PC did. Instead of just stopping there, I decided to think it through a little bit further and was surprised at what I came up with.

So I asked myself, "Why do I miss the multiple applications running like in Pocket PC?" For example, Cobalt is supposed to have true preemptive multithreading/multitasking or whatever you want to call it, which is really not so far off from what a desktop OS might do. And it sounds like with PalmOS for Linux, some of the thread and context limitations from the OS may be lifted also. I suppose that the future of Linux kernel, improvements in the Linux kernel, and better hardware CPU support will allow this to become even more robust. It's necessary, I suppose, to handle things like cell calls while doing wifi and bluetooth, and doing various other background computing for whatever reason. But I'm neither an expert on this, nor am I really all that concerned about learning the details. It's all very interesting to me for a moment when a clear explanation is given, and then someone goes and brings up a new angle and puts me back in my natural state of confusion all over again!

But my point is that we need to follow PalmSource's advice and look at what the user sees and needs on a handheld device. Their argument is that you really don't do two applications at once on the screen anyway. You have an application on the screen, and then you may have various other things happening in threads for a toolbar, an mp3 player, a pop up window activity, etc. If you really go to another application the screen switches, and you really don't need to know whether or not that first application is still runnning or not. You just want to be able to go back to it when you choose to.

Aha! That's the whole problem, isn't it?!

Here's why I say PalmSource may be exactly right about multitasking. They are completely right in this regard -- While we need background processes, we really don't care whether or not we have a bunch of screen-filling applications running at once if we are only using one at a time. In fact, managing what programs are running on Windows Mobile is one of the biggest annoyances leading to a third-party essental utility as an add-on to keep you from throwing the device out the window and hitting your neighbor in the head!

But, somehow, we haven't seen that PalmSource philosophy come through into the user experience. It has become more of a justification for the way PalmOS works than the basis for a good user experience.

Let me describe what I mean by going back to what I miss about Pocket PC. I could (with Wisbar Advance) pop up a task list and easily switch to any running application. So the ones I use back and forth can be switched easily. I didn't care if they continued to run, I just wanted to be able to continue using them. I also liked continuing to use them in the same state that I left them in. Not a problem if they are still running.

So it's not a multitasking issue, it's a user interface issue. And I think both Windows Mobile and PalmOS have kind of blown it so far. I'm sure they will both get better, but Windows Mobile shouldn't require an add-on to easily handle program switching and program closing. It's a headache to the user, and that's what good design is supposed to avoid, right?

And with PalmOS, you shouldn't have the messy program switching that you experience. For example, on my (delightful!) Treo650, if I put an mp3 on pause from RealPlayer and switch to another application, then when I come back my track starts at the beginning again. It remembers my track, but not my position in the track when I paused it. According to what I learned in a programming class for PalmOS, that isn't how it's supposed to work. The user isn't supposed to know that the application had to restart and didn't just keep running. But the problem is that I was inconvenienced by it.

Another example of how the UI can be a bit of a nuisance is when, for example, I'm happily reading something in iSilo. Then I remember something that I need to do. One of the great things about a pda is that when you remember something you can record it right on the spot and forget about it. So I go to the Tasks application to enter my todo item. So far so good. But on PPC, I can then go back to iSilo easily. Not so much because it's still running, but because there's a drop down menu that has it still listed assuming I didn't do something special to force it to close. So on PPC I just tap tap and I'm reading again. But with PalmOS (and no add-on software), I have to go to home, find iSilo and launch it. It might not seem a big deal, but for a core and common sort of action it can be a bit of a nuisance.

Now don't get me wrong... it's not a big deal. It's easily solved for the most part by picking the right apps or adding third party software. And this is not meant to be fodder for people to say "I told you PPC/Palm was garbage!"

But my point is that it's the UI that's the real issue in this Palm vs PPC fight over multitasking, not the technology or philosophy of the OS. I'm pretty sure that both OS's are actually quite capable. And the good news is that the UI is certain to improve quickly in both camps.

Good read, and worth the time. Thank you. Thinking it thru, it makes sense too. Again thank you.

Great editorial Bob... as always!

There is one instance, at least for me, where multitasking (and perhaps a fast CPU) becomes important even with handhelds: Internet connectivity.

I daily check RSS feeds with NewsBreak on my PDA. And I am not talking about 5 feeds here. I think I have around 100-150 feeds added to NewsBreak. Downloading all of them can take some time. With multitasking, I easily switch to another application, let's say iSilo, to read another chapter of my current e-book. Few minutes later I switch back to NewsBreak, and Voila!, have all feeds updated.

Another example: When I browse the web using NetFront or PIE, and may decide to download a larger file to my 2GB SD card, I don't have to wait until the download is done. Even if the download is 100MB big, I can easily switch back to reading my e-book or studying my stock market application without starring at the download process bar for half an hour.

Third example: At all the the time, I have an IMAP connection open to my e-mail account. When new mail arrives, I get immediately notified, even, for instance, if I am reading an e-book in that moment.

Not to mention GSPlayer, which is constantly running in background streaming live music from an Internet radio station.

You see, I agree with you that in the normal sense and for what PDAs were meant to be multitasking is not of intrinsic importance. But if you are like me who likes to do several things at once (yes, even we men can do that sometimes!), being able to switch applications without stopping them can be a real blessing and a time-safer!

As for the UI changes... I am disappointed that Microsoft's WM 5.0 almost looks identical to 2003 SE. I have much greater hopes that in this regard PalmSource will do something revolutionary with the first Cobalt releases ("Project Rome").

Thanks Alex!

Regarding the examples you gave, I might be wrong, but I think that PalmOS for Linux (and probably Cobalt already) supports all those things very well. Preemptive multitasking capability is built in, just probably not the same way it's done in Windows Mobile. And I am pretty sure that you have named exactly the kinds of things PalmOS was built to handle.

If you think about it, these things don't sound very different from what you see right now with background Real Player while reading an ebook... which is even part of Garnet. With Garnet it probably takes a "cooperative" application willing to play nice, but with Cobalt, the OS is more in control.

And remember that there may also be issues with multiple radio operations. I think until the LifeDrive, you couldn't do wifi and Bluetooth at the same time on a Palm device, for example. And it's up to the application to restart in the state you want it to restart in, so I don't think that's an OS limitation.

Maybe someone that know the details better than me can clarify?

Palmsource didn't decide to nix multitasking from their OS... they were limited BY LICENSE from exposing more than 1 thread to the OS from the underlying kernel (they licensed the AMX kernel from an embedded company called KADAK (http://www.kadak.com/html/kdkp1400.htm) in the early Palm days when they were still called 3Com, and kept with that single-thread model through 3 other kernel rewrites that they undertook).The terms and conditions of that license specifically state that Palm may not expose the API for creating/manipulating tasks within the OS. If you need access to these calls you need to contact Kadak at (604) 734-2796, or visit their website at http://www.kadak.com (http://www.kadak.com/)So they could have easily implemented it, but their license agreement with the kernel manufacturers restricted them from doing it. The kernel itself is multithreaded, multitasking (at the hardware level), but not exposed to the OS.

Most of these "limitations" are never technical in nature.. and this is no exception.

I've been in this conversation before, and you're right: it's fun to debate!

Personally, I see multi-tasking as a kludge to make up for sloppy programming (oooooh....I got a GOOD reaction from a PPC-zealot on that remark)! Take your example of Real Player: if it would properly return in EXACTLY the same state you left it, you would see NO difference between between task-switching versus multi-tasking. But, many developers don't put in the extra effort to do it right, and Palm suffers for it.

With multi-tasking, the program always runs, so the developer can be lazy about such things. However, this is a waste of processor power. I rather like how I can bounce between 4 different apps on the Tungsten C without experiencing a slow-down within each app. Things start getting a little sluggish on the PPC if you don't manage your tasks properly.

Solution? Not sure on that one. I suppose Palmsource could try to improve the developer tools so that "state-saving" is easy to implement, but developer-laziness can always overcome that.

For me, I use Zlauncher with QuickLaunch so that my recently-used apps are quickly available (like a taskbar), and then select applications that state-save properly. It's the best of all worlds, if you can find the good apps.

But, I'm sure the developers prefer the PPC Multi-tasking for ease of development.

- Jim

Hi Bob!

I very much agree with you on this, including the fact that Palm OS (including Cobalt) still hasn't really done anything to address the issue.

Dealing with multiple concurrent activities on these devices, at the user level, is something that we think is going to be one of the key things that needs to be dealt on the devices that are now starting to appear. In fact, phones are already starting to run into the complexity it causes, and in my opinion for the most part punting on it. As 3G gets more widespread, we think this is simply something that will have to be addressed in order for the average person to use the new features it makes available.

For PalmSource, Cobalt was basically the necessary first step needed to get the OS infrastructure in place to deal with this stuff, but very little was done in the UI. In fact, the slips in Cobalt are one of the very early UI efforts we did to start dealing with it -- the basic concept of the slip being a little mini-application that can run independently of the main application flow. However, I would really say as it stands they only barely start to help.

I have a few specific replies to your comments:

And it sounds like with PalmOS for Linux, some of the thread and context limitations from the OS may be lifted also. I suppose that the future of Linux kernel, improvements in the Linux kernel, and better hardware CPU support will allow this to become even more robust.


For the most part, I think the meat of the issue is in the way the UI works: Cobalt, Windows, Linux, and Symbian all have the basic kernel and system support to be able to do what is required. The real challenge is in figuring out how these features are exposed to both the user in the UI they experience and to application developers in how they write their applications.


For example, on my (delightful!) Treo650, if I put an mp3 on pause from RealPlayer and switch to another application, then when I come back my track starts at the beginning again. It remembers my track, but not my position in the track when I paused it.


As it happens, the Cobalt media player will remember your track -- and in fact, if you switch to another application while playing a song, it will continue playing in the background without a hiccup. The media system accomplishes this by running the media playback functionality in our background process. The media player app itself is really just a remote control for the media playback thread that is left running. You can, of course, also structure your application so that it runs all of its UI from the background process and "switching" to it just involves telling your background thread to bring up its UI. This is probably the way you would want to do things like web browsers.

Btw, the same MediaPlayer behavior applies to watching videos as well listening to audio, except I believe the media player will normally pause a video while it is not running as the main app.


Another example of how the UI can be a bit of a nuisance is when, for example, I'm happily reading something in iSilo. Then I remember something that I need to do. One of the great things about a pda is that when you remember something you can record it right on the spot and forget about it. So I go to the Tasks application to enter my todo item. So far so good. But on PPC, I can then go back to iSilo easily. Not so much because it's still running, but because there's a drop down menu that has it still listed assuming I didn't do something special to force it to close.


I don't know if this exactly addresses your need, but on Cobalt if you hold down on the Launcher/Home icon in the status bar, you will get a pop-up menu of the recent applications you have run, allowing you to switch back to one without going through the Launcher. I don't think the overall UI is all that great (it is not at all obvious you can do this, and having to press and drag as the only way to access this functionality kind-of sucks), but it's a start.

In the Multi-tasking vs Saved State debate, the fact is, one is better than the other one, and for a number of reasons.

Multi-tasking is better of course because:
1) It encourages the use of a robust OS with proper memory space protection, meaning its less easy for a rouge application to take your device down. If there is only one program running at a time then you do not need these special measures.
2) It removed the burden for the UI from the developer to the OS, meaning good software is easier to right, meaning more and better software, which benefits the end user.
3) Returning to a saved state has its own costs, and may not necessarily be instant e.g. re-paginating an ebook, re-rendering a web page or acrobat file, re-calculating a formula etc, loading a file from slow storage back into memory etc.

Thats regarding saved states. I believe in a way you are confusing saved states vs multi-tasking also. Clearly playing music in the background IS multi-tasking, as is running an IM program. Saved state as you described above is NOT. So the other difference between PPC's and Palms is the TYPE of multi-tasking, that is pre-emptative vs cooperative.

Pre-emptative is better, again for stability and robustness reasons, which is as useful on a PDA as on a desktop. In many instances, when software crashes on a PPC you are returned to the desktop. In Palm it resets the device. They are less stable and more fragile because of cooperative multi-tasking. The implementation is also very dependent on software developers, and if they mess up your device is toast.

Palms use a combination of cooperative multi-tasking and saved state. The Real Player on Palm is a good example of software that does multi-tasking (playing music in the background) but did not do the saved state properly. This imposes a burden on developers, meaning they spend more time coding around the deficiencies of the OS and less doing the real work of the software. It introduced additional complexity into every program, instead of just in the OS where it can be perfected and used by all the software. Maybe this is why PPC software is generally better than POS software.

I agree than PPC's could do a better job at exposing the multi-tasking, like a desktop taskbar does, but this is the only way their model is deficient. Lets stop acting as if we are constantly restrained by resources. We are no longer dealing with 33Mhz devices and 2 MB memory.

Surur

Palmsource didn't decide to nix multitasking from their OS... they were limited BY LICENSE from exposing more than 1 thread to the OS from the underlying kernel... Most of these "limitations" are never technical in nature.. and this is no exception.

While that was true at one point, Garnet actually uses a kernel that was developed in-house by Palm. In fact, the Garnet kernel is an early version of the kernel that was done for Cobalt.

One of the issues is that there is a lot more to multithreading than just having the kernel functionality. For example, though you (well we and our licensees) could spawn a bunch of threads on Garnet, there is very little those threads could actually -do-. None of the UI system in Garnet was thread-safe, so nobody except the single main application thread could do any UI at all. I don't other parts of Garnet all that well, but I don't think there were many other things the threads could do -- there were probably even limitations on what IO operations could be done.

When I got to Palm, Cobalt kernel and lower-level services were basically up and working... then we spent the following two years making the rest of the system actually able to take advantage of them.

In the Multi-tasking vs Saved State debate, ...
2) It removed the burden for the UI from the developer to the OS, meaning good software is easier to right, meaning more and better software, which benefits the end user.
...
Surur

But it must be kept in mind that better applications only benefit the user if they come without the burden of a less stable OS. The net benefit to the end user is not clear when comparing the integrated whole application+OS.

In reference to BobR's original discourse, I''ve found that for my use the Sony applets added to PalmOS5 in the UX series provide all of the application switching "fixes" that I need, particularily the CTRL-Num app launching functions. That is, providing my applications successfully "remember" where I left off. I use MobiPocket as my common eBook reader and it does a good job as do the majority of the applications and PIM applets that I use on a daily basis.

New pocketpc's are more stable than new Palms, and it takes less effort to make them stable also.

http://www.1src.com/forums/showthread.php?t=90438

Surur

New pocketpc's are more stable than new Palms, and it takes less effort to make them stable also.Who cares if they're more stable, if they're less functional?

Also, it shouldn't take any "effort" to make something stable. You're a user of the device. It should be stable by default. If it isn't, its broken. Find another vendor.

If you can have multitasking then why not? Multitasking doesn't mean that programs necessarily have to continue running in background if you don't want to. But you get to choose. For instance, Betaplayer has options that allow you select whether you want audio, or video, or both stopped when switching to another process.

If you've followed any of the discussions comparing Pocket PC and PalmOS devices, you know that the three topics almost guaranteed to come up are:

Pocket PC is more like a PC vs PalmOS is easier to use for a handheld
Pocket PC has better hardware and multimedia vs PalmOS is just as good
Pocket PC has multitasking vs Handhelds don't need that kind of multitasking

These points will continue to be debated ad infinitum, and to be honest it's a lot of fun! But today I want to give a perspective on the third item that I don't think has really been discussed much.

As you probably know, I recently moved from a Toshiba Pocket PC to a Treo 650, and I really like it. But I found myself wishing it had multitasking like the Pocket PC did. Instead of just stopping there, I decided to think it through a little bit further and was surprised at what I came up with.

So I asked myself, "Why do I miss the multiple applications running like in Pocket PC?" For example, Cobalt is supposed to have true preemptive multithreading/multitasking or whatever you want to call it, which is really not so far off from what a desktop OS might do. And it sounds like with PalmOS for Linux, some of the thread and context limitations from the OS may be lifted also. I suppose that the future of Linux kernel, improvements in the Linux kernel, and better hardware CPU support will allow this to become even more robust. It's necessary, I suppose, to handle things like cell calls while doing wifi and bluetooth, and doing various other background computing for whatever reason. But I'm neither an expert on this, nor am I really all that concerned about learning the details. It's all very interesting to me for a moment when a clear explanation is given, and then someone goes and brings up a new angle and puts me back in my natural state of confusion all over again!

But my point is that we need to follow PalmSource's advice and look at what the user sees and needs on a handheld device. Their argument is that you really don't do two applications at once on the screen anyway. You have an application on the screen, and then you may have various other things happening in threads for a toolbar, an mp3 player, a pop up window activity, etc. If you really go to another application the screen switches, and you really don't need to know whether or not that first application is still runnning or not. You just want to be able to go back to it when you choose to.

Aha! That's the whole problem, isn't it?!

Here's why I say PalmSource may be exactly right about multitasking. They are completely right in this regard -- While we need background processes, we really don't care whether or not we have a bunch of screen-filling applications running at once if we are only using one at a time. In fact, managing what programs are running on Windows Mobile is one of the biggest annoyances leading to a third-party essental utility as an add-on to keep you from throwing the device out the window and hitting your neighbor in the head!

But, somehow, we haven't seen that PalmSource philosophy come through into the user experience. It has become more of a justification for the way PalmOS works than the basis for a good user experience.

Let me describe what I mean by going back to what I miss about Pocket PC. I could (with Wisbar Advance) pop up a task list and easily switch to any running application. So the ones I use back and forth can be switched easily. I didn't care if they continued to run, I just wanted to be able to continue using them. I also liked continuing to use them in the same state that I left them in. Not a problem if they are still running.

So it's not a multitasking issue, it's a user interface issue. And I think both Windows Mobile and PalmOS have kind of blown it so far. I'm sure they will both get better, but Windows Mobile shouldn't require an add-on to easily handle program switching and program closing. It's a headache to the user, and that's what good design is supposed to avoid, right?

And with PalmOS, you shouldn't have the messy program switching that you experience. For example, on my (delightful!) Treo650, if I put an mp3 on pause from RealPlayer and switch to another application, then when I come back my track starts at the beginning again. It remembers my track, but not my position in the track when I paused it. According to what I learned in a programming class for PalmOS, that isn't how it's supposed to work. The user isn't supposed to know that the application had to restart and didn't just keep running. But the problem is that I was inconvenienced by it.

Another example of how the UI can be a bit of a nuisance is when, for example, I'm happily reading something in iSilo. Then I remember something that I need to do. One of the great things about a pda is that when you remember something you can record it right on the spot and forget about it. So I go to the Tasks application to enter my todo item. So far so good. But on PPC, I can then go back to iSilo easily. Not so much because it's still running, but because there's a drop down menu that has it still listed assuming I didn't do something special to force it to close. So on PPC I just tap tap and I'm reading again. But with PalmOS (and no add-on software), I have to go to home, find iSilo and launch it. It might not seem a big deal, but for a core and common sort of action it can be a bit of a nuisance.

Now don't get me wrong... it's not a big deal. It's easily solved for the most part by picking the right apps or adding third party software. And this is not meant to be fodder for people to say "I told you PPC/Palm was garbage!"

But my point is that it's the UI that's the real issue in this Palm vs PPC fight over multitasking, not the technology or philosophy of the OS. I'm pretty sure that both OS's are actually quite capable. And the good news is that the UI is certain to improve quickly in both camps.

I'm afraid you don't really seem to understand the true advantages of multitasking. At the same time you're also needlessly criticizing a UI deficiency in PalmOS that is easily remedied.

The following thread may be revealing:

http://www.allaboutpalm.com/forum/showthread.php?p=161#post161

http://www.allaboutpalm.com/forum/showthread.php?p=208#post208

http://www.allaboutpalm.com/forum/showthread.php?p=215#post215


Multitasking is the way of the future because it removes constraints that would otherwise waste a lot of time. The advantages are most apparent in wirelessly connected PDAs, but even unconnected PDAs can benefit from multitasking. The ability to browse the Internet while downloading email, listening to MP3s and copying text at will to a text editor requires "multitasking" (in the simplest meaning of the word). Why would anyone want to do multiple tasks sequentially when they can be done either at the same time or without having to waste time restarting programs?

In practice, the ability to quickly switch between apps conferred by having a multitasking OS is the least important advantage over a non-multitasking OS. The difference in ease of app switching between PPC + WisBar and PalmOS + McPhling is arguably rather trivial. Where PalmOS falls flat on its face is in its (dis)ability to perform tasks concurrently. Constantly stopping and starting apps, disconnecting and reconnecting to the Internet, etc. adds a needless burden to the use of a PDA.

For years I've argued in favor of PalmLinux - a Unix-based platform running Palm apps. Last year Ms. Hackborn berated me on another site for having the temerity to suggest PalmLinux was a good idea. Now it would appear her employer agrees I was right all along. Cobalt is merely a "baby step" in the right direction (towards true multitasking), but Palm/PalmSource has a LOOOONG way to go at this point in time. It sounds like the current (not available in stores near you) version of that legendary OS, Cobalt has some "issues" with memory management and stability. Furthermore, Cobalt's ability to simulate true "multitasking" is limited right from the start by PalmSource's choice of merely a "multithreading" architecture. It appears that Cobalt is little more than a glorified beta version of Palm's long overdue saviour: PalmLinux. The biggest question right now is whether or not PalmSource can solve all of the issues around porting Cobalt to a Linux kernel before their market loses interest completely and moves en masse to an alternate OS. PalmSource has claimed PalmLinux will be ready before mid 2006. I'll believe that when I see it. Because multitasking will soon be an essential OS feature, if Palmsource fails to deliver on its PalmLinux promise it will probably be game over for the platform.

It's interesting to note that PalmSource - a company that supposedly has such UI advantages over PPC - has repeatedly failed to make any improvements to that UI. A tabbed interface (e.g. LauncherX) and rapid app switching (e.g. McPhling) are obvious advances to the PalmOS UI that are still left to third party developers to provide. It remains to be seen if Palm will even provide an intuitive way to cycle between open threads in Cobalt. I've suggested a customized browser-style tabbed UI, or better yet, showing icons of all open applications on the DIA. Now we hear talk of an ambitious UI code named "Rome". Why can't PalmSource just fix the bugs and polish its current OSes before heading off on yet another wild goose chase? The lack of focus and praticality that killed Be seems to "Be" rearing its ugly head again...


TVoR

Who cares if they're more stable, if they're less functional?

Also, it shouldn't take any "effort" to make something stable. You're a user of the device. It should be stable by default. If it isn't, its broken. Find another vendor.


How are PPCs "less functional" than PalmOS PDAs? I've argued in the past that PPCs are "less intuitive" (usually lessened with time +/- utilities like WisBar) and "less stable" (now debatable) than PalmOS PDAs, but even I would have difficulty saying a $400 Dell X50v is "less functional" than a $400 Tungsten 5. Unless the PPC UI rendered these devices completely unuseable (it doesn't), functionality ends up being based significantly on included features. And in terms of features, Palm is - to put it mildly - simply not competitive. Not even close. Dual CF/SD expansion, dual Wi-Fi/Bluetooth wireless, user-replaceable batteries, VGA screen... these are specs that make PDAs "more functional". Solly Cholly.

TVoR

Thank you for your post TVoR. And I personally want to thank you for the more polite tone. I've followed some of your other discussions, and while you obviously have a lot of knowledge about these issues and some very interesting things to say, I've also noticed that you have a very animated and spirited style at other sites! That can be a bit too harsh for the friendly discussions we try to foster here at MR, so we greatly appreciate your considerateness concerning the style of your posts here. (It doesn't take much for us to edit or delete a post here if it becomes harsh, because the tone of the discussions is very important to us.)

Multitasking is the way of the future because it removes constraints that would otherwise waste a lot of time. The advantages are most apparent in wirelessly connected PDAs, but even unconnected PDAs can benefit from multitasking. The ability to browse the Internet while downloading email, listening to MP3s and copying text at will to a text editor requires "multitasking" (in the simplest meaning of the word). Why would anyone want to do multiple tasks sequentially when they can be done either at the same time or without having to waste time restarting programs? I think we agree here. It's central to the functioning of advanced devices. But isn't this all stuff that Cobalt can handle?

In practice, the ability to quickly switch between apps conferred by having a multitasking OS is the least important advantage over a non-multitasking OS. The difference in ease of app switching between PPC + WisBar and PalmOS + McPhling is arguably rather trivial. Where PalmOS falls flat on its face is in its (dis)ability to perform tasks concurrently. Constantly stopping and starting apps, disconnecting and reconnecting to the Internet, etc. adds a needless burden to the use of a PDA.I think that we also agree here. In fact, Dianne H had acknowledged that even Cobalt still falls a little short in this area so far because it's the internals that have been the primary focus and the UI improvements that depend on some of that infrastructure is coming next. I'm interested as to why you think the stopping and starting of apps is a burden to the user, though. If programs are written properly, isn't that transparent to the user as long as there are separate threads handling the background work like internet connections?

For years I've argued in favor of PalmLinux - a Unix-based platform running Palm apps. Last year Ms. Hackborn berated me on another site for having the temerity to suggest PalmLinux was a good idea. Now it would appear her employer agrees I was right all along. Cobalt is merely a "baby step" in the right direction (towards true multitasking), but Palm/PalmSource has a LOOOONG way to go at this point in time.A lot has changed over the years. Isn't it to be expected that people with vision are going to see valuable directions before it is safe enough to be right for a company to bet its future on it? I don't know anything about those discussions, but from what I've heard so far, I'm glad that we are headed to Palm for Linux. BTW, I know Dianne personally, and find it hard to believe that she berated you unprovoked! I know there seems to be some history there between the two of you, and that you tend to butt heads here and there, and it's very interesting to see different sides of a discussion, but please remember that all discussions here MUST remain polite! (If I sound a bit paranoid that the discussion might turn ugly, well.... I am! Because I've seen it go that way too much. So just be aware that things have to stay polite here. I don't want to lose out on anyone's thoughts, but I have to insist on politeness. ;) )

... The biggest question right now is whether or not PalmSource can solve all of the issues around porting Cobalt to a Linux kernel before their market loses interest completely and moves en masse to an alternate OS. PalmSource has claimed PalmLinux will be ready before mid 2006. I'll believe that when I see it. Because multitasking will soon be an essential OS feature, if Palmsource fails to deliver on its PalmLinux promise it will probably be game over for the platform. The move to PalmOS for Linux is definitely a challenge for PalmSource. Both making the move and getting devices rolled out with it. It's no walk in the park, but it's something they are committed to, so we'll just have to watch and see how well they execute. That's something that I asked Michael Mace about, and he said that execution is the most important thing for them now as they try to accomplish some significant things in the next few years. And they have to keep their focus and not try to do everything at once with their limited resources. But I really haven't heard them hyping Palm for Linux too much, nor promising any dates. They showed us the roadmap in San Jose, and they made it very clear what was done, in progress, and just projected. They also said it was a roadmap and a plan, not a promise. I don't see any reason to doubt them right now (they seem to have performed pretty well with the move to Garnet and the move to Cobalt, except for the lack of products on the market yet). But whether they roll out Palm for Linux in June 2006 or June 2007 probably doesn't determine the fate of the company. They would lose a lot of momentum and revenue, but I don't know that it's life or death for them as long as the existing Cobalt is viable.

I talked to one of the vendors working on a Cobalt smartphone, and was amazed to hear that it was actually better for them and easier to build the phone on Cobalt than Garnet. Their story was not about all the problems with Cobalt, but how it solved a lot of the problems that they would have had to do themselves if they had used Garnet.

So, yeah, it's a challenge to get to Palm for Linux, but I guess at the moment I'm a believer that they're on track and will get it done.

It's interesting to note that PalmSource - a company that supposedly has such UI advantages over PPC - has repeatedly failed to make any improvements to that UI. A tabbed interface (e.g. LauncherX) and rapid app switching (e.g. McPhling) are obvious advances to the PalmOS UI that are still left to third party developers to provide. Yeah, that may be a bit of a blind spot for PalmSource, but it also goes back to the matter of their focus, I think. UI improvements will pick up soon. Even then, maybe not as fast as we'd like because of the huge market for feature phones that they are also after.

It remains to be seen if Palm will even provide an intuitive way to cycle between open threads in Cobalt. I've suggested a customized browser-style tabbed UI, or better yet, showing icons of all open applications on the DIA. A tabbed UI would be really cool on a T5 or LD, with the bigger screens. But I'm not sure I'd want it on a tiny phone screen. I like the idea of showing the icons of open apps, but again probably only for the larger screen devices. How about simply an icon that brings up a drop-down task/app list, and the option to switch to it or close it if it's still running in the background. Heck, maybe even pretend that recently used apps are still running and also offer to close the ones that aren't even running just so people feel more at home with it!

Now we hear talk of an ambitious UI code named "Rome". Why can't PalmSource just fix the bugs and polish its current OSes before heading off on yet another wild goose chase? The lack of focus and praticality that killed Be seems to "Be" rearing its ugly head again...

TVoRYou don't really believe that it makes sense to stop developing and fix all the bugs do you? I work with development teams at my company and we all would love the opportunity to rewrite systems or work on the portions of the app that are the biggest pain in the neck to maintain. But there has to be a real business justification to do something like that. I think that's one of the fortunate things about the work PalmSource is doing on Cobalt and Palm for Linux, because they have apparently had the opportunity to a lot of the kinds of "fixing" you are referring to. It's a rare opportunity, so I hope they took good advantage of it! And, while it may not happen soon, I'm actually kind of excited to hear about the next "wild goose chase", aka "next big thing" from PalmSource. But I'm pretty optimistic, and think it might just be really neat!

I'm curious... you seem to have some significant ties or interest or inside scoop with the BeOS world. Can you share anything about your background that will help us understand where you are coming from?

Thanks again for your thoughts. You're welcome to disagree with everything I've said, but just please be nice!

I'm noticing that some people here are confusing "multitasking" with "multithreaded"... just be careful, they're not the same thing.

In any case, when/if the underlying kernel (now purported to be Linux) supports true multitasking, it only makes sense to allow developers to call the API that exposes those threads in their individual applications if they want to. For those that don't need it, the OS shouldn't enforce the use of it, unless its buried in a transparent API call that handles it automagically.

Multitasking is the way of the future because it removes constraints that would otherwise waste a lot of time.Multitasking isn't THE answer, but it is AN answer to some problems. It can cause more problems than it solves in some cases, depending on your architecture and hardware.

For years I've argued in favor of PalmLinux - a Unix-based platform running Palm apps. Last year Ms. Hackborn berated me on another site for having the temerity to suggest PalmLinux was a good idea. Now it would appear her employer agrees I was right all along.<smirk> Get in line, I was publically extolling the switch from AMX back in 1997/1998 or so, and at that time, Linux was a viable candidate. Its even moreso now, but it will take quite a lot of development time on their part to make it work right.

I still hope that they don't think their "move to Linux" will somehow garner them thousands of existing Linux and Open Source developers to do their development for them. It just won't happen.

It appears that Cobalt is little more than a glorified beta version of Palm's long overdue saviour: PalmLinux.Except that it has absolutely nothing at all to do with Linux or the underlying kernel running the device itself.

The biggest question right now is whether or not PalmSource can solve all of the issues around porting Cobalt to a Linux kernel before their market loses interest completely and moves en masse to an alternate OS.People don't choose their gadgets based on the OS that those gadgets run... they choose their gadgets because it solves a need that they have for the device (playing mp3s, managing PIM data, checking email while away from the office, etc.)

Do you know what version of firmware and what embedded OS your microwave runs? What about your television remote control? Why don't you care? Because they do exactly what is expected of them, without any problems. The only time people need to know what operating system their "Thing" runs, is when things go wrong and they need to fix it or find an alternative solution to solve the problem. When things work, people don't notice them.

People won't "move en masse to an alternate OS" just because Palm doesn't move to Linux. They might consider it when the device stops suiting their needs, but thousands of others who have never used a PDA before will find that Palm suits their needs perfectly.

PalmSource has claimed PalmLinux will be ready before mid 2006. I'll believe that when I see it. Because multitasking will soon be an essential OS feature, if Palmsource fails to deliver on its PalmLinux promise it will probably be game over for the platform.Sure, and BSD is dead and Apple is switching to Intel... er, ok, maybe not that last one <grin>

Seriously though, the platform won't be dead if their move to Linux doesn't succeed. They have a HUGE growing market in the smartphone and kiosk arena, especially with their recent acquisition in China. Don't be fooled, there are millions of PalmOS licenses being sold per-year, and not just on the devices you can buy at OfficeMax or Staples. Don't forget about the OEMs like Kyocera, Samsung, Sony (yes, still producing PalmOS devices), Acceca, Symbol, and about 2-3 dozen others.

It's interesting to note that PalmSource - a company that supposedly has such UI advantages over PPC - has repeatedly failed to make any improvements to that UI. A tabbed interface (e.g. LauncherX) and rapid app switching (e.g. McPhling) are obvious advances to the PalmOS UI that are still left to third party developers to provide.That is exactly what has made PalmOS the enormous success that it has been since 1996. That's close to 10 years of PalmOS devices out in the market. Without third-party support, your platform is dead.

Also, lets not forget how much they'd piss off the authors of applications that fit the niche you're suggesting. Let's say that Palm decided to incorporate LauncherX's capabilities into their main launcher (no offense to the author of LauncherX, Bozidar Benc, who died last year), including tabs. What happens to the people who want to buy LauncherX?

The key is to keep the interface as absolutely simple as possible, while keeping the powerful API underneath, exposed via the SDK, so authors can extend the capabilities and create a market for third-party software to keep the device market flourishing. If you piss off your developers by consuming their market, you're going to lose a LOT of users, and a LOT of developers.

Also, there may be patent or licensing issues related to some of the PalmOS applications out there. Just because "Tabs Are Cool" in your opinion, doesn't mean that Palm can just start using them.

It remains to be seen if Palm will even provide an intuitive way to cycle between open threads in Cobalt. I've suggested a customized browser-style tabbed UI, or better yet, showing icons of all open applications on the DIA.Not everyone likes that approach. Do you have an alternate for those who do not?

Also, stop thinking with a Windows mindset. Not everyone wants a desktop on their PDA. They may think they do, but that's because they're confused about how they access their data. The important thing is their data, their documents, etc. You don't need to port Microsoft Word (and its horribly unusable UI) to a PDA just to view and edit documents. The same thing goes for web browsing, email, calendaring, and so on.

Likewise, you don't need a "Start Bar" or "titlebars" or windowframes or abnormally-large scrollbars, etc. to interact with your data. Look at how much power the iPod put into 1 wheel. With Palm (as with some newer window managers coming out to service embedded devices), applications run modal, with full context, as they should. You shouldn't have a titlebar, unless you can grab it and move the window around. If you can do that on a 320x320 PDA screen, something is wrong, because its a horrible waste of space, resources, and code to allow that behavior.

Simple is best, which is why Palm still controls the majority of this market.

Now we hear talk of an ambitious UI code named "Rome". Why can't PalmSource just fix the bugs and polish its current OSes before heading off on yet another wild goose chase? The lack of focus and praticality that killed Be seems to "Be" rearing its ugly head again...Now here's a point I think we agree on. I've seen this time and time and time (and time and time) again with USRobotics -> 3Com -> Palm -> Palmsource -> Palm.

Part of the problem is likely due to attrition and turnover. If people keep jumping ship or getting laid off, passing code and projects to others to maintain can get overwhelming and ugly, especially if those people can't code. Look at how Palm jumped on the OSS tools to help embrace their developers, tried to "own" them, and rapidly dumped them when they realized they couldn't (POSE, prc-tools, pilrc and 1/2 dozen others). They're now on their... what... third or fourth kernel rewrite? And lets not even get into Protein, PACE and all of the other alliteration buzzwords that start with "P" here.

I noted an interesting fact which Dianne alluded to. It will be possible, under cobalt, to write the whole app (including the GUI) to run as a thread in the background. If this is simple, it would save a programmer a lot of work in the other parts of the program to save state properly and enable messaging between the parts of the program.

Could this be a way to shoe-horn multi-tasking into Cobalt for ALL apps, by hook or by crook?

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?

Surur

Who cares if they're more stable, if they're less functional?

Also, it shouldn't take any "effort" to make something stable. You're a user of the device. It should be stable by default. If it isn't, its broken. Find another vendor.

Are pocketpcs less functional? Methinks not. All one has to do is re-read Alexanders's thread on how he downloads email, rss, and listens to mp3s in the background while he is playing a game of minesweeper.

The problem is Palm didnt have that capability and insisted no-one wanted it. Now that the proof is that people want it (just look at sales), palm is all over it, but cobalt is vaporware, and probably wont comeout.

The only place at this point where palm is aheadand that is the treo 650. That is a verynice machine and the only problem with it is the palmOS :)

Will PalmLinus fix the problem of having to convert everything to .prc, .pdb from .txt, .doc, .html, etc? That is such a freakin pain...

I've been a fan of handhelds for the past five years or so and although Windows Mobile devices seem technologically superior, Palm OS devices were always a step ahead in usablity. What happened lately, me thinks, is that PalmOne touched a nerve somewhere by trying to release "new" handhelds in the embodiment of "old" technology. For a while that seemed to work fine; but then even the most die heart Palm fans were wondering if PalmOne wasn't up to the challenge anymore. There was a lot of talk about Cobalt, and yet we still see PalmOne devices using an operation system which core goes back more than seven years.

Is Cobalt vaporware? I don't think so. I think PalmSource is trying hard to do everything right this time! This is not only about finishing and releasing an advanced operation system. It is also about winning new licensees and about losing some of the dependance from PalmOne's major market share among Palm OS devices. PalmSource is a healthy company with lots of resources, and I don't see a reason why they should fail in bringing out an OS that will even make the hearts of WM die hearts beat faster again.

Thank you for your post TVoR. And I personally want to thank you for the more polite tone. I've followed some of your other discussions, and while you obviously have a lot of knowledge about these issues and some very interesting things to say, I've also noticed that you have a very animated and spirited style at other sites! That can be a bit too harsh for the friendly discussions we try to foster here at MR, so we greatly appreciate your considerateness concerning the style of your posts here. (It doesn't take much for us to edit or delete a post here if it becomes harsh, because the tone of the discussions is very important to us.)

Harsh? Moi? You must have me confused with some other Voices you're hearing. ;)

I think we agree here. It's central to the functioning of advanced devices. But isn't this all stuff that Cobalt can handle?

Possibly. Cobalt can do multithreading. If handled correctly, from a user's perspective this can potentially be almost as good as true multitasking. Depending on the implementation + the resources required of running apps + the resources available, there will be restrictions on what apps can run at the same time. 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.

I think that we also agree here. In fact, Dianne H had acknowledged that even Cobalt still falls a little short in this area so far because it's the internals that have been the primary focus and the UI improvements that depend on some of that infrastructure is coming next. I'm interested as to why you think the stopping and starting of apps is a burden to the user, though. If programs are written properly, isn't that transparent to the user as long as there are separate threads handling the background work like internet connections?

I was actually referring to the inability of PalmOS 5 to perform multitasking.


A lot has changed over the years. Isn't it to be expected that people with vision are going to see valuable directions before it is safe enough to be right for a company to bet its future on it? I don't know anything about those discussions, but from what I've heard so far, I'm glad that we are headed to Palm for Linux. BTW, I know Dianne personally, and find it hard to believe that she berated you unprovoked! I know there seems to be some history there between the two of you, and that you tend to butt heads here and there, and it's very interesting to see different sides of a discussion, but please remember that all discussions here MUST remain polite! (If I sound a bit paranoid that the discussion might turn ugly, well.... I am! Because I've seen it go that way too much. So just be aware that things have to stay polite here. I don't want to lose out on anyone's thoughts, but I have to insist on politeness. ;) )

Innovate or die. Palm has failed to innovate over the years, preferring to rest on their laurels. While not spending the money on R + D/thinking ahead saves money in the short term, this "strategy" also leaves a company dead in the water when the market changes. 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. Any company that fails to employ people with vision who's job is to push the envelope is a Dead Company Walking™. And before I get too self-congratulatory about my own visionary skills, in reality anyone who knows anything about PDAs and cellphones could see that PalmLinux was needed at least as far back as in 2000-2001. The problem at that time was limitations of the Linux kernel. I don't think there was even an ARM Linux project for PPC until just a couple years ago. The bottom line is Palm (a.k.a. the "completely separate Palm Companies™") is not some Mom and Pop corner store and has no excuse for the OS stagnation we've seen. They got lazy and greedy selling $400 Palm Vx that cost $50 to make and failed to innovate both their hardware and software. Now they're paying the price.

Ms. Hackborn's savage attack on me was completely unprovoked. I only gently prodded her with a stick once or twice. While she was sleeping. ;)

Please note: I'm always polite.


The move to PalmOS for Linux is definitely a challenge for PalmSource. Both making the move and getting devices rolled out with it. It's no walk in the park, but it's something they are committed to, so we'll just have to watch and see how well they execute. That's something that I asked Michael Mace about, and he said that execution is the most important thing for them now as they try to accomplish some significant things in the next few years. And they have to keep their focus and not try to do everything at once with their limited resources. But I really haven't heard them hyping Palm for Linux too much, nor promising any dates. They showed us the roadmap in San Jose, and they made it very clear what was done, in progress, and just projected. They also said it was a roadmap and a plan, not a promise. I don't see any reason to doubt them right now (they seem to have performed pretty well with the move to Garnet and the move to Cobalt, except for the lack of products on the market yet). But whether they roll out Palm for Linux in June 2006 or June 2007 probably doesn't determine the fate of the company. They would lose a lot of momentum and revenue, but I don't know that it's life or death for them as long as the existing Cobalt is viable.

I heard a few people say at DevCon that PalmLinux was expected in the first half of 2006. Here's a copy of the timeline slide from the PowerPoint presentation they gave at DevCon: http://www.palmfocus.com/images/summit/2005/large/img_4978.jpg We're now 18 months after Cobalt was supposedly first unsheathed and there are still no devices shipping with Cobalt. Cobalt has become the spurned beta for PalmLinux. Not too many companies are going to want to pay PalmSource for the "privilege" to become Cobalt beta testers. Meanwhile, PalmOS 5 (FrankenOS™) is collapsing under the weight of all the things it's now being expected to do. Does PalmSource think PalmOS 5 can keep going for another 2 years when PalmLinux is FINALLY ready for prime time?

I talked to one of the vendors working on a Cobalt smartphone, and was amazed to hear that it was actually better for them and easier to build the phone on Cobalt than Garnet. Their story was not about all the problems with Cobalt, but how it solved a lot of the problems that they would have had to do themselves if they had used Garnet.

I would hope Cobalt is easier to build a phone around than PalmOS 5! PalmOS 5 is a rickety, hacked-up kludge of an OS that wasn't supposed to still be around. Cobalt has features purpose-built for ease of use in smartphones. I thought this was a well-known fact.

So, yeah, it's a challenge to get to Palm for Linux, but I guess at the moment I'm a believer that they're on track and will get it done.

Palm needs more True Believers like you. Just remember: if they wake you up one night offering you Kool-Aid, don't drink it!

Yeah, that may be a bit of a blind spot for PalmSource, but it also goes back to the matter of their focus, I think. UI improvements will pick up soon. Even then, maybe not as fast as we'd like because of the huge market for feature phones that they are also after.

To not update the PalmOS UI after 9 years is beyond ridiculous. It's inexcusable that Palm has not bothered to try and improve on Rob Haitani's original UI work. I feel the UI work he and his team at Handspring performed when they hacked creaky old PalmOS 5 into the uber-slick Treo 600 OS is simply astounding. I'd rather have a polished version of the Treo 600 OS running on PDAs with D-pads than any of the subsequent buggy iterations of PalmOS we've seen over the past two years.

A tabbed UI would be really cool on a T5 or LD, with the bigger screens. But I'm not sure I'd want it on a tiny phone screen. I like the idea of showing the icons of open apps, but again probably only for the larger screen devices. How about simply an icon that brings up a drop-down task/app list, and the option to switch to it or close it if it's still running in the background. Heck, maybe even pretend that recently used apps are still running and also offer to close the ones that aren't even running just so people feel more at home with it!

Icons on the DIA selectable by a D-pad and McPhling-style pop-up lists could both work well. The key to effective "Zen of Palm" UI design is minimizing the need for extra movements/taps + also minimizing the need for stylus use. The Treo 600 team understood this better than any other set of PDA designers I've ever seen.

You don't really believe that it makes sense to stop developing and fix all the bugs do you? I work with development teams at my company and we all would love the opportunity to rewrite systems or work on the portions of the app that are the biggest pain in the neck to maintain. But there has to be a real business justification to do something like that. I think that's one of the fortunate things about the work PalmSource is doing on Cobalt and Palm for Linux, because they have apparently had the opportunity to a lot of the kinds of "fixing" you are referring to. It's a rare opportunity, so I hope they took good advantage of it! And, while it may not happen soon, I'm actually kind of excited to hear about the next "wild goose chase", aka "next big thing" from PalmSource. But I'm pretty optimistic, and think it might just be really neat!

Ummm... what's the point of putting out buggy, half-baked software and then rushing to put out a new version with more features before you've corrected bugs? Microsoft has been doing that sort of nonsense for years and we all pay the price for that corporate "strategy". It's a shame to see Palm adopting the same sloppy way releasing and supporting their products. I'd rather see an intuitive, efficient PalmOS that does a few things REALLY well than a bloated, buggy, ill-conceived mess that has a ton of incompletely-developed features. PalmOS is starting to sound more and more like PPC these days...

I'm curious... you seem to have some significant ties or interest or inside scoop with the BeOS world. Can you share anything about your background that will help us understand where you are coming from?

Thanks again for your thoughts. You're welcome to disagree with everything I've said, but just please be nice!

You mean like am I a jilted/fired former Be employee? Was I once spurned by Dianne at a Be connference? Does Pépé Gassée owe me money from a bar bet from 1998? Am I a former Be investor that lost their shirt when Gassée got greedy and turned down the generous mega-deal Apple offered to get BeOS as the next-generation MacOS? Ummmmm... no.

TVoR

Multitasking isn't THE answer, but it is AN answer to some problems. It can cause more problems than it solves in some cases, depending on your architecture and hardware.

Yes, but if implemented correctly multitasking is always the best option.

<smirk> Get in line, I was publically extolling the switch from AMX back in 1997/1998 or so, and at that time, Linux was a viable candidate. Its even moreso now, but it will take quite a lot of development time on their part to make it work right.

Well I first spoke of PalmLinux July 1, 1996. Can you beat that, Homeboy? Bring it on!

I still hope that they don't think their "move to Linux" will somehow garner them thousands of existing Linux and Open Source developers to do their development for them. It just won't happen.

True. But PalmSource seems naive enough to believe it will. "PalmLinux will save us. I know it will."

Except that it has absolutely nothing at all to do with Linux or the underlying kernel running the device itself.

Except that almost everthing in Cobalt above the Cobalt kernel is expected to be used in PalmLinux. Nice try, Bubba.

People don't choose their gadgets based on the OS that those gadgets run... they choose their gadgets because it solves a need that they have for the device (playing mp3s, managing PIM data, checking email while away from the office, etc.)

Yes, and when those gadgets can't do things (like multitask) that everyone else's gadgets can do, they choose the more competitive gadgets.

Do you know what version of firmware and what embedded OS your microwave runs? What about your television remote control? Why don't you care? Because they do exactly what is expected of them, without any problems. The only time people need to know what operating system their "Thing" runs, is when things go wrong and they need to fix it or find an alternative solution to solve the problem. When things work, people don't notice them.

See previous response.

People won't "move en masse to an alternate OS" just because Palm doesn't move to Linux. They might consider it when the device stops suiting their needs, but thousands of others who have never used a PDA before will find that Palm suits their needs perfectly.

See previous response.

Sure, and BSD is dead and Apple is switching to Intel... er, ok, maybe not that last one <grin>

Stranger things have happened. Some people even say Michael Jackson might win his court case!

Seriously though, the platform won't be dead if their move to Linux doesn't succeed. They have a HUGE growing market in the smartphone and kiosk arena, especially with their recent acquisition in China. Don't be fooled, there are millions of PalmOS licenses being sold per-year, and not just on the devices you can buy at OfficeMax or Staples. Don't forget about the OEMs like Kyocera, Samsung, Sony (yes, still producing PalmOS devices), Acceca, Symbol, and about 2-3 dozen others.

As soon as a platform/app/company loses momentum, the smell of death is upon it. It's very difficult to reverse a downward spiral unless a company is either a) very lucky or b) has leadership ***COUGH Steve Jobs COUGH*** capable of creating a cult-like following for its products. Anyone remember Netscape? Wordperfect? K-Mart?

That is exactly what has made PalmOS the enormous success that it has been since 1996. That's close to 10 years of PalmOS devices out in the market. Without third-party support, your platform is dead.

There comes a time when a mature company has to start absorbing what third party vendors do into its own product. It's called evolving.

Also, lets not forget how much they'd piss off the authors of applications that fit the niche you're suggesting. Let's say that Palm decided to incorporate LauncherX's capabilities into their main launcher (no offense to the author of LauncherX, Bozidar Benc, who died last year), including tabs. What happens to the people who want to buy LauncherX?

Tough. The world isn't perfect, is it? Those were the same (weak) excuses Palm used for years as justification for not spending a dime to improve PalmOS. Then they bought MultiMail and licensed Desktop To Go. Did users complain? And last I checked, SnapperMail, Quickoffice, etc were all being sold, while weaker apps were falling by the wayside. Survival of the fittest, Baby! Darwin was right after all. Wow. Maybe Microsoft knows what they're doing by absorbing the leading 3rd party apps into the Microsoft Collective year after year. Resistance is futile™...

The key is to keep the interface as absolutely simple as possible, while keeping the powerful API underneath, exposed via the SDK, so authors can extend the capabilities and create a market for third-party software to keep the device market flourishing. If you piss off your developers by consuming their market, you're going to lose a LOT of users, and a LOT of developers.

Bull. See previous response. The key is a clean, simple, POWERFUL, FLEXIBLE interface. Rob Haitani understands this. PalmSource apparently feels UI is a low priority. (Oh, I forgot - "Rome" will fix everything! Guess what? Rome wasn't built in a day...) By the way, most users don't give a rat's arse about developers. All they want is to be able to do everything they need to do as easily as possible for as little money as possible. Scouring the Internet for the top apps/utilities in an effort to optimize their PDA is not the typical user's idea of fun. Palm seems oblivious to this fact.

Also, there may be patent or licensing issues related to some of the PalmOS applications out there. Just because "Tabs Are Cool" in your opinion, doesn't mean that Palm can just start using them.

PalmSource would not lose a lawsuit over a tabbed interface or icons on a DIA. Has it come down to this now? Avoid improving your product out of fear of being sued? Please.

Not everyone likes that approach. Do you have an alternate for those who do not?

Easy. Give users the option to choose which interface they prefer. Pick up a TH55 or VZ90 to get a feel for how flexible UI can be in the same device.

Also, stop thinking with a Windows mindset. Not everyone wants a desktop on their PDA. They may think they do, but that's because they're confused about how they access their data. The important thing is their data, their documents, etc. You don't need to port Microsoft Word (and its horribly unusable UI) to a PDA just to view and edit documents. The same thing goes for web browsing, email, calendaring, and so on.

Likewise, you don't need a "Start Bar" or "titlebars" or windowframes or abnormally-large scrollbars, etc. to interact with your data. Look at how much power the iPod put into 1 wheel. With Palm (as with some newer window managers coming out to service embedded devices), applications run modal, with full context, as they should. You shouldn't have a titlebar, unless you can grab it and move the window around. If you can do that on a 320x320 PDA screen, something is wrong, because its a horrible waste of space, resources, and code to allow that behavior.

No one said anything about Windows. Tabs are not exactly a concept unique to Windows - as anyone with a filing cabinet can tell you. It's sad to see Microsoft-haters pretend that just because a design concept is used by a Microsoft product, suddenly it becomes Evil Incarnate. :rolleyes:

Simple is best, which is why Palm still controls the majority of this market.

Are you really sure "Palm still controls the majority of this market"?

http://www.palminfocenter.com/comment_view.asp?ID=7788#106629

Now here's a point I think we agree on. I've seen this time and time and time (and time and time) again with USRobotics -> 3Com -> Palm -> Palmsource -> Palm.

Reinventing the wheel continues to hurt PalmSource. Only now they've run out of both time and money. At least when PalmSource is bought out by Palm/pa1mOne next year they'll have more time to mess around shining sh*t.

Part of the problem is likely due to attrition and turnover. If people keep jumping ship or getting laid off, passing code and projects to others to maintain can get overwhelming and ugly, especially if those people can't code. Look at how Palm jumped on the OSS tools to help embrace their developers, tried to "own" them, and rapidly dumped them when they realized they couldn't (POSE, prc-tools, pilrc and 1/2 dozen others). They're now on their... what... third or fourth kernel rewrite? And lets not even get into Protein, PACE and all of the other alliteration buzzwords that start with "P" here.

Don't get me started. I wish someone could tattoo the words "Keep It Simple, Stupid" on every former Be/PalmSource employee's forehead. Then maybe they'd think twice before trying to come up with yet another harebrained Rube Goldberg-style "solution".

TVoR

Seriously though, the platform won't be dead if their move to Linux doesn't succeed. They have a HUGE growing market in the smartphone and kiosk arena, especially with their recent acquisition in China. Don't be fooled, there are millions of PalmOS licenses being sold per-year, and not just on the devices you can buy at OfficeMax or Staples. Don't forget about the OEMs like Kyocera, Samsung, Sony (yes, still producing PalmOS devices), Acceca, Symbol, and about 2-3 dozen others.


Looks like the numbers don't back you up, Bubba. Besides from pa1mOne, it appears that not a lot of PalmOS devices are being sold these days.

http://www.palminfocenter.com/comment_view.asp?ID=7788#106637

And if you think China will save Palm, guess again. Ask yourself just how many American companies have been allowed to make money in that repressive Communist country. Palm will just get USED by China just like every other company that has gone over there wide eyed, drooling over the potential of access to a billion person market, only to return after being taken for a ride, Beijing-style.

Okay, okay. We can argue about the numbers all day. And maybe another thread for that might be fun to do. But in this one, let's try to stick a bit closer to the multitasking/multithreaded discussion, please.

It sounds like part of the argument from TVoR is that PalmSource can't deliver on Palm for Linux in the timeframe that's planned, and that they have not implemented proper multitasking, a decent modern UI, or resolved their existing software issues yet, and that unless they make some strides forward remembering "simplicity first" for the user experience, the market will slip away, and might even be slipping away now depending on what numbers you read.

Those are all points that can be discussed and probably would create a lot of interest, but I think it's way too much to tackle in a single thread, so let's try to focus on the multi-tasking and application switching in this thread. I'm with 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?The only things that have been suggested as disadvantages of saved state that I'm aware of are: 1) It might be harder to develop under that paradigm, and 2) If not done right by developers, it damages the user experience.

And an advantage of the PalmOS approach is that you don't waste the system resources running multiple applications when you don't need to.

But I haven't seen anything that really indicates to me that there's all that much advantage on either side of the fence...

Heading back to the multitasking/state-saving discussion. surur mentioned this a few posts before and he was very right: we are not any longer talking about Motorola Dragonball (http://en.wikipedia.org/wiki/Dragonball) 33Mhz CPUs here. We are now talking about the 5th generation of the ARM microarchitecture (http://en.wikipedia.org/wiki/ARM_architecture) - more precisely Intel's (http://www.intel.com/design/intelxscale/) XScale (http://en.wikipedia.org/wiki/Intel_XScale) processor, which includes support for superfast multitasking (i.e. context switching) and multimedia environments.

It seems some people still believe that multitasking apps are a waste of resources. Totally unwarranted, I may add. There is a shareware tool called Supertasks 2.0 (http://www.softwareandson.com/SuperTasks/index.php) for Pocket PCs which depicts CPU consumption of individual tasks, processes and even services. You'll see, if you try it, that even if you run ten applications at once, including an mp3 audioplayer and some Internet-based downloads, that with a standard XScale 416 MHz CPU, no process is using more than 4-5% total CPU.

So to all multitasking naysayers: what is the benefit of state-saving and giving a process 100% of available CPU resources if that process won't be using more than 4-5% of it?

The drawback to multitasking is that applications have to compete for memory usage. You don't have a swapfile to flush unused memory pages to, like you have on the desktop. That said, if a process really uses so much memory that this becomes a problem, it's probably not suitable to run on a handheld in the first place.

The drawback to multitasking is that applications have to compete for memory usage.
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.

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.

Agreed. I was just pointing out a drawback to multitasking, not arguing for or against it. Incidentally, Windows CE allows an application to use up to 32Mb of memory, so MS did take memory usage into consideration.

I have not heard of this 32Mb limit in win CE. I have personally loaded some very large web pages (e.g. photo-shop contests) which used >50MB.

http://surur.sytes.net/screen3.gif

Surur

More on WM's memory management here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/advmemmgmt.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce30/html/threads30.asp
http://blogs.msdn.com/mikezintel/archive/2004/12/08/278153.aspx
http://cs856.watsmore.net/windowsce_arcd.pdf (PDF)

You can assign more than 32MB of memory in one process by using memory mapped files:
When a Windows CE-based device starts up, the operating system creates a single, 4-GB virtual address space, which all of the processes share. Part of this address space is divided into 33 "slots" of 32 MB each, one for each process's resources. As each process starts, Windows CE assigns it one of the available 32-MB slots. Slot zero is reserved for the currently running process.

When a process starts, the OS stores all of the dynamic-link libraries (DLLs), the stack, the heap, and the data section in the slot that is assigned to the process. DLLs are loaded at the top of the slot, and they are followed by the stack, the heap, and the executable (.exe) file. The bottom 64 kilobytes (KB) are always left free. DLLs are controlled by the loader, which loads all of the DLLs at the same address for each process.

In addition to assigning a slot for each process, Windows CE creates a stack for the primary thread and a heap for the process. The maximum number of threads that a process can maintain is dependent upon the amount of available memory. You can allocate additional memory outside of the 32 MB that is assigned to each slot, by using memory-mapped files or by calling the VirtualAlloc function to reserve or commit a region in the calling process's virtual address space.
If that is a good thing, I don't know. Laurens was mentioning the limit not to point out a disadvantage, I think, but a safe-guard by Microsoft to prevent process from misbehaving (by allocating too much of the total available RAM).

This really boils down to how the user will use the device. I think it's great that devices have become powerful enough that running multiple CURRENT apps is possible, but developers often max out a devices capability.

I prefer saved-state (with support of background threads) for the following reason:
A program will have nearly ALL resources available to it while it runs.

Until we develop a device that allows us to SEE multiple applications at once, there is little need to be running multiple entire programs at once. Even if you throttle down the CPU usage of a background app, it is still using a chunk of the heap RAM. I suppose you could try to move that RAM to a swap-space, but that means there will be a noticeable delay every time you switch.

However, as I said before, developers LOVE multi-tasking. It puts all the strain on the user instead. Now I have to deal with selecting what apps are active based on their use, CPU use, and memory use. How easy is the app to restart and get where I left off versus just letting it run in the background and suck down resources?

Developers do NOT like having to deal with multi-threading and save-states. It's a royal pain. But, as a user, I sure do like a program done right.

However, this is where I turn around and state that multi-tasking will be the future-wave anyways. Why? My Palm now has an obscene number of programs on it. It is naive to think that they are all programmed to play well with each other. My screen may be small, but 320x480 IS enough to start running "widgets" in the corners. Besides, some of today's programs are so large that re-starting takes more time than it would take to move swap-space back to the heap RAM. As for RAM, I remember a day when 2MB was considered plenty for both heap, databases, and programs. Now there is 245MB or RAM. There WILL be devices with sufficient RAM to do real multi-tasking.

In other words, we are now at the beginning where only games and video require ALL resources, so task-switching will become unnecessary. I prefer Palm's method...for now. I think PocketPCs were trying to be a laptop long before they had the power to do so, and their usability has suffered because of it. But I applaud Palm's switch to Linux and multi-tasking. The hardware has finally arrived (LifeDrive and T5), but now the software needs to catch up.

(How's that for seeing both sides?)
- Jim

I prefer saved-state (with support of background threads) for the following reason:
A program will have nearly ALL resources available to it while it runs.
I am not sure about HEAP allocation and such in Windows Mobile 2005, but unless you run out of memory, I have never had resource trouble when running multiple applications at once on a Pocket PC.

Until we develop a device that allows us to SEE multiple applications at once, there is little need to be running multiple entire programs at once.
Well, except for those who like to do multiple things at once, like Alex's example with the Internet applications. Btw, there is a tool called Seymour for PPC which allows you to SEE two running applications at once:
http://msmobiles.com/news.php/2294.html

How easy is the app to restart and get where I left off versus just letting it run in the background and suck down resources?
Like I said above, I don't see where resources are suck down when you run PPC applications in background.

In other words, we are now at the beginning where only games and video require ALL resources, so task-switching will become unnecessary. I prefer Palm's method...for now. I think PocketPCs were trying to be a laptop long before they had the power to do so, and their usability has suffered because of it. But I applaud Palm's switch to Linux and multi-tasking. The hardware has finally arrived (LifeDrive and T5), but now the software needs to catch up.
Totally agree with you here!

As you said, PPC's started of with the expectation that hardware will catch up, which is has. Now it has much less retooling to do than POS. There is actually a number of small programs that take advantage of multi-tasking by displaying stuff in a window. That task manager in my example picture is one of them. There is also sidex, which is a program launcher etc which swoops in from the side of the screen ( http://www.mtux.com/info_sx.aspx ), floating calculators (http://www.pocketgear.com/software_detail.asp?id=3424 http://www.pocketgear.com/software_detail.asp?id=5150 ) floating sticky notes and even an app that will split the screen. The ability is built-in, and people can and do use it.

Surur

I finally found the ultimate multi-tasking demonstrator.

http://www.handango.com/include/pictures/77902/seymour15.gif

Seymour allows you to work better with your Pocket PC by giving you the ability to view any two applications at once, including the Today screen. This lets you simplify how you work with your favorite applications and share data between them.

http://www.handango.com/ampp/store/PlatformProductDetail.jsp?siteId=1203&platformId=2&productId=40466&productType=2

If its running in the background you might as well show it also.

Surur

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:

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.

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...

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!

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.

@surur: I like the Seymour app you posted there. I can only think of a couple situations where I would use that...but I must admit that I really would like to have that WHEN I needed it. Mainly, it would be nice if I could have both my outliner and Word Doc available at once. Waiting for WordToGo to boot every time I switch gets a little old.

@Hackborn: Thank you for joining us! I must say your comments about your hardware constraints add a little light. Let me see if I can summarize properly (and correct me if I'm wrong):
You are unable to truly program for the high-end devices because Palm still wants the new OS to run on the economy devices. Hence, your comment about putting the Linux onto a 16RAM/16Flash device.

I really hope I got that wrong, because you are about to get rained with all kinds of comments about "holding back and crippling" the high-end devices for the sake of the economy devices. The fact that the Zire21/32 series actually uses POS5 is still a mystery to me. They have lo-rez screens, so compatibility is out the window, anyway. They should've been POS4 devices, so that POS5 could have been programmed for the big guns. You have a T5 and a Life-Drive. You should be programming to max out THOSE devices. Let the cheapies run on yesterday's OS for now. People who get the cheap stuff aren't looking for latest & greatest.

Whoa....way off topic. My apologies. Back on subject:
I do agree that some programs don't need to run in the background (addressbook, etc). Once again, does the load go to the developer or the user? A part of me would like to have something akin to the "nice" function in Linux: let me set the background priorities of apps. However, that feature itself would take a load.

Cooperative task-switching is great for squeezing the most performance out of a device, but it relies on all the programmers playing nice with each other. Multi-tasking has a high overhead cost. Remember how PPCs had a much more powerful processor, yet seem to run the same speed of POS4 devices? That's why.

Apple Computer use to do threaded task-switching, etc up to MacOS9. It made for a very fast system. However, many programs and extensions were starting to not play nice with each other. Stability was going down the tubes. Programmers were whining about how difficult it was to program for the Mac. Things had simply become too complex. Once the hardware became powerful enough, Apple switched to a robust, multi-tasking, protected memory system (OS X). Sure, it was a massive CPU-drain, but the new processors could take it, and now the user had stability and customized multi-tasking.

I love OS X on my G4, but it would have been silly to try to put that on my old PowerPC. When PocketPCs first came out, I saw it the same way: their design concept was stupid-silly.

But now we have the Hardware. I don't give a flying zip about your 16MB devices. Let the PowerPCs run MacOS9, and let the 16MB devices run POS5 or POS4. I want the LifeDrive running full-bodied, mutli-tasking Palm-Linux, not some diluted OS that was designed for a Zire31.

Okay, I'm done (for now). The PalmSource guys have done some great magic in the past, so I know they have some magic prepping for the future. I'm mostly fearful that PalmOne will mess up the hardware and force PalmSource to streamline and cripple their upcoming OS.

- Jim

You know, I think this thread and others like it point out a great opportunity for PalmSource to put out some simple whitepapers to clarify a few topics. It would be something that could be referred to over and over to clarify discussions. Heck, they could even put page and paragraph numbers so you could quote passages from a particular version in the average discussion. Topics like...
* PalmOne vs PalmSource (which will probably always be somewhat confusing even after the name change or PalmSource)
* How multitasking/mulithreading works in Garnet, Cobalt, PalmOS for Linux, and how it compares to Win Mobile
* Benefits of PalmOS
* Laymans explanation for NVFS and palm databases vs MS file systems
... and whatever other topics just keep coming up over and over and never seem to be clear. As long as it's not just Marketing fluff! ;)

I'll follow off-topic just briefly here, because it was an interesting point brought up, and then return on-topic.

Concerning the OS accomodating lower spec handhelds, I would have to say that I don't see it as a bad thing. Even so, I suspect that a lot of OS level adjustments can be made over time to grow with the hardware. But I think it is pretty nice to have a more powerful pda that really acts zippy. I feel the same way about desktops... it's horrible using them when things run slow, and sometimes you need the best desktops to get things zippy.

True, you only get benefit from faster CPU up to a point, but still I like hardware that can make up for sloppy apps that seem be so slow on the average handheld. Surely even third party developers have to consider some of the lower spec devices for the same reason -- to widen their market. I think it's good because the wider a market we see for the OS, the more PalmSource makes, and the more they can reinvest for the future. And, for good or bad, the biggest slice of the market is not in the top line spec devices, but the "average cell device" that is getting more and more powerful every year.

I second your thanks for Dianne's participation. Really cool stuff!

There will always be those of us frustrated with PalmOne and PalmSource, and there will certainly be many who just naturally prefer Pocket PC (which is okay because they have a great product also). But I am convinced that the more you learn about what PalmSource is really doing, and why, the more you respect their work and want to cheer for them to succeed. They more they succeed, the more great device choices we get to see in our hands! And even if you don't think they are making all the right choices, you have to at least get the feel that they are making some good choices and be excited about the great stuff that's coming. It's just hard to wait! ;)

Okay, back on-topic...

With regard to multitasking in Cobalt, remember that 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.So I think that with the exception of those shared threads not protecting as completely against inter-program interference, you can do pretty much the same basic things with Cobalt as Win Mobile multitasking. We may see it looking a lot better after some more UI changes which are coming after some of the core underlying and invisible work is done.

And I can't remember where, but I think I read somewhere that the way threads are handled can be changed as the hardware grows without major OS rewrites. (Not positive about that one.)

I think the UI is really the big deal here. With WinMobile you basically have a list of windows/apps that are running, and you don't have to worry about whether or not they are built to run in the background, or what state they will return in. You can even do some fancy things showing multiple applications at once on the screen, like we saw above. Pretty cool.

But don't forget that there are ways to do all that in Cobalt. Hopefully I don't have this all wrong. But the basic assumption seems to be one app on the screen being used at one time, which is pretty reasonable. (So you may not see those split screen apps for a long time, unfortunately.) But with such small handheld screens, especially in phones, you may not really want that too much. I think you can still have popup screens running in parallel with, say, a small overlay or popup or maybe cutout screen for something like the mp3 player while you are doing word processing. Or you can have various kinds of control bars to manage background processing for things like downloads. You could even have split screens for game interaction. But, yes, the applications are probably more responsible for managing how that works. That's another thing that will probably have to be improved in the OS.... support for developers to do that sort of thing more easily and gracefully.

Sounds like the state thing does matter, though, when you pull an app back up, and right now apps haven't really been able to do that well on PalmOS, so I suppose that is an indicator that the support structure isn't fully there yet. But all the other things that a user would (or should) care about seem to be relative to the UI design.

And I've seen enough to convince me personally that it's not just PalmSource blowing smoke, but that they have some pretty significant infrastructure work that's being done and UI work will move much faster very soon. Surely they are aware that their primary IP advantage in the Linux space is going to be UI and managing environments on mobile devices. That means that it's got to be a high priority on their UI work and they'll have to back it up with their internal resource allocation.

I don't think multitasking approaches are going to be significant enough to push many users to one camp or the other (unless people get caught up in the wake of the MS Marketing machine). Like I said, I haven't really heard any disadvantages to the PalmOS approach except some apps that don't handle state properly and some UI work that needs to be done to handle app switching on both WinMobile and PalmOS side anyway.

You are unable to truly program for the high-end devices because Palm still wants the new OS to run on the economy devices. Hence, your comment about putting the Linux onto a 16RAM/16Flash device.


One correction: in fact it is not nearly so much palmOne who wants Cobalt on lower-end devices, but rather other device manufacturers (in particular phone manufacturers) who have these lower-end requirements. Remember that PalmSource does the software; the hardware requirements come from the licensees we work with.

(And if you find it a little ironic that palmOne would be the one with the higher-end devices, while still not having a Cobalt device... well I do too!)

Btw, this is part of the explanation for why early on when Cobalt was introduced, Garnet was being positioned as the more phone-oriented product: the phone space tends to push down really hard into lower-end hardware, since it is so price and size competative, so from that perspective the lighter-weight Garnet seemed like a good choice for it. At it turns out, however, phones are also the devices that have the most need for some of the modern features in Cobalt, so it is really a much better platform for that market, as long as we don't go nuts with assumptions about how fast hardware capabilities are going to grow.

Personally, I think that we went from a system that was way under-powered for the hardware it was running on (Garnet), to one that is probably a little over-powered for the class of hardware we have right now. In the short-term, that means we ended up doing a little more work than expected to optimize parts of it, but we definitely have a good foundation on which to build for many years to come.


I really hope I got that wrong, because you are about to get rained with all kinds of comments about "holding back and crippling" the high-end devices for the sake of the economy devices.


Since we only do the software, I can't address the hardware in specific devices. However, in terms of the operating system, what this mainly means is that scalability is much more important in the software on these devices than it is on a desktop operating system.

This is something that we had in mind from day one when designing Cobalt, and that goal has gone into a lot of its architecture. In particular, as I recently discussed elsewhere, we think that one of the things needed to achieve better scalability is to have a lot more flexibility in how processes are used, instead of the traditional approach where an application is directly associated with its own process.

To achieve this, nearly all of the Cobalt system software is built on top of a standard component framework similar to COM or CORBA (it is called the Binder, if you've seen that mentioned elsewhere), but designed for system-level services as well. One of the main things a component system does is hide where a particular object lives -- you just make a call on an interface, and the object you are talking with can be in the same process as you or some other process. The caller doesn't care, and the component framework will implement this call as a direct function call or cross-process call as needed.

Because of this, we can basically decide, at runtime, how we are going to distribute the operating system and applications across processes, in any way we want. If we run everything in the same process, all the process and IPC overhead goes away, allowing you to run on much lower-end hardware. That doesn't mean you can't scale up to higher-end hardware, and in fact as time goes by we will be able to do some really nice stuff like run a web browser application in one process while a plug-in like RealPlayer that is embedded inside its web page can run in another process. That way, if the plug-in crashes, the browser itself is not disrupted at all, and there is no extra work required of the browser or plug-in to make this happen.

Truth in advertising: the current Cobalt kernel has a fairly embedded mindset (read "hard-coded") when it comes to processes, which limits how much we can use this aspect of the system. We do use this feature for things like running multiple applications in the background process, but today we can't go so far as to run everything in a single process. That should change when we move to Linux.


Cooperative task-switching is great for squeezing the most performance out of a device, but it relies on all the programmers playing nice with each other. Multi-tasking has a high overhead cost. Remember how PPCs had a much more powerful processor, yet seem to run the same speed of POS4 devices? That's why.


I am not sure about the terminology here -- no version of PalmOS has ever used cooperative task-switching, they have always been built on top of a pre-emptive multithreaded kernel. The limitation was that they only exposed one of those threads to applications, and all of the higher-level parts of the system (UI and other things) were single-threaded, so there was essentially no multithreading at all available to applications.


Apple Computer use to do threaded task-switching, etc up to MacOS9. It made for a very fast system. However, many programs and extensions were starting to not play nice with each other. Stability was going down the tubes. Programmers were whining about how difficult it was to program for the Mac. Things had simply become too complex. Once the hardware became powerful enough, Apple switched to a robust, multi-tasking, protected memory system (OS X). Sure, it was a massive CPU-drain, but the new processors could take it, and now the user had stability and customized multi-tasking.


I am not familiar enough with MacOS to say for sure, but I would suspect that development difficulties on it had little to do with "threaded task-switching." For example, the Amiga allowed multiple applications to run at the same time, with a full pre-emptive scheduler, but had no memory protection (processes) at all. Yet programming for it was really wonderful, especially compared to other personal computers at the time. And it was doing this on an 8MHz 68k CPU.

My impression is that MacOS was suffering from the same issues as Garnet (and Windows 9x) -- the entire architecture was originally designed as essentially a single-threaded system, with no memory protection. Trying to turn such a thing into a modern system with full processes and threads is really difficult, and in fact not the way to make that transition: MacOS X, Windows NT, and Cobalt all took the approach of designing a new modern system architecture underneath, and providing a new implementation of their existing APIs on top of it.

Generally multithreading doesn't introduce much overhead -- as I said, PalmOS has always been built on top of a multithreaded kernel. The big hit comes with memory protection, which is one of the basic reasons why Cobalt is significantly more heavy-weight than Garnet.

You know, I think this thread and others like it point out a
great opportunity for PalmSource to put out some simple whitepapers to clarify a few topics.


That is a really good idea. I'll try to talk with Michael Mace about it.


With regard to multitasking in Cobalt, remember that So I think that with the exception of those shared threads not protecting as completely against inter-program interference, you can do pretty much the same basic things with Cobalt as Win Mobile multitasking. We may see it looking a lot better after some more UI changes which are coming after some of the core underlying and invisible work is done.


Yep, they are functionally pretty similar. The most obvious thing missing from Cobalt is that we don't provide a standard user interface to manage multiple running applications. However, in a recent newsletter I wrote an article that described some APIs a developer could use to write their own application to do this. (Note that this isn't because we don't think this is an important issue, it is because we think it is important enough that we really want to do it right, and not just reproduce the desktop experience.)

(Btw, we don't have a per-process limit on the amount of RAM you can use. There is a limit on the total RAM all running applications can use, which can be arbitrarily configured for the device depending on how much RAM it has.)


But don't forget that there are ways to do all that in Cobalt. Hopefully I don't have this all wrong. But the basic assumption seems to be one app on the screen being used at one time, which is pretty reasonable. (So you may not see those split screen apps for a long time, unfortunately.) But with such small handheld screens, especially in phones, you may not really want that too much. I think you can still have popup screens running in parallel with, say, a small overlay or popup or maybe cutout screen for something like the mp3 player while you are doing word processing.


That is pretty much correct. There is one self-contained process running at a time as the "main application", and switching between main applications involves stopping the current one and starting a new one. However, the main application in no way owns the screen -- another application running at the same time as a "non-main" application (in the background process) can display a window whenever it wants, and the system will correctly multiplex it with other things on the screen. The window doesn't need to be full-screen; it can be a small dialog that floats on top of the main application's UI.

In fact, we support very sophisticated window compositing in Cobalt, so these secondary applications can do things like display a semi-translucent window that floats on top of other application windows, and allows pen events to go through to whatever is underneath. You can also create windows that have varying alpha levels -- for example, the on-screen graffiti window has a slightly translucent gray background to show you where it is, while the frames (showing the different graffiti areas) and ink in it are nearly or completely opaque. You can basically do whatever you want.

During our recent developer's conference, the LifeBalance people used this feature to write a background application that created a full-screen transparent window, in which they animated falling snowflakes. The effect was that you could be doing anything else on the device, while those snowflakes were falling down your screen on top of everything else. They had this running on one of the Cobalt devices that were floating around the conference.


Or you can have various kinds of control bars to manage background processing for things like downloads. You could even have split screens for game interaction. But, yes, the applications are probably more responsible for managing how that works. That's another thing that will probably have to be improved in the OS.... support for developers to do that sort of thing more easily and gracefully.


To be honest, right now we are not spending much time on adding ways to split the screen between multiple applications. Our big challenge is actually how to deal with smaller screens -- for example, a 2.2" diagonal screen is quite common. That kind of display is pretty darn small for just a single traditional PalmOS application, let alone trying to cram more than one on it.

It appears my lingo may be inaccurate on how the POS divides up the processes in the background. From the sounds of it, the OS chooses what tasks can be combined and which need to run on a separate thread, hence optimizing the overhead. I confess that I'm more of a desktop programmer than a PDA developer, for it seems my analogy of POS to the old MacOS9 is not exactly correct either. My point was that the current architecture of POS5 seems similar to the old Mac days in that a poorly-programmed application can monopolize all processing and RAM, and then crash the entire device if it glitched. The device is at the mercy of proper programming. Also, any multi-tasking is limited to what the programmer implements.

However, I just looked at my Tungsten|C and remembered those 26 Desk Accessories I have installed under the Zlauncher QuickLaunch feature. For the most part, I can do enough multi-tasking for now.

Once again, thanks for stopping by!

- Jim

It appears my lingo may be inaccurate on how the POS divides up the processes in the background. From the sounds of it, the OS chooses what tasks can be combined and which need to run on a separate thread, hence optimizing the overhead.


I wish! :) The current Cobalt is not nearly that good. That is, however, the kind of thing we are moving towards... though the main intent is to divide and combine processes dynamically. What is inside of Cobalt today includes a lot of the technology that will enable this, we just aren't to the point of making full use of it.


My point was that the current architecture of POS5 seems similar to the old Mac days in that a poorly-programmed application can monopolize all processing and RAM, and then crash the entire device if it glitched. The device is at the mercy of proper programming. Also, any multi-tasking is limited to what the programmer implements.


Oh yeah, absolutely. For the most part, that is no longer an issue in Cobalt. Because of the underlying support for protected memory and multithreading, if an application crashes we can catch it and recover as on a PC, and likewise if the application has become unresponsive we put up a dialog saying so and giving the user a chance to kill it.


Once again, thanks for stopping by!


You're very welcome, I hope it is useful!

Please note that the text of this post has been deleted because it was simply badgering, and that does not live up to the standards of this community. We welcome dissenting views from TVoR here, as well as from all other sources, but, as stated before, we insist on a respectful approach to sharing opinions, and this post was clearly not helpful to the discussion, andin fact makes a true discussion of the topics impossible.

Please feel free to PM me with any concerns, but we insist on making it possible for all of us to actually talk about the issues. Everyone is entitled to their opinions here, but politely and respectfully without badgering or personal attacks.

This post has been removed because of personal attacks. It's a shame because there were some interesting questions or points contained also. But we insist on respectful and polite postings, not bullying. We want to have actual adult discussions, not a 3rd grade online verbal brawl. [BobR]

TVoR, I think you understand our rules. Please follow them.

Quoting:

You're very welcome, I hope it is useful!
__________________
Dianne Hackborn
Manager, Application Frameworks, PalmSource Inc.
-----------------------------------------------

Even if it's not very useful for the, how do I be describe myself?, the dummies of the handheld community, it's awesome that you're willing to stop by and clarify points and discuss things. It's greatly appreciated