Laurens (http://www.mobileread.com/forums/member.php?u=957), author of Sunrise (http://www.mobileread.com/forums/forumdisplay.php?f=64), explains in his blog (http://laurens.typepad.com/sunrise/2004/12/more_on_palm_os.html) why he believes that by moving to Linux, PalmSource will ultimatively loose its competitive advantage and may not even survive in the long run:

Vendors choose Linux because it's free and PalmSource will have a hard time selling their proprietary layer at a profitable level to companies accustomed to paying next to nothing for the OS. As it stands, Linux devices do not have UIs as elegant as that of PalmOS, but that might still change. PalmSource might find themselves blazing the trail for UIs in Linux devices, only to find themselves caught up by an open-source alternative sponsored by device vendors.

One month ago, Palm OS users were confronted (http://www.mobileread.com/forums/showthread.php?t=2687) with the news that Laurens would not put his energy and resources into developing a Palm OS-based version of his upcoming Sunrise viewer. A few days after his announcement, PalmSource reported (http://www.mobileread.com/forums/showthread.php?t=2816) that the company intended to port Palm OS to Linux (also see our insider scoop (http://www.mobileread.com/forums/showthread.php?t=2862)).

There is a lot of speculation about the future of PalmSource and its operation system Palm OS, and I guess speculation will continue until we'll finally see (if we ever will!) a next-generation Palm OS device.

IMHO, Laurens shows himself to be either ignorant of recent history or blinded by a all too narrow view of the OS spectrum.

What Palm seems to be doing is not something new or novel in any way. There is very successful precedent in recent history that is very successful. This was done by Apple. They totally abandoned the MacOS and ported the "Mac experience" (a.ka. UI) to a top-level UI sitting on top of a Unix kernal. This was a vastly successful move as anyone who is aware of the world outside of PDA's and other portable devices.

Perhaps the most noteable failure in such an attempt was Next. Its failure was largely due to its introduction of a new UI with no legacy applications and users, though certainly, Jobs' narrow personal view of what the machine should be like and what it should do hobbled the machine and OS for too long. It should be noted that Jobs' did a very successful job of having Next "buy" Apple :-) and the second attempt, MacOSX, was successful.

Palm can make this port work iff (iff="if and only if") they successfully support legacy applications _and_ manage to make the more complex (read: more opportunity for bugs and misdesign) OS package reliable. To date, Palm has been successful largely because the OS is a "lean clean fighting machine". WindowsCE and all of its clan have had a long hard fight to make it in the device/PDA market largely because the OS is bulky, complex, and less reliable.

What Palm seems to be doing is not something new or novel in any way. There is very successful precedent in recent history that is very successful. This was done by Apple. They totally abandoned the MacOS and ported the "Mac experience" (a.ka. UI) to a top-level UI sitting on top of a Unix kernal. This was a vastly successful move as anyone who is aware of the world outside of PDA's and other portable devices.

While from a technical perspective PalmSource's plans may be similar to what Apple did with OS X, from a business standpoint their situation is completely different. Apple controls both the hardware and the software and - perhaps most importantly - does not sell its OS to third parties. (I'm sure they could release an x86 version of OS X if they wanted to, but then no-one would buy a Mac.) PalmSource OTOH is completely dependent on its licensees.

PalmOS already runs on 4 separate underlying kernels, depending on the model of PalmOS device you happen to be running.

Moving that multiple-kernel foundation to the Linux kernel unifies that base, and expands the hardware platforms available to the OS, at zero cost to Palmsource's developers and budget lines.

From a business perspective, this makes perfect sense.

From a technical perspective, this makes perfect sense.

From a moral perspective, it will draw disagreement. Such is life.

Laurens is but one of over 500,000 PalmOS developers, and Laurens is very small game, compared to the larger PalmOS development shops out there (who are also embracing Linux and Open Source software in general, as a way to help deliver their software to a wider audience).

Just because Laurens decided to move his previous Java product which ran on multiple platforms, exclusively to a dying legacy platform, does not mean that everyone else who disagrees, is leading a "dying business model".

Besides, didn't you hear? Linux and FreeBSD are already dead. They must be, since they're only used in only a few hundred thousand commercial hardware vendor products, successfully, every day, to the tune of millions of dollars in sales and savings to the companies developing them.

Ever hear of Hewlett Packard? TiVO? Linksys? D-Link? Sweex? Cyclades? Synetic? A little company called IBM?

Every single one of these companies and hundreds of others directly use Linux in their consumer-level hardware products, including printers, routers, switches, modems, and hundreds of other applications. This doesn't even begin to count the number of Free Software (developed-on-Linux) software packages used in commercial products.

Palmsource is making a good move, and in the right direction. My hope is that they have the inertia and ability to embrace thier existing support base, to make it successful, without pissing off their existing developer community.

Apple controls both the hardware and the software and - perhaps most importantly - does not sell its OS to third parties. (I'm sure they could release an x86 version of OS X if they wanted to, but then no-one would buy a Mac.) PalmSource OTOH is completely dependent on its licensees.Actually, Apple's hardware comes from IBM, directly. Who do you think makes the PowerPC processor used in present-day Macintosh boxes? IBM, not Apple. Apple doesn't make hardware (well, not at the chip and motherboard level anyway; they make cases and other enclosure designs for the IBM-supplied chips).

What OS you think IBM is pushing VERY hard to promote that processor? Here's one guess... it isn't OSX. Its Linux. Why? Because Linux is the perfect fit for that processor. IBM is committed to delivering this vision successfully to its partners and customers. They're 100% behind driving a successful Linux deployment on every single piece of their hardware, from the mainframe, mini, desktop, and mobile computing groups.

I know this, because I've personally been on three successful interviews for a position doing exactly that, promoting Linux-on-Power, within IBM (fingers crossed for the fourth interview).

Apple did the very same thing, when they decided to move their kernel and underlying OS base to a pseudo-FreeBSD core subsystem. They still maintain it all in-house, and I don't suspect Palmsource has the manpower to do this, but it is working out well for Apple. Granted, Apple has many more internal developers than Palmsource, but these things may change as Palmsource gets closer to a working product on the Linux platform.

Porting OSX to run on top of Linux, running on the PowerPC processor and hardware, provided by IBM, makes a natural transition for them.

Or maybe not. Maybe the pseudo-FreeBSD works well-enough for them for their current and future plans. Only time will tell.

Actually, Apple's hardware comes from IBM, directly. Who do you think makes the PowerPC processor used in present-day Macintosh boxes? IBM, not Apple. Apple doesn't make hardware (well, not at the chip and motherboard level anyway; they make cases and other enclosure designs for the IBM-supplied chips).

What OS you think IBM is pushing VERY hard to promote that processor? Here's one guess... it isn't OSX. Its Linux. Why? Because Linux is the perfect fit for that processor. IBM is committed to delivering this vision successfully to its partners and customers. They're 100% behind driving a successful Linux deployment on every single piece of their hardware, from the mainframe, mini, desktop, and mobile computing groups.


Why do you think IBM is so big on open-source lately? Because they want to drive the cost of software (including the OS) to zero. This way companies can allocate 100% of their budget to hardware, which is where IBM makes its money. Device vendors using Linux have the same goal, they would rather pay no licensing fee at all. (Handera, for instance, left the market because they couldn't afford the Palm OS licensing fee anymore.)

I fully agree with you that Linux has momentum in the device space, but that doesn't necessarily help a software-only company like PalmSource. That PalmOS layer had better be so far ahead that no alternative could hope to catch up. Furthermore, it remains to be seen whether developers will want to lock themselves into a vendor-specific API (i.e. PalmOS) on a platform that is supposed to be open (Linux). Also, Motorola (and others) have already invested millions in Linux development.

What worries me:

1. The Linux announcement was made when everyone was waiting for Cobalt to roll out. What have they been doing over the past year?

2. The Linux announcement is not a guarantee that the project will succeed. The whole China MobileSoft buy-out isn't even complete.

3. PalmSource is small. IBM, HP, Apple - all of them are BIG. Neither of them relies on a single piece of software. Plus they have the resources to heavily invest and endure a time with less income/revenue generation. Can PalmSource wait yet another year after the Cobalt flop?

4. PalmSource doesn't have that many licensees anymore. It lost its biggest one - Sony - more than half a year ago. Do the remaining licensees want to wait yet another year for a possible new Palm OS? palmOne already announced its interest in cooperating with Microsoft. Who is left? Does PalmSource have the power to win back lost alliances/licensees?

The possible move, by Palm, to a Palm UI on a Unix-variant core (Linux) may prove to be a good move. They are, IMHO, caught with a major choice on their hands and only two ways to go.

One route would be for Palm to strip their OS down to the very basic kernal targeting it for devices with embedded OS's that are hidden from users. These are devices like cash registers, basic phones, fax machines, ... , and other smart devices where the OS faces inward to the device and not outward toward the user. Its a large market but well populated at present and would be new to Palm. This would be a poor choice, IMHO.

The other is to advance the OS into the current trend of "more bells and whistles in my toys so I'll buy new ones even even though the old ones do the job fine". Here, Palm is better off using a well established existing OS kernal and using there relatively limited resources in porting the Palm user experience. Apple found this the better route when they needed to replace their antique and cumbersome OS with something more adaptabe to changing processors, device interfaces, and communication protocols. Apple took that portion of the OS that users saw and put in on top of a more adaptable kernal.

This second route is not without its risks, though. The market moves fast and one false step can kill the effort leaving Palm to be picked apart in recievership. If Palm does, in fact, make this move they must hit the streets with a stable release day one. It must also support legacy PalmOS apps, at least those written to the newer PalmOS5 & 6 APIs. Failure to do this will cause users to avoid the devices using the OS and their market position, falling as we talk, will evaporate before they can fix the issue and make a second release. For developers, this is somewhat of a scarey scenario and will be until much more is know about Palms intentions and design.

One route would be for Palm to strip their OS down to the very basic kernal targeting it for devices with embedded OS's that are hidden from users.Palmsource makes an operating system. They do not write kernels (well, they don't want to write kernels). They don't want to license a third-party kernel either, especially one that is so targeted to very specific hardware requirements, that moving to another platform (MIPS, for example) would be a painful migration.

This is why moving their underlying hardware abstraction layer to Linux, with their OS sitting on top, makes perfect sense. Focusing their efforts on the parts of their product suite that are actually seen by users, the UI and interfaces, is where they can begin to shine. Right now, they're spread too thin between maintaining 3 different diverging OS variants on several different kinds of hardware platforms.

From there, moving that UI to other platforms that are already running Linux, is an easy hop. This includes cash machines, mobile phones, printer interfaces, and other inter-connectivity devices. They also gain the enormous wealth of new toolkits that they can use at their disposal, to leverage that OS on top of the Linux kernel. This means gtk+, Qt and dozens of others. They also (potentially) gain the use of newer languages at runtime on their devices. Perl and Python on a Palmsource-powered PDA? Absolutely.

Here, Palm is better off using a well established existing OS kernal and using there relatively limited resources in porting the Palm user experience. Apple found this the better route when they needed to replace their antique and cumbersome OS with something more adaptabe to changing processors, device interfaces, and communication protocols. Apple took that portion of the OS that users saw and put in on top of a more adaptable kernal.Palmsource is not using "Linux the OS", they are using "Linux the kernel" for their migration (unless they change their direction again). It keeps them focused on their main product, PalmOS.

Great discussion. I didn't understand the real benefit of Palm's announcement until I read this thread. However, I have to agree with Tad that Palm's time is limited. With everyone defecting to PPC and Palm appearing generally unresponsive to their base, how much time can they really expect to have? A Linux move does sound like a great option, but it's too bad they didn't choose it sooner.

I'm still one of the folks who prefers my T|E to the PPCs, simply because the Windows Mobile OS is, as has been observed here, clunky and painful to use. My Palm may be a bit slow, and the screen a bit small, but it does what I need it to do. To add the strengths of a Linux kernal would be great, and who knows, maybe it would lure back some licensees. But, like Laurens, I'm not optimistic. Give us a sign Palm!

100th of any currency
I decided to buy a new PDA after 2 years of using my Clie NX60. Prior to that I used Palm Vx for 2 years. This time I decided not to go for a Palm OS model as there were none that was better than the NX60 (don't want a camera). Also Palm OS 6 had no intentions of appearing.
I ended up choosing Sharp's C860 with linux. I have to admit that having linux had its advantages like porting apps and games but there is hardly any pda oriented software for linux. This is where microsoft certainly has an edge.A few years back there were hardly any PPC apps compared to Palm OS. This is not so anymore. I can't see that happening with linux. The Palm OS apps are so nice for a PDA while the apps available for linux are too PC like. Even for a desktop OS linux is far from ready.

Much as I dislike windows it's what runs in my laptop. I havent found a nice game to play bridge in either PalmOS or linux. Palm OS has had its day. Whenever I would ask a developer to port their PPC app to the palm they would complain that programming was a real pain. No multitasking, strange memory limits, bad networking support etc. Till Palmsource can make it easier for developers to develop cross platfom stuff it will die. Microsoft and linux have that advantage with being able to port desktop apps quite easily. Linux has the disadvantage of having hardly any commercial developers.

Laurens does have it right IMO but I think that a new palmos can change things. Lord knows when that will happen.


tovarish

Interestingly, someone from mytreo.net explains (http://mytreo.net/news/archives/000308.php) how Cobalt 6 will change our lives (once it is out). I wonder if the Cobalt was we've seen it today through the PalmSource emulator will look the same once it is used in actual PDA and Smartphone devices. After all, in the existing Cobalt emulation code, Linux isn't even taken into consideration yet.

I wonder if the Cobalt was we've seen it today through the PalmSource emulator will look the same once it is used in actual PDA and Smartphone devices. After all, in the existing Cobalt emulation code, Linux isn't even taken into consideration yet.Sawfish looks exactly the same running on FreeBSD's kernel as it does under the Linux 2.4 kernel and the Linux 2.6 kernel.

Why should Cobalt look any different because it's running on top of a different kernel?

The intial work on Cobalt was primarily unseen kind of work relative to user experience, but it prepares the groundword for future "fun stuff". As Hacker indicates, it's not because of the new Linux kernel, but because of the way Cobalt works on top of it.

I don't agree with the absolute seperation of kernel (Linux) vs. user land (Cobalt). The ones goes along with the other. Due to the new features introduced by having a Linux kernel (for instance the superb TCPIP stack), Cobalt would most likely also introduce new applications such as an SSH Client, etc.

Also, hacker, you quoted FreeBSD. Remember that kernel and user land are very tightly integrated in this case. Unlike it is the case with Linux, everytime you update the kernel sources and recompile them, you should also do the same with the user land files.

Hence I am *convinced* Cobalt, if it ever returns from vaporware, would look different if it was built on top of Linux.

I wonder if the Cobalt was we've seen it today through the PalmSource emulator will look the same once it is used in actual PDA and Smartphone devices.

It will look exactly the same. The current simulator we have available is almost the entire Palm OS Cobalt, recompiled for Windows. Even most of the kernel is simulated, though some of the lower-level parts are different -- for example Palm OS threads are simulated using native Windows threads.

I don't agree with the absolute seperation of kernel (Linux) vs. user land (Cobalt). The ones goes along with the other. Due to the new features introduced by having a Linux kernel (for instance the superb TCPIP stack), Cobalt would most likely also introduce new applications such as an SSH Client, etc.

This is actually a good example against what you are saying -- the Palm OS Cobalt APIs for dealing with networking are basically the traditional socket APIs, which would easily sit on top of Linux with no changes. Switching from one kernel to another would basically have no impact on applications using them.

There is nothing special about Linux that makes it magic to implement an SSH client. Cobalt has a good, modern IO system (using Streams), which can easily support such a thing. The main advantage you'd get in this area moving to Linux is that it would be a little easier to port some existing SSH client... except you still have to deal with UI code, which is really where most of the work is.

Also, hacker, you quoted FreeBSD. Remember that kernel and user land are very tightly integrated in this case. Unlike it is the case with Linux, everytime you update the kernel sources and recompile them, you should also do the same with the user land files.

I am not all that familiar with FreeBSD, but I find this statement surprising. When a new version of Mac OS X comes out (with a new version of its kernel), you don't have to recompile your existing applications, do you?

In fact, user space never directly calls into the kernel. Instead you supply shared libraries (libc being the prime example) that do the kernel calls for you, which give to user space an API that can be maintained across changes to the low-level kernel traps.

If your kernel and user land are "very tightly integrated" like this, I would say you've got a very basic flaw in your system design. It isn't a problem in Windows, Mac OS, the current Palm OS, etc., etc.

Hence I am *convinced* Cobalt, if it ever returns from vaporware, would look different if it was built on top of Linux.

I guess this bears repeating: "Palm OS for Linux" does not replace the current version of Cobalt. We expect devices to ship with Cobalt 6.1 this year.

As for things looking different, there is nothing about changing the kernel that says this. For example, you can run X Windows on Linux and FreeBSD, and switching between them doesn't change how it looks or operates. The "looK" is really one of the most trivial aspects in this.

Mrs Hackborn, first let me thank you for taking your time to answer our speculations. This is highly appreciated, and I am sure not just by me!

On FreeBSD: FreeBSD is developed as an integrated system, with a kernel matching userland tools. For instance, one should not run a kernel compiled for FreeBSD 5.3 RELEASE on a CURRENT machine. The kernel and all userland utilities are meant to be upgraded simultaneously, and must be kept synchronized. While Linux users are usually forced to acknowledge this good system administration practice when they upgrade major versions of their kernel (e.g., 2.2 to 2.4, or 2.4 to 2.6), they often maintain the same userland across minor kernel versions. FreeBSD strongly encourages users to always keep the userland and kernel in sync. So I wouldn't consider this a "basic flaw", as you referred to it, but actually an instrinsic feature of the underlying OS system.

Again, I appreciate your elaborations!

The ones goes along with the other. Due to the new features introduced by having a Linux kernel (for instance the superb TCPIP stack), Cobalt would most likely also introduce new applications such as an SSH Client, etc.There are already two excellent ssh clients for Palm (and I use them both heavily, for remote administration of boxes, when I'm offsite and a client demands my attention):
pssh (http://www.sealiesoftware.com/pssh/)

http://www.sealiesoftware.com/pssh/screenshots/green.gif

TuSSH (http://staff.deltatee.com/%7Eangusa/TuSSH.html)

http://www.tussh.com/TuSSH.gif

On FreeBSD: FreeBSD is developed as an integrated system, with a kernel matching userland tools. For instance, one should not run a kernel compiled for FreeBSD 5.3 RELEASE on a CURRENT machine. The kernel and all userland utilities are meant to be upgraded simultaneously, and must be kept synchronized.This isn't exactly true. You can (and many do), upgrade their kernels only without building the world target every time to rebuild userland. You should keep them in lockstep, but there are very specific cases where you never want to upgrade userland when you upgrade kernels, lest you risk stability of your existing userland.

Looks nice indeed. I haven't come up with a decent SSH client for PPC yet. I tried Putty for Pocket PC, but it doesn't work very well and is not VGA-aware ;(