Apple to Buy out Palm? 331
JFlex writes "According to a story over at Personal Computer World 'Speculation that Apple plans to buy handheld maker Palm has been revived by a call from two leading Palm investors for the company to be put up for sale, according to the local paper of both companies.'"
Re:Good for Apply Maybe, good for Palm - NO! (Score:4, Informative)
Palm is already working a new version of Palm OS with Linux as the kernel, effectively creating their own "OS X" story. Whether they'll be as successful as OS X is remains to be seen.
Re:Why /. Why? (Score:3, Informative)
Have we reached the point where "you must be new here" comments can be shorthanded as "YMBNH"?
Slashdot is a news digest and discussion forum which the editors prefer to run like it's a cute little personal blog, rather than one of the most popular news sites on the Internet. There is no formal criteria for what does and does not get selected.
Re:Good for Apply Maybe, good for Palm - NO! (Score:5, Informative)
Palm Source isn't owned by Palm. It's owned by a Japanese company whose name I can't remember.
Palm don't own their own OS these days.
Idiotic (Score:4, Informative)
You obviously got modded "insightful" by an Apple-basher. Yes, Apple is down 20% from its peak, but it's still up 600% in the last two years, up 80% in the last year, up 50% in the last six months, and up 10% in the last three months. That performance whoops ass on just about any other investment out there.
Re:Good for Apply Maybe, good for Palm - NO! (Score:3, Informative)
ACCESS. See the PalmSource site [palmsource.com].
Re:Good for Apply Maybe, good for Palm - NO! (Score:5, Informative)
Yes. I've developed for it before, and it's got cruft coming out of its ears. It was designed around the idea that a device would never have more than 8 Megs of RAM, and that the controls/screen would be fixed in their design. In addition, memory is partitioned into small "databases" with explicit record sizes. These databases are the only thing keeping the data separate. If something goes wrong, one database can easily overwrite another. No MMU exists to prevent this.
Other issues include:
There's more, but those are just off the top of my head.
It's hideously expensive to rewrite software from scratch and a lot of companies will fail in the process.
My best suggestion would be an emulator. Given that a new OS would be able to take advantage of the greater speeds of modern ARM processors, most software could be run under a port of the current desktop emulator that developers use today. Performance critical software would do best to port, but new versions have always been an issue for them anyway.
Re:Buying palm, or buying BeOS? (Score:3, Informative)
So Apple being Palm would get them a bunch of hardware. I don't think Apple needs their hardware.
Re:Palm has access to interesting IP on their hand (Score:1, Informative)
Re:BeOS (Score:5, Informative)
Mod down. BeOS was formerly purchased by PalmSource (not Palm) which was recently purchased by Access of Japan.
Re:Buying palm, or buying BeOS? (Score:3, Informative)
Re:Windows CE (Score:2, Informative)
It comes full circle again (Score:2, Informative)
Palm was founded by Jeff Hawkins [wikipedia.org], Ed Colligan, and former Apple employee Donna_Dubinsky [wikipedia.org]. They also brought some programmers from Apple on board. Later they left and formed Handspring, then Handspring was bought by Palm.
Their histories are similar to Apple's so it would not be out of the question for Apple to buy Palm and use their technologies.
Steve Jobs and Steve Woz create Apple. Steve Jobs leaves and creates NeXT. Apple buys NeXT. Former Apple employees create Palm. Palm founders leave, create Handspring. Palm buys Handspring. Apple buys Palm? Their histories and people are intertwined.
Re:Good for Apply Maybe, good for Palm - NO! (Score:4, Informative)
But PalmSource has been working on Palm OS Cobalt, their next gen OS, for the last few years. They actually had a preview ready at the Palm Developers' Conference I attended in 2004: it has next-gen databases with a built in sql-like query language, next gen PIM applications, threading, real process separation, berkeley socket networking, well-thought-out security model, etc. It is a Real OS.
You've been able to get an emulator and tool suite since that conference: if you want, you could develop a new Cobalt app today.
The problem? No hardware. Since PalmSource didn't have a hardware division anymore, they couldn't force anybody to actually use the OS, and Palm opted short-sightedly to stick with Garnet.
Thus, the move to Linux, to make the platform more attractive to phone manufacturers. But keep in mind it's just the underlying kernel that's Linux: on top, everything is Cobalt, both to the user and the developer. The advantage is that phone makers can reuse more of their existing software infrastructure (drivers, etc.) if they've been developing Linux phones.
Re:In other news... (Score:3, Informative)
The 110 was actually longer than the 100/OMP. The 120 and 130 were the exact same form factor as the 110.
The Newton 2000/2100 was larger than the 110 (in width). It also had a much bigger screen (2X as big, 4X as deep).
The eMate was the largest Newton of all.
Unless you are comparing the 2000 form factor with the Motorola Marco or something...
Palm had three critical advantages over other PDAs at the time: size, speed, and connectivity.
Size: The Palm fits in a shirt pocket. The Newton doesn't. No other PDA at the time was as small as Palm (I'm not talking about the iPaq or other much later PDAs - I'm talking EO, Newton, General Magic and that group.)
Speed: Not necessarily the hardware speed, but in the responsiveness of the system. Palm felt fast. Newton felt slow - at least until the 2000 came out. Get an OMP or MP 100 and try to scroll through the Notepad - sometimes you are waiting many seconds for the system to scroll.
Connectivity: Palm's Conduit API wasn't perfect, but in the day it was better than anything else out there (again, pre-WinCE). You could write a Palm app and a desktop app and get syncing to work pretty well. Newton, the APIs never got out of alpha stage. There was not a good synchronization solution. The synchronization apps from Apple were OK for loading packages, but that was about it. Dan Rowley's X-Port was the best product in its class and he made use of connectivity APIs that were very flaky, were still in alpha stage, and were not generally available to all developers. Also, they were non-trivial to use for a number of reasons. Dan is an extrodinary engineer and got it to work through sheer will and many, many hours of hardcore hacking.