Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
News

QNX RealTime Platform Preview 113

Posted by Hemos from the YAOS-yet-another-os dept.
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."
This discussion has been archived. No new comments can be posted.

QNX RealTime Platform Preview More

QNX RealTime Platform Preview

Comments Filter:

  • WOW (Score:1)

    by mach-5 ( 73873 )
    I'm impressed. I'd have to say that as a Linux user, I think that QNX can give any distro a run for the money. It seems to me like the OS will be pretty mature from the release point on. It comes with a lot of apps and everything is fully featured. The DVD player is definately a plus. Can't wait to see this thing mature a bit.
  • 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.
  • OK, let me get this strait.

    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.

  • Actually I was just trying to show how open minded I am, for I love all God's creatures, and all the OS'es of the world. And cute fuzzy bunny wabbits and flowers.

    In all seriousness though, I was making a point, that I am open minded about the promises of any OS out there, I use BSD right alongside Linux and BeOS, and *GASP* even MacOS sometimes. I will try any OS and judge it based on its technical merits, not based on my own personal prejudices. And I CERTAINLY wouldnt allow those personal preferences to cause me to go out of my way to rip on an OS that wasn't my preferred one
  • Better yet is being able to build those embedded systems using the exact same system you use on your desktop.

    The synergies of dealing with one system for multiple purposes are huge. The same lesson that has been learned in IC's and microprossors will be learned in kernels as well: make something that is good enough over a range of applications, then focus all your energy on that technology, and pretty soon it will beat specialized technologies at their own games.

    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.

    This, however, is bullshit. Picking which parts to run can be done as easily with Linux kernel modules as with microkernel servers. I bet that the parts of Linux that can't be modularized are pretty comparable to the core QNX microkernel. (Yes, QNX is still smaller, because it's optimized in that direction.)
  • It appears that QSSL is opening the door to the desktop market while maintaining it's attention on the embedded market. This allows groups such as Phoenix Consortium to have a good deal of input on what is needed in desktop enviroment.

    As for Be, last time I looked, their stock price was at 4 9/16, down from something in the 50's earlier this year. I don't have much hopes for Be to survive the next 12 or so months.

  • A better comparison is QNX to Cygnus eCos [redhat.com], the Linux-preemptive RT/Linux [rtlinux.org] kernel/system, WindRiver's VxWorks [windriver.com], 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

  • QNX, an embedded device maker, will takeover Be's desktop market.

    Ummm, I think QNX is still primarily an internet appliance OS, so Be's desktop market is basically just withering on the vine, not eaten away by QNX. Although Be may very well make a nice internet appliance OS, it often appears that BeIA is a "hail mary" play by the company. Too bad, it would have been a nice OS if they could have kept up with all of the multimedia technologies, but since the Internet quickly moved to proprietary standards like flash and realplayer, which Be was hesitant to license, making their claims of being the "multimedia OS" unfounded. OTOH, Internet Appliances have a built in "killer app" (the Internet), so there may be less risk than creating a desktop OS w/o any application support. BeOS would be pretty cool if there were prosumer or professional content creation apps.
  • You should have gotten an e-mail with a username and password to get it from a URL at QNX. I signed up pretty much right away, as well, and got my e-mail last week.

    :wq!

  • No, you are wrong. Apple created Darwin using software that was already open source, e.g. the mach microkernel and FreeBSD. Nothing new there.

  • The nice thing about using QNX IS that it is wonderful for embedded systems.

    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.


    ---
  • HURD is not itself a microkernel. It is a series of servers which run on top of the Mach microkernel. Mach is very old technology, a "first generation" microkernel and not known for its performance. There aren't really any "second generation" solutions that are open source other than Fiasco [tu-dresden.de], and it has serious limitations.
  • What is that suppose to mean?
    --

    A mind is a terrible thing to taste.

  • 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.
  • I'm sorry, I'm a patch virgin. I copy everything from diff -u... down,
    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 /root/nvidia.pat and
    I do patch -p0 nvidia.pat from /root? Also, I've
    never gotten a patch to work. Is it supposed to take
    insanely long?
  • Maybe in america but definatly not in europe. The Video Toaster never even made it over to europe (where the majority of the Amiga userbase was situated). What killed amiga was the fact that Commodore was run by idiots who allowed the PC clone side of their business to haemorage money at an astounding rate while not marketing their one good product (the amiga).
    • BeOS' soft realtime should not be confused with QNX' hard realtime:
      • Soft realtime means that the OS will launch the process/thread/program with no guarantee that it accomplishes its task at time.
      • Hard realtime means that if the OS estimates the task won't finish in time, it won't launch it at all.
    • [...]QNX's DVD player[...] : Many commercial "salon"-DVD players are using Neutrino+Photon+XingDVD in ROM, we can then be sure this works.
      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.

    --
  • 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.

    This is just plain wrong. Why couldn't you ?
    You just select what sound you want (via make config or others) say 'make modules' and you're ready to insert module with insmod.

    What exactly WAS your problem ?

    BTW, if you used pre-prepared distribution (like you used with QNX) there would be no need for compiling at all, you would just load pre-compiled modules like you start pre-compiled program in QNX.
  • "Why does everything have to turn into a slam against Microsoft?"

    It wasn't.

    It was a jibe about the 'people' that use their products. Sorry for being so boring.

    -Sleen
  • Not mine, and I bought it for $179 at Fry's. Oh, and it plays video CDs, too.
  • How can you try to measure key-press responses exact to milli-seconds when it taks a lot longer than that to press a key? Sure you could wire up some sort of flat, fast button, but then why run it through the keyboard port?
  • So I call up the Commander.
    Please bring me my wine
    He said
    We don't have that spirit here.
    Coz Hemos drank it all.

    And still those posters are trolling
    from far away.
  • I hate to feed a troll, but... I personally prefer OpenBSD, Although I have used and am quite happy with FreeBSD as well. A lazy person like me just happens to enjoy the added comfort of the extra security of OpenBSD :)
  • I disagree with the article that the gui needs to be open source more than the kernel. Currently there are no complete "second generation" microkernels that are open source. Having the gui open source is cool too. Maybe it could be a replacement for X on Unix?
  • well then. in order for them to even start this out, they need to have at least a somewhat accurate hardware compatibility list.
  • I'm sorry, but that's just wrong. Apple has open sourced the microkernel for MacOS X with Darwin. Check out http://publicsource.apple.com [apple.com]

  • 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.


    ---
  • It is funny that this is what will be the final death blow for BeOS.

    That's like saying BeIA will be the final death blow for QNX in embedded devices.

    As many of you know, BeOS is no longer a desktop operating system.

    Don't confuse BeOS with BeIA -- one is for the desktop, and one is for internet appliances. Both of which exist.

    The BeOS developers no longer develop for the desktop, but have switched the focus of the company to embedded systems.

    No, you're confused. The *developers* of BeOS are still developing BeOS. That is why releases of an entirely new networking environment (close to Linux network performance levels) will be released shortly. That is why hardware opengl support that beats Windows and blows away Linux will be released shortly. (Both comments made on the basis of information garnered from the same source that did the fairly unbiased review of QNX: BeNews.)

    So, you see, it's the COMPANY that has focused on BeIA, not the developers. The developers will work on what the company wants them to work on. There are BeIA developers, and BeOS developers. Just as usual.

    The foolish move by BeOS left the door open for an agressive competitor--QNX

    Yeah, it sure was foolish. Let's consider their options.

    1. Continue to fight on the desktop market, where little money can be made while Microsoft and Apple dominate.

    OR

    2. Focus on the IA market, where they've already made a bunch of killer deals, and where no behemoth like Microsoft rules the market. A market that most analysts and industry pundits believe will be bigger than the PC (i.e. DESKTOP!) market in about 5 years or less.

    Hmm... you're right, you capitalist genious! They should have chosen option number one! That way, they'd go out of business, and neither BeOS or BeIA could exist...

    Now with QNX poised to take over the BeOS desktop market, BeOS will no longer be a viable OS for desktop users. Adios BeOS; Hello QNX!

    Shit... why didn't you say this up-front. That way I'd have known you were a troll before I started putting some deep thought into my response!

    -thomas



    "Extraordinary claims require extraordinary evidence."
  • Well, I definately wouldn't give up using Linux in favor of this (And although being able to dual-boot to it might be cool, I don't really think it would serve much purpose.) However, it seems like it might make a really nice operating system when you don't have time to mess with Linux. Linux takes a couple hours to get installed, set up, make sure you've got all the packages you want... from what the article says, I'd probably be able to get QNX working several times in the same time span. If, for instance, you have (or just have to use) a Windows box for some reason, slap this on and you've actually got a real operating system. Perhaps you can put it on that old 486 you've got sitting around and use it for menial tasks. Whatever.

    Oh, one other thought -- what about educational uses? Would, for instance, high schools have to pay to use it, or would they be able to install it for free? If the installation process is as simple as it sounds, maybe it would be possible to have QNX labs around -- it seems to me that this could be a great platform for kids to be working with, after it's been given a little more time to mature.

  • BeOS DOES HAVE Flash and RealPlayer.
  • This is a good question and.. really the only way to answer it is to write the be-all-end-all audio software application, port it to all OS's, and pick the winner.

    I've been working on this be-all-end-all audio software since March.

    I am actually designing what could be considered an "Audio Software Operating System" or an "Electronic Music Studio Simulator". It has its own graphics library, user input interfaces, audio interfaces, midi interfaces, file interfaces, etc. One can think of audio applications as "modules", which have their inputs and outputs routable to any other module in the system (this routing is determined GRAPHICALLY, similar to the interface found in the Nord Modular software and the Reaktor soft-synth software). I have a simple "Acid"-like module already working, and soon I'll begin working on the more bread-and-butter modules like oscillators, filters, samplers, effects, etc.

    Developing for my software requires learning its API's - this is always a stubmling block for programmers. However, it is essential in order to achieve portability. The nice thing about writing audio software to my API's is that your applications can be run on any OS that my system has been ported to (MacOs, Beos, and QNX ports are planned). Only a recompilation of your module is required (no rewriting).

    I am developing on Win32 because it is the development platform I've been using for 4 years. I've implemented my graphics API with both DirectDraw and GDI (user selectable). I've implemented my sound API with ASIO and MME (also user selectable). Menu's, fonts, controls, Windows, and the like, have been written from scratch, making use of my graphics API for drawing, and the Win32 WindowProc() for distributing mouse/keyboard messages.

    More info on the software/os is at www.treyharrison.com. If you'd like to help contribute to the software, my email is on the site. I'm working by myself right now, but will soon be looking for people to contribute modules.

    trey
  • What uses do people have for a realtime OS on desktop systems?

    It'll probably come in handy when they start needing more than 640k for whatever reason...

  • Free QNX (Score:3)

    by Animats ( 122034 ) on Monday August 28, 2000 @05:21PM (#821779) Homepage
    QNX is a neat little system. I just wish they'd get the promised free version [qnx.com] out the door.

    A few points to note.

    • QNX is not anything like UNIX. There's a POSIX emulator, but underneath, it's a message-passing microkernel. Almost everything runs in protected mode. You call services by passing messages to them, which is done very efficiently. If you're going to program for QNX, learn how to use its interprocess communication services; don't program it like it's a UNIX variant.
    • It really is hard real-time. There's a defined maximum interrupt latency. This is a big win for streaming media and video.
    • There's no paging. Everything has to fit in memory. This is probably good; memory is cheap enough today that paging is generally a lose. The performance hit when you have to page in from disk on Windows or UNIX is so huge you don't want to page anyway. QNX software tends to be much less bloated than Windows or UNIX, so memory consumption is less anyway. It's possible to do useful web browsing on a 386 machine with QNX, booting from a floppy and not using the hard disk. (QNX gives away a demo disk for this.) It's supposed to work. QNX is used mostly for hard real-time industrial control applications. There are nuclear reactors controlled by QNX. QNX users have a very low tolerance for crashing. The top priority at QNX Inc. is eliminating crashes, not adding features. Don't expect dancing paper clips.
  • Why is it that whenever a site that favors one OS talks about others it has to throw in little completely incorrect flames at the other OS'es? From the Benews site, speaking about microkernels...

    It is also the exact opposite of the Linux kernel, which is "monolithic" (everything is built into the kernel, hence the need for re-compilation when you add/remove hardware).

    Now, yes, the Linux kernel is monolithic, and you DID used to have to recompile when adding hardware, way back in the day. But nowadays we have these little things called modules, where you can just plug one in and voila! No recompiling needed. It really bugs me when people make incorrect statements at the expense of something that's not their little pet. I am a BIG fan of both BeOS and Linux, and would like for once to see them discussed without petty little pokes and prods. It's not quite a flamewar, but we as a geek community should try to better ourselves from creeping into the realms of FUD-slinging. We are better than that, people.
  • to get hands on... I know a lot of i-opener types [linux-hacker.com] have been interested into the interworkings of QNX for quite some time, and with the potential for even more loss-leader hardware (vaporous webpads) in the near future, we need people to be looking at this OS. The more people interested, and the more of a chance I have of having linux picture frames throughout my place ;)

    ----

  • "Personal use"? (Score:1)

    by Anonymous Coward
    Oh good, now I can get to all those high-speed, small-size, real-time, embedded projects I was holding off on....

  • Oh my! (Score:2)

    by pen ( 7191 )
    What's thisssss? Could it be? The widgetsessss! They're keyboard-accessesssssible! Shortcutsessss abound! No moussssing required!

    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!

    --

  • Not in MacOS... last time I tried that on MacOS 8.x and 9, it didn't work

    Yes in MacOS. I dunno when that started, but it seems to me that it's been there just about forever. (Way before OS 8, but I guess I could be wrong..) Anyway that feature has been there forever. The only way you don't get that is if you don't use the standard API for text, TextEdit. In which case.. well.. we're not comparing OSes, but rather applications. Anyhoo.. I still do wish there were keyboard shortcuts for other stuff...

    . ._ _ .__. ___ ___ ._ _. _.. _. .. .

  • Whoops, MustardMan already got it...sorry.
  • From a practical point of view, you might be right. But I have to point out that QNX was originally designed as a general-purpose OS. The emphasis on realtime and embedded applications is more a matter of market focus than technical limitation. And in the GUI-Multimedia-Broadband world we now live in, don't the specifications for a good RT OS and a good end-user OS sort of overlap?

  • If you're going to program for QNX, learn how to use its interprocess communication services; don't program it like it's a UNIX variant

    Actually, QNX provides a POSIX resource manager framework that makes the native IPC pretty much transparent

    There's no paging. Everything has to fit in memory

    This is incorrect. Earlier QNX OS's (e.g. QNX4 and QNX2) did not support paging. QNX RTP (aka QNX Neutrino) does support paging. It simply must be enabled by your application.

  • It's possible to do useful web browsing on a 386 machine with QNX, booting from a floppy and not using the hard disk.

    If you don't need paging, even a 386 is more power than you need. Come to think of it, when QNX first came out, they were claiming good performance on 8088s. Does anybody still alive remember the 8088?

  • From the article, it still has some application functionality problems, but it sounds nowhere near as buggy as Windows (making something as buggy as that would be a feat in itself).

    I have to wonder about including the games though. What is the real point other then showing a little more versatility in the product? Besides, what are the games? Tetris (again), or Pinball? It's not like we're going to see Half-Life for this thing any time soon.

    All in all, the main reason I can't see this becoming exceptionally popular at this point is the lack of drop-and-drag. Users like being able to do that. Of course, that could be easily corrected by adding a few lines of code. And it would still be smaller then SE.

    Kierthos
  • 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.

  • Re:Constant bashing... (Score:3)

    by variable ( 13935 ) on Monday August 28, 2000 @07:22AM (#821791) Homepage
    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.

  • Quote from BeNews: "The kernel can be extended by dynamically plugging in service-providing processes, such as file systems...good memory protection and easy upgradability. It is also the exact opposite of the Linux kernel, which is "monolithic" (everything is built into the kernel, hence the need for re-compilation when you add/remove hardware)."

    Is this right? I run plenty of modules on my system that are not in the kernel. I thought compliling your own kernel was one of the best things ABOUT linux.

    This is somewhat right. The Linux kernel is monolithic, but you can dynamically add/remove kernel modules.

    Isn't it incorrect to describe Linux as Monolithic? Especially with all the chimps hanging around Redmond...

    Why does everything have to turn into a slam against Microsoft? Monolithic, in this case, is not meant as a derogatory remark.

  • 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.
  • 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.
  • I believe this is the last post
  • There is actually Q3A running on RtP.
  • I was going to register a login with their site just so I could respond to the obvious flame-bait troll article, but I had second thoughts. Why do we allow these people to get our collective blood pressure up and goad us into these flame wars? At the end of the day, it's not going to make one bit of difference into what we use. We'll still be using FreeBSD, OpenBSD, NetBSD, Linux, BeOS as well as QNX when it actually comes out. And, we'll be happy.

    QNX is just yet another choice. On the surface, it looks like a very interesting OS. However, is it Open Source? If I wan't to change something in the core OS, can I do so like I can in Linux and *BSD?

    The author kind of misses a couple of points. First, QNX was designed for embedded systems and real-time applications; Linux wasn't. She compares apples and oranges when talking about Linux being a monolithic kernel (which it hasn't been for years) and QNX being a modular system. They were made for two different applications. Second, the author says that it's a competitor to Linux for the desktop. Well, they both still have to compete with Windows which still has the monopoly on the desktop.

  • I really don't understand what the big deal is about QNX. It's not as interesting as VxWorks, it's not as stable as... well anything. It's buggy as all hell, and it only is guaranteed to meet deadlines if you don't fork. (try it, it's true, it can blow deadlines by up to 40ms under certain circumstances) It's kind of like unix, but different enough to bite you in the ass a lot, and make it so you have to do porting work on anything normal that you'd want to run. Photon is a nice windowing system, but it's not worth running qnx for. It's non-free in the libre sense, and it's ludicrously expensive to use commercially. Actually it's this bizarre 'points' system where grep might be 3 points to release it, and whatever, and they charge per point, some negotiated fee. Will somebody please tell me what the big deal about qnx is? if we want people working on something interesting, make rtlinux work, or just help linux have lower latency in general for apps that don't really need rt capability.
    ----------------------------
  • I really don't understand what the big deal is about QNX. It's not as interesting as VxWorks, it's not as stable as... well anything. It's buggy as all hell, and it only is guaranteed to meet deadlines if you don't fork. (try it, it's true, it can blow deadlines by up to 40ms under certain circumstances)

    It's kind of like unix, but different enough to bite you in the ass a lot, and make it so you have to do porting work on anything normal that you'd want to run.

    Photon is a nice windowing system, but it's not worth running qnx for.

    It's non-free in the libre sense, and it's ludicrously expensive to use commercially. Actually it's this bizarre 'points' system where grep might be 3 points to release it, and whatever, and they charge per point, some negotiated fee.

    Will somebody please tell me what the big deal about qnx is? if we want people working on something interesting, make rtlinux work, or just help linux have lower latency in general for apps that don't really need rt capability.
    ----------------------------
  • That would be pretty cool, actually: imagine being able to play tetris on your synth while the guitarist takes a ten minute solo!

    I can play pong on my kurzweil k2500rs until the guitarists come home!!!

    -Sleen

  • Hi,

    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:

    1. There's a tight microkernel OS which provides GQOS (Guaranteed Quality of Service) for different devices. In particular, the hard-drive and sound cards. It actually times hard-drive and sound-card accesses to give upper limits on the timing of these.
    2. This then interfaces with the standard drive and soundcards - IDE, SCSI and SB16 (to begin with)
    3. Drivers can be added by anyone
    4. Applications can be added by anyone
    5. The system provides a threading system specifically for sound-generating threads
    6. It's all open

    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?

  • Try GNU HURD (http://www.fsf.org/software/hurd/hurd.html).

    It's a reasonably mature microkernel that is open source (under GPL). As an OS, it does quite well, but it needs more apps.
  • Well, it seems you have an invalid email address or I'm too stupid. Here's what I tried to mail you, and if you wish to contact me you can use:

    absolutniks@hotmail.com

    Too bad I can't award a +1 interesting to your post describing your architecture for a dedicated audio OS, seeing as that I've already posted extensively in the discussion. Anyway, it's probably not that much alive anymore, so I figured to contact you directly.

    You indicate you've got a sketch of the microkernel all worked out. Does that mean you've got a sketchy version of the system that's ready to run? I'd like to see it in action, even though I probably wouldn't be able to appreciate the finer details of OS design. The overall description you gave in your post sounded pretty interesting. Some sound ideas, there, too (as far as I can tell - the slashdot nick wasn't chosen completely at random ;). From what I understand about OS design, a media OS would definitely benefit from having a microkernel. Also, if you set device management up in a way that specifically facillitates audio production, that would definitely be a Good thing.

    There's a number of serious, non-technical problems I'm afraid you'll come across when developing an open audio OS, though.

    For one, all the professional software that's established right now is anything *but* open. The exact design of ProTools, Logic Audio or Acid is a jealously guarded secret, and for a good reason: the vendor that can deliver the most performance has a distinct advantage over the competition. So even if you manage to get the OS in place, manufacturers of software programs and hardware (drivers!) would probably be reluctant to contribute if they have to plug into GPL-ed code. A solution would perhaps be to come up with a different kind of open license that allows for proprietary applications and drivers to hook into the system.

    Unfortunately, you'll need the pros to make it feasible. There's tons of small shareware apps out there that contribute to the music making process, but there's *nothing* that will put all the little bits together. Sure, some of the shareware is exceptionally good, but I have yet to find a cheap or open program that will let me record a one hour electronic jam to disk or that can deliver a usable set of tools for mastering. Even the enormous library of free plugins is incomplete. Oddball effects aplenty, but no acceptable compression or reverb. Maybe that is because the math involved is just too difficult for an amateur coder to comprehend, I don't know.

    Then there's the problem of getting applications. If there are none, noone will use it, and noone will develop applications for it if there's noone using it. BeOS is one, notorious example of this (unfortunately. I really, really liked it, but there was nothing I could use it for so it went).

    Also, don't think that millions of hackers will come to your rescue and deliver myriads of elegantly designed drivers and a plethora of killer apps in the same way they helped spread Linux. Your system appeals to a whole different audience (myself, partly, included). "Do you yearn for the days when men were men and wrote their own device drivers?" No, sorry. All I've got is this great idea for a song that I want to record a quick sketch of without having to recompile my kernel before I can do it, thank you. Musicians aren't hackers, even when hackers are musicians they're not terribly interested, apparently, in marrying their two affinities. Witness the almost complete absence of usable audio tools in Linux. Last time I checked, there wasn't even a decent tracker around. (Decent as in - it's at least as good as Impulse Tracker and it doesn't require constant tweaking to be usable).

    Sure, some people cook up interesting gizmo's for Windows and Macs (to a somewhat lesser extent), but these are accidents rather than a well thought out open source revolution. There's usually no plan behind it, just a musician who happens to be able to code, or vice versa, who scratches an itch and gets something going. For a dedicated audio OS, they're useless. They won't join in unless they have a very good reason to. Even the charisma of Linus or RMS wouldn't be sufficient to make this happen.

    There's been tons of people who have *started* to produce some form of an open source soundsystem, but as of yet all these projects have failed. Probably because of the reasons I've just mentioned. Music is a specialized field, as such the userbase is going to be quite small. Having come to the end of all my "buts", let me just say that I *would* be interested in the kind of OS you envision. I just think it's going to be exceptionally difficult to get such a project off the ground. Unfortunately, I can't help you do the coding. Web stuff is pretty much all that's in my toolkit. Optimizing C or C++ most definitely does not form a part of my toolkit. Testing, musician friendly interfaces, the less hardcore stuff, now that I can do, but, though important, this is probably not what is needed at such an early point. In the early phases of development there's going to be more "this driver just made my soundcard explode" problems than "if I set the resonance to 98 and the cutoff to 31, the reverb starts to sound funny".

    Maybe what is needed is for a number of audio minded developers to come together in some way, like a well-advertised website, for example, and start sharing ideas. Get the basic skeleton in place and talk to the people who are currently developing applications for Windows, for example. It's probably going to be a hell of a job, however. Thanks for sharing your ideas, though...much appreciated and enjoyed.

    One last question to end an insanely lengthy mail: what's V2_OS?

    Good luck

  • I have been using helix gnome a little and I like it.
    But I was wondering if anyone know if they
    are taking a shot at making after-install
    configuration of linux any easier?
    like re-configurating X or changing your timezone?
    I know you can run Xconfigurator or whatever but
    it would be really nice to be able to change
    it all from withing Helix Gnome.
    Also.. What is happening with linuxconf?? The last
    time I used it had great potential but was
    a UI nightmare. Are anyone working on
    improving it.. or are anyone making something better??

    I really, really like the way these screenshots look
    but according to the article DnD didn't work
    so they seem to be a bit behind in some areas

    I for one would love to have sucha enviroment on my
    linux workstation, it really *looks* polished..


    "One World, One Web, One Program" - Microsoft Promotional Ad
  • 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!

  • I think much of what you are saying here applies to the old QNX4 kernel. The Realtime Platform release will be using the new Neutrino kernel, which is a very different beast.

    In fact, I was able to build many of the standard UNIX toolsets (shadow utils, bash, textutils, etc) without changing any code after running ./configure.

  • Do the modules run in kernel memory space? If a module decides to play Russian Roulette with pointers, can it take down the whole OS? If so, then it's monolithic.

    Can you debug a device driver by lazily coding it, loading it, testing it, crashing it, fixing it, reloading it, all without having to reboot the kernel?

    It isn't bashing to point out that Linux is monolithic. It's simply a statement of fact. It only becomes bashing in the readers mind, after the reader considers the differences between the two approaches.


    ---

  • It sounds great. No doubt about that. Maybe even worth the price if it really can run Linux binaries through LxRun. I dunno about that, though. What about X11 compatibility? The article claims it has built in X functionality. How complete is this? Could you run heavy duty Linux apps, like StarOffice and Netscape for Linux?

    How difficult would it be to port a heavy duty app - not a small open source app like GNU bash or wget, or GNU tar - but a truly heavy duty application like Apache, or BIND? These are Industrial Strength Apps that people need and use daily, and if they aren't ported....well....(trails off). Yes, I know it's a big ask to port all that stuff. If it did happen, though, QNX would be THE thing.

    Then again, it depends on the cost. While the core OS looks to be industrial strength, if they want too much for it, you might as well stick with FreeBSD or Linux. If the licenses are too Microsoftian, people might shun it no matter how good it is. Open source OS's have raised the stakes. It's no good to have a killer product if you're going to be Microsoftian about it, because the Open Source crowd will eat you for dinner.

    Still, the driver support is exceptional (Supports everything from most PC's I own and work with). It might very well be worth a try - heck, what am I saying. I can't wait to try this thing. But I'm not optimistic. In the end, propreitry software can lead to no good, and lead to Microsoftian pricing structures which just don't make sense. It'll be a fun OS to play with, but if they want too much for its use - Microsoftian pricing - I might as well not bother and just stick to Linux. Really.

  • the QNX advantage (Score:2)

    by Anonymous Coward
    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.
  • 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.

    I think you mean, Yup :->

    What problems did you have doing exactly that? (Well, you would also have had to insert the soundcore module.)
  • Allow me to respectfully disagree with you:

    Comparing MacOS Rebirth to Windows Rebirth simply isn't fair, as the program originated on a Mac, was finetuned for a Mac and never quite adapted well to Windows/Direct X. Compare it to FruityLoops [fruityloops.com] instead. It packs way more functionality in the drum department, a huge number of 303-like devices (pretty good clones, and the amount you can use is only limited by your hardware and eight groups of effects together (plus master group) in realtime, without *any* latency problems.

    I dislike Windows as much as the next guy (really!), as it's unstable, messy and a product of the Evil Empire and all that, but the awful truth is that it's plain better for realtime audio than MacOS. Possibly OS X will put Apple back on track, but for now, they're being surpassed.

    I'd love to use BeOS, though, but I'm not aware of any *serious* *good-quality* music software for it.
  • I never said calling it monolithic was bashing it. I even admitted that yes, the kernel IS monolithic. What I have a problem with is his incorrect blanket statement that makes it seem like you have to recompile the kernel every time you change any hardware. With the exception of some stuff (possibly sound, as was pointed out already), that is simply untrue. In your post, you made some real statements as to why monolithic can be a bad thing. What I object to is the writer's generic, incorrect statement, with little backing and no explanation, which basically seems little more than jumping up and down shouting "ooo ooo bad bad!" If the article had included some of the arguments you made, I would have had no problem with it. YOUR Post is a statement of fact. The author's is a statement of FUD
  • You may be right. But when I'm writing music software I would like to be able to guarantee the latencies for the user. One glitch is too many! Windows is not architected for glitch-free low-latency playback (mind you, neither is the MacOS!) Your playback could suddenly go to pot if, say, someone opened a network port on your machine. Not to mention the problems if the disk thrashes. I guess for synthesis this is acceptable, but for processing (i.e. take a LIVE audio input and process it; maybe save it to disk) none of these OSes are up to the job.

    Except, perhaps, BeOS ... but I have only "heard good things" about BeOS, and never actually tried it out.

  • My money is on BeOS.

    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?

  • No respectful disagreements this time. Yes, neither Windows nor MacOS is really good, but one is worse than the other. For synthesis, Windows is fine. It involves no syncing, just playback and number crunching and you don't really notice it if tiny deviations occur. I'll be the first to agree with you, however, that harddisk recording is somewhat of a problem. I once recorded some vocals over an existing track and the recording process slowed down the playback process, making the singer out of sync with the preconstructed bits. Nasty as f***. Maybe, though, the problem is with current hardware. If your disks get faster, possibly the problem would go away by the time MacOS XX or Windows 3000 comes out. I don't know of *any* system where harddisk recording works. Even dedicated stand-alone recording devices such as the Roland VS series can't do it without data compression (ughh).
  • The Nord Modular doesn't do the actual synthesis in software, though. It uses a number of dedicated dsp chips for. You only use the GUI to put together the patches, which then get stored on the chips. There's not much that's time critical about that.

    It's a really cool system, btw, and the fileformat for the patches is public, so nothing's stopping you from writing a gui frontend for Linux. If I'm not mistaken, someone wrote a PalmOS version as well.

  • Re:the QNX advantage (Score:3)

    by GypC ( 7592 ) on Monday August 28, 2000 @01:17PM (#821817) Homepage Journal

    Pantsless reboots? Oh man... I'm so there!

    "Free your mind and your ass will follow"

  • I run plenty of modules on my system that are not in the kernel. I thought compiling your own kernel was one of the best things ABOUT linux.

    First, you're getting the kernel modules with the pluggable service model of the microkernels mixed up. In the Linux module world, all the modules run in kernel space, but in a microkernel, a fair bit of the services run in user space. Take, for example, mkLinux. The "hardware" that mkLinux runs on is the Mach Microkernel. All the hardware drivers and other system-specific bits and bobs have been rewritten to use the Mach services instead. Rip out the memory manager (because that's Mach's job, not the Linux service's), and you have an oversimplified view of mkLinux, where the Linux "service" runs in user space.

    You can compile your own kernel in other unices too. Granted, you won't compile from the source, but both BSDI and SunOS 4 will let you compile the kernel mainly from object files, and all that. Most commercial unices now don't come with this feature out of the box, because it's an expensive-add-on-feature.


    --
  • Not really. By the looks of the review, it seems to be quite a competitor to Linux and Be on the desktop level. I mean just because it is fast/light (as if that precluded it from being a desktop OS.) Doesn't mean that it should be limited only to embedded platforms. I mean this WAS going to be the next Amiga OS you know.
  • A real-time operating system is an operating system that can offer guarantees about the scheduling of processes.

    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.

  • Exactly WHY wouldn't you want to give up Linux in favor of this?

    Well, more software and support, for starters. From what I see, (And as they state) this isn't intended to become a desktop standard OS, by any means -- rather, it will fill a small niche. As so, developers will probably stick to their traditional platforms. And of course, perhaps this will be a kick in the pants to the Linux folk ... Nothing better than competition to spur development.

    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?

    I personally love it. Now, I'm a console kind of guy ... always booted to DOS back in my Windows days, and didn't even install X. (Partly because I'm using old hardware, partly because I didn't want it.) However, there are a few things that really need a GUI, and non-X based graphics is an iffy thing on most systems. In these cases, the sheer bloat and occasional strangeness of X makes me shudder. If this GUI is good and fast (I can't really speak with authority, but if their claims are any indication, these people know what speed means) I say port it and make it a standard. Sounds great to me :)

  • No it's that most of us Linux users *DON'T CARE* all that much about the desktop market

    You make it seem as though "most of us Linux users" are running servers. We're not.
    Besides, if "most of us Linux users" don't care about the desktop market, why is so much attention being paid to desktop-candy?

  • uh, what? Above you accuse BeNews of being clueless, and now you display your own ignorance by saying that the Video Toaster killed the Amiga? Dude...
  • Actually, the Mac has pretty well defined keyboard accessibility also. I don't like using it as much as Windows, but it is there, and it is a standard.
  • they may support tons of video/sound/etc hardware, but to not have 3Com networking cards natively supported, what do they plan to accomplish? I have at least 10 3Com network cards (in addition to Western Digital and DLINK, etc).

    I give great props for the opening of the OS to the public for free, and I see great things in the future for QNX, but just as Linux was lacking greatly in the driver dept, QNX is lightyears behind :(
  • Be IPO'd with a stockprice of $6, has been in the $3 range, and all the industry "experts" such as your distinguished self have predicted the imminent downfall of Be for years. Yet it still hasn't happened.
  • Fix the versioning problem. If the binary standard changes every kernel version, then I can't be expected to use binary, pre-compiled modules

    That would mean interfaces written in stone, and layers for backwards compatibility. There are some advantages in doing this from a module developer standpoint. As a drawback, this also means that if something crappy slips into the kernel, or if you don't get the design absolutely right the very first time, it won't ever get out... and this also mean additional work for kernel-developers. It just doesn't work this way.

    But then, there are already pretty solutions out there. See how VMWare compiles and installs its kernel modules as needed, for instance: you have a "glue" layer between the kernel and the real code. All kernel dependencies are put in the "glue" layer, VMWare's people mantain it as kernel changes and there's a script (IIRC, launchable from within VMWare with no more than a... mouseclick) that recompiles and installs the module for your current kernel.

    Fact: 99% of people CANNOT figure out modules.conf

    And here I agree with you. The problem exists, and some effort has been spent on 2.4.x kernels, which are definitively smarter on this. Of course, don't expect a GUI in the kernel for configuring the parameters that cannot be guessed at all. But expect an administrative GUI in userspace (like LinuxConf, or such).

    can detect hardware and install it without any knowledge on the users part

    Installers are used at installing time -> Linux needs good installers (RH 6.2 installer seems to be on the right direction - to be conservative). But then, let's have a look: how would I expect, say, my mom to install a new hard disk? Probably she'd ask someone more expert even if the installation procedure was absolutely foolproof.

  • Sure, and people will actually buy a new harddrive and install QNX on it to watch DVD, instead of buying a $180 DVD/CD/MP3 player at Fry's that requires no installation or maintenance, works with their TV, and comes with a remote control.
  • According to the site it will come with demos for Q3, UT and Redline Racer. It also comes with Renderware 3 which would allow for some cool games to be built. This has possiblities for console type systems. Add in the DVD plugin and it could be a versatile gaming platform. This all depends on the developers liking it and picking it up. BeOS seemed to be helped some by releasing but not as much as they hoped at least yet (we will see). I hope QNX gets a big shot in the arm from this. I can't wait to see how this will work on older hardware like my old 486 Thinkpad. Might be a nice little setup
  • I realize that Linux is monolithic, and I also realize that some things DO require a recompile, and that the modules aren't the end-all solution. I appreciate your clarification of the issue, because it was a thought out statement about how things are structured. The BeNews article had more of a FUD-like tone to it. It made a grossly inaccurate blanket statement, which, while having some grains of truth, was far from giving the whole picture, and was said in a way that it came across as more of a bash towards linux, rather than any discussion of the technical merits of QNX. Instead of being "wow, QNX can do some neat stuff!", It was more like "ooo ooo ooo look how much linux stinks, you shouldnt use it!" I for one wish more people would be like you, discussing technical issues for what they are, and not letting personal preference weigh the tone of their words.
  • Sjeesh man, if you want to spread FUD, at least get some of the basic facts straight. You made at least 3 significant mistakes in your reasoning:
    • "library namespace" isn't an issue here. For one thing a namespace has nothing to with it, and the issue at hand is about add-ons, not libraries (there is a subtle distinction in BeOS).
    • It is perfectly possible to LINK mozilla under BeOS, it just won't RUN since it can't load all of its add-ons (BTW, I wouldn't call 50 megs of add-ons "non-trivial", I'd describe it as "bloated").
    • It is perfectly possible to get Mozilla to run on BeOS, since the 32 meg limit applies only to add-ons, not to libraries. By *really* linking against these add-ons (they are required anyway, so it doesn't really make a difference), you can have Mozilla run on BeOS.
    Next time you post, don't make such an ass of yourself.
  • There is full support for the 90X series of 3COM cards as well as the 5X9 cards. This pretty much covers every 3COM card made in the last several years.


  • You are runing it? I enlisted as soon as they announced that there would be a free developer version. I've been waiting ever since. Were you among the first lucky ones to get the CD?.. :) .. Since it's free do you think it would be elegal to put an ISO image on some FTP?.. I'd love that..

    Thank you.
    //Frisco
    --
    "No se rinde el gallo rojo, sólo cuando ya está muerto."

  • 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

  • Free? (Score:1)

    by cvore ( 178992 )
    I just had to point out that the QNX kernel is free as in beer, not as in speach. The kernel is not free software, or even open software. "Besides making QNX free for non-commercial use, QNX also provides source code for most components - drivers, protocol managers, and so on. Only the kernel and other core portions of the QNX platform remain protected" Look at other closed source microkernel OSes like windows NT: Gnu/Linux, that is freesource/opensource. If one finds a bug in the kernel, you fix it. :-) I don't feel its right to clain that QNX is "open in all the right places". Though its a nice step forward. Realtime microkernels are cool, though I don't feel a desktop don't realy need the realtime part.

  • Re:Oh my! (Score:1)

    by pen ( 7191 )
    The MacOS keyboard accessibility is as defined as it is limited. While there is a set of standard-throughout-everything shortcuts, they only cover a small part of the functionality. For example, I cannot run a menu (that doesn't have a preset shortcut key) or push a button with the keyboard. Heck, I can't even select text in a textbox without the mouse.

    OTOH, the standardization of everything in MacOS is unlike anything else I've ever seen. Every version includes some new improvements, like the keychain that can be used from any program. Clearly defined APIs allow anyone to implement something in their program without having to rewrite it. This is sort of like what Microsoft tries to do -- only it works much better.

    --

  • 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.
    ----------------------------
  • Actually, the impression I got on the Hurd web page is the microkernel architecture is a problem for apps written to work on a monolithic kernel (like most unices, especially Linux). So there are enough GNU utils that make it useable, but not important things like Quake ;)

    Of course, I'm not involved with HURD in any way outside of having done a bit of microkernel research, so I can't say for sure how well the project is going.

    Anyways, I think that's all I'll say on this before I get modded 'off-topic'.
  • 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?
  • 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.
  • 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.
  • You know what? It sounds like there's really a niche for really high-quality sound synthesis and processing software. Maybe someone should write a special-purpose OS just for this? They could fork the Linux tree for the low-level "getting the machine up" stuff and just write basic drivers for SVGA, SB16, IDE and SCSI which would kick the crap out of what can be done on any of Linux, MacOS or Windows.
  • 1 - You seem biased against VxWorks, did you have a bad experience with it?

    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 /.'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.
    ----------------------------

  • I Agree With The Article (Score:3)

    by Phrogman ( 80473 ) on Monday August 28, 2000 @07:36AM (#821854)

    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 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.

Slashdot Top Deals

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

Close