Slashdot Mirror
PalmOS 5 Turns Gold
Stalke writes: "On sunday, PalmSource (the spinoff from Palm responsible for the development of the PalmOS) announced that PalmOS 5 has gone gold. This latest version of the operating system includes support for ARM processors, Bluetooth and 802.11b, high-res displays (320x320; although Sony already uses even high res displays in its NR70) and more. Products with PalmOS 5 should start shipping in just over a months' time!"
Wow first Moz now this. What next HURD getting done?
I'd do something interesting, but my server can't handle a slashdotting.
The thing I love most about the Palm and the PalmOs is that it works, that it's extremely simple and that it's extremely reliable.
I didn't like when they introduced colour and I care even less for all the fancy features promised with PalmOS 5.
Frankly, if the only direction is more colours, better resolution, more MP3, full feature video and other such assorted crap, then I guess it's time to ditch the Palm and go for a Symbian smart phone.
At least then, when the good old b&w simplicity of the V series is no more supported.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Open the source, Palm!
So they can get the nimble development cycle of such projects as Mozilla and Gnome? I'm sorry, but I don't think so. Any operating system -- especially something embedded like PalmOS -- is going to be over the level of many programmers. I certainly wouldn't want to have to deal with lines and lines of palm assembly...
In the case of PalmOS, I don't see any advantage to opening the source. Palm does a good job with it, and I don't think there's enough "flashy" jobs to keep OSS programmers going.
Not to mention that they need the royalties from other companies licencing it.
I don't see them open-sourcing it anytime soon.
Dragging people kicking and screaming into reality since 1996.
For reference, the hi-res support in OS/5 is not limited to 320x320 per say. Though it's likely that is what many devices will come out with, the choice is actually up to the OEM, but the API is reasonably generic so that it abstracts real screen pixels away from internal pixels.
As was clearly stated at the PalmSource conference back in February, the OS is equally suited to a 640x640 display or even the odd resolutions like 320x480 (like the NR70).
Maybe I'm being trolled, but...
Any operating system...is going to be over the level of many programmers. I certainly wouldn't want to have to deal with lines and lines of palm assembly...
Palm does a good job with it, and I don't think there's enough "flashy" jobs to keep OSS programmers going.
Okay, I wasn't suggesting that you (whoever you are) should work on the Palm OS. I don't care if you like assembly programming, or if you find OS coding "flashy" or interesting. Your comment about assembly is especially telling. Clue: assembly languages are written to be programmed by people. Lots of people can understand and write assembly code. It is not javascript, but it is not voodoo either. Check out the Linux kernel source, and you will find plenty of assembly, all written by real life volunteers.
Check out the traffic on LKML sometime. Lots of people in the community find this kind of stuff very interesting and are quite capable of doing it.
Not to mention that they need the royalties from other companies licencing it.
That is only to recoup the costs of closed source development. Costs that would not exist were the source open.
Karma: Good (despite my invention of the Karma: sig)
XBox runs Win2k embedded.
WinCE is becoming the norm in new ATM machines and other devices.
How many copies did it have to sell to "go gold"? Using that figure, can we project when it will "go platinum"?
did this silly company hire king midas?
everything is going gold around here...
|---------------|
practically an AC
Isn't about time the Palm OS provided threaded applications? My understanding it that it is build into the OS, but there are currently no APIs. In the Treo, at least, when you are on the phone, you can't continue to use your applications. It seems to me that this will put Palm OS at a disadvantage as PDAs are integrated with cell phones.
it doesn't matter anyway. PalmOS5 is for ARM cpus. So *everyone* is going to have to upgrade. No current dragonball hardware can run it. This is for a new breed.
You know what this means.... time to port the AGI interpreters to Palm.... Space Quest II is comming to your handhelds!!!!
:)
It shouldn't even matter if your high-res screen doesn't support color.... Many of us used to play that game on a monochrome monitor in those days. The only part that really got unplayable (before I was stuck for 4 years, damn "rub berries on body"!) was the swamp-creature-with-vines-maze. It's easy on a color screen, because the lines ar pink-on-green, but on monochrome, it looked like jibberish.
What next, 3 buttons to click to open the menu to scroll down to the 'print format' action button?
I can't wait until it starts to blue screen.
goto www.palmos.com you'll find screenshots there. The OS looks pretty much the same though, the changes are mainly internal and you really wont notice them till apps come out with support for them.
Later,
Phil
When are we going to see a new release of BeOS?
Never. BeOS is dead. Perhaps you'll see parts of the API in PalmOS 5.x, but there won't be any new release of BeOS. IF you want a BeOS like enviroment check out Cosmoe OS (it runs on top of Linux).
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
s/SCREEN_RES/get_screen_res()/g
or more likely: s/160/get_screen_res()/g
As a Palm OS developer by trade I've been using the OS 5 development kits for about 4 months now since they were released at palm souce, and I must say that the end users really aren't going to get that much out of this latest release. Reasons being are that the ARM enhancements are designed as what are being called "armlets", small peices of code within the m68k code that is accellerated for an ARM proccessor. Palm isn't pushing native ARM applications which has pluses and minuses, new apps will still run on the older devices minus any armlet functionality, but the new ARM devices are going to have apps that are running slower than they should be do to the m68k -> arm translation. The other thing about this release new API, they've cleaned up a lot of the garbage and added a lot of new functionality so as a developer you got lots of more toys to place with, but as an end user don't expect this to be some holy grail of pda os's. Another downfall of Palms current plan for OS 5 is that they are targetting a handheld unit with a 66mhz arm proccessor, yes a 66mhz proc.. It's rediculous because the new xscale arcitechure which has 400mhz+ cpus has dropped the ARM prices dramatically. But anywho, I am excited to see a unit running OS 5.
Later,
Phil
Pimlico software make DateBk, which is a diary replacement because Palms own version is ... well, crap. It's just too limited when you compare it to Outlook.
As much as I don't like a company going down the pan, if Palm have done it right, Pimlico would find that they won't be able to sell DateBk on the new OS. Because Palm's own diary book should be so good, that people would have no reason to update.
I've said it many times, if Palm can get their new Datebook/Memo/ToDo/Address book to sync 100% with Outlook, then they're onto an instant winner. Just because the population of /. would avoid Outlook like the plague, doesn't mean the rest of the world does. If they can take an *exact* copy of their PC stuff on their new Palm, then they'll be a happy bunch.
(I'm led to believe that even PPC doesn't sync over everything - but at least it's more than Palm)
Avantslash - View Slashdot cleanly on your mobile phone.
I beta tested it. No screen shots, but you can feel the BeOS influence in it. I'm sure some purists will complain about OS bloat, but it's quite efficient and snappy on an ARM, while supporting a lot of advanced features.
There are two C/C++ development toolchains for Palm OS: Metrowerks CodeWarrior and what's called prc-tools, which is GCC, GDB, etc configured and patched as a cross-compiler for Palm OS. Some surveys suggest that each of them has about 50% of the market of Palm OS developers.
In the past, Palm OS SDKs have supported both toolchains: the 3.5 and 4.0 SDKs contained various linker (static) libraries in both CodeWarrior format and, for GCC, COFF format. The 4.0 SDK was even available from Palm as an RPM as well as a Unix tarball.
The 5.0 SDK's ReadMe has this to say about GCC:
There are no GCC libraries and no Unix SDKs.I've also posted to palm-dev-forum about this.
In practice, it's not a show-stopper: the header files, which are all you really need to use the new 5.0 APIs (notably high density graphics and ARM subroutines), work fine with GCC. There's a bit of extra pain on Unix due to line termination issues and PalmSource's lack of familiarity with case-sensitive filesystems, but it's not too bad.
The GCC link libraries are entirely missing from the 5.0 SDK. This is unfortunate: while you can easily write an application without using them, the glue routines in one of the libraries makes compatibility with various versions of the OS easier, and PalmSource recommends their use.
Curiously, while the ReadMe says the SDK "does not provide any support for [GCC]", PalmSource were happy to fix showstopper GCC-usage-related bugs in the SDK's header files when they were pointed out to them during the SDK's beta period. Thus the note in the ReadMe is not really true.
All that's really missing is the GCC linker libraries and the Unix builds of the SDK. Because they were happy to fix those header bugs, because their Web pages still claim to "support prc-tools", and because of what various PalmSource employees have told me, I don't believe there's been any conscious decision (or conspiracy :-)) not to support GCC. I think the problem is that, even
though the GCC library and Unix build scripts are still lying around from
the 4.0 SDK, it's simply nobody's job to take responsibility for maintaining
the scripts or for pressing the button that runs them.
It's all very disappointing: in all probability, there's no technical reason why the 5.0 SDK doesn't include GCC libraries or an easily installable Unix package, it's just that no-one cared enough to make them. It seems like it was always just Someone Else's Problem.
It's not too late to fix this. The company I work for and I know how to build these things (I wrote the scripts in a previous life :-)), and we've offered to help PalmSource build them several times. Hopefully they'll take us up on it, and make the users' lives easier.
Oh, disclaimer: I'm a prc-tools maintainer.
So they can get the nimble development cycle of such projects as Mozilla and Gnome?
Nice job carefully picking your examples. As you point out below, PalmOS is an OS. Apples to apples means lets compare it to the nimble cycles of Darwin, FreeBSD, Linux and others.
I'm sorry, but I don't think so. Any operating system
Like Gnome and Mozilla?
-- especially something embedded like PalmOS -- is going to be over the level of many programmers.
Yep. We all know OSS programmers are simpletons. Gee, PalmOS might be hard. Since when is that a reason for keeping something closed source?
I certainly wouldn't want to have to deal with lines and lines of palm assembly...
I certainly don't want you dealing with it either! Leave it to the hordes of OSS coders cranking out amazingly complex, useful, robost code.
In the case of PalmOS, I don't see any advantage to opening the source. Palm does a good job with it, and I don't think there's enough "flashy" jobs to keep OSS programmers going.
Flashy isn't the reason to make it OSS. It's not even the main thrust of most OSS software. Solid security, better core functionality, functionality that serves a small market segment, adherence to standards and support of a wider variety of hardware are just a few of the reasons it would be nice.
The issue is always tradeoffs.
The current generation palms have three outstanding aspects: small form factor, long battery life, simple and reliable data replication. These also are, in my opinion, the must-dos.
If they had meant to make more of a desktop replacement (like WinCE), they would have compromised these goals initially. In time, more features like multimedia capabilities can and should be added to the platform. If they did not, then (1) people would never upgrade their existing palms, and support would be reduced over time; (2) inevitably, a killer application will appear that they will be unable to support.
However, I would be sorely disappointed if these were done in a way which compromises the most important aspects of the system in order to "measure up" to the more ambitious and less successful competition. Nobody can beat Microsoft in an arena of its own choosing.
I'm optimistic, but I'll reserve judgement until I've actually tried some of the units.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
In the early days of the Palm Pilot, all was shiny and new. Developers loved it, and cranked out tons of shareware and freeware. All the software expanded its scope far beyond being just a PDA.
;), and added some yummy Java. They ran a beta version past developers, who enthusiastically saluted, and released it this spring in the US. Like in the Palm's youth, applications are being rapidly developed for it (and anything that doesn't get away quickly enough is getting ported).
Some of the original people left the company to found Handspring. They created the Springboard module for their PDAs, and everything was exciting again. Palm *followed* by adding a SD card to their PDAs. Instead of market leader, Palm became market imitator. In fact, their attempt at OS X desktop software (version 4.0) was so bad that Handspring was recommending that their Mac customers stick with version 2.* under Classic! Then again, Handspring abandoned the Springboard, leaving the Palm world pretty dull except for some of Sony's hardware.
So, does that leave us with Microsoft? Hardly! Some time ago, Microsoft drove Sharp out of the US market (basically Sharp wasn't going to play umpteenth fiddle in the Pocket PC world in the US, and so took its toys home in a huff). Sharp worked hard back in Japan, and built themselves up into the leading PDA there, with enough marketshare to become the fifth largest PDA maker in the world. Still Sharp wanted to come back to the US with a bang, so they decided to carve out their own niche that they could be #1 in. Taking a page out of Apple's book, Sharp built their best Zaurus ever and took an open source operating system (Linux), a very cool GUI (hey, Qtopia isn't Aqua, but it leaves other PDA GUIs looking, well, flat
I've got a Palm III and a Handspring Visor Platinum. My Zaurus blows them away. There is really no comparison. The Zaurus is a tiny but real multiprocessing Linux workstation that is a worthy companion to my OS X Macs. It coexists beautifully on my Airport network, sharing files (via FTP) with my Macs and browsing the web with a real browser capable of reading Slashdot (not those dinky postage stamp "pages" for PDAs). It can read and write Word and Excel files (even those created in AppleWorks). It can view pictures from my digital camera, play MP3s, and even view a GMK trailer ("Honey, I shrunk Godzilla and Mothra!";). I can create full tar'ed backups with a couple of taps, and use FTP and my G4 iMac to back the backups up on a CD.
The one thing the Zaurus lacks is a desktop with sync support under OS X. I only use the Zaurus with my Macs and I'm not missing the ability to sync. In fact, I use the cradle as a charging station, I've never plugged the USB cable into anything. The Zaurus is powerful enough to stand on its own as long as you do backups often. If Sharp and Trolltech never get the Mac support done, a third party could write what they need, since the data is stored in XML and both the Zaurus and OS X have good Java support. Wireless syncing via Java would be more fun anyway.
"The path of peace is yours to discover for eternity."
"Mosura", 1961
Too bad some moderators are stupid and mod up false post as 'informative'.
A message from the system administrator: 'I've upped my priority. Now up yours.'
You are clearly in the minority. The classic Mac desktop moved the concept of ease of use and user interface consistency out of the lab and into the mass market. I keep a copy of the original Macintosh User Interface Guidelines on my bookshelf just to remind me that most of the good work in user interface design was done back in the early 1980s, and most of what has come since has consisted of giant leaps backwards.
The Mac User Interface Guidlines are a travesty that held back UI development for years.
In what way?
Hmm. Why am I bothering to ask a follow-up question of a fucking AC?
W.A.S.T.E.
One example I like a lot is that the UI guidelines require that menus be a maximum of two layers deep, to keep the user from having to open up many sub-menus. This makes sense, but some commands are better organized into a more heirarchical system.
Um. That's simply not true. Submenus are hard for users to navigate. They require the user to have more knowledge about what options live where, and they require a much greater degree of mouse dexterity. For the handicapped, or the very young, or the elderly, hierarchical submenus are very tough to use.
In this example, the Mac UI guidelines are absolutely correct, in my opinion.
I'd have to move the mouse to the top of the screen and open up several menus every time I wanted to use a command
First of all, I guess you don't realize that moving the mouse to the top of the screen is much easier than the common alternatives, such as moving it to the top of the window or moving it to a menu palette somewhere on the screen. A user can simply slam the mouse forward and hit the menu bar every time. In this way, the top-of-the-screen menu bar can be considered to be infinitely tall; the user doesn't have to worry about where the mouse pointer needs to be in the vertical axis to hit its target. Just push forward until the pointer stops moving. Top-of-the-window or toolchest-style menus are harder targets to hit, and therefore harder to use.
And I'm not sure what you mean by "open up several menus." The guideline declares that every menu option should either be in the top-level menu, or located in a narrowly defined submenu. In other words, having a submenu called "tools" is in flagrant violation of the HI guidelines.
So it seems like the truth is just the opposite. If the GIMP were organized like a HI-compliant Mac app, you'd hardly ever have to open more than one menu, and never more than two.