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."
Am I missing something? (Score:4, Informative)
But doesn't Apple's Mobile Safari used the very same WebKit?
Re:Am I missing something? (Score:5, Informative)
Re:Am I missing something? (Score:5, Informative)
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: (Score:3)
Errr, correction: Not Opera.
Re:Am I missing something? (Score:5, Informative)
*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).
Re:Am I missing something? (Score:4, Insightful)
*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.
Why is it reasonable to render the UIs of Web apps using WebKit but unreasonable to render any other kind of UI using WebKit? Your objection doesn't make any sense. If WebKit is totally unsuitable for rendering UIs then Web-based apps must be unusable on iOS, Android, and BlackBerry, all of which use WebKit to render Web UIs. I don't understand the artificial distinction you're creating between "Web UI" and "every other kind of UI."
Explain to me this: In all of the (presumably many) times you have used a WebOS device, has the performance of the UI been your #1 complaint? What didn't you like about the UI on WebOS?
Re: (Score:2)
the ui's on webos could have been made vastly different, had the design choices been different. they might have had a normal widget homescreen etc.
it's not unreasonable to use "web technologies" to build some ui's, but it's never optimal and you limit yourself from doing lots of things and make lots of other things complex to achieve.
most 3rd party "cool" sw for webos seem to use sdl anyways.
a web browser that uses web technology to render it's favorites, settings etc views for example, those ui views are r
Re: (Score:2)
and, of course, if "browser" based UIs are truly poor, then I don't hold out much hope for Windows 8.
Re: (Score:2)
Re: (Score:3)
Because WebKit is stil broken for some basic functionality, like applying CSS3 transforms after scaling at a factor of less than 1:1 - something that Firefox, Opera, and even IE9 get right..
It's one thing to have a web browser that needs to scale at less than 1:1 - you can call the OS to handle it. But what if the web browser IS the OS? Then you are, as some slashdotters would put it, boned.
Re: (Score:3)
Re:Am I missing something? (Score:4, Insightful)
Re: (Score:2)
Don't underestimate the power of native UI
Re:Am I missing something? (Score:4, Insightful)
Graphical rendering of your screen is most processor-intensive part of the unit. It's why iPhones and iPads have a dedicated GPU [wikipedia.org] What - you think those page wipes and zooming were done by the main cpu? That would be a cpu made with unobtainium.
Re:Am I missing something? (Score:5, Informative)
"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: (Score:3)
Re: (Score:3)
UI performance has always been one of the #1 complaints people had about webOS. The Touchpad has to be overclocked to 1.5-1.7GHz (dual core, mind you) and have lots of performance patches and experimental kernels used before it even approaches the responsiveness of the first iPad (1GHz, single core, 1/4 the RAM). I think webOS has some great concepts, but it seriously hamstrung itself by forcing everything to be rendered with WebKit.
Re:Am I missing something? (Score:4, Interesting)
Re: (Score:2)
Using webKit to render UI is technically brilliant. It's only drawback is that the process isn't as CPU efficient as is commanding C libs directly (AFAIK iOS and android do this) due to the added abstraction. Definitely universal rendering frameworks is the correct way to go, unfortunately webOS was a half effort endeavor and therefore never got the hardware to make it shine, nor did it get the performance optimization it deserved.
Anyway, now that it is going to be open sourced someone will come up with a w
Re: (Score:2)
I donno, web interfaces seem horribly inefficient and stupid relative to native interfaces. I pretty much considered WebOS fatally flawed the moment I heard about it. And it fulfilled my expectations. Worse, there are apparently some fools that decided MeeGo must follow WebOS's lead. lol
There is a very clear formula to building a better smartphone : Expand Android's NDK by optimizing glibc instead of using Google's minimal libc. Cut what features must be cut, but optimize anything that produces reasona
Re:Am I missing something? (Score:4, Insightful)
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.
This is the same schtick that came around after Nokia dropped Qt... I'd say it's armchair quarterbacking from people who don't really understand programming at all, sounds good in the executive boardroom during the "lessons learned" meeting, but is impossible to verify unless you're in the trenches, and I bet that in the trenches you can find all kinds of conflicting opinions about what went wrong.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re:Am I missing something? (Score:5, Informative)
Re: (Score:2)
Win8 is also using the browser as "app platform" (as one of the options, though). We'll see if it truly is not viable, or if HP just did it wrong.
Re: (Score:3)
I expect it's forked pretty heavily for customization and optimization purposes. If HP couldn't get good WebKit talent, they'd have been stuck with something much closer to vanilla performance.
I can also see not wanting to adopt the same platform if your hardware isn't competitive.
Re: (Score:2)
HP's management must really suck, basically. (Score:2)
What I get out of this is that it's impossible for anyone with real talent to work productively for the people in charge of HP's WebOS.
Opera's guys have major talent, as you pointed out, so they'd probably be unable to work with them either.
Re: (Score:2)
The article says slightly ambiguously that WebKit is the basis for WebOS' apps.
Re: (Score:2)
Re: (Score:2)
Eh, no. Firefox uses Gecko.
Safari and Chrome use WebKit.
Re: (Score:2)
I didn't see him claim Firefox used Gecko, though he was vague in regards to what browser he actually was referring to. My guess would be either Konqueror, which probably had a bigger market share in the past, or Google Chrome, but it would be hard to call that Linux's competitor to Firefox, though it probably is the major alternative to Firefox on the Linux desktop.
Re: (Score:2)
Re: (Score:2)
Bah. I meant Webkit when I said Gecko. I think I alluded to everything you said in my post, which may have been clearer had I not substituted the word Gecko when I meant webkit. But I fully agree, that nobody seems to use Konqueror anymore.
Re: (Score:2)
Bah. I meant Webkit when I said Gecko. I think I alluded to everything you said in my post, which may have been clearer had I not substituted the word Gecko when I meant webkit. But I fully agree, that nobody seems to use Konqueror anymore.
lol, anymore?
Re: (Score:2)
Of course, the REAL fail is thinking that there's such a thing as "the linux browser". Linus Torvalds doesn't make browsers, and there are plenty of "Linux browsers" out there. Arora (QT4), Chrome, Galeon, Firefox, Konq, links, lynx, reKonq, Seamonkey, all sorts of plasma mini-browsers, whatever ... you get the picture :-)
Webkit? (Score:3, Informative)
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: (Score:3, Informative)
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 p
Nonesense (Score:4, Interesting)
Re: (Score:3, Insightful)
Re:Nonesense (Score:5, Informative)
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.
Re:Nonesense (Score:5, Informative)
"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: (Score:3)
To be honest, you don't even need to do 1 or 2. Just doing 1.1 a simple one line deal my touchpad went from crap, couldn't play any videos, constantly slow, to really good, played youtube at 720 (assuming good network) and could play HD videos I'd copied onto the device so the kid could watch Shrek etc in the car on trips.
Why they had logging turned up THAT far on a released product is beyond me.
In other words (Score:2)
WebKit is to tablet PC operating systems as SmallTalk was to object oriented languages. A great idea existing before the state of the art could support it.
Wow, that isn't burning bridges (Score:5, Funny)
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?
Not really surprising (Score:3)
This isn't that surprising as I remember how much trouble WebOS had to get GPU acceleration working for developer access and use in gaming etc.
Re:Not really surprising (Score:5, Interesting)
Open source community fixes these things. (Score:4, Insightful)
You mean there's a difference between engineers? (Score:2)
But wait, I thought that engineers were just pluggable resources...
Re: (Score:3)
Don't read too much into that statement.
There is a difference between nails too.
Evidence shows another thing? (Score:2)
Last time I checked, WebOS was really snappy and smooth, and provided a great user experience. Maybe games were hard to code, but the apps I tried out when the first WebOS phone came out felt MUCH smoother than my Android phone.
There are probably many reasons why WebOS failed, but I am very confused by this statement given how well WebOS felt (And I have read the same from many many users in the Internet). The complaints about WebOS were never that it felt like a web app, too limited or that it felt too sl
Re:Evidence shows another thing? (Score:5, Informative)
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.
was there a widgets library for the native? (Score:2)
because that's important bit of information.
games don't need it usually, and most games for webos were just linux apps running on sdl(that played without recompile with some tricks on maemo).
Re:Evidence shows another thing? (Score:5, Informative)
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.)
Re: (Score:2)
Android was also similar in this regard - developers could only use Java for development at first until the NDK was created, which allows C/C++ development of native binaries for maximum performance. Really, the platform would have been crippled without it from a gaming / multimedia perspective.
Microsoft is still too dense to make this realization with Windows Phone. They still only allow C#, which although performance issues due to lake of native support probably isn't the extreme issue it was with webOS
Re: (Score:2)
not _entirely_ true about android.
you see, you could(and can) without NDK run linux binaries by executing them(binaries that you provided in your package). of course you'll have do io to them in some non-optimal way, but you still could do it, I'm not sure if any popular apps besides rooting etc apps used this for doing any heavy lifting though.
Re: (Score:2)
But what amount of integration would the linux libraries have with the Android layer itself (pre-NDK)? Could they even access OpenGL ES? If not then that what could be implemented would be quite limited. In my case, I would have been able to use it for the physics engine and scripting host, which are two of the bigger CPU consuming libraries in my app. However, it still would have been a compromise in several ways.
Web Obsession (Score:2, Interesting)
There seems to be an increasing obsession with using browser technology as *the* technology, and it sucks big time.
The web started as a way of displaying text - and later text plus graphics - with a mechanism to like pages across machines; its that latter bit that is Tim Berners-Lee's brilliant insight. Unfortunately - and this clearly isn't TBL's fault, he'd have needed a crystal ball to have seen what was coming - people wanted to use the browser to ever more sophisticated stuff (essentially to become a m
Bad article (Score:5, Interesting)
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.
Re: (Score:2)
it's not that, they could have added any standard they wanted to webkit. probably did add a bunch of stuff, to interface phone functionality, messaging etc.
fyi, webos isn't the only in town which dabbled with and promoted the idea of doing all your apps with web technologies. the middle management reasoning is actually that it's because it's easier to do web apps and web guys are cheaper! in reality it doesn't pan out quite like that of course. instead you'll have a bunch of new problems(that and nokia appa
Re: (Score:2)
Inner Platform Effect [wikipedia.org].
Re: (Score:3, Insightful)
Re: (Score:2)
there is nothing about XML applications or the DOM, per say, that make it suck. Apple has a "dom" (nib files) and it works quite well. The problem is obviously somewhere else. Something that could go faster, but we don't - for security, or for compatibility with magazines-in-html... but nothing about HTML, in and of itself has to be that slow, imho.
Re: (Score:3)
Who writes this crap? (Score:2)
Since when has a renderer been the be all end all of an OS? Show the code. I got $20 saying someone in the FOSS can replace it without heavy lifting.
Have to agree (Score:2, Insightful)
WebOS was never going to do anything other than fail. Things like google Apps might be ok for really light work where shared access is the most important feature but they are the goto for very few people. Otherwise dropbox would not be nearly so popular. Don't get me wrong [xh]tml + java script might be a wonderfully flexible thing to develop your shell in but its not going to provide the rich experience users want out of an application.
No matter what the industry shills and marketing droids try and tel
Re: (Score:2)
For the record I am aware that you can write native code apps for webOS but that was not the preferred method being pushed by the vendor(s). We all know that working with lessor favored technologies from a commercial software stack tends to leave you abandon at the whim of some middle management guy at a company you have little or no influence over. So we know what technology the bulk of webOS apps were going to be written in and it was not going to be the C++ interface.
Re: (Score:2)
Sending what is a basically a web browser with some java script libraries out to compete against polished binary platforms in a consumer already dominated by well polished easy to manage binary apps was space was not and is not going to work.
Then it is fortunate that WebOS developers have an alternative. [palm.com]
H.P. (Score:2)
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.
Re: (Score:3)
Re:H.P. (Score:4, Informative)
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.
Re: (Score:2)
That's not language, it's style.
It's convention. It used to be common to put periods after each letter in an acronym. The convention changed in a way that's more streamlined, as it often does, and still using the old convention is a distraction, old-fashioned, and makes the newspaper look out of touch and downright naive when everybody else has moved on. You could argue it was a case of style if there was mixed usage, but at this point they are pretty much the only holdout.
As for abbreviations, 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).
U.S. seems to be the one holdover, but I suspect eventually that w
Who cares (Score:5, Insightful)
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.
Re: (Score:2)
"What was special about webos from the user point of view?"
1. Cards metaphor, true multitasking
2. Synergy, and the notification system
3. Bluetooth pairing even with non-webos phones, to accept calls and display SMS messages.
Off the top of my head.
Re: (Score:2)
Ahh from the users point of view thats either weird or not new or not new anymore.
1) My android phone can play google music while I do other stuff like the kindle app.
2) Again my android phone and my ios ipod touch have a notification system. I find it annoying. Just another inbox to check, whats yet one more...
3) Not even sure how to replicate this. I think you mean I could pair my phone to my wifes phone like an extension phone? Thats just ... weird. Isn't that just pairing to a automotive hands-free
Re: (Score:2)
1.) I also own android devices. The multitasking there is limited to certain apps. You have to close one app to open another, and how it behaves while backgrounded and where it will be when you restore varies greatly.
2.) Yes, but the notification system in WebOS is just better. Also, the other half of my second point was "Synergy," which folds your emails, IM's, and SMS's into a unified system that is very nice.
3.) This one is my fault, as I was thinking specifically of the touchpad. On the touchpad, y
Re: (Score:2)
> 1. Cards metaphor,
Nice, but that is just the task switcher. Sure it is nicer than Android (2.x), but does it matter in the grand scheme of things?
> true multitasking
Android had multitasking for a long time, but it is optional (as it should be).
> 2. Synergy, and the notification system
Nice, except it was poorly implement, and only worked sometimes. Android has something similar, not as nice, but it seems to work much better.
> 3. Bluetooth pairing even with non-webos phones, to accept calls an
Re: (Score:2)
I have not played with the iPhone much, but compared to the Android, I would choose WebOS hands down. I love the interface and the multitasking abilities. It is my hope that open sourcing WebOS will give it some new life, because I really would like to see the OS continue. It holds a lot of promise, and I would hate to see the UI ideas go away.
Disclaimer: I am an HP employee, but I have no connection with the WebOS or TouchPad team at all. I was able to get a hold of a TouchPad through the employee fire
webos developer here - the "insider" has no idea. (Score:5, Informative)
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.
Re: (Score:2)
i guess the whole discussion becomes mute
Or moot even.
But probably not mute, because there's a whole big thread of noise on it right here. And if you think a thread of text is quiet, think of all the spit-takes, laughing and angry words had when reading and writing replies.
Or maybe I'm the only one that talks to my monitor.
Re: (Score:2)
when you download the SDK, you get the PDK included. this was only recently the way however - with 3.0 SDK.
Re: (Score:2)
Fatally flawed because it was web based (Score:2, Interesting)
I played around with a palm phone w/ webOS for a while. Its fatal flaw was not webkit, but that everything was web based. It assumed that you had unlimited wireless data. I could not even be boot up the phone without a cell data plan. It would not even use my wifi access point. The palm web site strongly recommended purchasing an unlimited data plan because it used so much data.
Then all the carriers dropped or heavily restricted their unlimited data plans. Ouch.
Re: (Score:3)
My old palm pre is on my desk right now, it operates in airplane mode and works just fine, with no cell plan at all. My data usage was less under palm as compared to my verizon android phone, though I suspect this is because there are more free ad supported apps on android.
webkit is the same in safari as in webos! (Score:5, Informative)
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:webkit is the same in safari as in webos! (Score:4, Informative)
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.
Dejavu (Score:3)
CEO Meg Whitman explaining away another big HP failure that was not her fault? Why does this feel familiar?
A lot of people should have quit so she could blame them for her troubles-- could you get a better recommendation than the CEO saying they are failing because you quit their huge corporation? (except perhaps that it is Meg Whitman...although maybe nobody holds her record against her anymore since they did hire her back again.)
Re: (Score:3, Informative)
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 tim
OS not the problem (Score:3)
Palm failed due to underpowered hardware. Sprint was the first big carrier, they released the underpowered pre, then nothing to replace it. Pre 2 was never released in the US ( I don't think), same with Pre 3. The real story of the failure of webOS is really about the lack of hardware.
Bupkis! (Score:2)
This article is bupkis. ChromeOS is based on Chrome, which is based on WebKit. Seems to work just fine.
JavaScript was a joke that got taken seriously... (Score:2)
0. Dynamic Scripting Engine
1. Efficient Operating System
Choose ONE
Compiled VM Bytecode can be transformed into static machine code for a given platform, ala modern VM's: Java, Davlik, etc. JIT compilation tries to do the same thing, for dynamic language platforms (like JS) but it's still got to have an interpretor abstraction layer to support the dynamic changes. JavaScript is a prototype based system, which means I can replace the .toString() function at any time during runtime, and even generate n
Apple was buying an OS once, too (Score:2)
It still baffles me - how dilbertian do you have to be to shell out 1.2 bln $ for a hack that took just nine months to develop?
When Apple was looking for a new OS back in the 90's they approached BE Inc. (who were working on a new OS at the time) estimating that BE was worth 50 mln $ at most. BE refused the offer asking for well over 2oo mln $ assuming wrongly that Apple had no alternatives; Apple ended up buying NeXT and bringing back Steve Jobs to Cupertino. (They also considered licensing Windows NT from
Re:Most stupid story (Score:5, Informative)
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/ [inspiredgeek.com]
Seems to me that it's all a fundamental UI issue.
Re: (Score:3, Informative)
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:Most stupid story (Score:4, Insightful)
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.
Re:Most stupid story (Score:4, Informative)
Re: (Score:2)
What the article is saying is that WebOS apps running inside WebKit cannot compete with iOS apps running natively.
The article doesn't say that. You infer that. The summary doesn't even mention iOS apps.
.
But frankly, I don't agree with the analysis that using webkit must necessarily be less efficient than having another layout and rendering mechanism. Perhaps implementing behavior in javascript instead of C would add a little overhead that might be too much when dealing with slow processors...
Re: (Score:2)
Normaly (and on all real cases available) a web browser is slower than other GUI toolkits because it has to solve a plentora of other problems, not just showing things on the screen, and the toolkit can do just one thing. Besides that, software embebed on browser is written in Javascript, that is interpreted and again, normaly (and on all real cases available) interpreted languages are slower.
But none of those probems must be this way. They just happen to be.
Re:Wah! (Score:5, Insightful)