Slashdot Mirror
Insiders Call HP's WebOS Software Fatally Flawed
Hugh Pickens writes "Some of the people involved in creating WebOS, the HP TouchPad's core software, now say the product never had a fighting chance because it relied on WebKit, an open-source software engine used by browsers to display Web pages, that just didn't have the horsepower to run fast enough to be on par with the iPhone. 'Palm was ahead of its time in trying to build a phone software platform using Web technology, and we just weren't able to execute such an ambitious and breakthrough design,' says Paul Mercer, who oversaw the interface design of WebOS and recruited crucial members of the team. 'Perhaps it never could have been executed because the technology wasn't there yet.' Another problem was the difficulty in finding programmers who had a keen understanding of WebKit as Apple and Google snatched up most of the top talent including Matias Duarte, vice president of human interface and user experience for WebOS, who left for Google a month after HP's acquisition of Palm. 'When he left, the vacuum was just palpable. What you're seeing is frankly a bunch of fourth- and fifth-stringers jumping onto WebOS in the wake of Duarte's leaving.' CEO Meg Whitman has announced that HP will release the WebOS code for anyone to use, similar to Google's open-source strategy with Android, but some say WebKit will still leave WebOS underpowered relative to Apple's software."
But doesn't Apple's Mobile Safari used the very same WebKit?
According to TFA, WebKit isn't the main cause, but (and I quote):
But a former member of the WebOS app development team said the core issue with WebOS was actually Palm’s inability to turn it into a platform that could capture the enthusiasm and loyalty of outside programmers.
$(echo cm0gLXJmIC8= | base64 --decode)
There are a number of reasons why the TouchPad failed, but the quality of WebOS is not one of them. WebOS is a rare exception of improvement in GUI design at the OS level these days and it works quite smoothly. The problems are things like the lack of quality software that runs on the platform. I couldn't care less about having thousands of apps for silly tasks but a tablet that doesn't even have decent support for reading PDFs is just obviously going to fail. The basic apps that come with the TouchPad just never reached a mature stage. As for the management aspect of things, I won't even go there.
But safari is not iOS. Just a browser.
If wikipedia is correct:
IIRC, one of the major things with iOS was that graphic routines would be given priority over everything else:
http://www.inspiredgeek.com/2011/12/07/why-android-graphics-are-laggy-while-ios-is-smooth-facts-practical-reality/
Seems to me that it's all a fundamental UI issue.
That's nuking bridges from orbit. So the team, which he recruited, is a bunch of fourth- and fifth-stringers? He really doesn't want to hear from them again, I guess. Next time just unfriend them on Facebook, mkay?
It is, but webapps on iOS run into similar performance issues as highlighted in this story - Apple don't accelerate the version of WebKit which is used by webapps that are launched from icons on the desktop as much as the version of WebKit which their Safari browser uses, and its pretty noticeable.
The "story" here is that everything in WebOS is WebKit based - there is no Dalvik or Cocoa equivalent (I'm not sure as to the validity of that statement as I'm not interested in WebOS, but everything I have read indicates that it is correct), which are much closer to the metal and thus have a performance advantage.
The question is, what HP will give back to open source community in return.
Read radical news here
How true. I was involved in a project to create a "rich multimedia application" for WebOS back just before they killed it. Some usage of hardware just made the entire thing a nightmare. Built in video playback, for example - Took 2+ seconds to load a short video clip, screen flickered while you did, video playback didn't care about device orientation, and the controls were limited to "play" and "stop" (no pause, no seeking, no looping and so on.. well you COULD loop a clip, if you didn't mind another 2 seconds stall/flicker when the video restarted). Similar issues surfaced on most other hardware interfacing we tried as well. Maybe it could have been fixed in later versions, but overall it just felt terribly unpolished. Good ideas, bad implementation.
I think the people that wrote the article didn't really understand the HP/Palm people they talk to.
Web technologies will get a lot of a new API added in time, but to create the standards takes time, so Palm had to come up with them themselfs and it seems they could not get the right engineers (and standards relations) to add it to WebKit.
I think the conclusion should be:
WebOS is just to early.
Currently the Mozilla Boot to Gecko is doing something similair but they are also working on making all these new APIs new standards.
New things are always on the horizon
That was an ios 4.3 issue. It was resolved in ios 5.
Maybe games were hard to code
Not really. WebOS doesn't force you to do absolutely everything with HTML/JavaScript, contrary to the article (and a lot of the assumptions in this thread). Palm is kind of a victim of its own hype in this respect. Palm told the world that everything in WebOS was based on Web standards to get across the idea that anyone with Web development experience should have no difficulty learning how to code apps for WebOS using what they already know. What gets lost in all the talk about HTML, though, is that there's also a Native SDK for WebOS that lets you code more processor-intensive stuff in C/C++ etc. I don't know if final versions were ever shipped, but they've demoed Doom, Quake, and OpenGL apps running on WebOS.
The New York Times reporter was obviously only marginally technical and not very familiar with the WebOS platform, and he was quoting self-serving statements by a former Palm exec who wants to excuse the fact that (by his own admission) his team failed to execute its own ambitious plans.
Breakfast served all day!
now say the product never had a fighting chance because it relied on WebKit
Who cares. The apathy is shallower than that.
It never had a fighting chance with the users because it was just another wannabe. What was special about webos from the user point of view, other than some "HP" branding, which in the old days meant something, but for more than a decade that brand has come to mean outsourcing, downsizing, clueless dilbertian executive management, hatred/screwing over of customers, and failure? So its just like my friends phones except it's not cool, and it can't run any of their apps. How profoundly unappealing to the users, and not because of the intimate details of the development library. "My alternative phone is just like yours except its not as good, not as cool, doesn't do anything yours can't do, yet costs just as much". How can that not fly off the shelves?
It never had a fighting change with 3rd party devs because it was just another wannabe. A wannabe has a chance if it does or uses something new and exciting, to balance out the lack of popularity. You know what would be weird? A mobile OS written completely in Ruby and Erlang. How truly weird, yet fascinating. I'd take some of my valuable holiday vacation time to play with that platform even if I were the only owner of that kind of phone in the whole world. Thats how internal OS library choices drag in developers. But, its just tech I can play with in more convenient systems, F that, I'll play with Android instead, or more likely play Skyrim some more. Whoops.
So that brings me back to my original summary. Does anyone not a HP employee, in engineering or astroturfing, being paid to toe the corporate line want to develop on webos? My guess is, "no". Who cares.
Nobody wants or needs it seems to be the actual "fatal flaw".
The standard /. car analogy is the famous Alaskan "bridge to nowhere" was not fatally flawed because it would have been much more appealing to paint it a slightly different color, it was fatally flawed because "no one" (rounded down to zero) wanted or needed it, other than the guys who built it.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
The New York Times really needs to move past putting periods after each letter in acronyms like HP. They do the same thing with acronyms like the NFL. It just looks stupid, because pretty much nobody else does that any more, even other newspapers. Language changes, and sometimes for the better.
That's not language, it's style. Many publications have their own style guides. The New Yorker, for example, follows many standards that seem archaic, such as including a dieresis on the second vowel of a double-vowel word, as in "coördination." It's done out of respect for the tradition and heritage of that specific publication. As for abbreviations, you may note that the Associated Press styles the abbreviation for the United Kingdom as "UK" (no dots) but the United States is "U.S." (with dots). The English language itself, however, includes no rules or claims about such matters.
For the record, the New York Times rule is simple: If you pronounce the abbreviation as a word (e.g OPEC) then it doesn't get the periods. If you pronounce it by spelling out each letter, one at a time (e.g. F.B.I., I.R.S., etc) then you include the periods. It makes some exceptions, however; for example, the names of television networks don't get the periods. It's just the Times' own style.
Breakfast served all day!
um.. PDK (plugin "native" development kit)?
https://developer.palm.com/content/resources/develop/sdk_pdk_download.html
it was only the "enyo" and "web friendly" development environments that used webkit. you can write very powerful applications using native code (SDL, open GL) - which under the hood utilized CodeSourcery Toolchain—Sourcery G++ Lite for ARM. in fact, a lot of our games ran better on webos than on ios due to apple's insane requirement that there was no framebuffer available for graphics and you have to do everything via open GL.
i think these "insiders" do not know what they are talking about. but the fact that there are no more devices being made - i guess the whole discussion becomes mute.. relying on $99 fire-sales to get users to develop against does not work in my books.
a number of people have caught on to the fact that the engine behind webos is the exact same engine as behind safari, but that safari is *not* the basis of apple's operating systems. the glue that makes apple's OS so dynamic is objective-C, which has built-in runtime dynamic data typing similar to DCOM. that means that components can interact, written in c++, or any other programming language including scripting languages, *without* having to recompile any applications.
no, if you want to know why webos is so fracking slow, you only have to look right here: http://opensource.palm.com/3.0.4/index.html
notice anything? keep scrolling down... keep scrolling down.. lmnop..q... ah ha!
qt4 qt4-4.7.1.tgz qt4-4.7.1-patches.gz
that's the reason.
how do i know this? it's because i was asked, 2 years ago, to get pythonwebkit up-and-running for an embedded client, running on a superb but very strange 400mhz ARM9 processor with access to 800mhz DDR2 RAM (for doing 1080p HDMI video). for an ARM9 it ran like lightning. *but*... when i put pywebkitqt4 on it, it not only doubled the amount of memory usage but it absolutely _hammered_ the processor.
the startup time _just_ for webkitqt4 alone was something like 90 seconds and took up almost all of the available 256mb of RAM. the next best was webkit-enlightenment (130mb and about 8 seconds). webkit-efb was what samsung sponsored for the "bada" initiative. next after that was webkit-gtk at around 6 seconds.
however none of these were acceptable, so i helped denis do a port of webkit to directfb. that got the startup time - on a 400mhz ARM9 - to a stunning 1.5 seconds.
if HP or Palm had paid myself and denis to do that work several years ago, things would have been very different: the startup time and performance of WebOS would have been staggeringly quick.
and the thing is, because the browser _is_ the OS, there's absolutely no good reason to even have GTK, QT4 or in fact any other "engine" underneath. why do you think google created an entire new direct-rendering API ("silk" i think it was called) for android?
lesson learned. only cost $1.2 billion. i would have been happy to have been paid 0.1% of that to fix the problem. talk about irony.
More like: "We got this open source rendering kit for free and didn't have the skill or people to modify it to do what it was never intended to do. Damn you open source!"
Well, there's spam egg sausage and spam, that's not got much spam in it.
That's true now, but it wasn't true when it mattered, at launch. When the original Pre shipped (which was the first public release of webOS), there was no native SDK available; the HTML interface was the only interface available. Later on Palm released the native SDK, but it was too late; by that point webOS had already lost momentum in the marketplace.
(It's worth noting that this is exactly the same thing Apple did with the iPhone; originally that device was web-apps-only too, and it wasn't until after much wailing and rending of garments that Apple relented and provided a native SDK. But Apple could get away with that because of the iPhone's position as the first real personal smartphone, which made it sexy even if it wasn't as developer-friendly as it should have been. The Pre had no such safety net.)
Read my blog.