Slashdot Mirror
QNX Realtime Platform Now Available
A reader writes "The QNX development platform is now available. It's available in three versions: the Windows-based self-extracting installer, the ISO image and the QNX4 install archive" You can also get it from QNX's site itself.
n/m . . . I found it. %-)
--
I work at QNX - anyone looking for official statements should look to the QNX web site and ignore what I have to say. That said:
The license agreement makes the lawyers happy but greatly overstates the case. Most of the core technology in the RTP as it stands today is released and fully supported by QNX both for development and runtime application (QNX Neutrino OS, core Photon GUI, compiler and libs, voyager web browser etc).
What is not released are some of the other components that make for a better installation experience or a more rounded desktop development environment but are probably not ready yet for commercial release. I say probably because there are bound to be people out there for whom the RTP just plain doesn't work. There will be some hardware, some way in which its used, that we just hadn't anticipated or seen before.
Given the number of people out there who will try it, there will probably be a whole lot of cases like that. There's only so much we can cover in the lab.
With useful feedback from the community to guide us hopefully we will be able to bring the remaining components to release quality in short order.
I recieved my copy of the Mac OS X Public Beta today, as well as the develement tools. (I'm a member of the ADC)
According to Apple, the dev tools (gcc/g++, InterfaceBuilder, ProjectBuilder and a bunch of little apps) will be available for free on-line. It will require a free registration. I believe sometime in October, but don't quote me on that.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I'm making a mirror the RTP for people wanting to
download in Australia/New Zealand (only, sorry)
ftp://mirror.aarnet.edu.au/pub/qnx/qnxrtp/
http://mirror.aarnet.edu.au/pub/qnx/qnxrtp/
-jason
I actually spent the summer working with QNX (for robotic systems) and it is pretty cool. It is drastically different from any other *nix I've played with (granted thats fairly limited) but if you read the docs its managable.
One thing I've been wondering though is will livid work with it? If so, perhaps it will make the dvd's actually watchable in a unix environment. On my PIII 650 laptop the dvd playback keeps getting prempted by the kernel, and skips. Annoying.
Thanks for repeating exactly the same links that appear in the article write-up. You sure helped a lot of people that way.
Microsoft isn't a real word. However, you COULD say that it was commercial, proprietory, closed-source, or anything inbetween. For example, you can say it is object oriented. It doesn't actually have an object model, and it doesn't treat everything as an object (which is what object orientation technically means), but the OS is built on a set of objects, so the claim is still true.
Monolithic IS a real word. Something monolithic is anything that is one large, closely connected mass. Even if the kernel ran drivers as seprate processes, if there was a super-close connection between the two, then it would still be monolithic. I would consider something modular if it had a set of clearly defined, more or less invariant interfaces between components, even if the thing was one honking large binary.
A deep unwavering belief is a sure sign you're missing something...
With risk of being redundant . . . QNX has a 1.44M Demodisk you can download for free. It's pretty sweet. It boots off a floppy, resides in flash RAM, has a GUI, a web browser, server (this is new), TCP/IP and a few applications. Yes, all on a 1.44M floppy. I used to play with this back when it first came out but it looks like they've really made some strides with it.
:-)
Might hold you over till the CDs come out.
--
Read the FAQ. Their opinions are stated in plain view:
Q: Why doesn't QNX provide source to the kernel and other core OS modules?
A: Because QNX developers don't need kernel source to extend the OS.
Anyone who's ever done serious work in embedded systems know the kernel source is absolutely essential for debugging, not only the application but also the kernel. All OSes contain kernel bugs. They're a pain to find and fix without source, and those of us who've been there are not going back lightheartedly. You all know this, that's why we're embracing open source. How come so many of you are now eager to jump back into the dark hole that is proprietary software?
For embedded work, there's ECOS already. It's Free Software and runs on a dozen different CPUs, with new ports coming all the time. If you want the 3D acceleration, anti-aliases graphics and macromedia player, you're probably not looking for embedded stuff in the first place.
Sure, QNX is fun. Play away. But it isn't the future.
The problem, btw, was PCMCIA. Booting with a 3C option got me to a shell, but starting photon kills the keyboard. Grr. Time to try on a desktop machine.
Continue in sid=pb?
Why can't the transit system be this efficient?
QNX == Cool hackware, sold by hackers to users, on their own money. Demand and features are market driven.
Mass transit == A bad hack, forced on unsuspecting users by politicians, with the users money. Demand and features both artificially inflated and deflated by same politicians who also ensure they are the only game in town.
.sig: Now legally binding!
Wasn't this preview based on an ancient beta?
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The beta was released only a few weeks before this one.
A deep unwavering belief is a sure sign you're missing something...
Ha ha! He just did, in the very post that you're flaming (except that he didn't really say microkernels are better; all he did was prove it, and then let you draw your own conclusion). And that reason is: GPLed drivers (e.g. ALSA) run in their own address space (instead of linking with the kernel) thereby avoiding the possibility of GPL violation if QNX wants to keep the kernel source closed. I bet Sun wishes Solaris could do that.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I only had two points. I'm not talking about monolithic in the technical sense (I rarely talk about anything in the strict technical sense) but in the end-result sense. One often has to recompile the kernel in order to insert new hardware. This is because there is a close association with the hardware and the drivers. Thus, it is monolithic. The fact that a kernel upgrade requires me to recompile doesn't surprise me, the fact that I have to recompile the modules as well does. This implies way to close of a link between kernel and driver. The vast-majority of the cases may be true for trival hardware, but is decidely not true for major items like video-cards and sound cards.
A deep unwavering belief is a sure sign you're missing something...
A disk driver in QNX deals with the disk interface and disk, and leaves the job of putting a file system (DOS, QNX, Linux) on top of it to a file system DLL. QNX supports DOS, QNX and Linux filesystems on disk, and some others that are found on CD-ROMS and yet other file systems over networks.
a lot of people still find it necessary to use BZ2 to compress their kernel because it's still too big.
Sigh. The "b" in "bzImage" stands for "big". On x86, the Linux kernel is generally stored as a gzipped file (note that this isn't true of most other architectures that Linux runs on. PPC, for instance, doesn't use a compressed kernel). The only difference between zImage and bzImage is that the code used to start the kernel is capable of dealing with bigger files in the second case. zImage only exists now because a tiny amount of hardware didn't like the newer code, a situation which has now been fixed.
Sure, you can switch *some* hardware without recompiling, but only that which is already a module...
Almost all hardware can be compiled as a module from an existing source tree and inserted into a running kernel. If it worries you, compiling the kernel with everything as a module is a perfectly valid thing to do. No reboots for changed hardware then.
Rebooting to install hardware is dumb and shouldn't be necessary.
Given that most hardware requires you to switch off the power to install it, I suggest you take this up with the hardware manufacturers as well.
I am constantly amazed at the amount of really cool, really quality stuff, that people, real companies even, are pumping out for free. For a "free" OS, the QNX developers sure have put a lot of effort into something that wouldn't seem to me to generate any profit for them. According to the BeNews review, QNX looks and feels slick and trim. I am amazed at how much effort was put into making this a functional desktop OS. Add to that their full POSIX compliance and their (eventual if not immediate) open sourcing of a lot of the code.
Not to slight BeOS. BeOS is amazing as well. I think we geeks have it pretty damn good. I just wish I had enough machines and a big enough internet connection to play around with all these freebies.
It's 10 PM. Do you know if you're un-American?
--
"Science will win because it works." - Stephen Hawking
I am currently posting this from QNX, right now. It installed in a few minutes on a 1GB partition (didn't try smaller, but it seems that 500M would have been more than enough). It is very fast. (For the record, I am running an Athlon 700 with a GeForce 2 GTS, so... even windows is very fast.) The web browser displays slashdot nicely, and all of the fonts are beautiful. They get even better if you turn on antialiasing, :-), but even without it they are far better than X. The network installer seems a bit flaky (it seems to display different packages at different times), but it does not seem to be much of a problem. Actually, all of the network code seems a bit flaky... but it seems to autoconfigure itself and fix whatever is wrong (i'm using a dhcp cable modem.) While typing, I just connected to IRC succesfully... (first time.) Lastly, the GUI is... cool. Try it, it's a small download compared to ... even BeOS.
--
Restating the obvious since nineteen aught five.
Blue sky warning here. How hard would it be to checkpoint a kernel?
What I'm after is a way of bringing a machine down in such a way that application processes can be frozen, a new kernel swapped in, and the applications unthawed.
It all comes down to is how much kernel state a process has; by definition very little. It has at most handles for internal kernel datastructures. So as long as the two kernel versions know enough about each other to translate those, you shouldn't need to reboot a machine to upgrade the kernel.
The big thing I've overlooked is hardware state; things like BIOS/network/whatever. These services will likely need to be restarted.
Thoughts?
QNXStart.com is a new third party developers forum for QNX. Unfortunately it is not a mirror site
But it has some downloads: Gimp,ICQ,AbiWord among others. By the way, some other sites of interest:
NNTP: inn.qnx.com
WWW: support.qnx.com
USENET: comp.os.qnx
Really, Linux is monolithic. Sure it has kernel modules, but they can't be reliably used between kernel versions. So often times, upgrading the kernel or changing the hardware (in case you haven't compiled that driver for your kernel before) usually requires a kernel recompile.
A deep unwavering belief is a sure sign you're missing something...
Comment removed based on user account deletion
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
i installed QNX from the ISO. after some troubles getting it to boot, i eventually got into the photon microgui. "this is pretty slick" i thought. i was amazed to discover my SB Live! was supported. unfortunately, my tulip compatible network card wasn't working. i decided that if it wasn't going to work with my network card, it wasn't worth it.
/mbr", i feel better already.
that's when i decided to go back to windows. unfortunately, i was unable to ascertain from the QNX bootloader how to actually do this. i tried lots of options and keystrokes that i thought might help, but to no avail. all i could do was make QNX start to load and then fail. (i had gotten into it originally with some sort of safe mode).
so, i busted out the trusty ol' redhat 6.2 cd (remembering there was an emergency boot option). too bad you can't install lilo using that... after unsuccessfully trying, i said, "fuck it. i'll just install a base RH 6.2 over my QNX partition". i told it to reformat the partition as ext2 and install no packages. little did i know that RH would just sit there if you didn't choose any packages. *sigh*
fortunately, it did delete the QNX partition, which left the QNX bootloader with no choice but to throw me back into WinMe. after a quick "fdisk
I like the interface much better then BeOS, but BeOS is obviously ahead of the game in terms of hardware support and stability. The desktop for QNX is pretty interesting and instantly more usable then BeOS. The browser also kicks the living crap out of NetPositive. Another nice plus is the package installer for adding add-ons to QNX. That's pretty slick, but again not very stable - bombing itself twice and being unable to open various packages from the online repository. On the networking note, supports DHCP which had me up and running with no config whatsoever.
On another note, I installed the OS X beta on my G4 today. I was initially impressed with the UI but got annoyed with it rather quickly. Also annoying is using classic apps in OS X as launch time is nearly a minute or two and speed lags well behind. On the plus side, network config was a snap, and the UI does have a few nice things to be said about it, but I felt like a six year old after awhile, which isn't a good feeling. No development tools though!
A more accurate statement would be that the Linux kernel is a monolithic kernel, which, unlike the QNX microkernel, does not provide MMU protection of core OS processes. This also makes it much easier to write and debug QNX device drivers.
You can debate the definition of "monolithic" and talk about "kernel modules" all day long, but the fact is that the Linux kernel all runs in the same memory space, so it is a less robust design than a microkernel. (Note that I said robust _design_ not implementation. It is possible to write a crappy microkernel).
Unlike some OSs, QNX is not monolithic. ALSA is just a module somewhere above kernel space, so its not actually part of the OS proper.
A deep unwavering belief is a sure sign you're missing something...
Anyone know what (duuuh heck) this is?
skunk:~$ file qnxrtp.tar.F
qnxrtp.tar.F: frozen file 2.1
skunk:~$
Anyway, for the sake of Tucow's bandwidth, I'm mirroring the file here. MD5 sum = 316236554639edf717a94026ee940812.
iSKUNK!
D'oh! Guess the ISO is the way to go, then :-)
Tucows doesn't seem to be running slow at all, but if others disagree, here's a little something that should help:
File: qnxrtp.iso
Size: 95911936
MD5 sum: 75c8dc3a42f80a85ef8c733a317d8ebd
iSKUNK!
I wonder if they tried to beat RedHat to their 7.0 release.. it would of almost been better for the excitement of RH7 release to calm down a little bit.. but I think that it may of rained on their parade.
--------------------
it's fast .. clean ... it remidns me beos.
... but with linux you can do a lot more.
.. do I need to trash Beos ? I think no. I'll have Unix networking with a nice GUI (linux far away .. NOW) and a solid OpenGL (better then linux asap for Be is out .. not too far).
... but too different from BeOS and if compared to linux for SOMETHING is better.
... we don't need another OS to waste energy .. Linux and Beos are growing so nicely now.
...
but beos is more advanced not not "old style" unix.
anyway qnx is better then linux for it's quality of code
with Bone and OpenGL coming to Beos
Qnx is kewl anyway
I'm getting bored of changing OS
Qnx will be a toy in the desktop
Check the preview on BeNews here. They have screenshots and everything.
BTW, BeOS is better than QNX. Seriously.
Interesting, what QNX calls a filesystem driver, the rest of the world calls a disk (i.e. scsi or ide) driver. I guess that means that QNX only supports one file system, or they just call file system drivers something else (further compounding the confusion).
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Future battles will be waged in the embedded market, not the desktop market. If Linux is to succeed in Linus's quest for World Domination(tm), then QNX must be the first up against the wall.
I am in the process of setting up RTLinux for data collection and device control (using D/A boards and digital I/O). The RTLinux approach seems VERY sound, and straightforward.
Looking at the QNX website, I can not find any information on what data aquisition boards it might support. Dow that mean I would have to write the drivers from scratch? (Not a problem, I have to do the same to RTLinux, although I can make use of much existing code). How does QNX support such hardware (not listed in "Supported Hardware")?
So, while Linux, as delivered by Linus and crew is not real-time, it has been successfully used in real-time systems (there are various methods; for my needs, RTLinux's approach appears quite adequate)
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
2% CPU Usage while playing an MP3... Man, as soon as they Port my Adobe products....
Why can't the transit system be this efficient?
I am become Troll, destroyer of threads
I'm talking about a usable DESKTOP Linux distribution. Even Slackware, which is pretty sevelte, takes up 150-200MB base install, plus 100-something for X, and another 100 something for GNOME and KDE. This includes compilers and stuff like Perl, TK, etc that a Linux distro is more or less unusable (as a desktop) without. I can tell you exactly where all the bloat is.
A) Libraries. There are tons of libraries on a Linux system.
B) X. X takes up around 70MB on my machine. The BeOS GUI is inside the 3.1MB app server.
C) Gnome and KDE. The BeOS WM is also inside the 3.1MB app server, and the "DE" is spread out through different servers.
You can set up a fully usable BeOS machine in under 50MB. (Graphical, everything.) Try that with Linux.
A deep unwavering belief is a sure sign you're missing something...
GNOME and KDE? XFree 4.0? Kernel 2.4? Compilers? TK, TCL, Perl, etc? I have a hard time believing that. Of course, if you're using the thing bare-bones, this stuff isn't necessary, but when I say BeOS takes ~100MB, I'm talking full install. Compilers, media players, IDEs, etc (perl, and all the GNU tools). All the stuff I mentioned is absolutely necessary for most Linux distros. Take, for example GCC. You can't really get by without a compiler. Say you have XFree 4.0.1. NVIDIA's drivers don't yet have an RPM for that, so you've got to compile it. Upgrading the kernel usually necessitates a recompile (in order to take full advantage of it.)
A deep unwavering belief is a sure sign you're missing something...
Real Time Linux is a real-time kernel that runs a standard Linux kernel as a pseudo-userland thread. It is essentially a hack to run standard Linux binaries on an otherwise real-time system.
Whenever an interrupt is issued, the RTLinux handler is run, and if necessary the RTLinux scheduler. The standard Linux kernel scheduler only runs during idle time. And RTLinux can pre-empt the standard Linux kernel, because Linux is run essentially as a process of the RTLinux kernel.
So my point is that the latency of the Linux kernel as we know it has no real bearing on the performance of RTLinux. RTLinux is it's own kernel, designed from the ground up for real time. To my knowledge, it shares no code with Linux. Linux is run "on top" of RTLinux, and thus stays out of the way of the ultra-important real-time scheduler.
Check out their site for more info...
--Lenny
Whilst I've not used this latest version of QNX, a couple of years ago I designed the control system for a wafer polishing tool that used QNX for the control system. We ran it on 3 single board computers, one with a hard drive, the others booting off flash and sharing the hard drive of the first. It was nice because the hardware and resources were transparently available on all three SBCs, computer 1 could easily get to serial ports on computer 2, etc. By dividing the control tasks up into a number of modules and using the QNX send/receive/reply IPC stuff, we were able to move tasks around on the fly and the system didn't know or care where stuff was running. I just wished they had supported gcc at the time. Watcom was ok, but it was a really old implementation of c++....
jim
I've wrestled with reality for 35 years and I'm happy to say, I finally won out - Elwood P. Dowd
Computer hangs on "Generating helpviewer search database"... dang. I wanted this to work. Does anybody know what's up with that?
Not really. If you look at the BeOS distribution, it has GCC, Perl, most of the GNU tools (like sed, awk, bison) its own desktop environment, sample code, media files, etc. The Linux distro I'm talking about is bare-bones Slackware. GNOME, KDE (I need apps from each one), XFree86 4.0.1, Kernel 2.4, ALSA, and various important libraries. You have to look at it as functionality vs code size. BeOS and QNX fit a hell of a lot of functionality, into a very small code size.
A deep unwavering belief is a sure sign you're missing something...
Would you like to point out how? If you look at my postings on the BeDev list and BeNews, you'll realize that I critisize BeOS too when the time is appropriate. I never said to anybody that YOU SHOULD USE BeOS. I merely point out when somone is spreading FUD about it, or when somone gives Linux undeserved credit.
A deep unwavering belief is a sure sign you're missing something...
As such you acknowledge that you are not authorized to use any the QNX Realtime Platform: (i) in a live operating environment, (ii) with data that has not been sufficiently backed up, or (iii) for benchmark or performance testing. You should expect the QNX Realtime Platform to be somewhat unreliable. It is your responsibility to take adequate precautions to prevent damage to your resources in the event the QNX Realtime Platform fails. We intend that all components of the QNX Realtime Platform will be offered as commercial versions; however, we cannot guarantee if or when this will happen.
I thought this was a product. That sounds like a beta or worse. QNX used to be really good about reliability, and I thought that would continue. Apparently not.
I never said monolithic is bad. I said that since QNX is not monolithic, ALSA doesn't have to be part of the kernel to work, and thus the kernel need not be Open Source.
A deep unwavering belief is a sure sign you're missing something...
From the QNX developer FAQ:
"[I]f one appliance in a home network has an Internet connection, or flash memory, or an MP3 music archive - whatever - all other appliances can access that resource automatically. Not only is this cool, but it can dramatically lower the cost of entry for home networks"
Isn't being cool reason enough to try it out? This is almost enough to get a second box running in my shoebox apartment so that I can set up a lan and try this out. It's not so much that it can share the resources, but that there's no work involved.
Mr. Spey
Cover your butt. Bernard is watching.
Cover your butt. Bernard is watching.