Slashdot Mirror
QNX RealTime Platform Preview
Mike Bouma writes "Since the QNX RtP will be free for personal use this late-september, this BeNews preview will see how QNX RtP compares to BeOS and to free Linux systems.
QSSL is a member of the Phoenix Platform Consortium which goal is to produce an Amiga-like successor OS. QNXStart.com will be a starting point for the QNX RtP community and is first in a series of Phoenix partner websites."
Which would make a better OS for a software synthesizer:
The simple answer: Whichever platform has the software already existing for it (at least if you need to use it in the near future).
The ideal situation would seem to be an OS that has the graphical capability to present an interface for MAKING instruments, and then a working capability where the graphics are gone and you PLAY the instruments. Whizbang stuff for building the instruments, and simple multitimbral interface for using the built instruments.
All of the OSes you listed are _capable_ of doing this. As for "best", I'd lean towards BeOS (as it's streamlined for this kind of thing), but "whichever one has both this software and the other day-to-day software you use" is probably the best answer, IMO.
BeOS is going down because of the shift in focus to embedded devices by Be Inc. QNX, an embedded device maker, will takeover Be's desktop market.
Doesn't the reason for BeOS failing also apply to QNX? Is QNX going to focus on the desktop and leave embedded devices to Be? (I bet that idea has JLG creaming his pants)
Without drag and drop support I won't use it, so it's still Be for now.... although I seriously want that DVD player.
Insanity is the last line of defence for the master diplomat. But you have to lay the groundwork early.
A better comparison is QNX to Cygnus eCos, the Linux-preemptive RT/Linux kernel/system, WindRiver's VxWorks, etc... It is really unfair (for both sides) to compare a "lightweight" OS for small, embedded systems against a be-all/do-all behemoth like Linux (which does have a minimum size limitation).
I'm sure you'll be able to find some overlap, but it's really a question of "which is better for this application" and not "which is better period".
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
And, IMHO, a nice thing about it being wonderful for embedded systems, is that even if the desktop turns out to be a flop (my Amiga paranoia has already set in), they still have another thriving market for the product. That way, even if things go badly, people who like it won't be quite so easily orphaned. Not quite as safe as open source, but it should still do the job of avoiding another Commodore incident.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Hey, thanks a lot.
A deep unwavering belief is a sure sign you're missing something...
Linux is nowhere near playing in the same league as these microkernels (QNX and BeOS) until it fixes several things. A) Fix the versioning problem. If the binary standard changes every kernel version, then I can't be expected to use binary, pre-compiled modules, can I. Neither can vendors supply pre-compiled modules. Sure it's fine now, when all the hardware is supported out-box, but what about when Linux "makes it." Driver updates are a common occurance, and with the current situation, will be hell for users. B) Fact: 99% of people CANNOT figure out modules.conf. Fact: 99% of people shouldn't HAVE to figure out modules.conf Fact: 99% of people have no DESIRE to figure out modules.conf Fact: Unless everything comes preconfigured and you never upgrade your hardware, 99% of people WILL have to figure out modules.conf Fact: BeOS (and supposedly QNX as well, I haven't tried) can detect hardware and install it without any knowledge on the users part. Linux can't even figure out that tulip is an ethernet driver.
A deep unwavering belief is a sure sign you're missing something...
I'm sorry, I'm a patch virgin. I copy everything from diff -u... down, /root/nvidia.pat and
/root? Also, I've
save it to nvidia.pat, and patch -p0 it in the same directory that contains
NVIDIA_kernel-0.9-4 right? So I've got
/root/NVIDIA_kernel-0.9-4 and
I do patch -p0 nvidia.pat from
never gotten a patch to work. Is it supposed to take
insanely long?
A deep unwavering belief is a sure sign you're missing something...
Engineers "played" with such DVD players and managed to get their output on several (different) displays at once, due to the extraordinaire versatility of Photon.
--
Trolling using another account since 2005.
If you had a slower processor and/or a really high system load, you might have some breakup in your audio. Or perhaps if you did something more demanding (DVD playback?) you might have problems? On my 700 MHz Athlon Linux box, I have noticed that the animations at the beginning of some Loki games (Myth2, Heavy Gear 2) are slightly choppy.
Another type of example that comes to mind, is a behavior I have seen on OS/2, Windows, Linux (Gnome/KDE), and Macintosh: sometimes poorly responsive GUIs. If the system is really busy, you can click on a widget and not get immediate visual feedback that the computer "heard" you. Make the GUI feedback process realtime, sort of how Amigas do the GUI feedback as a high-absolute-priority process, and you could get Amiga-like snappiness.
Realtime probably isn't strictly necessary for the desktop, but it's still a cool feature.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
A few points to note.
----
Hooray!
(Explanation: One of the biggest reason I shy away from MacOS, X, and some other GUIs and continue to use Windows on the desktop is the way a mouse seems to be required to use those. In Windows (well, I use NT) just about anything can be done with the keyboard, unless the developer of the particular program went out of his way and wrote some custom widgets or something.)
Oh yeah, and those screenshots are pretty!
--
Okay, show me how to configure X windows automatically on Mandrake 7.1. (On my TNT, a damn common card, it don't work.) Show me how I can configure my soundcard in RedHat 6.2 without looking up my IRQs and DMAs (I've got an AWE64, again, a very common card.) Show me how Slackware 7.1 can install my two network cards (something that doesn't work on Mandrake either, they only detect one) without me editing modules.conf.
A deep unwavering belief is a sure sign you're missing something...
This is a sticky issue.
For example. If I didn't turn on "enable sound" the last time I built a kernel, can I just rebuild sb.o and insert it into the kernel? Nope.
Yes Linux has loadable modules, but that is not nearly the same thing as what QNX provides with each driver being a process that can be started with an & and killed via "kill" at runtime and with each driver being in its own memory space. Linux is a monolithic kernel (which can sometimes have advatages) and you still need to rebuild stuff to make devices work. This is even more true between kernel versions.
Good that you made this post, everyone should be informed and not too hung up on buzzwords.
........ "The faster I go, the behinder I get" - Lewis Carroll
Binary Standard: The BeOS driver API has changed a couple of times. Apparently the only place where there are "hacks" to load drivers with older versions are in the module loader.
Modules.conf: Nearly everything can be figured out. BeOS configures my soundcard totally without my help. Linux doesn't. BeOS detects my two network cards and just asks me for IPs. Linux (Slackware 7.1) will only detect one card and I've got to edit modules.conf by hand. To install ALSA I even have to tell modules.conf how many cards to support! That's ridiculous.
Detection: Again, installers can't do everything. A lot of people DO install their own hardware. And those people aren't necessarily all UNIX gurues. The problem is that under Windows, it's plug it in, insert driver disk. (90% of the time.) Under Linux, it's plug it in, then do all sorts of hardware dependant (installing a vid card is different from installing a sound card) stuff to get it running.
A deep unwavering belief is a sure sign you're missing something...
Actually, it seems that Linux software ports over real quick. Photon seems to have a layer that allows X apps to use Photon. I do know that GTK was ported over very quickly, and since it's POSIX complient, most apps should compile out of box. Not to mention the fact that it's going to get a port of lxrun.
A deep unwavering belief is a sure sign you're missing something...
I hope you're still reading this thread. I'd email you, but you give no address. (I've been sick since Monday).
I envisage something more like this:
Then you can run it on a low-end machine or a high-end machine and it just gives you as many simultaneous tracks as it can handle. The system is open so anyone can go in and write modules or drivers.
By replacing the OS you get to provide the speed and consistency of access that such a system needs.
Thing is, I began designing such an OS five years ago, based on the StrongARM. Now, I wouldn't recommend doing audio on the StrongARM (unless you want to watch your 200 MIPS turn into 40 MFLOPS) but I certainly would recommend a Pentium III (watch your 1300 MIPS turn into 5200 MFLOPS!) But the point is, I have the microkernel design pretty much sketched out.
It'd be sort-of like an open-source BeOS!
So anyway, I'm quite revved up by this. The existence of Linux means I can basically crib drivers before I write my own GCOS drivers and get a system working in a small amount of time. Even V2_OS might be a good place to start (although the kernel is not open-source, it isn't protected either, so V2_OS makes a good bootstrap loader for a real OS ;)
So what do you think?
--
It's a
-- Danny Vermin
In my experience, most softsynthesis takes place on, well, uhm, sorry...Windows. I think there you have at least a partial answer to your question. Before people start screaming that the only reason for this is that Windows has a larger userbase: most (semi-) professional musicians, i.e. people who can afford the steep costs of a reasonably good software synth (at USD 500 they're not exactly toy software) prefer Macs. So I guess this must mean that there's something about Windows that makes it very suitable for real-time audio manipulation. I'm further guessing that this has something to do with Direct X, which lets software access the hardware directly. If you compare the Mac version of Acid to the Windows version (which is heavily optimized for Direct X), for example, you'll find that it's much less responsive and capable of handling *large* mixes. A similar situation occurs with name audio programs like CuBase, Wavelab and Logic, which contain almost no Win/Direct X platform-specific optimizations (sp?). They're clumsy and slow. So, to answer part of your questions, between the two major desktop OS-es (notice I said *desktop OS*, and not just *OS*), Windows wins because there's already a more or less stable way to handle the hardware side of things gracefully.
I'm guessing that Linux will *never* be suited for hardware-intensive tasks like audio. There isn't, as of yet, a way to circumvent X and the kernel.
And as for BeOS: well, from what I've seen from it, it could actually be good, if there was any software for it. For a Media OS it has surprisingly little substantive software. Demos of thirty mp3's playing simultaneously do make it look promising, though. I'm guessing they've designed the OS specifically so that it puts as few barriers as possible between the app and the media subsystem. Unfortunately, it is such a niche-system no manufacturer in their right mind would spend the millions of dollars needed to write an app. to specifically take advantage of the system.
Finally, QNX: from what I've learnt about it in the past five minutes, it looks kinda promising because it's supposedly fast as hell. Still, though, no one is using it, so there won't be any serious software for it in the near future. Maybe what *will* happen, though, is that hardware manufacturers start using it as an os for virtual analog synths, because it would take away the need to develop a new OS specifically for a certain device. That would be pretty cool, actually: imagine being able to play tetris on your synth while the guitarist takes a ten minute solo!
News and bla for computer musicians: http://lomechanik.net/
With QNX, all drivers and OS modules - not just applications - run as separate MMU-protected processes. This architecture boosts reliability in a variety of ways. For example, ISVs can add custom drivers and system services without modifying the OS kernel and introducing potential kernel faults. And if an application or driver does behave "badly," the OS can intelligently restart the offending module, typically without a reboot. This is possible even if you are sitting at your computer without any pants on as I am currently doing. This architecture also makes it easier to upgrade drivers and other system software, again without rebooting.
Except, perhaps, BeOS ... but I have only "heard good things" about BeOS, and never actually tried it out.
--
It's a
-- Danny Vermin
Windows is simply unacceptable. The other post here about DirectX is quite misinformed. MacOS gives unbelievably better latency than Windows. Compare ReBirth for Windows/DirectX with >20ms latency (>100ms on NT) to ReBirth for Mac with MacOS is reasonably low-latency, but it's going in the wrong direction. Unices (love em or hate em) are again not designed for real-time work. The RT Linux stuff is promising, but apparently it's hard to dynamically link stuff into the real-time section, and you can't even use the FPU without jumping through some hoops.
BeOS on the other hand is designed from the ground up for low-latency high-speed access to multimedia hardware. BeOS is asking for this sort of software, and it's cheap (if you're paying $500 for a soft synth, another $50 for the OS to run it on isn't too big a deal).
The absolute best solution, of course, would be to not use a proprietory OS. But that's a way off yet ;)
So, you wanna help me write this?
--
It's a
-- Danny Vermin
Real-time systems are usually divided into hard real-time systems and soft real-time systems. With a hard real-time system, a late result has zero or negative value. With a soft real-time system, a late result has a positive value that becomes smaller as the time interval between the deadline and result increases.
Real-time does not mean "real fast", it means predictable. A batch payroll system could be considered a real-time system if there are deadlines that must be met.
Mea navis aericumbens anguillis abundat
I am hoping some synth types are /ing here today....
Which would make a better OS for a software synthesizer:
1.BeOS
2.QNX
3.Linux with realtime patches/modules
3.Win98 lite
4.MacOS
Softsynths like Reaktor from Native Instruments are becoming comparable to professional synthesizers in terms of interaction, capability, and musicality. But so far it seems the OS's these softsynths run on are a limiting factor.
The ideal situation would seem to be an OS that has the graphical capability to present an interface for MAKING instruments, and then a working capability where the graphics are gone and you PLAY the instruments. Whizbang stuff for building the instruments, and simple multitimbral interface for using the built instruments...
Which would be the best???
-Sleen
I am referring to the QNX4 kernel. Do you have experience with the new version, and most importantly, have they fixed the obnoxious 'i'm forking therefore you may experience unexpected latency of' bug?
I was writing an app where latency over 3ms would crash the hardware (bad hardware, i know) and this one bit me hard, and left a bad bad taste in my mouth.
----------------------------
Exactly WHY wouldn't you want to give up Linux in favor of this? (Not a flame, I'd just like to know advantages/disadvantages compared to Linux.) Additionally, a platform that doesn't use X always gets points in my book.
BTW) Is Photon's solution a good one. It's fast, light, and mostly X compatible. Could we finally get rid of X with something like this?
A deep unwavering belief is a sure sign you're missing something...
What does this have to do with Linux? QNX doesn't even use X. Also, GNOME might be doable. GTK was quickly ported, QNX is officially POSIX complient, and Photon is pretty compatible with X.
A deep unwavering belief is a sure sign you're missing something...
Fuckwit. True, QNX does have some niceties that BeOS doesn't. HOWEVER...
A) There is no proof that QNX can cut it the way Be can in media.
B) It still doesn't have plans for accelerated OpenGL (currently the only thing accelerated is Mesa/Glide.)
C) It might be more of a competitor to Linux than anything else. From my POV, it supports my hardware, is fast and small, and is a fully POSIX complient UNIX. Those are the only reasons I keep Linux around, and it might be nice to use a UNIX without all the attendant bloated-ness I had associated with the system. If all goes well, it's not bye bye BeOS, but bye bye Slackware.
PS> As of now, NVIDIA Driver 0.9-4 still doesn't work with kernel 2.4-test6+. Any kernel hackers have any clue why? It seems to have something to do with the dissaperance of MAP_NR.
A deep unwavering belief is a sure sign you're missing something...
1 - You seem biased against VxWorks, did you have a bad experience with it?
/.'ers love QNX. It's not gratis (to use for real), it's not libre, and it doesn't offer any significant capabilities that are unique solely to the system. My point was simply that for people who are just toying around and learning about RT-OS's, why not help develop something that fits in with the ideals that /.'ers allegedly hold in high regard.
2 - i've seen qnx4 crash horridly.
3 - nope, it's a real bug. if you pester qnx enough, and give them enough money eventually they'll tell you that they lose the ability to guaranteee it will meet deadlines during forks.
4 - nope, not completely posix. sed is broken, to name the first bug i discovered in it.
5 - yes, but vxworks has a slightly more sane licensing scheme, if only slightly.
6 - yep, debugging and such on vxworks isn't as simple as it is on qnx, but i had to use ice to find the fork latency bug. that's not what I call easy either.
I don't claim that making an RT-OS is easy, but I don't understand why
----------------------------
I am one of the folks running the pre-release version of this puppy, and I have to agree with the article completely. I had no problems installing it, and have had no problems running it. It detected my hardware perfectly and installed like a breeze (probably the easiest installation of any software I have ever installed). This is going to be a platform to watch.
"The first time I got drunk, I got married. The second time I bought a chimpanzee, after that I stayed sober" Arian Seid
The nice thing about using QNX IS that it is wonderful for embedded systems. Better yet is being able to build those embedded systems using the exact same system you use on your desktop. There is nothing more painfull for development turn-around time then having to x-compile and reboot or download to another platform. Being able to use the exact same GUI and kernel has major benifits. You don't need to #ifdef and compile differnt parts to make it fit in your PDA. Simply only run the parts of the system you need to run. This is the true advantage of the microkernel.
........ "The faster I go, the behinder I get" - Lewis Carroll