Comments on: Is Palm Building their own OS?

Marty

May You Live in Interesting Times

I just want a 320*480 device with a TX-sized screen and wi-fi/cellular connectivity. Since BT has turned into nothing more than a neutered shell of what it was originally promised to be, that can be omitted in favor of a cellular radio.

So...take a TX, drop the BT, add in cellular, keep all antennas internal even at the expense of signal strength. Add a higher capacity battery, a charge LED & a voice recorder for good measure and I'll pay whatever price Palm asks for such a beast!

Whether or not it has voice functionality is irrelevant to me (I'd prefer it left out for size/cost/complexity issues) as long as there's something similar to what the good Vampire mentions. But the tiny SSS and the hideous antennae protruding are the MAIN reasons I still have trouble stomaching the Treo concept.

Pilot 1000-->Pilot 5000-->PalmPilot Pro-->IIIe-->Vx-->m505-->T|T-->T|T2-->T|C-->T|T3-->T|T5-->TX

What you mean by this is that the "features" of FrankenGarnet are fine.

The consequences of FrankenGarnet are an unstable and underpowered system that results in mistrust of the device and causes companies to leave the Palm OS to adopt WindowsMobile devices. Mistrust isn't an overnight problem, but will cause users to slowly move away from Palm OS.

I'm sure that you have had a perfectly acceptable time with your Treo as an individual and therefore Garnet must be fine. There isn't a specific bug, but rather the fact that Garnet has been stretched out way beyond its original capacity and is held together with fraying strands of duct tape. It isn't reliable. Some more advanced features (like a full powered browser) would be either not feasible (or feasible and costly to develop). In the long run it should be obvious that an OS with a development "tariff" is not advantageous for the Palm economy.

You make mostly valid and accurte points. There's a distince reason I've never had a Treo. Remember, just because I've never owned one doesn't mean I have not USED one.

It's just that the Treo in its most *current* advanced permutations (700w/650/700p?) trail the top conventional Palm PDAs (TX, T5, T3) in most areas...specifically, screen size & resolution, RAM and/or wi-fi. Those are the three most important factors along with battery life for me when choosing a mobile device.

I have also been rather underwhelmed with the Treo's voice quality & RF performance. I use a V3c on Verizon and find its voice quality leagues better than a colleague's Verizon 650.

I have zero problems with the market wanting & buying Treos. I do agree that Garnet is well past its prime but I'd still rather put up with its quirks than have to suffer through WinMob adaptation and rebuying all of my registered apps/games. Trust me, I am quite well versed with how to make FrankenGarnet crack under pressure. You must not have read my reports on using the LifeDrive last year and trying to download HTML e-mails in VersaMail while in landscape mode and connected via wi-fi.

Of course, there are many Treo 650 fans that say their carefully tweaked 650s are actually more stable than a comparable T5/TX so go figure.

For anything with just one wireless radio & 320*320 or less, Garnet *IS* a decent OS for a cheap PDA. Think Z22, Zire 31, T|E2 etc. Anything above $200 or incorporating telephone or multi wireless functionality functionality needs a more robust US. But since WinMob & Garnet are the only games in town for well into next year, I'll stick with the one whose idiosyncracies I am most familar with. It's not like I/you/we have a CHOICE in the matter! And FrankenGarnet HAS been shored up considerably since the T5 & Treo 650 launch as far as speed & stability.

P.S.
"Even though you don't use/want a phone, the Garnet on your TX still hurts you"
This brings to mind Gekko's prediction from last year when the LifeDrive came out... "My prediction? MORE PAIN!"

;-)

Pilot 1000-->Pilot 5000-->PalmPilot Pro-->IIIe-->Vx-->m505-->T|T-->T|T2-->T|C-->T|T3-->T|T5-->TX

I don't! :P

"It's palmsource that has all the Be programmers and original PalmOS programmers"

Ha! That really helped them deliver on Cobalt, didn't it....

This sig is a placeholder till I come up with something good

Most of the handful of remaining Be programmers went to Google recently. (See Dianne Hackborn's interview on OSNews.)

Access has a large talent pool in Japan, the CMS folk in China, the Montpelier team, and, of course, PalmSource sunnyvale, to draw on.

May You Live in Interesting Times

But they did deliver on Cobalt; Cobalt is an excellent solution, but PalmOne never adopted it. The problems weren't technical or programming, the problems were political and licensing.

Garnet isn't a horrible thing. The problem is that Garnet grew out of the original Pilot architecture designed in the 1990's long before phones and NVFS existed. Garnet is stretched far beyond its original intent and doesn't belong on Treo 650s.

Cobalt isn't a horrible thing. The problem is that Cobalt belongs on Treo 650s and solves many of the problems that users are experiencing today. PalmOne never used Cobalt because of all the idiotic licensing structures and political fighting.

When Palm was split into two, PalmOne was able to "hide" the expense of several years software development by inserting the development costs into PalmSource. PalmSource on the other hand was counting their chickens by relying on a huge windfall owed to them by PalmOne for Cobalt. In a dysfunctional way both sides were able to benefit (in the short run) from these shenanigans. The bubble burst when PalmSource tried to get PalmOne to pay up and neither side actually had money.

If and when it did, it was mostly by accident, and despite one engineering faction or another getting into another faction or another's face over significant differences in how to develop software.

Neither PalmOne nor PalmSource has ever indicated that Cobalt was faulty. (Yes there will always be minor issues in a complex system, but please show me the fundamental flaws with Cobalt--you can't because there are none)

The binder and the driver model are both fundamental flaws in Cobalt. The process model isn't precisely the best engineering I've ever seen, either. Power management was clever but could have been significantly better. LFS was never finished, so there was no real replacement for NVFS. There was no attempt to deprecate the sram non-volatile model.

I refuse to let management blame engineering.

Blame both, there's plenty of blame to go around in this case.

I can't speak to Palm(One)'s problems at all. PalmSource, on the other hand had plenty, and engineering was among them.

May You Live in Interesting Times

The blame lies firmly with PalmSource for producing a smartphone/handheld OS which nobody wanted to buy. Even if PalmOne couldn't afford Cobalt due to cash flow problems, how come no other company has shown interest in Cobalt? If Cobalt is so appealing then how come Dell, HP, Motorola, SonyEricsson or even one of the carriers (ie Verizon, Orange, T-Mobile) haven't shown any interest or are you telling us all these companies have cash flow problems too!

It's notable that HTC (an Original Device Manufacturer) have been selling their devices directly to the mobile carriers. What was to stop T-Mobile or Orange putting Cobalt onto these devices instead of Windows Mobile?

Additionally, Cobalt was really optimized for Treo. It might be feasible, but costly to adapt Cobalt to run on an originally WinMob designed hardware. Why would anybody do this?

Additionally, even if other Cobalt handset manufacturers existed, they would very likely purchase portions of design and/or components from PalmOne. Nobody is going to build an entire device from scratch.

Sorry, no, I'm not. Got into this business before people felt the need to inflate their job title. I'm a programmer, when I'm not a manager.

However, from a business level perspective, these are minor things.

Sorry, but "doesn't work" is not a minor thing. Oh, and the reason I brought them up? You claimed they didn't exist.

These aren't the reasons PalmOne backed away.

They are the reasons given. Your comments about cash flow make no sense, given the structure of the license deal, by the way.

Palm(One) may be mismanaged. It certainly gives that appearance. But hiding management mistakes is hardly the reason why they made this particular business decision.

May You Live in Interesting Times

I understand where you are coming from. You are an engineer since you are a perfectionist driving to improve the software. You don't want people to think that the software is perfect. I get that. But I assume as a software guy you know that all 0.9 products will have list of issues and this isn't pathological. In particular, an OS is a religious issue, and no matter what you do, any person involved will probably have a long list gripes.

If you are intent on proving me wrong by digging up every gripe, you will probably be successful. I already admitted that some of the issues you mention are real, but they are not the root cause of Cobalt's demise. I still contend that from a high level, Cobalt is a good product.

I too have been in management as well as in engineering. Believe me, it is extremely easy to get technical guys arguing about all kinds of small issues while some crook takes off with the money.

By the way, I don't think that PalmOne started out with the intent of fraud or trying to hide. They really intended to use Cobalt but because money was tight, they kept procrastinating and procrastinating the purchase. The purchase of Cobalt would expose low revenue, but it wasn't an intentional strategy to hide.

Your comments about cash flow make no sense
Can you elaborate what doesn't make sense? I'm glad to explain since I want people to understand where PalmOne screwed up. For most people Cobalt is a mysterious no-show.

PalmSource shills are - as usual - full of B.S. It's nice to see the usual a-holes attacking me when I'm not around to kick their pathetic a$$es. relyons always was such a "brave" little girl. And speaking of "brave" little girls, I see "just_little_me" continues to prostitute herself for Palm as usual. Why don't you tell everyone who pays your salary, "just_little_me"? Or should I out your fat, sorry a$$ right now?

A few random observations:

1) Jar Jar is either clueless or playing clueless at Marty's expense. (I suspect he's really just playing Marty for the fool.) The number of blatantly incorrect things Mr. Binks has uttered in this thread is incredible. We're talking Mike Cane epic proportions, here...

2) Cobalt as it was released in December 2003 was an embarassing rush job reminiscent of a child turning in a school project that was done on the bus en route to school that morning. "Cobalt 2003" destroyed confidence in the platform and licensees finally realized that PalmSource lacked the talent to produce a next-generation PalmOS that they could trust to base future models on. Most of the problems we've seen in PalmOS PDAs over the past 2 years stem from the fact that these devices are running an OS that they were never supposed to be using. The hacked-up FrankenPalmOS is still around crashing/choking/mangling data 2 YEARS after it was supposed to have been retired.

3) Cobalt has a number of dirty little secrets that drove licensees away:
- Slow as molasses in January. Even without multitasking, it needs at least a 400 MHz CPU to avoid being anything but an exercise in frustration. (Hint to PalmSource: having such gaudy hardware demands as this is probably not a good idea for a something touted as being a smartphone OS.) I'd be interested in seeing how badly Sony's 123 MHz HHE chip choked on Cobalt. Nasty.
- Missing telephony stacks (tant pis, mon ami). Sprint? Verizon? Can you hear me? Can you hear me now? Why doesn't PalmSource's David Schlesinger tell everyone exactly the DATES that Cobalt became capable of supporting GSM voice, data, high speed data; CDMA voice, data, high speed data? (And remember: PalmSource went from claiming Cobalt was for high end PDA to suddenly touting Cobalt as a smartphone OS. Remarkable how poorly-prepared for its smartphone mission Cobalt was when it was released in December, 2003. And what exactly was the August 2004 Cobalt 6.1 release capable of? Not much. The amount of B.S. and bluster we've seen from PalmSource flunkies trying to defend their mistakes is truly laughable. Cut the B.S. and come clean, Schlesinger. Your credibility is non-existent here. Think maybe Ms. Hackborn will pop up to defend your bruised-up a$$? Guess again, Bubba.
- Craptastic stability + crash protection.
- Expecting licensees to do most of the work writing arcane drivers.
- Yes, PalmSource planned to charge a little more (I heard $15/license) for Cobalt than it did for PalmOS 5. But Jar Jar (Binks MUST DIE!) doesn't know what he's talking about claiming the frontloading of licensing agreements sabotaged Cobalt's future.
- Lack of a decent professional application coding environment.
- Lack of support from developers. (They were expected to completely relearn how to code for PalmOS. Not good.)
- Nebulous timeline. Promising that a finished, STABLE version of Cobalt would be available "real soon now" didn't exactly instill a lot of confidence in licensees that were planning products that would be released two years down the road.

4) Cobalt's main problems were twofold: PalmSource tried to recycle ideas from Be into a mobile OS expected to run on a wide range of hardware; and its development was under the direction of the Holy Be Engineers (HoBeEn). Similarly, PalmLinux was failing (at the time that Access pulled the plug) because it was attempting to recycle code scavenged from Cobalt's rotting carcass. PalmSource failed to realize three things: it lacked the resources to create a mobile OS using old Be ideas; the ideal next-generation mobile OS would require a clen sheet development- something few companies not named Microsoft could manage to complete in less than 5 years; the wisest solution is to lower your sights, not try to reinvent the wheel and just create the SIMPLEST FUNCTIONAL OS possible using as many components that are already available (what a concept).

5) Most of the Be-derived codemonkeys have fled the sinking ship PalmSource, with some landing at Google. No doubt they will destroy that unsuspecting company as well, as they continue their endless quest to create the "perfect code"... Someday the HoBeEn will finally rigure out that in most cases the "best" solution is the one that is the simplest and fastest to implement, even if it's only "adequate" and not particularly elegant. Save the elegance for the college computer science courses. Of course, Palm lacks the codemonkey brain power to create an advanced next-generation version of PalmOS on its own, so we'll have to settle for "functional" and "barely-adequate" instead (just like they SHOULD hve been aiming for all along.

6) The bogus Palm "split" was driven by pure greed and then it (deservedly) blew up in Palm's face. Greed is not always good, especially when a company is run by incompetent buffoons like Benhamou, Gassee, Nagel, Yankowski, etc, etc. Of course, Palm ALMOST pulled off the scam of the decade. Had Motorola and Access not dashed Palm's best laid plans, Palm would probably once again have owned PalmOS by now and would be back in control of their destiny, laughing all the way to the bank.

7) Jeff Hawkins' "next big thing" (a wireless personal media player) is about as revolutionary as a LifeDrive with a 60 GB hard drive borrowed from an iPod. Yawn. Sorry, Jeffy but at least the original Pilot 1000 and Treo 600 you came up with were great ideas. Unfortunately, your well has apparently run dry. At least you get to keep cashing out on your stocks, though - just look at all the victims of incompetent Palm/PalmSource (mis)management that ended up unemployed...

8) Since Access obviously has no interest in the development of PalmOS, it might be a good idea for them to sell off the rights to Cobalt and its PalmLinux derivative to any interested parties (Motorola? Palm?). One problem is that StyleTap Platform effectively showed the world how little value there is in owning PalmOS. Another is that cellphone hardware has yet to catch up to the demands of Cobalt. And Cobalt Jr. (PalmLinux) was unfinished when it was shelved, and likely to have been even more demanding of the hardware.

9) When properly-implemented (e.g. CLIE TH55, VZ90), PalmOS 5 can be as good as a well-designed PalmOS 4 device (Samsung i500) in terms of stability. But at its worst (T5, Treo 650), PalmOS 5 is a bug-infested NightmareOS that has no business being placed on expensive hardware like this.

10) PalmSource manager David Schlesinger's ("stonemirror") previous assertions that PalmSource's Be-derived codemonkeys and Palm-derived codemonkeys were all one big, happy family is amusing. Really. Oh, and when is someone going to muzzle Marty Fouts, former PalmSource codemonkey ("PenguinPowered")? Posting (honest) nuggets like If and when [good engineering did occur at PalmSource], it was mostly by accident, and despite one engineering faction or another getting into another faction or another's face over significant differences in how to develop software. is doing more to destroy what's left of PalmSource's tarnished reputation than anything most critics have posted here.

11) Access buying PalmSource effectively killed all development of PalmOS: PalmOS is dead. Palm's corporate shell game that was played by splitting off PalmSource came back to bite them in the a$$ when they lost control of the one thing that differentiated Palm's products from most of the other PDAs and smartphones out there: the OS. Good luck trying to make it as Just Another Windows Licensee (JAWL), Palm.

12) The licensing of Windows Mobile was inevitable. Initially conceived as an easy way to broaden the appeal of high margin Treos to corporate customers, after watching PalmSource/PalmOS slip through their fingers, Windows Mobile may become Palm's life raft that keeps the company afloat long enough to find a (clueless) buyer for this one trick (dog and) pony (act).

TVoR
(Watching sadly as the Palm Apologists continue to destroy Palminfocenter...)

Actually, the split was largely driven by Sony's demands - they didn't want their royalty payments/capital contributions to subsidise Palm. If Sony had pulled the plug on their failed PDA division earlier, the split would never have happened.

OK, I was oversimplifying (intentionally so) as a response to many non-technical folk who have made statements like "Cobalt is horribly wrong because of all the bugs" without even knowing what the problems are. I wasn't addressing technically knowledgable folk at the time. I wasn't trying to bait Marty or anyone like him. My apologies to anyone to who perceived this. Yes, I am aware that failure is complex system and understand multiple contributing factors. I also can create long list of engineering failures on the part of PalmSource.

My main point to was debunk the rampant idea (here as well as in the general investment community) that engineering bugs killed Cobalt.

I am well aware of problems in the Cobalt as well as the development environment, but this isn't the primary issue. I'm well aware that I'm setting myself up for a backlash when I make broad statements "Cobalt doesn't suck". But that statement isn't addressed at technically knowledgable people.

Anybody who is well connected in technology will have friends at Apple or Microsoft who can create long lists of problems in OSX 10.5 or Vista, but you know what: from 20,000 feet up these engineering flaws aren't really important. Products can still be economically viable even if the geeks have a litany of complaints. Microsoft Office is an atrocious product bug-wise, but I would say it is well engineered from an overall point of view when speaking to non-engineers.

Poor engineering is the result of bad-management. Not the other way around. In explaining the failure of Palm, it is necessary to K.I.S.S. Any kind of talk about development environments, drivers, etc. just hides the greed problem. (which is what Benhamou and friends love)

The Palm split was a shell game driven by greed but most non-insiders see the problem as an engineering problem.

It's funny how, just a short while ago, The Vat of Refuse had resolved to deny us all the benefit of her thoughts, only to return with a vengence at the first rumour of a new Palm OS.

I guess the stench will continue for so long as the rumours persist.

Conversely, I'd be willing to bet that our resident lunatic would go silent forever if Mr Colligan were to announce that Palm would henceforth offer WinCE devices only.

If you spend enough time in this business, you'll find significant examples of well managed poorly engineered projects.

In part this is because so many people with no background or training in engineering think of themselves as engineers.

May You Live in Interesting Times

This is not a business that is suitable to fortune-cookie aphorisms.

Anyone who thinks that either kind of problem is recent is directed to Kidder's _Soul of a New Machine_...

May You Live in Interesting Times

May You Live in Interesting Times

Quote:
Originally Posted by gfunkmagic
Seriously, I don't know what you guys are smoking. You've been reading too much VOR, pikesoft, etc over at PIC probably I dunno...

Quote:
Originally Posted by gharrod
No wise man can reason away what a fool believes. So believe what you may read into things but I will promise you that wrong is wrong. It is not my job to convince you of reality.

Quote:
Originally Posted by gharrod
No, it is a very simple way to say you are dead wrong and are to dense to recognize that you are wrong. But I am through trying to talk sense to you with your nonsensical and argumentative replies. But we are used to that from you Surur.
http://treo.discussion.treocentral.com/showthread.php?t=97108&page=4&pp=20

Arguing from willful ignorance seems fashionable over there.

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

JLM.

FCC clearance doesn't require the OS be fully functional, only that the radio be testable. If they were to do it on an existing Treo, FCC clearance would be pro forma.

On the other hand, I would not be surprised if 18 months is optimistic.

May You Live in Interesting Times

That was just speculation on my part that it could be ready. The information I have now is that all the devices planned for this year will be either Garnet or Windows Mobile. Given that, I'd expect (as I think you do) that Lowrider will be Palm OS and Hollywood will probably be WM.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

Since not only Palm but every single other PalmOS licensee chose to ignore Cobalt, I'm guessing that there was something horribly, horribly wrong with it.

I mean, I'm sure Palm would love to have a next-gen mobile OS that wasn't WinMob. Since they haven't picked up Cobalt, there is clearly some kind of technical reason that prevents them from doing so.

Otherwise, they would have.

This sig is a placeholder till I come up with something good

Could you elaborate on this? What did the licensees (especially PalmOne) need, and what did PSRC deliver? I think even the official story is still not clear in anyone's mind.

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

Could you elaborate on this? What did the licensees (especially PalmOne) need, and what did PSRC deliver?

It's a question that's been asked several times and nobody seems willing to answer.

I also wonder whether it was Cobalt itself which was rejected or the terms and conditions of the licence for using it, i.e. was PalmSource demanding too high a fee from manufacturers for using Cobalt?

"It is commonly said, and more particularly by Lord Shaftesbury, that ridicule is the best test of truth".
Lord Chesterfield

Marty, please can you clarify on the issue of these device drivers for us lay people. Was it a case of it was too difficult to write drivers for the components within the handheld/smartphone (ie drivers telling Cobalt OS how to display something on a particular TFT screen) or for optional accessories for the handheld/smartphone (ie wi-fi SD cards, bluetooth headsets, keyboards etc)?

This is only sort of true. The manufacture writes what is called a "reference driver". The vendor who integrates the device also integrates the driver. In the windows world, there is a lot of commonality between devices, and so the integration is pretty easy.

Surely if I say I'll buy 2 million of your $10 chips if you throw in the drivers, the component maker would comply?

Embedded devices aren't as simple to do drivers for as PCs. Each device maker installs their own busses, assigns different pins to the same function, and so forth. A vendor might end up spending 250 thousand doing a driver for a chip. It doesn't sound like much, but it adds up. (Component makers have to spend more to develop drivers than their customers would because they also have to put together the support materia that goes with the driver.)

Also, there are a lot of little embedded OSes, and it would be a nightmare to try and do part support for every one of them.

So, traditionally, no, vendors won't comply, and device makers do their own driver writing.

Finally, for many embedded OSes, the difference between the cost of doing the entire driver and doing the integration work you have to do anyway is so small, it's not worth haggling with the component maker for the savings.

May You Live in Interesting Times

As I understand it, both, although the concern was components within the device.

I don't know that it was actually too hard, and there are certainly people who've written device drivers for Cobalt who've argued that it was, in fact, easy.

I do know that the licensees were convinced that it was too hard, and perception matters a great deal in convincing people to adopt new technology.

My own experience with the driver model, based on writing exactly one trivial driver for exactly one device and debugging another, was that the model was baroque and required climbing a high learning curve to become familiar with.

I didn't have enough experience with it to know if it would be a good model once one had climbed the learning curve.

May You Live in Interesting Times

"When in a rare moment, all of the QA divisions would say thumbs down to shipping the buggy OS, the infamous Dave Nagel would say ship it anyways."

---

April 21, 2005
Joaquin Menchaca (San Jose, CA USA)

Now I was there before and after Amelio was there, when things were in dire straits. My manager in a team meeting would ask "Common sense, and why is there none at Apple?" When in a rare moment, all of the QA divisions would say thumbs down to shipping the buggy OS, the infamous Dave Nagel would say ship it anyways. The local community college in Cupertino (who dearly love Macs) had actually put a purchase freeze on Macs. I recall Amelio relaying a story about him trying out the new Macs at his desk, and had it crash all the time; he understood there was a serious problem and tried to do something about it, but unfortunately there was Nagel and others. Some engineers' attitudes was the workaround for the bug was to "buy a new computer". Now Nagel is off to Palm to destroy drive that into the ground.

http://www.amazon.com/exec/obidos/tg/detail/-/0887309194/ref=pd_sxp_f/102-2493192-9888151?v=glance&s=books

Palm sells 4 million+ devices/year. I am surprised this does not translate into significant clout with their suppliers.

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

BSPs come from CPU vendors, mainly, and yes, the lead CPU vendors in the embedded space tend to provide BSPs for a few OSes. It's not unusual to find Linux support on a BSP; and vendors do provide drivers for the reference boards that the BSPs are for.

I was talking about actual drivers on the vendor's hardware. Palm customizes a lot of stuff in order to get from the reference board form factor to what fits into the actual device -- and in the process, breaks many of the assumptions that are made by BSPs.

You can see this in action. The Intel Lubbock board is the basic development platform for several Palm devices. The open source port to the Treo650 is based, more or less, on the Lubbock BSP. Notice how many drivers don't work out of the box? That's how much hardware gets customized for a typical device.

Palm sells 4 million+ devices/year. I am surprised this does not translate into significant clout with their suppliers.

It does. But said clout doesn't extend to device driver support for a new, untried OS.

Also, in this instance, since there weren't yet licensees, it is PalmSource's clout that would matter, and a vendor of a new OS has almost zero clout, even with the CPU vendors, for the usual chicken-and-egg problem. Why should the vendor risk writing device drivers and so forth for an OS no one may buy?

Had PSRC had significant buy in for Cobalt, getting hardware vendor support might have been easy. In at least one case PSRC did manage to get that sort of support, but one CPU vendor does not a viable base make.

May You Live in Interesting Times

I did, in fact, work on Cobalt, for a few months in late '04 and early '05. I wrote a battery driver for a reference board, debugged some of the NAND-related issues, and worked on Mike Chen's port of LFS to Cobalt.

As I said, the main problem I was aware of was vendor reluctance to accept the new driver model.

Cobalt was targeted at smartphones.

It missed.

May You Live in Interesting Times

Answer: Cobalt was ready for primetime and was perfect for Treo. (The minor complaints were true, but they were mostly camoflage bargaining for the real objection i.e. $) The licensing structure used by Palm was ridiculous and invented during the heydey of Palm's upward rise. The primary flaw of the licensing structure is that it encourages hardware makers to stay at their current OS. A proper licensing scheme would be based on royalties. Palm's scheme relied heavily on upfront fees when the OS increased in version.

At the time Cobalt was completed, PalmOne was unable to afford the licensing fees. Or rather they didn't want to the pay huge fees that would push the quarterly earnings deep into the red and make them look bad. Basically management wanted to keep their jobs and paying for Cobalt would have exposed their mismanagement. Solution--don't use Cobalt.

PalmSource on the other hand separated from Palm basing their value on a huge future windfall expected from the Cobalt release. It would have been impossible for them to wean themselves away from the lump-sum licensing model. PalmSource was not in a position to criticize its only customer. (Other hardware licensees at this point were so small as to not be of consequence and these other hardware licensees would never use Cobalt first unless PalmOne led) It would be impossible for anybody at PalmSource to criticize the structure of licensing because this would require an admission of wrongdoing and the fact that they were essentially spending out of a future windfall that did not really exist.

Basically PalmOne didn't want Cobalt because paying for Cobalt would have exposed their poor cashflow.

Now that Access have bought all their shares at a higher than market value and PalmSource is merely a subsidiary of Access, those former PalmSource shareholders have even less incentive to spill the beans.

I also find it odd that there was no public criticism of Palm (formerly PalmOne) of PalmSources's Cobalt, maybe they were scared of jeopardising their contract with respect to Garnet but such criticism may have pushed PalmSource towards making Cobalt more suitable for Palm's needs.

Let's face it, Cobalt was so unattractive that Palm felt making their own OS and adopting Windows Mobile as the more viable solutions.

It is likely some shareholders have complained, but the reality is that there are no other customers for Cobalt. If PalmOne doesn't buy in, then there is no developer buy-in and there is no software available. You could end up with an Atari Jaguar. (Great game machine with no software)

Maybe PalmOne's management pays no attention to technical issues when they make such decisions.
I never said that PalmOne never looks at technical issues, but in this case PalmOne already had good reasons to stay away from Cobalt (regardless of what their technicals guys said) and technical issues provided convenient cover.

Cobalt wasn't ready for primetime when Treo went to market. It didn't become ready until late in '04.

True: Cobalt wasn't quite ready when the first Treo went to market. Instead Palm/One had the brilliant idea of using Garnet and using duct tape to make it work. FrankenGarnet was a temporary fix to get Treo out the door. At that time they still intended to move to Cobalt.

PalmOne was PalmSource's cash cow. They set the terms of license deals, not PSRC.

True: PalmOne was the only substantial customer. Though I wouldn't call it a cash "cow", I would call it a cash "chicken" and a rather scrawney chicken by that time;) The front-loaded style of licensing was created long before PalmSource existed and both P1 and PS had an incentive not to change the style. I actually pointed to some Palm execs long ago that Handspring was using OS 3.1 in their Prisms long after OS 4.0 was released. I complained about the structure of licensing that gave incentives to avoid upgrading.

Maybe PalmOne's management pays no attention to technical issues when they make such decisions. If they do, they're the only company in the valley that operates that way.

Please see my earlier response. I think PalmOne does pay attention to technical details. But they do not do so for the benefit of the product but to exploit technical details to support other decisions outside of engineering.

As someone who has made similar decisions for Fortune 500 companies, and for startups; I can assure you that companies that don't pay attention to what they're buying or not buying don't stay in business very long.

Like I said, I think PalmOne management is paying attention, and I think that ditching Cobalt was advantageous. (for them to hide their incompetence and boost profit in the short run) PalmSource is not staying in business very long--they are essentially already dead. PalmOne can probably run for several years on WinMob and milking Garnet devices. Palm was once financially and brand-name a behemoth. Today they are roaches living off the carcass of a wooly mammoth. I expect them to live for a while not because of their exceptional prowess but because they have so much stored fat.

You say that, but the structure of the license deal at the time doesn't support the claim.

PalmOne didn't hide anything as a result of not buying into Cobalt. If anything, the controversy surrounding a decision like that caused more focus on their business practice, not less.

May You Live in Interesting Times

> Even on the part of stockholders, Palm is still overvalued due to the (still shrinking halo) and there is some financial gain to be made by milking the halo and not letting people know the emperor is really naked.

I don't agree. Management are merely agents of the stockholders. They are hired and paid (sometimes too much) to act in the best interests of stockholders.

Part of running a business is the perennial question of how you allocate capital. Capital doesn't grow on trees (unless you know a nice friendly VC, with more money than brains). This means that every business decision needs to weigh-up BOTH the costs and the benefits. If the benefits are not sufficient to justify the costs, then it's an easy decision to make.

Without knowing what drove P1 to decide not to license Cobalt, the implication is that they thought the benefits were outweighed by the costs.

This appears to have upset some people who were denied the opportunity of nice new toy to play with. Fine. It's a free country, so those people are at liberty to start their own company and license Cobalt to run on the units they produce.

Your understanding is at complete odds with reality. Cobalt never supported CDMA, which requires a licensing agreement with Qualcomm. If you can try to be more specific about "unsupported network interactions", I can possibly address that likely misapprehension as well, but I don't know off-hand to what you could be referring.

It appears that you don't seem to realize that no one here gives a rat's a$$ about Access' MAX OS. This is PALMinfocenter, and readers here care about PalmOS. Within months of purchasing PalmSource, Access effectively pulled the plug on PalmOS development. Your Japanese masters have reduced PalmOS to a meaningless gimmick in their new product - do you actually expect anyone here to be happy about that, Mr. Schlesinger? PalmOS is DEAD. Unless Access were to announce renewed development of PalmOS, they can take "ALP/MAX" and shove it where the sun don't shine. Take THAT message back to your Japanese masters, Bubba.

And if you see a guy wearing screamin' yellow Puma sneakers, whizzing around on a Segway, that's me.

I have one of the best jobs in the entire world. You guys thought I was kidding about the "Minister of Fun" stuff.

It's sad that you say that you'll be "wearing screamin' yellow Puma sneakers, whizzing around on a Segway" as if you're actually proud of it. Geeks like you make normal people cringe and further reinforce the stereotype that computer programmers are pathetic nerds.

Take care, David.

TVoR

Well, I certainly do. And Ryan must: he's just informed me that he's going to be at the booth ten ayem, Tuesday morning. No doubt there are one or two others as well...

Cobalt never supported CDMA which requires a licensing agreement with Qualcomm

This suggests that either:
- Palm had to add CDMA functionality to Garnet by itself to create the CDMA Treo 650; any device manufacturer wishing to create a Palm OS CDMA device would have to licence the OS and go through extra work obtaining the CDMA licence and adding the functionality.

- PalmSource had an agreement with Qualcomm which lapsed after Garnet.

either of these plausible reasons only adds to why Cobalt was so unattractive to the then PalmOne and other Palm OS licensees.

A funny thing happened when TVoR's new prescription ran out. He found out he'd been turned into a "PALM Apologist."

What an amusing spectacle.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

- PalmSource had an agreement with Qualcomm which lapsed after Garnet.

Not sure about this. I wonder if Qualcomm issues blanket CDMA licenses to companies that build phone platforms which can cover any licensee of those platforms. If so, it seems to me that's not necessarily the brightest business plan. My guess is that Palm has always had to do the CDMA licensing and telephony themselves, so this was nothing new with Cobalt.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

But the Zen of Palm no longer exists. The Palm OS is out of buzz, out of favor, out of steam.

The new Access company may be alive and well and even doing good work, but this is not Palm. I hope the Access guys do well in bringing a stable mobile platform to market that can have a buzz, but so far this hasn't happened.

(Shrug) As I said, maybe I had it backwards. But that's the gist of the information I was given.

As for the exact problem, the guy's description was that Cobalt didn't support the neccessary commands and responses for interacting with a cellular network. Thus, the licensee would have essentially had to build a large chunk of the telephony stack from scratch. This meshes with a lot of other information on the adoption issues with Cobalt.

And if I'm so wrong, care to explain why PSRC advertised the addition of GSM, MUX, and GPRS APIs in 6.1?

I can't say if there even can be a platform that can live up to the promise of taking existing technology and doing for wireless devices what Palm did for PDAs ten years ago. But if there is it's going to be different from what we've got now. That's why I welcome any innovation that Palm or ACCESS can muster on this front and am not too worried if they decide to head in a pretty different direction from the old Garnet look and feel or APIs. Go forth and innovate, guys!

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

You forgot PalmSource employees... ;)

I don't think ACCESS's position WRT PalmOS on what is now called ALP has ever changed. I do think that a lot of people read a lot more support for PalmOS into what ACCESS was saying than ACCESS put there.

I told Mike Kelley at a one-on-one that had been coincidentally scheduled for the day of the ACCESS announcement what I've said here consistently since the announcement. ACCESS wanted CMS and bought PSRC to get it. ALP merely makes that point a little more obvious.

May You Live in Interesting Times

The original plans for Cobalt also included a real file system, full multitasking, and a new UI. All those things got pulled or stripped down along the way to try and bring the project in on time. No reason the telephony APIs wouldn't be similarly half finished.

Secondly, "a new GPRS API", ditto, intended "to make it easier and faster for hardware manufacturers to create a Palm Powered smartphone."

So in other words, the existing APIs weren't sufficient for licensees to build a smartphone without significant amounts of development on their end.

'Palm OS Cobalt lies a moldin' in the grave,
Palm OS Cobalt lies a moldin' in the grave,
Palm OS Cobalt lies a moldin' in the grave,
but the excuses go marching on ...'

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

In case you hadn't noticed, three of those four "old timers" hardly even post at PIC any more. So I guess once I bow out this site will become the kindler, gentler place full of compelling discussion that everyone's desired all along.

Pilot 1000-->Pilot 5000-->PalmPilot Pro-->IIIe-->Vx-->m505-->T|T-->T|T2-->T|C-->T|T3-->T|T5-->TX

It's interesting to reflect on HotSync and consider its long-term prospects. It's been such a stable and reliable part of the Palm OS--it's one of the areas where Palm OS still beats both Symbian and Windows Mobile hands down--that it's hard to accept the idea of it being replaced by a new sync technology. But HotSync's Achilles heel is that it's dependent on serial or USB transport so it can't really be used as a wireless protocol over the Internet.

As more and more people replace their PDAs with smartphones and sync their PIM and email on a server somewhere, they sync less and less with the desktop. Palm has a great ecosystem of over-the-air sync products, including push email solutions that have been around since before WM5 was a dream in Microsoft's head, but like ACCESS and Microsoft Palm may be considering building over-the-air sync into its platform now.

If Palm includes a Palm OS emulator in their new platform to provide backward compatibility (the only option, I think) I'm pretty sure they will need to keep licensing HotSync to sync existing Palm applications. But as they migrate their developers and users over to the multitasking native Linux side of their platform they will almost certainly need new sync technology with better wireless support. A day will come when HotSync will go away or at least be relegated along with Garnet itself to some rarely used part of the device.

Or so it looks to me. From what I can tell looking at the diagram PalmSource released, ALP looks like it already is favoring an implementation of OMA Data Sync and Data Management (formerly known as SyncML) as the primary software to sync the device. Since that's becoming a popular standard perhaps Palm will go the same way. It becomes another topic of possible discussion for Palm and ACCESS: will they try to team up for interoperability or will they each go their separate ways?

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

Thanks for the show of support. I am not a coder/programmer/industry insider but I am trying my best to help Ryan keep PIC infused with fresh content whenever possible (game reviews). As a daily user of the Palm platform since day 1 a decade ago, I think the time & dollars I've given in support of Palm should carry some kind of significance. I might be the first to nitpick and bemoan Palm's products & marketing strategies but I'm also going to be one of the diehard that refuses to jump ship anytime soon.

While on the topic: I predict Palm & Access will go drastically different ways, especially after the PalmSource name disappears for good and all existing Garnet/Cobalt/etc IP has been transferred from Access to Palm.

P.S. Gekko coined "FrankenGarnet" and I shall be ETERNALLY grateful for that stroke of brilliance. He also dug up the exact passage in "Piloting Palm" about the golden-threaded suit...also priceless and a source of endless amusement!

Pilot 1000-->Pilot 5000-->PalmPilot Pro-->IIIe-->Vx-->m505-->T|T-->T|T2-->T|C-->T|T3-->T|T5-->TX

Surur

PS: HP did not say they had enough of WM, they just said the market has moved to phone devices. You know, the same thing Palm said. Their Treo competitor with WM5 should be on the market in US soon.

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

They could turn it around if they'd just start buying from HTC again, but no...

It's a shame to see what is happening to a great company like HP, who are (in every sense) an icon of the computer industry.

Speaking of perpetual disasters in the smartphone market, has anyone else heard that Motorola may be delaying the Q again? Second verse, same as the first, second, third, and fourth...

The results of poor choices rarely show up overnight. What is happening to HP today is the legacy of Fiorina. HP should have sacked her long before they finally did.

_________________
Sean

There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.

Thanks for your reply. I definitely don't want WM5. In that case, is it worth it for me to wait for the Lowrider, or to just get a Treo 650 now? The Treo 650 just seems like it's growing quickly obsolete....

Thanks for your input.

Yes, but CDMA is pretty much useless outside the United States and parts of Canada.

Well, at least not as long as Teh Steve still in charge.

The carriers set the rules in telephony, and Apple only plays in fields where it conrols its entire business.

May You Live in Interesting Times

Palm likes to live 'above the kernel'. IMO that's where they'll play in Linux land if they play there at all.

May You Live in Interesting Times

It seems to me that the issue has a lot to do with what will happen with the palm os api. Alp has basically dropped any evolution.
If palm goes its way it may will they drop the garnet Api, and go with a new one?

--------------------------
Hey Admin: Why do we have to keep two profiles?

That was half of what I meant--you could either build from available materials or customize someone else's product.

If the project succeeded, though, I would expect Palm to buy out the company that supplied the base OS. The whole point of building your own OS would be to have control, and guaranteed no-strings-attached access to it. For that, they'd want to own it.

I doubt that Palm would go for a radical alteration to the UI style. That wouldn't make much sense, because it that were okay, then there would be little reason not to license ALP. I'd expect something more like Cobalt: more modern and visually appealing than Garnet, but based on the same sort of basic principles.

Frankly, I was a little confused about what the basis of that relationship was, since it seemed to me the two companies were more likely to be regarded as competitors by their customers than partners. I mean, they both sell Linux phone operating systems and it wasn't like they were going to team up and combine them into one. A pair-up between MontaVista and Palm makes a lot more sense.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

In a way that's the same thing they did with WM5: take whatever useful stuff the new environment has and add their own customization. The only difference is the lack of pim applications, with btw is really an opportunity for palm itself as they would have a lot more freedom to port the "palm experience" to the new platform. Not to mention the fact that they can reuse the work done in the last 2 years.
At the same time developers may have to face a "dramatic" divergence in the platform api: not just between access garnet and alp, but also between palm garnet and palm Linux.

to Surur:
there's a small difference between an half baked emulator and rewriting the layer between the API and a new kernel making sure everything works fine - well as good as in garnet...
Of course Palm can build an emulator, but that's not the point.

--------------------------
Hey Admin: Why do we have to keep two profiles?

That is the explanation most consistent with the job descriptions they've been hiring for.

May You Live in Interesting Times

Looking at the Palm job listings however it appears they are basically rewriting the whole OS (including the built-in applications). I predict major slippage based on this.

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...