greenboy wrote:
Floid : QNX doesn't do the impossible with low mem. I forget the requirements for the demo disk, but they must've been at least 8MB, and it's no longer offered.
Hi Floid,
That's because it used QNX's 4.x-lineage products, which since early Phoenix days have been surpassed by the 6.x stuff. Incidentally, the reason this would even require 8 megabytes was for browser caches. I think the demo would run in considerably less though (4 meg I think, but it's been so long since I read about the QNX 4.25 demo and then tried it...)
There were people developing QNX-based products that used less - bring what ya need and leave the rest at home ; } ...There are and have been embedded products that ran in less of course, but these were based on some pretty limited OSes - some really had little that could be called an OS.
Yep, and I oversimplified. I can't remember if I managed to find pages that would overload the browser, because my most vivid memory is unfortunately a lack of support for the keyboard in my particular 486! (Random chipset incompatibility, doubtless another reason ATX-era hardware is now recommended.)
There were more than a few people in Phoenix who got useable systems running in 16 meg (first place to check is buffers and cache defaults, then find the libraries you might never require, etc), some that got it down to running in 8 - and I think a couple of QNX vets got it running in 4 (still with the Photon MicroGUI, I believe!) ... So, even sophisticated products can definitely run on modest Flash - and that's with an OS that has way more services than the old, simpler 4.x microkernel and process manager, etc.
Hmm, I wish they'd told me.
(Note that I did write a quick HOWTO based on what cam? told me that may still be archived somewhere on the QNX.com newsgroups.)
But yes, it can be done. With my buffers trimmed, I personally found Photon + Voyager + Shelf just a hair bulkier than I would've liked, to be comfortable within my constraints, with the features I wanted enabled... But that was because I'm a gimp, and every time I added more RAM, I wanted to *do* more! (I don't think I ever got to the point of figuring out which libraries could be weeded.)
Once I threw 128MB in, it became a nonissue anyway. I'm holding a grudge over grandmother's iOpener, but that's not QSSL's fault, and there's not much anyone can do about that (unless I get off my butt and clone the interface under QNX6 with the Opera server)...
The point I was trying to get at is, of course, that the RtP and followon distributions are 'development' platforms, as claimed - you don't dump them on a machine and get a browser running in 1MB on a 386SX any more than you dump OpenBSD on a machine and get 'instant security.' (Well, okay, bad example, given 'Secure by Default,' but hopefully someone gets my point.) They do, however, make life a lot easier if you're willing to put the thought into it!
You mention Momentics: As you surmise Momentics itself is the offspring of RtP, essentially being a developers' desktop complete with the GNU toolchain and a fair number of other facilities for development and personal use, has generous buffer defaults, etc. This makes it possible to comfortably design, self-hosted with QNX, for products that run in a lot tighter space - targetting multiple architecures with runtimes, natch - which I still think is the superior way to painlessly have top performance on many processor architectures.
Sure works great for embedded applications. Not the quite the same market as what some of us hoped the DE would be, of course, since with general-purpose software, you're still at the mercy of the developers, rather than the marketers of the runtime.
Any cool design wins lately?
(The "pro" version adds Eclipse IDE with extensive third-party tools, really deep systems analysis tools, custom libraries for embedded work, and lots of othjer goodies).
Sweet; last time I dropped by on IRC, the port was in progress, and the 'community' sites were shuffling, so I couldn't keep track. Freebie developers still have to live with vi?
...Anyway, it's incredible what they've achieved in a few short years - but back to the memory requirements issue: as RtP (QNX6) alphas and beta progressed it became obvious that people were wanting more more more and that the price of memory and storage was becoming cheap enough to design cost-competitive products with greater features and facility. QSSL even pretty much shelved the non-MMU version, offering it only as custom work, since the median architecture for their OS was logically more sophisticated anyway.
That's been a better move than anyone could probably have expected. I'm counting down the weeks until we see a watch with a Geode in it.
For those who haven't been watching, today's problem is figuring out what to *do* with all this cheap memory. Other than bloat Office another 500MB.
Taking this back to AOS4 (or my fave before even QNX, MorphOS), it's indeed as you've said: we DO want more more more and it takes more space to do that. But really (and thus the lengthy QNX talk here) these OSes are probably in no danger of becoming bloated and slow by ruling desktop-OS standards. It's just a natural progression, with a little extra "weight" there to serve legacy needs.
Exactly. When it's no cheaper to use a PIC than the practical equivalent of a workstation from a few years ago... then it's time to figure out how to make that complexity work for us (modular OSes, 'safe' languages, rapid-development systems), not against us (Windows CE?).
So what does MorphOS have going for it over QNX? :-D
