Slashdot Mirror
IBM Picks Qtopia Over PalmOS And PocketPC
Bill Kendrick writes "ZDNet,
Geek.com and others are reporting IBM's decision to choose Trolltech's Qtopia (the embedded version of their Qt library, used by the Sharp Zaurus PDA) in their forthcoming devices.
See the announcement at Trolltech's website, and an
earlier press release at IBM.com." Here's an earlier post about the new IBM reference platform.
I'd say IBM has made quite a shift since its inception. Moving from massive, room-filling mainframes to miniature gigabyte pocket drives and Qt-toting PDAs. It's nice to see that ol' Big Blue can still jump through the ever-moving hoops of technology.
Posting as directed.
The trolls have given back a lot to the Linux community. KDE would be nowhere without Qt. Dual licensing seems to be one of the few open source business models that actually work (unfortunately, mostly for libraries). Plus, Qtopia is a great platform to work with, so good lock to Trolltech.
It also goes a step further than motorola's annoucement earlier this week as here we have an opensource product in the middleware as well as the OS--and the middleware/interface makes a real difference in this type of device. Note that they will use a Montavista kernel, just as motorola: I guess the palm market is becoming so saturated that differentiation from competitors is also crucial at this stage--this will allow them to offer different apps etc than palm/pocket PC.
Goodie goodie, IBM is back on the handheld market with some fun stuff--we as consumers might see some great new apps.
yours ever, fz.
is this suprising? IBM's a big supporter of Linux in pretty much every area that it can be. Embedded, desktop, server, mainframe, etc.
Hopefully Trolltech/IBM will support the standard SyncML protocol, which would give them iSync support "for free".
But go on, just show us what you're up to and code something better. It will be adopted and enhanced if it's really good, the free software community is very good at joining well-thought projects.
How did parent get modded to +5?
Yes, let's all move over to a windowing system with serious licensing issues that's designed from the ground up to be run on embedded devices. That sounds perfect.
And what is this "plan" to start phasing out X windows? Was there a meeting I missed? Last I checked X was still being heavily developed.
"I'm not saying we take drastic steps now, but we'd be stupid to take no steps to transition the desktop to QT all the way down."
This is ridiculous. We'd be stupid TO take steps to transition "the desktop" to Qt all the way down. You're the only one who wants this. Not everyone loves KDE, and even less people love Qt. The seperation of the windowing system and the actual desktop is what gives *nix users the configurability to give their desktops personality. If you want a one-size-fits-all desktop, get windows.
As for you're space shuttle comparison, X windows is not inherently big (at least is doesn't have to be). It's not old. As I said, it is still under development, and there have been recent releases. Having history doesn't make software old.
As far as I can see, you're the only one with your head in the sand. It sounds like you're regurgitating all the inaccurate FUD-based trolling that goes on any time an article related to X is posted.
Qt is in no way a replacement for X, and it never will be, in it's current form.
Everyone is entitled to their own opinion. It's just that yours is stupid.
Why do people keep suggesting X is replaced? I'm not sure what sort of problems they have had, but it seems evident that they don't understand the nature of those problems and just blame X.
The problem is not X, but rather XFree86. XF86 is monolithic, and contains its own drivers. I realize this is mainly because *nixes don't have their own video, but Linux does. For years I've had problems with mixing Framebuffer Consoles and X, simply because they both fight over the same video. In a better designed system, Linux would provide the video and X would ride on top of it.
There is nothing wrong with the Linux Framebuffer except for lack of decent drivers. The DirectFB intends to solve this, but at this point XFree86 totally beats out DirectFB in driver support. Why does Unreal Tournament 2003 require XFree86? Because it needs OpenGL. Why the hell does OpenGL, something you're never going to use remotely, require XFree86? Because everyone uses X!
And that's where things have gone stupid. NVidia's drivers are for XFree86. Other closed-source vendor video drivers are for XFree86. This is a problem guys. What if we want to use the video drivers for something other than XFree86? Oops, you can't. We need to separate the hardware and X protocol layers from XFree86. This would lead to better compatibility and stability, and give ease to future expansion. At least on Linux systems, XFree86 should not be trying to roll its own drivers.
If you don't think we need to clean this up, consider that nearly every Linux crash is always due to XFree86. And please, don't tell me how you shelled in from your other box to kill XFree86, you may as well reboot if it comes to that.
So you are right, people wrongfully blame X when they should really be blaming XFree86. Before flaming me, please note that I am not against the X protocol, but the idea of an X server having its own drivers. Even so, I think using X for local applications is a bit redundant.
Which brings me to my next argument, which is about replacing X as a fundamental application layer. IMO, it should be possible to have locally running apps that access the video directly without having to go through some weird pile of extensions. 99.99% of the time, I am running apps locally. For me, and nearly all Linux users out there, "remote" should be the exception, not the rule.
The trouble, of course, is that there is a lot more to X than just a framebuffer. Try DirectFB sometime and you will realize this quickly. X has some very important things, like Window Managers, Input methods, hinting (for things like docklets), keyboard/mouse grabbing, etc. We'd need good replacements for all of these, along with X compatibility for it all. This is not trivial.
Qtopia (nor Qt/Embedded) is not the answer to the desktop. It is a really cool system, but is pretty much limited to the scope of PDAs. What we really need is a Qt/DirectFB (there is already such a port of gtk). This is just one step of many, though.
X windows reminds me of the space shuttle. It's big and old and we know it won't last forever
One thing I consistently don't see in posts critical of X is an explanation of *why* it won't last forever. Seriously, what's wrong with it? The only specific points I hear are not only vague, but wrong. Just to get the crap arguments out of the way, I'll list the most obvious ones and then maybe someone can give me some *real* reasons.
That's a good sample. What I'd like to see is some really good, technical arguments that point out significant deficiencies in X that cannot be addressed without a clean start. I won't even demand that the deficiencies be good enough to justify all of the effort that will be required to reimplement everything for the replacement, although a *really* good answer would cover that as well.
Any takers?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I don't see how IBM could have chosen Qtopia over PalmOS or PocketPC since those operating systems don't run on PowerPC hardware. Rather, it appears to me that IBM Microelectronics wants another market to sell PowerPC chips into and chose just about the only viable solution that wouldn't take years to deliver.