OSNews

That "application compatibility layer" is called Java runtime and is available in one form or another for many operating systems, including QNX, since like forever.

From the picture, the current UI is more likely done with Flash Action Script.

My guess would be, you can do UI in either Java, Flash, or Native (OpenGL) at the end.

Flash is also incredibly likely. Adobe and QNX are good friends...

Completely untrue that Adobe and QNX are friends. I have my own experience to vouch for this. See if you can get Adobe to port AIR to QNX, for instance.

Make no mistake - QNX is riding the coattails of other, more popular, operating systems to get Flash functionality.

Thom, you can go ahead and install QNX on desktop systems. It hardly requires any knowledge whatsoever - and is easy to set up as it supports x86. Please, just stop being such a blind fanboy. If you're going to editorize something through OSNews, please - get some experience as opposed to relying on theory.

Theory is that Betamax is better than VHS too.

Beta(max) is still used in movie production, where VHS never got popular. I think that technically Betamax was superior, but that VHS won on the non-technical aspects (like the minidisc was superior to early flash memory in every single technical aspect but died due to OpenMG stupidity)

QT works fairly well on QNX as is, but it needs a bit more work. The qnx version is based on the QT for embded linux branch of QT (http://doc.trolltech.com/4.6-snapshot/qt-embedded-linux.html)

All in all QT being the default would be a huge win for the platform. I have a feeling it will be (i am fairly sure actually but my contact won't confirm or deny it for me at this time), but I'm crossing my fingers!

It's amazing how some people at OSnews are very close to those big corporations we regularly mention in news.

As an example, I think vivainio has mentioned some times ago that he has a strong link with Nokia, though I can't remember if it's because he is employed by them initially or because he worked with Trolltech before and logically followed QT when it was bought.

And now, you say that you have a contact who knows thing about that RIM-QNX relationship.

Makes me ashamed to be a physics student who's very far away from all that business and is forced to get information in an indirect fashion

Edited 2010-09-29 20:16 UTC

I'm employed by Nokia initially. Everyone at Nokia deals with Qt these days though.

Even though I have not developed for QNX, quoted parts of your post do not make much sense. The same argument can be used for a number of platforms (Windows, iOS to name but a few) and yet development is not suffering.

Again, I differ to experience. It's different when you're the market leader and innovating at a breakneck pace, creating standards faster than developers can keep up and generating profits hand over fist. However, there will come a time when innovation on a platform slows and quality is measured by how well it supports new standards led by other (possibly competing) companies. The same is true if you're developing for a platform that chases the market leader. My experience tells me that QNX lacks this support. It chases 80% of functionality of competitors well, but the last 20% comes at a premium and... in the past... they didn't quite deliver... for me. YMMV.

Cloud applications have brought development to the server and as long as you have an up-to-date browser, you're somewhat supportable. Server-based solutions are *somewhat* platform agnostic.

Embedded development frequently turns this around. Your platform becomes more important. You'll want your applications to work with hardware, ie, inserting gps coordinates to a picture, or something to that effect. From a vendor's standpoint, it's a constant struggle to keep up with new drivers, honing apis and developer kits. It's not going to be easy for QNX, despite the fact that they have RIM numbers.

The difference is one of scale. With major platforms no matter what you're trying to do, chances are there are lots and lots of other people trying to do exactly the same thing. And if there is a serious bug, that makes doing that thing impossible there will be a lot more pressure to get it fixed or for someone to find a work around. Also since windows has been used for so many different things for so long, chances are someone has already run across your problem and found a solution.

With small platforms like QNX, chances are you will literally be the only one of their customers trying to do that thing. Thus there is no one you can ask for help and you are far to insignificant for QNX to spend any resources helping you.

Developers haven't suffered from the closeness of iOS? Ok.

... yes, and as we are talking cell phone OSes, which platforms are you actually suggesting, which are not proprietary OSes? :-)

Why?!

iPhone -> Objective-C
Android -> Java (NDK is only being used in some cases)

QNX based on Linux ? Are you sure of that ?

Otherwise I agree, Unix has grown very big lately. Funny, considering that it was initially built with very different needs than the modern desktop and mobile computers in mind.

Where did he say that QNX is based on Linux? in his post he said that Linux was a implementation of UNIX but that doesn't mean it is UNIX. QNX used to be marketed as 'Quick UNIX' until they were told that they couldn't continue calling it any longer since it didn't pay the fee to call itself a UNIX (Mac OS X can since it has paid and passes the Single UNIX Specification 2003 (SUS2003) recently).

What Mac OS X shows is if you have the funds and the focus you can make a good desktop operating system off *NIX - the problem is that what is required to create something that spans over the open x86 desktop market. You someone who can provide leadership and a group of investors willing to provide long term funding for something that might take at least 2-3 years before it see's the light of day and maybe another 3-5 years before it is profitable thus able to provide at least 8-10 years worth of funding which I don't see happening any time soon.

Edited 2010-09-30 10:07 UTC

"(...) Android and MeeGo and even Bada are based on Linux as are QNX and WebOS"


Maybe an alternate option is a hobby dev with a vision who somehow manages to lead a team of enthusiasts, in which case it takes even more time but still is possible.

Thanks for the correction - there is this horrible trendy I see these days of people equating Linux to UNIX that they are being used interchangeably by people without the slightest understanding that one doesn't mean the other. I even see people claim that Mac OS X is based on Linux! everytime I see such posts I die a little inside.



True which kinda goes back to SkyOS and how personally I would have preferred to see him use a *BSD core of some sort then create a custom interface, display server and so forth on top so that the value can be added by not being 'yet another *NIX for the desktop'. I wish I had the development skills because that would be the first thing I'd do - take the FreeBSD core, build on a new display server and interface then develop it from there.

The first thing I'd do in building any desktop operating system (if I had the skills) was to use QNX as a base. Fully transparent distributed computing, a true microkernel (none of that monolithic crap), a super-efficient and tiny (in all senses of the word) fully accelerated display server, self-healing and self-recovery in all layers and components of the system...

It's a piece of genius. Nothing comes even CLOSE - certainly not hodgepodges like Windows, Linux, and Mac OS X.

They have lots of nice optimizations in place to allow quick communication between kernel modules.

I imagine that QNX is the only successful micro-kernel OS out there.

VxWorks does quite well afaik and is a micro kernel too. Micro kernels in general are found in embedded computers anyway, because size and modularity are pretty key in that field.

Not quite right. SymbianOS has some success around the world, too, and if I remember well it's based on a microkernel called EKA2...

Yes, where would AmigaOS be nowadays, if Gateway did not screw the deal with QNX in 1998 :-( ... it would simply be power of QNX and brand power of Amiga (still good sounding brand back in 1998).

My point exactly, but ohno, better skip it for Linux, because, it's like, Linux!!! ...

Never mind AmigaDE (rather Tao-groups Elate and nothing more I suppose) which was just 100% retarded unless it actually _RAN_ on something Amiga.

Isn't QNX a major player in the embedded space (machinery, aerospace, etc, where there is zero fault tolerance) as well?

And yes, QNX and Symbian are two great examples of highly successful micro kernel OS's. Also, MacOS and iOS are based on the Mach micro kernel, and employ at least partial micro kernel design.

People often think that since Linux won over the failed (so far) Hurd project, and that Minix was only an academic OS, that the debate between monolithic kernels and micro kernels was over, and monolithic won.

But obviously that is not the case. Both have been successful.

What we in the business class "close but no Amiga", with two very different meanings.

#1: Sadly everything come short to the Amiga as we remember it.

#2: Amiga by all definitions of successful isn't

We lend the concept to the quantum physics guys.

"but Android and MeeGo and even Bada are based on Linux as are QNX and WebOS."

I also reacted to it.

Heh yeah that made me smile. QNX predates Linux by a decade.

...over what? Windows? Yeah, call me when desktops, laptops, servers, etc (you know, the computing devices that people use to do actual work) start getting replaced those things. Right now, they're just consumer toys.

The only "triumph" here is the triumph of proprietary UNIX over open sores Eunuchs. I'm sure that really annoys the hell out of Stallman and co!

No it mean it will be based on QNX? ;D

It's not just the graphics. The architecture of the low level stuff provides a foundation that will ultimately limit or enhance what a user can do. There are many many low level details that affect usability. It's more than just graphics.

Indeed. Low-level stuff can help the UI layer, and hence usability.

Consider, as an example, a kernel based around the concept of events. You have standard round-robin scheduling around most of the time, but when an interrupt comes around it is processed immediately.

The result of that is a very snappy UI : even when under load, the OS takes the time to process mouse clicks as soon as they come and refresh the UI immediately.

Snappiness means a busy user. A busy user feels that the computer is working quickly and efficiently, even when it's not actually the case.

Of course, that's a quick an dirty example, but I think it shows how good low-end components matter too. A good mainframe kernel with batch scheduling would still be terrible at powering a desktop OS.

Edited 2010-09-30 16:40 UTC

True, but all the operating environments have tackled this. Neither Linux nor iOS have mainframe batch scheduling (Linux has a multitude of schedulers geared towards interactiveness). It's not a problem any of them have. I would think the GPU power and code running on top of it (relatively unaffected by a decent scheduler) would have way more impact than the differences between scheduling engines.

It'd be an interesting benchmark to run. I suspect the differences would be minimum. And again, the challenges that companies like Nokia, Google, Microsoft, and Apple have aren't really low-level based. It's usability and whole-operating environment.

Do you think that their schedulers are that good as far as interactivity is concerned ? My favorite test for interactive performance is to run many while(1); loops in the background and see how responsive my desktop remains.

On the ideal perfect desktop OS, it should remain just as fast, since this code snippet only uses CPU power and should be phased out by the scheduler in favor of more urgent tasks. But in my experience, the behavior of most desktop linux distros under load is far from ideal. Couldn't stress-test iOS, if someone with a jailbroken iPhone can try this, please report me how well the OS behaves


GPU power shouldn't be needed for normal operation. If it's needed, either the UI layer is awfully coded, or there's some overuse of heavy (as opposed to easy to compute) animations around.


Again, if you can get your hands on a wide range of mobile devices, please do run the while(1) torture test I'd really like to see if mobile devices manage to resist under load.

Other nice tests are repetitive malloc/free (to check how system calls behave), and my personal favorite, the file operation torture test, which in pseudocode looks like this in one of its simplest spawns :

while true do
..size = 0
..open(file)
..while size < 1GB do
....write byte(random number between 0 and 255)
....commit changes to file
..end do
..delete(file)
end do

The goal is to check if the desktop layer can still access files when it needs to, while several copies of this monster are running and eating disk bandwidth for dinner.

As a side note, using Windows 7 on my brand new and relatively high-end laptop, I don't even need to torture the OS like this for interactivity issues to appear : the simple combination of an AVG scheduled scan and a Windows backup running in the background are sufficient to make multimedia playback freeze periodically along with the rest of the UI (mouse doesn't move smoothly and things like that).


Indeed, they compete at a higher level, and there's a lot of things to do in the high-level UI layers. Good low-level foundations mostly benefit interactivity, which although very important is not the sole part of a good UI.

But looking at current OSs, I think that interactivity is still a subject that should be worked on.

Edited 2010-09-30 17:31 UTC

Based on your own non-standard definition?

Those are all operating systems. Android doesn't even use a vanilla Linux kernel.

How so? Linux is a fat monokernel while Darwin and NT are hyrbids.



No x64 cpus just have more registers and use RISC-like microcodes at the core. They do not have a reduced instruction set.

And mainstream RISC architectures added more instructions (Altivec, etc). Extremes are almost never useful.

Technically, the "Reduced" in RISC does not mean "fewer number of instructions" rather than a reduction in the complexity of the instructions in the ISA. It helps to think that the opposite of RISC is CISC, the C is not for "lots of instruction" instructions but for "Complex."

Ironically, even most mainstream RISC had to further reduce the complexity of their instructions by adding "crack" stages to further distill some RISC insts into even more simpler micro-ops when they introduced out-of-order scheduling.

Therefore, by the last decade there was little difference between the high end X86 OOO parts and the high performance RISC processors. Which is why RISC went the way of the dodo in certain markets, because it had zero value proposition over the competing x86 parts which could enjoy mass production and thus cheaper prices.