Palm OS Spinoff
iCharles writes "According to this SEC filing per this Palm Infocenter story, it would appear that Palm is spinning off its OS devision. I'm a Handspring user, so it sounds quite interesting to me."
← Back to Stories (view on slashdot.org)
Now if we could only convince Microsoft to do the same thing!
Of course, Handspring tends to customize their OSes heavily to fit their hardware. 3.1H and 3.5.2H(x) are relatively substantial retrofits. I love the fact that the PalmOS is such a streamlined, efficient tool. I think as its own company, focused on the OS, they could really do some good. OTOH it could shake Palm's grip on the market further... but if the market really expands, hey, maybe there's room.
The story mentions that at least one future Palm is going to be using an ARM processor (Hercules 1.0). i guess that means we'll finally see linux on genuine Palm(tm) hardware, at the expense of have a cool processor name like the Dragonball VZ.
It also brings up interesting prospects for the future of Palm OS. If Palm's OS division is making a Palm OS for an ARM processor, will we start to see Palm OS as an option on iPaq's and th like? It's just my personal opinion, but I like Palm's interface more than WinCE, but right now, the hardware that runs it is slower. I guess we'll see.
I'd get rid PalmOS too.
When Palm eventually moves to ARM-based hardware, I'm sure we'll see creative, inventive people making Linux ROM images for the hardware the same as they have for the iPAQ. But they won't be coming from Palm Solutions (the hardware/parent company), and I sincerely doubt they will be coming from any of the licensees. Why jump ship from a platform that had 80% of the retail market in August of this year, in addition to 80%-90% of the market for the past six years? That's foolish.
In addition, there is a world of difference between a Linux PDA and a Palm PDA. The PalmOS is built from the ground up as a handheld, all-in-RAM, XIP OS. Linux is originally a server OS. Yes, there has been absolutely astounding work in recent years in bringing Linux into embedded systems, but that's not enough. The paradigm of Linux is the same as the paradigm of the PocketPCs; a file system. The PalmOS has no file system, save for on expansion cards which are a new development. It's a database-like in-RAM format. That's what makes it so fast. You can get better performance out of a 33MHz Palm than you do out of a 150MHz PocketPC. There's a fundamental archetectural reason for that. Sure, Linux and Win32 may be familiar for many developers, but in order to do it right you need an archetecture and API that is designed for that type of system.
There's also the UI issue. The Palm UI was designed with Mac-like simplicity and consistency from the get-go. (Not surprising, considering that the majority of the founders were ex-Apple ane ex-Newton people.) The "Zen of Palm", alternately the subject of praise and flame wars, is really what made this organizer work as a portable computer. For cultural reasons, Linux doesn't have that. We (Slashdot readers) put up with a great deal more disparity in UI across a Linux desktop than a handheld user is willing to deal with. Simply throwing KDE or QT at it won't solve the problem of a UI that is consistent, learnable, and has almost zero learning curve.
Sure, a company could take the Linux kernel and tools and write a Palm-esque interface for it, and rewrite the guts enough to be naturally resource-based XIP. But by that point, you're almost writing a new OS to start with. And every company is going to have their own "redux Tux", which means you won't be able to generate a single executable file that you can throw on any device, the way you can with a Palm. One truism of the Open Source / Free Software (whichever camp you are in) movement is a lack of unity in APIs and UI. That will kill any mass market attempt at a handheld. The market is not interested in a device you can tweak and customize and recompile. It wants a device you can charge, pickup, and use. And at least right now, Linux is not that.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Palm: Hey, you guys wrote a super cool OS for the desktop that rocked, and you did it relatively quickly, too.
Be engineers: Thanks!
Palm: We've got to write a new OS for the ARM archetecture that is fast, multimedia-ready, and backward compatible. Think you can do it?
Be engineers: Uhhh...
Palm: Here's $11 million, we just bought what's left of your company.
Be engineers: Sure!
Don't look for BeOS to appear on the Palm anytime soon. Look for the same kind of cool developments on the Palm, this time with a market share that can actually appreciate all that hard work.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Why does Palm think they're about to, in any way, create a new hardware device that they think will surpass these existing innovative devices? Palm is ALWAYS behind the curve on hardware advances in this area. We're not even talking about comparing them to the iPAQ, VTech Helio, Agenda, Yopy, and the other dozens of non-PalmOS, non-WinCE handheld PDA devices.
Currently, Palm's OEMs for the PalmOS® software include:
They get licensing from each and every one of these OEMs. Their hardware is the last thing to ever be updated. It is without a doubt, the least innovative portion of their business.. and they're choosing to keep it?!
I don't quite understand the motive behind this decision on their part. I suppose I'll find out at Palmsource in February.
These are the same industry analysts that thought "Wireless Web" and "3G" would be big, because they brought "content" and "multimedia" to cell phones.
Nobody beyond a handful of wannabe-geeks who want to say "look what my handheld can do!" give a damn about multimedia on a handheld. "Ooh, I can look at 3"x2" color Powerpoint slides, and listen to supercompressed MP3s over tinny speakers!"
Give the handheld a VGA output port and good headphones (maybe even Bluetooth) and all of a sudden PowerPoint and MP3 on a handheld are very attractive to a lot of people.
Remote display is extremely useful for developing software for the handheld and for debugging it. Also, a 200MHz handheld is a powerful machine--with X11, you can use it like a desktop and with desktop applications running on it when you connect it to a network.
2) Why the need for different toolkits?
Because there are already lots of handheld applications written for toolkits other than Qt. Face it, the world isn't going to switch its vertical application development to Qt just because some people think it would be nice.
On a PDA, a single, integrated, interface is the way to go.
If you think "consumer market", perhaps. But Linux PDAs are for vertical apps, and the cost and success of vertical apps is driven by ease of development and porting among platforms, not by some nebulous notions of appearance. Multiple toolkits are a reality in that market.
Linux programmers need to start programming apps for 320x240 displays, and QT/Embedded sounds like a good place to start.
FLTK and Java are already much more widely used than Qt/Embedded, and they don't cost anything.
Palm does NOT own BeOS. The deal hasn't been accepted yet by the shareholders. We will know for certain on Nov. 12th, when there will be a special shareholders meeting.
As for BeOS itself, check out http://www.befaqs.com/save or http://www.beunited.org . There are efforts to get Palm to license BeOS itself (which they have no intention of using, they only bought the Be Engineers remember? so they could build a new PalmOS).
Running Qt/Embedded has all sorts of disadvantages, however:
You can't use X11 remote display for development on/for the handheld anymore.
Use VNC instead then. VNC is also much more useful than X once the palmtop is out in the wild - palmtops don't usually have constant network access when they're in your pocket, and VNC can detach and reattach easily to existing sessions, even if you change your IP address in the mean time. X requires a constant network connection or else the app that you're running over X dies.
You can't share the handheld screen between applications written in different toolkits anymore.
And this is a bad thing? Personally I'd be very happy to see embedded Linux not making the same usability mistakes that desktop Linux has in the past, and which it is only now recovering from. Lots of toolkits == inconsistent interface == usability problems. Diversity is great, but there are places where it is inappropriate, and user interface is one of them. Not to mention the bloat aspect of having multiple toolkits...
You are tied to a single toolkit for handheld development.
See above.
Don't forget that Qt/embedded is also API-compatible with Qt/X11, which means that porting Qt apps from the Linux desktop is a cinch - and that's how Opera and Konq/e have been so rapidly successful - they are both based on Qt. Don't underestimate the importance of having a good browser for a palmtop. The only browsers I've seen for X11 that are optimized for display on a small palmtop screen are... Opera and Konq/e. You might as well run them under Qt/embedded.
How many full-blown browsers do you know written in FLTK or Java? Maybe when there's a nice tiny browser for FLTK using Gecko as a rendering engine there'll be something to talk about.
As for size, well, perhaps TinyX+FLTK+Blackbox really is no bigger than Qt/e. But think about what you get with Qt - Signals and Slots, a fast and very powerful canvas widget, full-blown Unicode support, in fact, all the nice features that have made Qt a huge success on the desktop. And, as I've said above, porting the multitude of existing Qt desktop apps is a no-brainer. Not to mention of course that the superb QPE is available, so if you want a complete environment for your users, it's just a compile away. No additional coding required.
FLTK doesn't offer any of this. In fact, no current X11 toolkit other than Qt itself offers all this. If you start adding other toolkits on top of TinyX then you can make up for some of the more important features... but oops, there goes your size, and your consistent interface.
If you have political problems with Qt, then say. You certainly seem to be short on valid technical problems.