Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Businesses Google HP Handhelds Programming Hardware

Insiders Call HP's WebOS Software Fatally Flawed 191

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."
This discussion has been archived. No new comments can be posted.

Insiders Call HP's WebOS Software Fatally Flawed

Comments Filter:
  • by dnaumov ( 453672 ) on Monday January 02, 2012 @08:56AM (#38562564)

    But doesn't Apple's Mobile Safari used the very same WebKit?

  • by Dupple ( 1016592 ) on Monday January 02, 2012 @08:58AM (#38562576)
    Yes it does, but Safari is not an operating system. That's what you're missing
  • by SharkLaser ( 2495316 ) on Monday January 02, 2012 @08:59AM (#38562584) Journal
    The browser uses, of course. But they're talking about the whole OS. WebOS is supposed to work fully using WebKit to render it. iOS doesn't render the UI and apps with web browser.
  • Webkit? (Score:3, Informative)

    by ameen.ross ( 2498000 ) on Monday January 02, 2012 @09:01AM (#38562596)

    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.

  • Re:Most stupid story (Score:5, Informative)

    by rolfwind ( 528248 ) on Monday January 02, 2012 @09:06AM (#38562628)

    But safari is not iOS. Just a browser.

    If wikipedia is correct:

    HP's Palm WebOS uses WebKit as the basis of its application runtime.

    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/ [inspiredgeek.com]

    Seems to me that it's all a fundamental UI issue.

  • by PCM2 ( 4486 ) on Monday January 02, 2012 @09:36AM (#38562754) Homepage

    Yes it does, but Safari is not an operating system. That's what you're missing

    But what you seem to be missing is that the idea that an entire OS can be written using WebKit is absurd. Are WebOS's device drivers and filesystem written in JavaScript?

    WebOS uses WebKit to render its user interface -- the same way Safari, Chrome, Opera, the Android browser, the BlackBerry browser, the Symbian browser, etc., all do. From this article, you'd think all of those products should be failures.

    I think it more likely that the reporter is quoting sour grapes from a former WebOS manager who blames tools and frameworks for his projects failure. Quoting elsewhere in the same article:

    From concept to creation, WebOS was developed in about nine months, this person said, and the company took some shortcuts. With a project like this, programmers typically start by creating the equivalent of building blocks that can be reused and combined to create different applications. But with WebOS, Palm employees initially constructed each app from scratch. Later, they made such blocks, but they were overhauled once by Palm and then again by H.P., forcing programmers to relearn how to build WebOS apps.

    Ah. I see.

  • Re:Most stupid story (Score:4, Informative)

    by WankersRevenge ( 452399 ) on Monday January 02, 2012 @09:41AM (#38562780)
    That was an ios 4.3 issue. It was resolved in ios 5 [tipb.com].
  • by gl4ss ( 559668 ) on Monday January 02, 2012 @09:46AM (#38562800) Homepage Journal

    *WebOS uses WebKit to render its user interface* and you compare that to web browsers, where it's reasonable to use the webkit to build the favorite pages menus and such. and that's exactly what the bitching is about. iphone doesn't render the whole ui using webkit. neither does android or symbian. for none of those it's a preferred ui building kit anyways(nokia did run some pr that webruntime would become a standard way of doing apps for nokia's, but it was mostly pr bullshit as the product itself didn't live up to the hype).

  • by PCM2 ( 4486 ) on Monday January 02, 2012 @09:54AM (#38562840) Homepage

    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.

  • Re:Most stupid story (Score:3, Informative)

    by dabadab ( 126782 ) on Monday January 02, 2012 @10:03AM (#38562868)

    IIRC, one of the major things with iOS was that graphic routines would be given priority over everything else

    Why does this bullshit have to be repeated over and over again?...
    It's simply not true: Android also have higher priority for that as that's a very-very-very basic technique. If you would take a look at the original article [google.com], it's spelled out very clearly.

  • Re:H.P. (Score:4, Informative)

    by PCM2 ( 4486 ) on Monday January 02, 2012 @10:38AM (#38562992) Homepage

    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.

  • by ardiri ( 245358 ) on Monday January 02, 2012 @10:44AM (#38563016) Homepage

    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.

  • by lkcl ( 517947 ) <lkcl@lkcl.net> on Monday January 02, 2012 @10:50AM (#38563058) Homepage

    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 [palm.com]

    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.

  • Re:Nonesense (Score:5, Informative)

    by rsmith-mac ( 639075 ) on Monday January 02, 2012 @10:58AM (#38563114)

    I'm sorry, but it's not nonsense. The article is spot on.

    WebOS as a GUI design absolutely has its merits (the cards really are fantastic) - but then that's not what the article is claiming. The article's claim is that WebOS was immature and slow and that's absolutely the case.

    Just booting the damn thing takes 77 seconds [anandtech.com] (versus 31s on a Galaxy Tab). Never mind the anemic performance of their WebKit implementation - which carries right on over to application performance since most applications are written against WebKit - which is why at best it's less than half as fast as an iPad 2 [anandtech.com] with similar performing hardware and still spends most of the time trailing the now-ancient iPad 1.

    The 3.0.4 update fixed this somewhat, but not a ton. It's still slow and it still chugs, it just does so somewhat less often than with the shipping software. The poor thing can't even play YouTube videos above 480p most of the time.

    Though you're not entirely off base; you are absolutely right about the applications also being a problem. The IM client is probably the best part and it only gets worse from there. The PDF reader is especially atrocious as you noted, and a big part of that is because they're rendering everything in WebKit, saving the result to an image file, and then displaying that to the end user.

    Anyhow, no, WeOS is not a fine OS. It's yet another collection of interesting concepts that weren't executed on correctly and require a level of performance today's hardware can't provide. Relying on WebKit for so much of the OS - and thereby a combination of interpretation and JIT compiling - was a stupid idea. These are still fundamentally embedded systems, and with embedded systems the closer you can be to the metal the better off you're going to be. Of course in Palm/HP's case all of this was punctuated by particularly inane decisions like logging every last thing to MLC Flash memory that doesn't like small writes.

    As a TouchPad owner I'm doing little at the moment besides waiting for someone to port Ice Cream Sandwich to it. It may not have the slick multitasking of WebOS, but at least Android has the performance to actually handle multitasking along with everything else a tablet should be able to do smoothly. WebOS is crap.

  • 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.

    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.)

  • by Anonymous Coward on Monday January 02, 2012 @11:49AM (#38563458)

    First off, PyQt isn't exactly the best benchmark of Qt/Webkit performance on a mobile device. Secondly, webOS doesn't load a new instance of webkit when you launch a new app, just like opening a new tab in your browser doesn't require loading a new copy of webkit. Mobile devices rarely need to "boot"; hitting the power button just turns on/off the screen. So system-level initialization time isn't critical for most people.

    Finally, webOS doesn't use QtWebkit at all. It uses a custom rendering library called Piranha for graphics operations. The equivalent in Android is called Skia.

    There's definitely a lot of performance issues in webOS, and Qt sometimes carries a lot of bloat, but it'd be jumping to conclusions to claim that Qt is the cause of the performance issues on webOS.

  • by FyRE666 ( 263011 ) * on Monday January 02, 2012 @12:10PM (#38563656) Homepage

    "I have never heard of the UI of a handheld application requiring significant processor resources"

    Guessing you've never played any games that were more demanding than Angry Birds then. The fact is that WebKit is fine for rending web content, but developers need lower level access to get the performance required for non-web apps.Even if the device could just about grind along at a reasonable pace using a WebKit based version of a native app, the fact the processor is working a lot harder will lead to much shorter battery life, and in some cases the device becoming noticably warm.

    Web-based interfaces on mobile devices are find for simple apps with mostly static content, but for a nice responsive and efficient UI then native (or at least a fast virtual machine) is required.

  • Re:Nonesense (Score:5, Informative)

    by milimetric ( 840694 ) on Monday January 02, 2012 @12:20PM (#38563744) Journal

    "WebOS is crap"

    I agree if you change it to this

    "out-of-the-box WebOS is crap"

    Though I still love WebOS and most things it stands for, for the reasons you mentioned. Here's what I did to make it not crap (I have a TouchPad and an HP Pre 3).

    1. Install Preware: http://theunlockr.com/2011/09/16/how-to-install-preware-on-the-hp-touchpad/ [theunlockr.com].
    1.1. Install the patches that muffle system logging.
    2. Install custom kernel and set the lowest CPU frequency allowed to 768, keep the max at 1.4 (for the HP Pre 3, same idea for the Touchpad, different freq.)
    3. With your HP Pre 3 which comes unlocked for only ~ $200, sign up for an unlimited "non-smartphone" data plan with AT&T. This'll get you $10/month unlimited data.

    These simple steps will get you a phone that's just as smooth as an Android device (iOS is still smoother), and $20/month cheaper for unlimited data, and without a contract. The downside is of course that you're now definitely deep inside geek territory installing custom kernels and what not. I'll say that I'm pretty sensitive to basement-nerd induced stress, and so far that's been low on WebOS compared to other open-sourcey crap like the new Ubuntu.

  • Re:Webkit? (Score:3, Informative)

    by RightSaidFred99 ( 874576 ) on Monday January 02, 2012 @01:41PM (#38564492)

    Yeah, I don't understand how anyone could possibly think the reason WebOS didn't take off was because of its performance or some performance related issue as is intimated in the article summary. It doesn't even make sense, it's silly.

    The problem was of course exactly what you quote. From a user perspective I found WebOS pretty cool. I was a long holdout but got a $150 32G Touchpad and used it for a while and was surprised how user friendly the interface was. I prefer it to Android and of course vastly prefer it over the iPhone.

    Unfortunately, WebOS is mostly dead so I have desecrated it by installing Android on it now because I want the Android app library available.

  • by Anonymous Coward on Monday January 02, 2012 @03:22PM (#38565238)

    What makes you think that the webkit part of Qt was used? That was prototyped, determined to be too slow at the time & reverted back to using WebKit directly. The only part of Qt that is used is QtCore & QtOpenGL which are not the problem. A large part of the problem was LunaSysMgr (the window manager + compositor + event manager for WebOS) - it's ridiculous how much memory it takes up. Every single "card" takes up a full-screen resolution, even though only 1 card is visible full-screen at a time, thus 600KB for a 480x300 screen. Scaled back, the cards are (IIRC) 0.75 the full-size, which amounts to 300 KB. On the Touchpad, this is 3 MB & ~1.7MB respectively. Furthermore, typically you only have 3-5 cards visible on a screen at a time. Thus instead of using a max of 1.5 MB of memory, for 10 open apps you're using 6 MB (8.5 MB vs 30 MB on Touchpad).

    Another problem with SysMgr that is somewhat trickier is that instead of building a scene graph, it utilized Qt's rendering pipe-line which simply went through each hierarchically component & rendered it, which is slow in OpenGL, but even that was worked around (notice how the launcher in WebOS 2.0 was really fast - there was a lot of work that went into making it like that).

    Other issues include that the OpenGL rendering used a blocking call to know when to start painting the next frame, meaning you had only a portion of 16ms to draw, animate, & process events (to get 60fps).

    And this was just SysMgr. You can find examples like this in many places. Too many hacks by too many people who didn't think through those temporary hacks (nor put any effort to resolving them).

    But at the end of the day, none of it mattered because if you don't have customers who want to buy your product.... the shitty marketing campaign which turned away customers and burned a ton of cash... the shitty carrier relationships forcing Palm to carry a huge inventory....

"I've seen it. It's rubbish." -- Marvin the Paranoid Android

Working...