QNX vs Linux
Dolf van Mil
Hello,
we have a discussion over here concerning the difference between QNX and
Linux.
The questions in this discussion :
Why should I use QNX and not Linux.
Why should I use Linux and not QNX.
Can someone give me the answer or a direction on these questions?
Thanx in advance...
Dolf
Ziemek Borowski
Fri, 31 Oct 1997 13:05:01 +0100, Dolf van Mil na comp.os.linux.misc
wrote:
Its quite good system (You of course saw demo from http://www.qnx.com/
?
>Why should I use Linux and not QNX.
becouse its GNU and Unix ;-)
--
Ziemek Borowski
Dan Hildebrand
In article <3459C96C...@schmit.nl>, Dolf van Mil <do...@schmit.nl> wrote:
>Hello,
>we have a discussion over here concerning the difference between QNX and
>Linux.
>The questions in this discussion :
Can you describe your project in a little more detail? There are lots of
differences, and rather than attempting to catalog them all it might be
more productive to talk about the differences that will matter most to your
application.
--
Dan Hildebrand (da...@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: +1 (613) 591-0931 Kanata, Ontario, Canada
fax: +1 (613) 591-3579 K2M 1W8
Anyone for thermonuclear tennis?
On Fri, 31 Oct 1997 13:05:01 +0100, a small green fish snuck into
Dolf van Mil's internet account in order to express the following:
> we have a discussion over here concerning the difference between QNX and
> Linux.
> The questions in this discussion :
> Why should I use QNX and not Linux.
> Why should I use Linux and not QNX.
> Can someone give me the answer or a direction on these questions?
What are you going to use one or the other for?
It helps if we know what the system needs to do,
otherwise any recommendation is of questionable
value at best.
Jerry Hicks
Ziemek Borowski wrote:
>
> Fri, 31 Oct 1997 13:05:01 +0100, Dolf van Mil na comp.os.linux.misc
> wrote:
>
> >Why should I use Linux and not QNX.
For Unix applications, we prefer FreeBSD.
>
> --
> Ziemek Borowski
--
Jerry Hicks
jerry...@bigfoot.com
Dan Hildebrand
In article <slrn65jqvd.275....@linux.ceu.edu.pl>,
Ziemek Borowski <ziemek....@ziembor.waw.pl> wrote:
>Fri, 31 Oct 1997 13:05:01 +0100, Dolf van Mil na comp.os.linux.misc
>wrote:
>>Why should I use QNX and not Linux.
Hey now, if QNX is being built into televisions and set top boxes it can't
be that expensive. :-)
On the other hand, while Linux is essentially free to acquire and deploy,
when you're developing a project the cost of development tools is
insignificant compared to the salaries of the development team, the cost of
the manufacturing facility, marketing efforts for the new product, etc.
Cost of development tools isn't the overwhelming factor. Issues like time
to market and basic product capabilities are more important (still, QNX
development systems cost less than those of many of the other realtime
OS's).
>Its quite good system (You of course saw demo from http://www.qnx.com/
>?
>
>>Why should I use Linux and not QNX.
>becouse its GNU and Unix ;-)
GNU packages port and run on QNX as well. :-)
Dolf van mil
Dan Hildebrand wrote:
>
> In article <3459C96C...@schmit.nl>, Dolf van Mil <do...@schmit.nl> wrote:
> >Hello,
> >Linux.
> >The questions in this discussion :
>
> differences, and rather than attempting to catalog them all it might be
> more productive to talk about the differences that will matter most to your
> application.
> Dan Hildebrand (da...@qnx.com) QNX Software Systems, Ltd.
> http://www.qnx.com/~danh 175 Terence Matthews
> phone: +1 (613) 591-0931 Kanata, Ontario, Canada
> fax: +1 (613) 591-3579 K2M 1W8
--
We are planning to develop a access control / security system based on
personal identification. So we need to read a card / badge, send the
cardnumber cq status to a host system and open a door or something like
that if the card is okay. This is not all of the system, but gives a
basic knowlede of the project. The system has to be very easy to service
/ update. We want to run several processes the same time.( if we change
a display, we only have to kill&reboot / update the display process )
I hope that there is enough information avalible to give a better
answer.
Thanx in advance...
Dolf...
=====================================
Dolf van Mil
HTTP://www.cistron.nl/~dolfvmil
======================================
Jerry Hicks
> We are planning to develop a access control / security system based on
> personal identification. So we need to read a card / badge, send the
> cardnumber cq status to a host system and open a door or something like
> that if the card is okay. This is not all of the system, but gives a
> basic knowlede of the project. The system has to be very easy to service
> / update. We want to run several processes the same time.( if we change
> a display, we only have to kill&reboot / update the display process )
>
> I hope that there is enough information avalible to give a better
> answer.
>
> Thanx in advance...
>
> Dolf...
>
> =====================================
> Dolf van Mil
> HTTP://www.cistron.nl/~dolfvmil
> ======================================
QNX on a single-board computer, diskless with flash. Piece of cake.
Overall reliability of such a configuration is probably best served with
QNX; since a much smaller footprint is required for the OS, fewer
components are needed as well.
Although Linux can be configured for a flash boot, it's hardly
mainstream practice for that OS. It will most certainly require some
kernel level development and (dis)ingenious arrangement of the files to
facilitate serviceability. Then tracking the patches and updates for
Linux, field upgrades... Not for me, YMMV.
For QNX on the other hand, these areas are their strong suite. I have
been through embedding a not-so-trivial application (see
http://www.celcore.com) into flash. There is no other OS of any sort
which comes close to the support offered by QNX for these applications.
QNX has good partnership relations with hardware vendors such as ZiaTech
which are proactive in providing flash support for QNX.
End-to-end, QNX would be my choice for your application.
Good Luck,
Jerry Hicks
jerry...@bigfoot.com
Frank Miles
In article <3459C96C...@schmit.nl>, Dolf van Mil <do...@schmit.nl> wrote:
>Hello,
>we have a discussion over here concerning the difference between QNX and
>Linux.
>The questions in this discussion :
>Why should I use QNX and not Linux.
>Why should I use Linux and not QNX.
>Can someone give me the answer or a direction on these questions?
One nice thing about QNX is that you can get the Watcom compiler/debugger
for it. GCC/GDB are nice but for me are lacking in some important
capabilities. Hopefully these deficiencies will be fixed soon...
If you are developing in something other than C++, ignore this comment.
-frank
(I switch between OS/2 and Linux, often developing under OS/2
using Watcom, then porting to Linux, if possible).
Dan Hildebrand
In article <3459F8...@cistron.nl>,
Dolf van mil <dolf...@cistron.nl> wrote:
>Dan Hildebrand wrote:
>>
>> In article <3459C96C...@schmit.nl>, Dolf van Mil <do...@schmit.nl> wrote:
>> >Hello,
>> >we have a discussion over here concerning the difference between QNX and
>> >Linux.
>> >The questions in this discussion :
>> >Why should I use QNX and not Linux.
>> >Why should I use Linux and not QNX.
>> >Can someone give me the answer or a direction on these questions?
>>
>> differences, and rather than attempting to catalog them all it might be
>> more productive to talk about the differences that will matter most to your
>> application.
>
>personal identification.
There certainly are a lot of security systems built with QNX. :-)
1. Norad missile bases
2. Desert storm perimeter alarm systems
3. Several commercial security firms (the big names in the business)
4. Several prison-wide security systems (sliding doors, cameras, etc)
5. Lots and lots of smaller systems. I'm sure other QNX users will
jump in here to describe them.
Device drivers for most of the necessary hardware is available through
various third parties (zoom/pan camera control, etc).
>So we need to read a card / badge, send the
>cardnumber cq status to a host system and open a door or something like
>that if the card is okay.
Does QNX need to run a each access point, or would you have less
intelligent peripherals at the doors networked to a central control system?
Do you need a GUI at each access point? Or only at the central control
screen? Do you want to run a bank of video monitors from a single CPU? Do
you need a hot standby node to survive various hardware failure modes in
the primary controller?
>This is not all of the system, but gives a
>basic knowlede of the project. The system has to be very easy to service
>/ update. We want to run several processes the same time.( if we change
>a display, we only have to kill&reboot / update the display process )
No sweat. You can replace most of the components of a running QNX system
(including networking, filesystems, GUIs, etc) on the fly without
resetting.
>I hope that there is enough information avalible to give a better
>answer.
It's a start. :-)
Frank Miles
In article <345A09...@xedia.com>, Paul Koning <pko...@xedia.com> wrote:
>Frank Miles wrote:
>> One nice thing about QNX is that you can get the Watcom compiler/debugger
>> for it. GCC/GDB are nice but for me are lacking in some important
>> capabilities.
>
>
> paul
Nothing fancy. Mostly, being able to inspect local data variables
_reliably_. Not even moving all declarations to the top of functions
(as has been recommended in the past) seems to fix this problem).
Since ddd and xgdb are based on gdb, these fail too. I presume this
works in 'C'.
I'd also like to be able to source-level debug into libs, but AFAIK
Watcom doesn't do this either.
Clearly there are some powerful features in gdb, but there are deficiencies
too.
-frank
Paul Koning
Igor N Kovalenko
Dan Hildebrand <da...@qnx.com> wrote in article <63d5ak$u...@qnx.com>...
> In article <slrn65jqvd.275....@linux.ceu.edu.pl>,
> Ziemek Borowski <ziemek....@ziembor.waw.pl> wrote:
> >Fri, 31 Oct 1997 13:05:01 +0100, Dolf van Mil na comp.os.linux.misc
> >wrote:
>
> when you're developing a project the cost of development tools is
> insignificant compared to the salaries of the development team, the cost
of
> the manufacturing facility, marketing efforts for the new product, etc.
True, but you guys always forget that someone must find that 'development
team' first. It is damn hard for QNX, due to high price of development
tools. Programmers are not going to spend so much money just to learn QNX.
And companies are not going to buy QNX due to lack of qualified
programmers.
The only way to break this infinite loop is cheap and highly available
educational program. One which you have does not work, because it is not
that cheap and it is not that available at all. It must be accessible for
any individual programmer.
> Cost of development tools isn't the overwhelming factor. Issues like
time
> to market and basic product capabilities are more important (still, QNX
> development systems cost less than those of many of the other realtime
> OS's).
>
Because other realtine OS's vendors do the same error, just worse. This is
not excuse IMHO.
> >Its quite good system (You of course saw demo from http://www.qnx.com/
> >?
> >
> >>Why should I use Linux and not QNX.
> >becouse its GNU and Unix ;-)
>
> GNU packages port and run on QNX as well. :-)
>
Sometimes...
Please, try XFree86 or just mSQL 2.0 ;-)
--
Igor Kovalenko
Dolf van mil
Dan Hildebrand wrote:
%<------------%< Stripped all the old stuff ;o)
>
> Does QNX need to run a each access point, or would you have less
> intelligent peripherals at the doors networked to a central control system?
> Do you need a GUI at each access point? Or only at the central control
> screen? Do you want to run a bank of video monitors from a single CPU? Do
> you need a hot standby node to survive various hardware failure modes in
> the primary controller?
>
We have several access points and we have to communicate with a host
system.
With the other question in this section you set me thinking. ;o)
>
> >This is not all of the system, but gives a
> >basic knowlede of the project. The system has to be very easy to service
> >/ update. We want to run several processes the same time.( if we change
> >a display, we only have to kill&reboot / update the display process )
>
> No sweat. You can replace most of the components of a running QNX system
> (including networking, filesystems, GUIs, etc) on the fly without
> resetting.
>
Thats what i like.....
> >I hope that there is enough information avalible to give a better
> >answer.
>
> It's a start. :-)
Well no hard feelings.. but i'm ( we are ) not going to type the
complete concept on the internet. Just give some basic information.
> --
> Dan Hildebrand (da...@qnx.com) QNX Software Systems, Ltd.
> http://www.qnx.com/~danh 175 Terence Matthews
> phone: +1 (613) 591-0931 Kanata, Ontario, Canada
> fax: +1 (613) 591-3579 K2M 1W8
--
Okay, anyway thanx for reacting...
Greeting Dolf..
=====================================
Windows loaded : system unstable
Dolf van mil
http://dolfvmil.www.cistron.nl/
======================================
Frank Miles
In article <63fud0$j1h$1...@news.pt.lu>, Alain Knaff <,> wrote:
>In <63d7f2$p0m$1...@nntp6.u.washington.edu>,
>Frank Miles <f...@u.washington.edu> wrote:
> >
> >Nothing fancy. Mostly, being able to inspect local data variables
> >_reliably_.
>
>due to optimization: if a variable is only used in a small part of a
>function, then its storage space may be used for other variables when
>the code is outside this part. In this situation you cannot inspect
>the variable when you're before the first assignment to it, or after
>the last read from it. Turning off optimization may fix this problem.
The problem persists, even with no optimization. Others have had this
problem too, just check out dejanews if you don't believe me. It is
unpredictable as to what variables will be afflicted (at least, I have
yet to detect any pattern). Maybe it goes away in C without optimization;
that's not always the case in C++.
> >I'd also like to be able to source-level debug into libs, but AFAIK
> >Watcom doesn't do this either.
>
> Gdb does this source level library debug, if you compiled your libs
>with the -g option, and if you have the source around.
This is fairly flakey, IMHO. It "sorta" works, but trying to single-step
can be erratic. At least with the libs I've tried to build. I generally
end up having to separately compile and do a direct link. Annoying and
time consuming -- but not as bad as the previous problem.
I'd like to be able to shift more completely to Linux, but for right now
the lack of something better than the current gdb is one of the barriers.
I take the responses so far to mean: no, there's no immediate prospect
of a replacement to, or improved version of, gdb.
-frank
George Henry C. Daswani
: True, but you guys always forget that someone must find that 'development
: team' first. It is damn hard for QNX, due to high price of development
: tools. Programmers are not going to spend so much money just to learn QNX.
: And companies are not going to buy QNX due to lack of qualified
: programmers.
That and the watcom manuals are hundreds of dollars a set.
Bullshit..
How about things like "unable to get kernel thread" when compiling
large apps. Oh yeah, I guess qnx blames that on nameloc..
How about the piss poor 3c509 drivers that basically leaves the network
manager in an adhoc state after running it for a while?
How about the piss poor quality of QNX windows? What about localized
support for QNX Windows? Oh yeah, I guess you WANT somebody
to port years of work to photon instead.
How about the NFS caching bug introduced in QNX 4.23A and the
socket patch is still in ALPHA! - a lot of qnx software doesn't
seem to leave the alpha/beta stage. I guess we can just upgrade
to 4.24 instead and throw away months of validation work.
: > >Its quite good system (You of course saw demo from http://www.qnx.com/
: > >?
Hmmmm, I've been supporting QNX on a software development setting and
I find LINUX a much more reliable system for software development.
(PERSONAL OPINION).
The demo doesn't mean anything considering that it's not what you
encounter in real life IMHO.
: > GNU packages port and run on QNX as well. :-)
: >
: Sometimes...
: Please, try XFree86 or just mSQL 2.0 ;-)
Heck, even something simpler like rdist! or bringing things
like POSIX threads to QNX 4.2X? How about implementing SYS V
IPC instead of that proprietary message passing? Or how about
implementing other services like NIS support?
Why does QNX keep on trying to compare themselves to Linux?
Instead of wasting time in the newsgroups comparing linux to
qnx, they should actually try to start implementing things
like POSIX Threads, porting XFree86 to QNX and etc.
George Daswani
Beckman Coulter Inc - DDC Software Dvelopment Tools
gdas...@tofu.dse.beckman.com
----- I DON'T SPEAK FOR BECKMAN COULTER - ONLY FOR MYSELF -------
Alain Knaff
>(as has been recommended in the past) seems to fix this problem).
>Since ddd and xgdb are based on gdb, these fail too. I presume this
>works in 'C'.
The problem also happens in 'C' (maybe more rarely). In 'C', it is
due to optimization: if a variable is only used in a small part of a
function, then its storage space may be used for other variables when
the code is outside this part. In this situation you cannot inspect
the variable when you're before the first assignment to it, or after
the last read from it. Turning off optimization may fix this problem.
>I'd also like to be able to source-level debug into libs, but AFAIK
>Watcom doesn't do this either.
Gdb does this source level library debug, if you compiled your libs
with the -g option, and if you have the source around.
>
>Clearly there are some powerful features in gdb, but there are deficiencies
>too.
>
> -frank
>
--
Linux - Why use Windows, since there is a door?
Alain
Igor N Kovalenko
Hey, I see there is a guy who has more complains than even me! :-)
But some of them looks a bit unjustified, even for me :~|
George Henry C. Daswani <gdas...@Deals.odc.net> wrote in article
<63eu40$mt4$1...@holocron.odc.net>...
> How about things like "unable to get kernel thread" when compiling
> large apps. Oh yeah, I guess qnx blames that on nameloc..
>
I also like another one: "resource temporarily unavailable".
But note also (to recall the subject of thread) that Linux VM is not
shining one either. You can get something like "Can't get free page" there.
> How about the piss poor 3c509 drivers that basically leaves the network
> manager in an adhoc state after running it for a while?
>
Ehh... How about piss poor crap known as 3c509 NIC?
Yes, it seems to work with other OS (including Linux), but they don't do
fault-tolerant networking with load balancing and transparent brouting...
Note also that Linux support for other popular NICs (e.g., Tulip) was quite
crappy for a long time either.
Some time ago I used to argue that 3c509 must be supported by QNX, but it
can't work better than it designed. Note also, that it was not really
supported until QNX 4.24.
> How about the piss poor quality of QNX windows? What about localized
> support for QNX Windows? Oh yeah, I guess you WANT somebody
> to port years of work to photon instead.
>
World is full of piss poor apps, written for quite powerful systems. People
often like to blame a system when they don't really know it for enough
extent. This may be not your case, but I developed some apps for QNX
Windows and don't think it is poor piss, although there are some problems,
of course.
> How about the NFS caching bug introduced in QNX 4.23A and the
> socket patch is still in ALPHA! - a lot of qnx software doesn't
> seem to leave the alpha/beta stage.
Yup, here I agree - their NFS is poor, at least because they don't support
access control in exports.
In other hand, Linux is permanent beta, is not it? And FreeBSD has much
better NFS than Linux isn't it :-) Everything is relative ...
> I guess we can just upgrade
> to 4.24 instead and throw away months of validation work.
>
Good idea.
> : > >Its quite good system (You of course saw demo from
http://www.qnx.com/
> : > >?
>
> Hmmmm, I've been supporting QNX on a software development setting and
> I find LINUX a much more reliable system for software development.
> (PERSONAL OPINION).
>
QNX is good enough too, except for lack of choice for tools. The problem
IMHO is that QSSL does some chaotic steps, which does not inspire people to
develop them.
E.g., they always advertized QNX as self-hosted system, which eliminates
cross-development. Ok, now they advertize cross-development system for NT.
Who will write (or even port) dev. tools to QNX then?
Next, they going to release Willows, what will allow to use Win32 (may be)
to develop QNX apps (likely under Windows). Who will use (or just bother to
learn) QNX/Photon API then?
We never know which step they will do next, nor even in which direction...
> The demo doesn't mean anything considering that it's not what you
> encounter in real life IMHO.
>
Here we may have a chance, according to some rumor...
> : > GNU packages port and run on QNX as well. :-)
> : >
>
> : Sometimes...
> : Please, try XFree86 or just mSQL 2.0 ;-)
>
> Heck, even something simpler like rdist! or bringing things
> like POSIX threads to QNX 4.2X?
I think they will do it very soon. May be already doing...
> How about implementing SYS V
> IPC instead of that proprietary message passing?
SYS V IPC can be a complement, but not replacement. I think lack of memory
mapped files prevents this so far...
QNX also does support POSIX messages, but this is what is really poor piss
:~|
> Or how about
> implementing other services like NIS support?
>
Don't think this is important, although Sun fans may think differently.
> Why does QNX keep on trying to compare themselves to Linux?
> Instead of wasting time in the newsgroups comparing linux to
> qnx, they should actually try to start implementing things
> like POSIX Threads, porting XFree86 to QNX and etc.
>
QNX and Linux developed using very different development model. A small
team of engineers develop QNX, but this model works well as long as members
of this team know what they going to do very well. But this can't be true
for wide range of features.
Linux has advantage of distributed development, what allows each feature to
be implemented by programmers, who knows appropriate things best. So, Linux
being developed faster and this will be true in future too.
QNX can compete with Linux, despite of high price, because it was designed
for different purposes. And it serves its purposes quite well so far. But
certainly, QSSL will never have easy life if they want to stay in
business...
Good luck to them, and to us :-)
---
Igor
Jerry Hicks
Richard Steiner wrote:
>
> Here in comp.os.linux.misc, Dolf van Mil <do...@schmit.nl>
> spake unto us, saying:
>
> >Hello,
> >we have a discussion over here concerning the difference between QNX and
> >Linux.
> >The questions in this discussion :
>
> I'm given to understand) for the home user, whereas Linux is not. And
> Linux has a much larger program base at this point in time, though I
> think many GNU programs have been ported to QNX.
>
> Personally I think the single-diskette QNX demo is neat, but until the
> OS is available at a price point that I as a home user can afford, it
> might as well not exist.
>
> --
> -Rich Steiner >>>---> rste...@skypoint.com >>>---> Bloomington, MN
> OS/2 Warp 4 + Linux + Executor = PC Hobbyist Heaven!
> The Theorem Theorem: If If, Then Then.
Good observations Rich... except for a couple :)
It exists because for some applications (real-time PC based) QNX remains
the best, most popular, and inexpensive solution. It also exists
because of a fiercely loyal customer base; many have been working with
the company for over a decade. You don't keep customers around like
that for no reason. I received exceptional support from their sales,
marketing, and technical staff, end-to-end until our products shipped.
Celcore (http://www.celcore.com) likely would have never made it without
their help. In truth, the partnership QNX has with ZiaTech (our hardware
vendor) insured that we got an extremely stable microkernel with
guaranteed hardware compatibility and robustness.
QNX is definitely a commercial product, for commercial developers,
although they do have a very good discounting program for educational
institutions. Since the products are available unbundled, with modular
pricing, a run-time system can be delivered quite inexpensively.
The architecture of Photon is certainly worthy of study outside of the
QNX domain. It has been acknowledged to be one of the most significant
GUI designs ever implemented. I am very impressed with the technology.
The marketing however...
The few people I've met who have been disappointed with QNX have tried
to treat it as though it were Unix. QNX is *not* Unix, nor does it
purport to be. In developing real-time applications on QNX, this is
important to remember. It's a microkernel, a real one.
Even so, it can perform many of the tasks Unix does very well. We use
FreeBSD in conjunction with QNX to round out a really nice development
environment for real-time applications. We have found the combination of
these systems to be *very* tough to beat. Linux simply doesn't compare
to FreeBSD in terms of tools for distributed configuration management
(CVSup). Of course, many GNU programs run well on all three systems.
Gordon Bell (or was it Dan Dodge?), one of the QNX principals, discussed
the importance of the freeware movement at the last QNX Conference. I
remember a promise that QNX would do everything possible to work in
cooperation with that movement and enhance QNX's ability to draw from
the mindshare.
FWIR, they have a paid up arrangement with FSF, so that actually makes
QNX a cash contributor to the software that many of us value from that
organization.
I think this is a very smart strategy...
Good Luck,
James Youngman
>>>>> "Frank" == Frank Miles <f...@u.washington.edu> writes:
Frank> I'd also like to be able to source-level debug into libs, but
Frank> AFAIK Watcom doesn't do this either.
You *can* do that with GDB. All you need to do is link against
unstripped libraries, and have the library source installed in the
correct place. One way of doing this with Red Hat Linux, for example
is to use RPM to build the C library from the source RPM file and just
leave the source code in position after the install step. Works fine.
Of course, the libc source takes up quite a bit of space, though.
Frank Miles
In article <wk200yj...@vggas.com>,
To summarize my e-mail to Mr. Youngman, this seems to fall apart
with C++ code in the libs. I sure would like a better GDB!
-frank
Jerry Hicks
Joel Hardy wrote:
>
> On 3 Nov 1997 08:23:01 GMT, Richard Steiner <rste...@skypoint.com> wrote:
> >QNX is a real-time OS, Linux is not.
>
> real-time, and there's a real-time project out there somewhere (I think).
Sounds real stable Joel. Ready for life-support systems too.
>
> --
> Joel Hardy (de...@inficad.com -- the "From:" field might be wrong)
> http://www.inficad.com/~deeng -- due for a major overhaul sometime soon...
> http://www.linux.org -- Linux!
Not me, no thanks. I'll bet many other experienced developers feel the
same way.
Jerry Hicks.
jerry...@bigfoot.com
Dan Hildebrand
In article <slrn65r1d3....@mirage.skypoint.com>,
Richard Steiner <rste...@skypoint.com> wrote:
>Here in comp.os.linux.misc, Dolf van Mil <do...@schmit.nl>
>spake unto us, saying:
>
>>Hello,
>>we have a discussion over here concerning the difference between QNX and
>>Linux.
>>The questions in this discussion :
>>Why should I use QNX and not Linux.
>>Why should I use Linux and not QNX.
>
>QNX is a real-time OS, Linux is not. QNX is relatively expensive (so
>I'm given to understand) for the home user, whereas Linux is not. And
>Linux has a much larger program base at this point in time, though I
>think many GNU programs have been ported to QNX.
>
>Personally I think the single-diskette QNX demo is neat, but until the
>OS is available at a price point that I as a home user can afford, it
>might as well not exist.
Whether or not you use QNX at home, you do use QNX (or products built with
QNX) several times a day (credit card transactions, point of sale systems,
emergency dispatch systems, industrial control systems, etc). Whether or
not QNX exists is very important to the people who build those systems.
:-)
Armin Steinhoff
In article <345DAE04...@ix.netcom.com>, Jerry says...
>
>Richard Steiner wrote:
>>
[ clip ..]
>The architecture of Photon is certainly worthy of study outside of the
>QNX domain. It has been acknowledged to be one of the most significant
>GUI designs ever implemented. I am very impressed with the technology.
I agree ...
>The marketing however...
What marketing ?? You mean the department for 'globe trotting' ?
Well, that's one of greatest luxury of QSSL ... the member of these
department tend to ignore theire customer base, the possibilities
to communicate with them using the internet in an active way ... it
seems not existent !!
What about the 'quartely' published QNX News ?? ... how does they
'use' this communication instrument !
IMHO, quarter of a year are 3 month, isn't it ??
Does the Third Party partner programm still exist ??
BTW, has anyone seen a customer survey in the past ??
Armin Steinhoff
nospam-...@pobox.com
For another source of information on this issue, check the QNX FAQ,
which I'm posting right now.
In comp.os.qnx Richard Steiner <rste...@skypoint.com> wrote:
: Here in comp.os.linux.misc, Dolf van Mil <do...@schmit.nl>
: spake unto us, saying:
: >Hello,
: >we have a discussion over here concerning the difference between QNX and
: >Linux.
: >The questions in this discussion :
: >Why should I use QNX and not Linux.
: >Why should I use Linux and not QNX.
: QNX is a real-time OS, Linux is not. QNX is relatively expensive (so
: I'm given to understand) for the home user, whereas Linux is not. And
: Linux has a much larger program base at this point in time, though I
: think many GNU programs have been ported to QNX.
: Personally I think the single-diskette QNX demo is neat, but until the
: OS is available at a price point that I as a home user can afford, it
: might as well not exist.
: --
Igor N Kovalenko
Hmm, it looks like Jerry is more successfull on defending QNX than even
QSSL :-)
I mostly agree, but few notes...
Jerry Hicks <wghh...@ix.netcom.com> wrote in article
<345DAE04...@ix.netcom.com>...
>
> Good observations Rich... except for a couple :)
>
> It exists because for some applications (real-time PC based) QNX remains
> the best, most popular, and inexpensive solution. It also exists
> because of a fiercely loyal customer base; many have been working with
> the company for over a decade. You don't keep customers around like
> that for no reason. I received exceptional support from their sales,
> marketing, and technical staff, end-to-end until our products shipped.
>
This depends of where you are.
Here we have expression: "Tsar [that is King] is far away, God is far
above". Your destiny is in hands of your local distributor ... which is
sometimes your competitor :~|
> Celcore (http://www.celcore.com) likely would have never made it without
> their help. In truth, the partnership QNX has with ZiaTech (our hardware
> vendor) insured that we got an extremely stable microkernel with
> guaranteed hardware compatibility and robustness.
>
Yup, I saw the website. Glad for you and for Celcore. Congratulations :-)
> QNX is definitely a commercial product, for commercial developers,
> although they do have a very good discounting program for educational
> institutions. Since the products are available unbundled, with modular
> pricing, a run-time system can be delivered quite inexpensively.
>
Just vapour. Unless you have different definition for "inexpensive".
> The architecture of Photon is certainly worthy of study outside of the
> QNX domain. It has been acknowledged to be one of the most significant
> GUI designs ever implemented. I am very impressed with the technology.
Agree.
> The marketing however...
>
;;;-) [supposed to be smiley with too much tears].
> The few people I've met who have been disappointed with QNX have tried
> to treat it as though it were Unix. QNX is *not* Unix, nor does it
> purport to be. In developing real-time applications on QNX, this is
> important to remember. It's a microkernel, a real one.
>
I don't see a reason to be proud of "QNX is *not* Unix".
GNU is *Not* Unix, but GNU OS aka Linux is much more Unix than QNX. It is
also POSIX compliant. If you write a system which is compatible only to
itself, you just have less customers. And yes, a lot of users would like to
see QNX more compatible with Unix, but getting frustrated now by numerous
non-motivated differences and limitations. I think that QNX should be as
close to Unix in interfaces as possible, except where it will lead to major
deficiences.
Actually, steps which QSSL made developing Neutrino allows me to think that
they think the same way.
> Even so, it can perform many of the tasks Unix does very well. We use
> FreeBSD in conjunction with QNX to round out a really nice development
> environment for real-time applications. We have found the combination of
> these systems to be *very* tough to beat. Linux simply doesn't compare
> to FreeBSD in terms of tools for distributed configuration management
> (CVSup). Of course, many GNU programs run well on all three systems.
>
If QNX would be more Unix, perhaps you would use CVSup or whatever FreeBSD
app right on QNX?
> Gordon Bell (or was it Dan Dodge?), one of the QNX principals, discussed
> the importance of the freeware movement at the last QNX Conference. I
> remember a promise that QNX would do everything possible to work in
> cooperation with that movement and enhance QNX's ability to draw from
> the mindshare.
>
> FWIR, they have a paid up arrangement with FSF, so that actually makes
> QNX a cash contributor to the software that many of us value from that
> organization.
>
> I think this is a very smart strategy...
>
Interesting, I did not knew this.
Just wondering, why QSSL does not purchase cheap source license for XFee86
to resell binaries for QNX? Perhaps, they can also donate a computer with
installed QNX to XFree86 team and get support, as they pay to FSF anyway.
This can stop endless trouble with X for QNX ...
Regards,
Igor
Joel Hardy
Not for too long. The scheduling code for Linux is getting closer to
real-time, and there's a real-time project out there somewhere (I think).
--
Igor N Kovalenko
Martin Zimmerman <ca...@wooga.cuug.ab.ca> wrote in article
<EJ3sE...@wooga.cuug.ab.ca>...
> Igor N Kovalenko (in...@mail.wplus.net) wrote:
> > Just vapour. Unless you have different definition for "inexpensive".
>
> volume forcasts. I don't think this is unreasonable. Personally, I
> don't think their development tools are overpriced. They are quality
> tools that pay for themselves quite quickly, i.e. they have a high
> Return-On-Investment. The price for support plans are reasonable (hell,
> *I* can afford one!). Check the runtime pricing for QNX/Neutrino, *very*
> decent, even at list.
>
Perhaps, you got it from your local distributor :-)
> > I don't see a reason to be proud of "QNX is *not* Unix".
>
> Define Unix. Good luck.
>
I'm not a purist. See below.
> > see QNX more compatible with Unix, but getting frustrated now by
numerous
> > non-motivated differences and limitations. I think that QNX should be
as
> > close to Unix in interfaces as possible, except where it will lead to
major
> > deficiences.
>
> Go compare SunOS, Solaris, Dec OSF/1, AIX, IRIX, and HP-UX. You will
> see a wide range of "compatabilities". If you look at how far some of
> them divert from the "core" QNX is closer than a couple in some areas,
> and farther in a few as well. Hell, HP-UX can't guarantee that code
> written for 10.10 will work in 10.20 which is only supposed to represent
> a minor change. Unix is a myth, there are more flavours of Unix than
> I'd care to count, and each requires varyin degrees of work to "port"
> code.
>
If someone is worse, you are not nesessary good.
Noticed systems are well known for their incompatibility, but I don't think
QNX should be known for the same reason.
> From my limited experience in porting code, and in my experience in
> writing portable code, the ease of the port depends far more heavily on
> the programmer's attention to OS specific extension than on the
> compatability of the OS. Each "unix" out there, tries to keep a core
> that is compatible, but they also keep extensions that are not. The
> extensions are what gives them a competitive advantage. Now, depending
> on the intentions of the programmer (or development team) they may
> choose to write portable code, or they may choose to use the extensions
> for a particular "unix" to get the "best" code for that platform.
>
> So, in short, compatability itself can even be a myth. You choose to
> write compatible code, or platform-specific code. If you want code that
> is platform-specific across a large number of platforms, then you get
> used to #ifdef HPUX ... #endif constructs for each and every platform.
> QNX suffers from this as much (or as little) as any other "unix" out
> there.
>
I have my own definition for compatibility. A system is [more or less] Unix
compatible, when I can say 'Well, I'm hard', get a program written for some
version of Unix and tweak its source to run on that system (without major
rewrite and redesign).
It is possible to say so for virtually all version of Unix, but not for
QNX. If a program use e.g., memory mapped files, you are lost. I can
continue, but afraid that Ken will slant me again for repeating the same
things... But when I try to port WebStone and see that there is no rexec()
in libs, although there is rexecd in /usr/ucb, I getting angry. (Thankfully
it is fixed in 4.24).
Another issue is common set of utils, or whatever you call user interface.
QNX has brain dead shell, which makes impossible to use directly a lot of
makefiles. It has ugly version of vi either. It lacks some important
features for no reason, like supplementary groups, shadow management or
secure terminals. Hell, even cp works differently, what is absolutely
meaningless. Not to mention ugly and incomplete terminal definition files.
So, newbies with any Unix experience keep asking questions like 'why
install does such a different thing', 'how do I add a new user', or 'why vi
behaves so weird', or 'why mc does not work properly', 'why there is no
man' (or why its equivalent called tmhv and not included with OS), 'why
there is no /var/run' (which some shipped daemons like pppd must use) and
'why no one ANSI emulator is able to work with QNX properly in ANSI mode'.
There is no excuse for mentioned problems, IMHO.
Finally, to be clear: don't argue that Unix is kernel, but QNX is
microkernel. I know. I just think that QNX should comply with:
1) Most of widely used Unix API.
2) Most of techniques, procedures and utilities to use and maintain the
system.
3) Most common filesystem layout.
Where 'most common' is too vague, it is better to choose one most widely
used (e.g., BSD, SYS V or Linux) and be mostly compliant with it, so when a
program will be written for it, it will likely comply and run under QNX
too.
Regards,
Igor
Jason Kennedy
In article <wgcid$13$g1000$h107$i0$j45e...@caamora.com.au>,
Jonathan Michaels <j...@caamora.com.au> wrote:
>a little show od support by qssl would be very much appreciated,
>especially by the people who helped put qssl on the map, because with
>out us mr hildebrand you have got noting other than a whole lot of hot
>fetid air and boxes that are only fit for recycli
>ng.
>>
>with apologies to the newsgroup for the lenght and harshness of my
>post.
>regards ... jonathan
>EMail: j...@caamora.com.au
>
> ... i do all i can, with what i have, are you able to say the same ?
>--
>Caamora ______________________________________________________________
>PO Box 2036
>Clovelly West NSW 2031 Australia data +61 2 96659249
>------------------------------------------------- <j...@caamora.com.au>
Hi Jonathan
We will be contacting you regarding your project. I have posted the
full outline of the QNX Educational Program in another thread in this
news group as well.
-- Jason
----------------------------------------------------------------
Jason Kennedy
Educational Program Coordinator
QNX Software Systems Ltd
Kanata ON K2M 1W8
mailto:ja...@qnx.com
http://www.qnx.com/
voice 613-591-0931
fax 613-591-3579
Erich Ritzmann
Martin Zimmerman wrote:
>
> Igor N Kovalenko (in...@mail.wplus.net) wrote:
> > I don't see a reason to be proud of "QNX is *not* Unix".
>
> Define Unix. Good luck.
UNIX is one of those things in life that does have a very precise (and
legal)
definition. For more info see:
http://www.UNIX-systems.org/what_is_unix.html
> > see QNX more compatible with Unix, but getting frustrated now by numerous
> > non-motivated differences and limitations. I think that QNX should be as
> > close to Unix in interfaces as possible, except where it will lead to major
> > deficiences.
>
> Go compare SunOS, Solaris, Dec OSF/1, AIX, IRIX, and HP-UX. You will
> see a wide range of "compatabilities". If you look at how far some of
> them divert from the "core" QNX is closer than a couple in some areas,
Having done so, I agree, QNX is not UNIX, but Solaris sure comes close,
and
so does Linux for that matter. Personally, I like the model where there
is
commonality around a standard core, and competition in terms of
ancillary
features, support and of course, stability.
--
Erich J. Ritzmann
Open Systems Consultant
Mortice Kern Systems Inc.
*** Opinions are my own ***
Dan Hildebrand
In article <wgcid$13$g1000$h107$i0$j45e...@caamora.com.au>,
Jonathan Michaels <j...@caamora.com.au> wrote:
>
> DH> In article <slrn65jqvd.275....@linux.ceu.edu.pl>,
> DH> Ziemek Borowski <ziemek....@ziembor.waw.pl> wrote:
>>Fri, 31 Oct 1997 13:05:01 +0100, Dolf van Mil na comp.os.linux.misc
>>wrote:
>
> DH> it can't be that expensive. :-)
>
>the day people such as myslef can afford to purchase qnx will be the
>day that remarks such as this wont be as deneaning as thay are a savage
>comment on the voraciousnes of organisations such as qssl.
I'm sorry if my posting offended you. I was trying to point out that to
OEM's building high-volume systems, QNX runtime licenses can be quite
inexpensive. I can appreciate that QNX development systems are not free,
even though we're working to help students through our educational support
program. We've taken some measures to address your needs with the
educational program and I hope they work out as well.
Jerry Hicks
Martin Zimmerman wrote:
[snip]
> Define Unix. Good luck.
[snip]
My own definition is any member of the family tree that can -directly-
trace its lineage to Bell Labs Unix.
Around here, we generally use the term to describe the kernel and not
the utility or development programs traditionally hosted on a Unix
kernel.
Indeed, according to our definition QNX, HP-UX and Linux are not Unix.
The 4.4BSD kernel and derivatives such as FreeBSD are though.
Linux isn't even an operating system. It's a kernel. Just ask Richard
Stallman (I dare ya ;)
I must agree with Martin that common usage is extremely vague.
Jerry Hicks
jerry...@bigfoot.com
John E. Perry
Someone wrote:
> ...
> >Not for too long. The scheduling code for Linux is getting closer to
> >real-time, and there's a real-time project out there somewhere (I think).
> >
One of the principals in the RT-Linux project just wrote an article for
Embedded
Systems Programming Magazine. In sum (as I recall), he says
1) There will likely never be a true realtime Linux -- his group is
closest to
it, and their work consists of kernel patches that sidestep Linux for a
small set
of facilities, and all the heavy-duty stuff remains in the non-realtime
kernel.
It's apparently similar to the real-time MSDOS approach.
2) Linux is not really appropriate to embedded use. It's simply too
large and
complex.
3) Under the Linux development model, dozens to hundreds of desktop
workstation
advocates with no interest in realtime do the majority of development,
and the
few realtime workers cannot keep up with progress in the massive code
base that
is simply not adaptable to realtime use.
If I've misunderstood any of his points, someone else who read the
article please
clear things up (even better, someone connected with the project who
might read this
newsgroup). Also, the web site Mark Voikovitch posted is the New Mexico
University
group which I understand is the center of RT-Linux work.
John Perry
Pulse Electronics
jpe...@norfolk.infi.net
Martin Zimmerman
You need to discuss a real project with them with at least semi-real
volume forcasts. I don't think this is unreasonable. Personally, I
don't think their development tools are overpriced. They are quality
tools that pay for themselves quite quickly, i.e. they have a high
Return-On-Investment. The price for support plans are reasonable (hell,
*I* can afford one!). Check the runtime pricing for QNX/Neutrino, *very*
decent, even at list.
> I don't see a reason to be proud of "QNX is *not* Unix".
Define Unix. Good luck.
> see QNX more compatible with Unix, but getting frustrated now by numerous
> non-motivated differences and limitations. I think that QNX should be as
> close to Unix in interfaces as possible, except where it will lead to major
> deficiences.
Go compare SunOS, Solaris, Dec OSF/1, AIX, IRIX, and HP-UX. You will
see a wide range of "compatabilities". If you look at how far some of
them divert from the "core" QNX is closer than a couple in some areas,
and farther in a few as well. Hell, HP-UX can't guarantee that code
written for 10.10 will work in 10.20 which is only supposed to represent
a minor change. Unix is a myth, there are more flavours of Unix than
I'd care to count, and each requires varyin degrees of work to "port"
code.
From my limited experience in porting code, and in my experience in
writing portable code, the ease of the port depends far more heavily on
the programmer's attention to OS specific extension than on the
compatability of the OS. Each "unix" out there, tries to keep a core
that is compatible, but they also keep extensions that are not. The
extensions are what gives them a competitive advantage. Now, depending
on the intentions of the programmer (or development team) they may
choose to write portable code, or they may choose to use the extensions
for a particular "unix" to get the "best" code for that platform.
So, in short, compatability itself can even be a myth. You choose to
write compatible code, or platform-specific code. If you want code that
is platform-specific across a large number of platforms, then you get
used to #ifdef HPUX ... #endif constructs for each and every platform.
QNX suffers from this as much (or as little) as any other "unix" out
there.
Cheers,
Camz.
--
Martin Zimmerman QNX FAQ Keeper ca...@passageway.com
Camz Software Enterprises Work In Realtime www.passageway.com/camz/
QNX Programming & Consulting Work In QNX www.passageway.com/camz/qnx/
Dan Hildebrand
In article <345DAE04...@ix.netcom.com>,
Jerry Hicks <wghh...@ix.netcom.com> wrote:
>
>Gordon Bell (or was it Dan Dodge?), one of the QNX principals, discussed
>the importance of the freeware movement at the last QNX Conference. I
>remember a promise that QNX would do everything possible to work in
>cooperation with that movement and enhance QNX's ability to draw from
>the mindshare.
Correct. Allowing this source code (and commercial UNIX source as well) to
port easily to QNX is important to us.
>FWIR, they have a paid up arrangement with FSF, so that actually makes
>QNX a cash contributor to the software that many of us value from that
>organization.
It may be outside my experience, but I don't recall us making a
contribution of this sort. We do submit bug fixes and diffs though.
James Youngman
>>>>> "Jerry" == Jerry Hicks <wghh...@ix.netcom.com> writes:
Jerry> My own definition is any member of the family tree that can
Jerry> -directly- trace its lineage to Bell Labs Unix.
[...]
Jerry> Indeed, according to our definition QNX, HP-UX and Linux are
Jerry> not Unix. The 4.4BSD kernel and derivatives such as FreeBSD
Jerry> are though.
In that case I find your point of view hard to understand; the HP-UX
kernel was once upon a time based upon 4.2BSD (I think is was 4.2).
Nick Costescu
In article <345EAF9B...@norfolk.infi.net>, jpe...@norfolk.infi.net wrote:
>Someone wrote:
>> ...
>> >Not for too long. The scheduling code for Linux is getting closer to
>> >real-time, and there's a real-time project out there somewhere (I think).
claims. But it does not begin to provide the functionality which QNX does.
There is no comparison for real time work. There was also a problem with
RTLinux not handling spurious interrupts (ie. if interrupts were being
generated before a handler was installed for that IRQ, your handler would
never get called).
One advantage RT-Linux has is that now it allegedly supports SMP. I'm still
trying to find out about the elusive QNX/Neutrino SMP (Dan?).
*********************************************
Nick Costescu / ECE Dept / Clemson University
Tel : (864) 656-7708 / Fax : (864) 656-7220
http://www.clemson.edu/spurgeon
http://ece.clemson.edu/crb/students/ncostes
James Youngman
>>>>> "Joel" == Joel Hardy <de...@localhost.localdomain> writes:
Joel> On 3 Nov 1997 08:23:01 GMT, Richard Steiner
Joel> <rste...@skypoint.com> wrote:
>> QNX is a real-time OS, Linux is not.
Joel> Not for too long. The scheduling code for Linux is getting
Joel> closer to real-time, and there's a real-time project out there
Joel> somewhere (I think).
RTLinux.
Igor N Kovalenko
> program will be written for it, it will likely comply and run under QNX
^^^^^^ - oops, i mean
'compile'.
--
Igor
Jerry Hicks
Yup, I was wrong about HP-UX. (Thanks James).
I translated HP-UX into OSF/1. *HP* didn't however.
They've got DCE and OSF Streams, but are indeed directly descended from
4.2BSD.
They say raw eggs are good for the complexion... I should know :)
Jerry Hicks
jerry...@bigfoot.com
Frank Sweetser
da...@qnx.com (Dan Hildebrand) writes:
>
> In article <63nc8m$8...@qnx.com>, Dan Hildebrand <da...@qnx.com> wrote:
> >In article <345DAE04...@ix.netcom.com>,
> >
> >>FWIR, they have a paid up arrangement with FSF, so that actually makes
> >>QNX a cash contributor to the software that many of us value from that
> >>organization.
> >
> >It may be outside my experience, but I don't recall us making a
> >contribution of this sort. We do submit bug fixes and diffs though.
>
> After checking with our accounts payable/receivable department and
> discovering that we haven't made a a contribution to the FSF, we've decided
> to correct this and make a contribution. Thanks for raising the issue.
Well, QNX just went up a couple of notches in my opinion... here's to
putting your money where your mouth is! :-)
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.res.wpi.net RedHat 4.9.1 Linux 2.0.31 i586 | at public servers
Sam: What do you say, Norm?
Norm: Any cheap, tawdry thing that'll get me a beer.
-- Cheers, Birth, Death, Love and Rice
Robert Lynch
Steve McPolin wrote:
[snip]
> That is a 'UNIX System', there is a difference. 'unix' is
> a design philosophy which values systems composed of precise,
> powerful, interoperable components. C is 'unix'; C++ is not.
> SVR4 is a 'UNIX System', but hardly a 'unix'.
> Plan9 isn't a 'UNIX System', but is 'unix'.
>
> QNX is not a 'UNIX system', although it is POSIX-certified
> and bears more than a casual resemblence to many 'UNIX system's.
> I like to think QNX reflects the 'unix' philosophy.
>
> --
> Steve McPolin, QNX Software Systems, Ltd.
> point+click: st...@qnx.com
> lick+stick: 175 Terence Matthews; Kanata, Ontario, Canada; K2M 1W8
Just to interject... in "Peter Norton's Guide to Unix" one finds:
RULE: To learn Unix, keep in mind that Unix is a culture.
I've been fascinated by this thread about QNX, the kudos and brickbats
it gets, and simply amazed that I'd never heard of it prior to the
thread. Which points up another quote from the Peter Norton book:
RULE: Keep in mind that Unix is fun.
Imagine QNX/Linux emerging from the DOZE/Windoze world... Never!
Sorry if I'm interrupting some serious discussion.
Bob L.
--
Robert Lynch-Berkeley CA USA-r...@best.com
http://www.best.com/~rmlynch/
Christopher Browne
On 5 Nov 1997 17:01:18 GMT, st...@qnx.com (Steve McPolin) wrote:
>In article <345F81...@mks.com.NOSPAM>,
>Erich Ritzmann <erit...@mks.com> wrote:
>>Martin Zimmerman wrote:
>>> Igor N Kovalenko (in...@mail.wplus.net) wrote:
>>> > I don't see a reason to be proud of "QNX is *not* Unix".
>>> Define Unix. Good luck.
>>
>>legal)
>>definition. For more info see:
>
>a design philosophy which values systems composed of precise,
>powerful, interoperable components. C is 'unix'; C++ is not.
>SVR4 is a 'UNIX System', but hardly a 'unix'.
>Plan9 isn't a 'UNIX System', but is 'unix'.
>
>QNX is not a 'UNIX system', although it is POSIX-certified
>and bears more than a casual resemblence to many 'UNIX system's.
>I like to think QNX reflects the 'unix' philosophy.
There's a book entitled "The UNIX Philosophy." I have the tenets
listed at: <http://www.hex.net/~cbbrowne/unix.html#PHILOSOPHY>.
C encourages development of relatively small programs that interface
using pipes, which is certainly "Unix-like;" C++ encourages "hooking
things together" by passing objects/messages between bits of code,
which certainly is *not* Unix-like. Java appears to discourage
Unix-like interfaces; CGI appears to encourage them...
Windows NT, OS/390, and OpenVMS all have "POSIX layers," and may have
some "UNIX Certifications," but do not encourage building Unix-like
applications.
QNX *seems* to reflect "UNIX Philosophy;" Linux, Hurd, *BSD, Plan 9,
and sundry others most certainly do.
The various commercial UNIXes (AIX, HP/UX, DGUX, Digital UNIX,
Solaris) are not all *legally* "UNIX" operating systems, but certainly
are reasonable systems on which to build "Unix-like" application
systems.
--
cbbr...@hex.net, <http://www.hex.net/~cbbrowne>
Have you contributed Your Fair Share to Linux? For ideas, see:
<http://www.hex.net/~cbbrowne/lsf.html>
Steve McPolin
In article <345F81...@mks.com.NOSPAM>,
Erich Ritzmann <erit...@mks.com> wrote:
>Martin Zimmerman wrote:
>>
>> Igor N Kovalenko (in...@mail.wplus.net) wrote:
>
>> > I don't see a reason to be proud of "QNX is *not* Unix".
>>
>> Define Unix. Good luck.
>
>UNIX is one of those things in life that does have a very precise (and
>legal)
>definition. For more info see:
That is a 'UNIX System', there is a difference. 'unix' is
a design philosophy which values systems composed of precise,
powerful, interoperable components. C is 'unix'; C++ is not.
SVR4 is a 'UNIX System', but hardly a 'unix'.
Plan9 isn't a 'UNIX System', but is 'unix'.
QNX is not a 'UNIX system', although it is POSIX-certified
and bears more than a casual resemblence to many 'UNIX system's.
I like to think QNX reflects the 'unix' philosophy.
--
Jonathan Michaels
Dan Hildebrand wrote in a message to All:
DH> In article <wgcid$13$g1000$h107$i0$j45e...@caamora.com.au>,
DH> Jonathan Michaels <j...@caamora.com.au> wrote:
>Dan Hildebrand wrote in a message to All:
>
> DH> In article <slrn65jqvd.275....@linux.ceu.edu.pl>,
> DH> Ziemek Borowski <ziemek....@ziembor.waw.pl> wrote:
>>Fri, 31 Oct 1997 13:05:01 +0100, Dolf van Mil na comp.os.linux.misc
>>wrote:
>>>Why should I use QNX and not Linux.
>>If you have much money choose QNX ;-)
>
> DH> Hey now, if QNX is being built into televisions and set top boxes
> DH> it can't be that expensive. :-)
>
>the day people such as myslef can afford to purchase qnx will be the
>day that remarks such as this wont be as deneaning as thay are a
savage
>comment on the voraciousnes of organisations such as qssl.
DH> I'm sorry if my posting offended you.
not so much offended as indignant, specifically after the somewhat
rough handling at the hands of the australian end of the qssl chain.
DH> I was trying to point out that to OEM's building high-volume
DH> systems, QNX runtime licenses can be quite inexpensive.
i can relate to that, when i was 'in the trade', we used qnx for
apropriate projects as the cost to purchase and maintain was ... sorry,
i've lost the thread, i agree with you.
DH> I can appreciate that QNX development systems are not free, even
DH> though we're working to help students through our educational
DH> support program.
here, is where my argument lay, not just for the student type, well
maybe it is for the student types. as far as i can remember qnx is
competetievly priced when it comes mainstream product in main stream
Amreica.
but, in emerging economies and the disadvantaged people in Amreia and
Australia and Frenace and Britain .. the whole world over, would do
well to get thems selves retrained as process control 'engineers' and
get them selves onto groundfloor jobs in areas
where they jhave years
of workshop technica; expertese at things other than designing process
control devices (this is what i hoe to achieve).
maybe i have confused everybody .. an example should clear it up,
assumiong you can get past my poor english.
a man (or woman) works as a fitter in a machine shop from the time they
were aprenticed (i don;t know what the american term for this is, but
the german and europans should understand). this person learms how the
lathes work and why things are done the wa
y that they are done by
watching and trying new things on the mschines .. he (she) builds up
very much experience in this very technical filed that engineers think
that they know a lot about. well along comes new day and costs must be
cut so the engineers
who read a computer trade journal featuring qnx
(or os9) controlled lathes that can replace several highyly experienced
machine operators .. so the company hires one or two qnx/os9 machine
plc programmers / engineerrs to replace the two dozen operators a
nd
they purchase a good compliment of the new machines.
looks brigth and rosy for the company, ther wages bill is low and the
insuraces are very low .. enginers have less shop floor accidnts that
machine operators as a clas so thier insurance premiums ar much much
higher (than for engineers). the all of a sudd
en machines start to
break bits (cutting edges), shafts need replacing, lathe engines are
burning out at much faster rates than beofre.
has anybody been in a shop where this has happened ?
the engineers scratch thier heads and throuh up ther arms, the few real
operators don;t unders tand the new electronic machines to know what is
realy going on and the machine programmers havent got a clue .. thier
prograsms are feeding metal at the apropr
iate rate and th cutting
temperatures are withing tolerance .. but the programs are falling over
and not becus of cod bugs .. the fall overs are evidenced by the ever
mounting scrapped jobs ...
i could goi into a light analysis of this picture but the enginers that
you all are should be able to see what is happening and don;t nned me
to tell you your jobs.
as for the scraped worker with many years experience what of them, they
could hav solved the metal quality issues in a flash and reset the
cutting rates and adjusted the bit angles to compnste for the micro
crystaline irregularities that were causing the
grabbing at the
trailing edge of the shearing face of the cutting bit .. this is a real
world example from my own personal experience. the new machines were
some sort of new fabricated english lathe witha phillips program unit
grafted onto it running os9.
it coul just as easily have been qnx, well
manybe not 25 years ago, is qnx that old ?
point being made here, is that the workers could have taken thir 10+
years of shop flor experince and purchased a qnx development kit and
started back at school to become whatever thes new fnagled titles would
be called.
its like the differance between a draughtsman that is classically
trained on a real drafting board and the new ones who learn on a twenty
inch almost flicker free draughting board using autocad for students ..
thier is a certain level of nuance that the n
ew onse will never have
because they don't understand what drafting is about .. drafting is
much more than pushing a mouse around a desktop.
maybe with qnx specific reskilling educational program some more people
such as myslef coulld once again become usefull members in the
industries that no longer need thier hands or bodies but would benefit
most greatly from the learning that those very sa
me hands and bodies
carry with them. it is one ting to help uni students make it good in
uni cources, i am suggesting that the same could be established fro
trade school and or some of the govt reskilling [rogrames to help the
'underpriviledged' or what e
ver we they are called today.
DH> We've taken some measures to address your needs with the
DH> educational program and I hope they work out as well.
as i said earlier (personally) i was most surprised and more than a
little stunned, with your curtious email .. i look forward to taking
advantage of your kind offer.
in closing i'd like to add this to the sandbagger .. grin
i have a very direct writig style that is sometimes missunderstood, i
mean no ofence but many people get out of bed on the wrong side (with
respect to myself) and others are just spoiling for a fight .. i had
intended to 'make an observation or two and of
fer an opinion' as i had
originally offered .. but as usual my directness has gotten me into
trouble, not from yourself, but from a few 'defenders of the faithful'
in email. i will get round to answering all, it may take a while, i am
a bit slow at the mo
ment. nerve conduction studes tend to leave one a
little gittery and just a bit edgy.
Nick Costescu
>>the day people such as myslef can afford to purchase qnx will be the
>>day that remarks such as this wont be as deneaning as thay are a savage
>>comment on the voraciousnes of organisations such as qssl.
I don't know about all that. As a student in a controls and robotics program
here at Clemson university, I have not seen too much voraciousness and
savagery. Since we qualify for QSSL's educational program they give us their
software and manuals free or at minimal cost.
QSSL puts out a great product which does what it claims to (RTOS).It has a
very nice GUI (photon) which is very similar to X/Motif as far as programming
goes (we made a smooth transition from X/Motif programming to photon).The OS
comes on 4 floppies (including networking). The gui comes on about 4 (with
development stuff).
You can get a demo floppy which has the OS, Photon, web browser, and some
other stuff off their web page (www.qnx.com).
As far as development tools, I'm happy with the watcom stuff on QNX. The
debugger is nicer than any Linux debugger I've seen (though it could stand
some improvement - like a bigger window :) But it has all the nice Turbo C
Debugger style features.
I habitually program on Irix, Linux, SunOS and QNX. The bulk of my work right
now is on QNX as it is real time control software. All of the above OSs have
their target audience. QNX is my choice for real time work. It lets me get the
job done quicker and better with less overhead. I have used RTLinux, and while
it is very clever, it is a limited hack when compared to the robustness of QNX
which is designed from the ground up for real time work.
Geoff Roberts
>In article <63o5ik$a...@qnx.com>, da...@qnx.com (Dan Hildebrand) wrote:
>
>>>the day people such as myslef can afford to purchase qnx will be the
>>>day that remarks such as this wont be as deneaning as thay are a savage
>>>comment on the voraciousnes of organisations such as qssl.
>
Actually Dan obviously didn't write that. I have spoken to the person
who did, and I believe that this and a couple of other comments are
regretted somewhat, and were to a large extent born out of frustration
and some misunderstandings.
I also believe that Johnathon will also from here on in become an
enthusiastic and loyal proponent of QNX (just like many others who
frequent this newsgroup) now that he has vented his liver and had some
of these misunderstandings cleared up.
>I don't know about all that. As a student in a controls and robotics program
>here at Clemson university, I have not seen too much voraciousness and
>savagery. Since we qualify for QSSL's educational program they give us their
>software and manuals free or at minimal cost.
Unfortunately some QSSL distributors outside of America don't view it
as favourably as this. I think it might have something to do with
short-term vs. long-term issues....
>QSSL puts out a great product which does what it claims to (RTOS).It has a
>very nice GUI (photon) which is very similar to X/Motif as far as programming
>goes (we made a smooth transition from X/Motif programming to photon).The OS
>comes on 4 floppies (including networking). The gui comes on about 4 (with
>development stuff).
>
>You can get a demo floppy which has the OS, Photon, web browser, and some
>other stuff off their web page (www.qnx.com).
>
>As far as development tools, I'm happy with the watcom stuff on QNX. The
>debugger is nicer than any Linux debugger I've seen (though it could stand
>some improvement - like a bigger window :) But it has all the nice Turbo C
>Debugger style features.
>
>I habitually program on Irix, Linux, SunOS and QNX. The bulk of my work right
>now is on QNX as it is real time control software. All of the above OSs have
>their target audience. QNX is my choice for real time work. It lets me get the
>job done quicker and better with less overhead. I have used RTLinux, and while
>it is very clever, it is a limited hack when compared to the robustness of QNX
>which is designed from the ground up for real time work.
I think you speak for a lot of us Nick. Personally, I am not doing any
hard real-time stuff at the moment (mainly soft). But what I am doing
requires performance, elegance, and fast development time (try
knocking up a raw ethernet driver using an FD interface in a couple of
days in NT!) I find that QNX allows me to achieve this, and I shiver
when I consider the fact that if QNX were not around, I might have to
use something like Linux or [cringe] NT.
My 2 cents worth.
Geoff Roberts.
Realtime Technology Systems Pty Ltd,
Canberra,
Australia.
http://ww.rtts.com.au
Dan Hildebrand
In article <63nc8m$8...@qnx.com>, Dan Hildebrand <da...@qnx.com> wrote:
>In article <345DAE04...@ix.netcom.com>,
>
>>FWIR, they have a paid up arrangement with FSF, so that actually makes
>>QNX a cash contributor to the software that many of us value from that
>>organization.
>
>It may be outside my experience, but I don't recall us making a
>contribution of this sort. We do submit bug fixes and diffs though.
After checking with our accounts payable/receivable department and
discovering that we haven't made a a contribution to the FSF, we've decided
to correct this and make a contribution. Thanks for raising the issue.
David M. Glotfelty
> George Henry C. Daswani wrote:
> How about things like ....
> ( List o' QNX problems snipped )
> Hmmmm, I've been supporting QNX on a software development setting and
> I find LINUX a much more reliable system for software development.
Concur. Migrated a prototype comms support system prior to deploying
to +20 target field systems from propriatary QNX to POSIX Linux.
Cost of manuals and platform licenses was nothing compared to
ability to use O.S. source when needed. Support on net for all OS
aspects immediate with wide talent base vs. hours on phone. Like
iRMX from Intel where we spent thousands on tech support which couldn't
compare to Linux newsgroup support.
> Heck, even something simpler like rdist! or bringing things like POSIX
> threads to QNX 4.2X? How about implementing SYS V IPC instead of that
> proprietary message passing? Or how about implementing other services
> like NIS support?
One effort in migrating our code was changing propriatary message
passing to Sys V InterProcessCommunication - well worth the effort
to get us out from under the propriatary yoke and POSIX compliant.
Now if Linux or whatever platform doesn't meet our needs, moving
is no big deal and IPC works great. The O.S. makers that are not
competing effectively with free systems have much to fear from
implementing cross platform standards or standard tools.
> Why does QNX keep on trying to compare themselves to Linux?
> Instead of wasting time in the newsgroups comparing linux to
> qnx, they should actually try to start implementing things
> like POSIX Threads, porting XFree86 to QNX and etc.
Obvious. My condolences for small systems houses that face
this. But as a Unix developer and user Linux is a godsend.
Regards,
Dave Glotfelty
-
*-- Just A Knight Dreaming of Castle Anthrax --*
family website http://glotfelty.home.ml.org
*---------- email: glot...@erols.com ---------*
Jonathan Michaels
Geoff Roberts wrote in a message to All:
GR> On Thu, 06 Nov 1997 22:42:23 GMT, nco...@eng.clemson.edu (Nick
GR> Costescu) wrote:
>In article <63o5ik$a...@qnx.com>, da...@qnx.com (Dan Hildebrand) wrote:
>
>>>the day people such as myslef can afford to purchase qnx will be the
>>>day that remarks such as this wont be as deneaning as thay are a
savage
>>>comment on the voraciousnes of organisations such as qssl.
>
GR> Actually Dan obviously didn't write that. I have spoken to the
GR> person who did, and I believe that this and a couple of other
GR> comments are regretted somewhat, and were to a large extent born
GR> out of frustration and some misunderstandings.
GR> I also believe that Johnathon will also from here on in become an
GR> enthusiastic and loyal proponent of QNX (just like many others who
GR> frequent this newsgroup) now that he has vented his liver and had
GR> some of these misunderstandings cleared up.
ummmmm, thanks geoff, i don't know quite how to say this with out
making it look like i was retreating to or from the high moral ground.
i feel quite passionatly about the plight of the disabled (for
understandably obvious reasons) and as such would like to see my
segment of the community be catered for as well, that is not to be
excluded because we are not all fresh faced pretty little gi
rls and
boys with rosey pink cheeks .. sory for the slight sarcastic
inflection.
>I don't know about all that. As a student in a controls and robotics
>program
>here at Clemson university, I have not seen too much voraciousness and
>savagery. Since we qualify for QSSL's educational program they give
>us their
>software and manuals free or at minimal cost.
GR> Unfortunately some QSSL distributors outside of America don't view
GR> it as favourably as this. I think it might have something to do
GR> with short-term vs. long-term issues....
yup, one of the point i didn't quite get around to getting up steam
over, or mores the point if i ever did make it as a qnx programmer i
would be faced with the prospect of having to deal with people with
long memories .. as some member of the distributor
classes for vcarious
proruct lines tend to be.
GR> I think you speak for a lot of us Nick. Personally, I am not doing
GR> any hard real-time stuff at the moment (mainly soft). But what I
am
GR> doing requires performance, elegance, and fast development time
GR> (try knocking up a raw ethernet driver using an FD interface in a
GR> couple of days in NT!) I find that QNX allows me to achieve this,
GR> and I shiver when I consider the fact that if QNX were not around,
GR> I might have to use something like Linux or [cringe] NT.
yup, and i have been an avid even enthusiastic suporter of qnx over the
20 someting years .. though now it will (hopefully) be with a more
direct and hands on aproach, as opposed to my former position of
recomending and ore supporting recoemdations on tec
hnical grounds for
the use of qnx components in various local projects.
GR> My 2 cents worth.
another 1.65 cents ..
accounting for hong kong dollar devaluation by the time you read this
post, grin
Johannes Stratmann
Jonathan Michaels <j...@caamora.com.au> wrote in article
<wgcid$13$g1000$h107$i0$j461...@caamora.com.au>...
why is this thread QNX vs. Linux and not QNX & Linux ???
why not an open FLEET network protocol that is understood by
Linux or Windows ? why not a filesystem that can be read by OS/2 or Windows
?
why is the driver architecture bound to QNX ? why Photon and not XWindows
at all ?
why no man pages ? why is the compiler support bound to watcom ? why no
DCOM
support when CORBA is much more expensive ? Where is Java ? Why to pay for
a
Internet suite when a lot of other systems support this for free ? Where
are the books
about writing device drivers for QNX ?
Armin Steinhoff
In article <01bced67$b82c59e0$64930cc0@ta_sn_1>, "Johannes says...
>
>Jonathan Michaels <j...@caamora.com.au> wrote in article
><wgcid$13$g1000$h107$i0$j461...@caamora.com.au>...
>
>why is this thread QNX vs. Linux and not QNX & Linux ???
good question ...
>why not an open FLEET network protocol that is understood by
>Linux or Windows ?
FLEET is proprietary to QNX and the base of the OS technologies are too
different, so it would be very difficult to port FLEET to e.g. LINUX.
> why not a filesystem that can be read by OS/2 or Windows ?
It's available ... use SAMBA or the SMB client!
>why is the driver architecture bound to QNX ?
Because of the special QNX architecture ....
> why Photon and not XWindows at all ?
XWindows is not usefull for small embedded systems ... but
the better question is: why is PHOTON not more or less compatible
to XWindows ?
>why no man pages?
Right ... it just TO DO. Use the GNU stuff ...
> why is the compiler support bound to watcom ?
Watcom is one of the best compilers ... was a good decision.
But there are also other C compiler available, AFAIK.
> why no DCOM support when CORBA is much more expensive ?
DCOM is not an open standard ... it's a proprietary communication
platform from M$. CORBA is an open standard !
>Where is Java?
It's late ... but QSSL is working on it.
>Why to pay for a Internet suite when a lot of other systems support this for
>>free ?
That's marketing ...........
>Where are the books about writing device drivers for QNX ?
Customer orientation is the issue ...... no excuse allowed!
Armin Steinhoff
Igor N Kovalenko
Armin Steinhoff <Ar...@de.Steinhoff.de> wrote in article
<647tql$5...@drn.zippo.com>...
>
> In article <01bced67$b82c59e0$64930cc0@ta_sn_1>, "Johannes says...
> >
> >Jonathan Michaels <j...@caamora.com.au> wrote in article
> ><wgcid$13$g1000$h107$i0$j461...@caamora.com.au>...
> >
> >why is this thread QNX vs. Linux and not QNX & Linux ???
>
> good question ...
>
Yep, this is really unholy war. Linux has real enemies and QNX too.
Sometimes the same :-)
> >why not an open FLEET network protocol that is understood by
> >Linux or Windows ?
>
> FLEET is proprietary to QNX and the base of the OS technologies are too
> different, so it would be very difficult to port FLEET to e.g. LINUX.
>
It is even harder because FLEET technology is unpublished and available
only for non-disclosure agreement. A silly approach, IMHO.
> > why not a filesystem that can be read by OS/2 or Windows ?
>
> It's available ... use SAMBA or the SMB client!
>
Nothing prevents some hard cool guy to write appropriate driver to read QNX
filesystem under any OS. This will allow them to coexist smoothly using
dual-boot.
I'm getting tempted periodically to do it for DOS/Win and Linux, just no
spare time (so yes, I'm hard cool) :~|
> >why is the driver architecture bound to QNX ?
>
> Because of the special QNX architecture ....
>
Any system use some specific tricks in drivers. Including all versions of
Unix. QNX driver architecture is most elegant I ever heard about.
> > why Photon and not XWindows at all ?
>
> XWindows is not usefull for small embedded systems ... but
> the better question is: why is PHOTON not more or less compatible
> to XWindows ?
>
Some package like Willows sure would exist, allowing to recompile Photon
apps for X. Probably it would be possible to recompile X for Photon, but
this will take much more work. I guess, QSSL will not do the last, but may
be the first, if they will see reasonable demand. Guys, if you would like
such feature, please tell to Dan :-)
> >why no man pages?
> Right ... it just TO DO. Use the GNU stuff ...
>
I think that QSSL should provide a QNX specific man version, which will try
HTML files first, then look at man pages if nothing available. This way it
will be compatible with both QNX help files and GNU man pages, which you
get when install some GNU package.
> > why is the compiler support bound to watcom ?
>
> Watcom is one of the best compilers ... was a good decision.
> But there are also other C compiler available, AFAIK.
>
GNU C does exist for QNX, although there are no libs. This may be solved
someday.
> > why no DCOM support when CORBA is much more expensive ?
>
> DCOM is not an open standard ... it's a proprietary communication
> platform from M$. CORBA is an open standard !
>
Sure, M$ 'standards' always have the same advantage: they are cheaper :~|
> >Where is Java?
> It's late ... but QSSL is working on it.
>
> >Why to pay for a Internet suite when a lot of other systems support this
for
> >>free ?
>
> That's marketing ...........
>
The most widely used browser is still Netscape, which is NOT free despite
of popular belief. Tools like mail/news readers are part of Netscape
either. Speaking about M$, yes you get everything for free there, because
Bill is crazy in attempts to kill Netscape. Note also, that MSIE is just
modified version of Mosaic, licensed to M$ NOT for free. So, you pay for it
indirectly (hidden price).
The price is the isuue, however. That's marketing. QSSL's proprietary
'marketing' ...
> >Where are the books about writing device drivers for QNX ?
>
> Customer orientation is the issue ...... no excuse allowed!
>
Because nobody cares to write one, due to low volume of market (in terms of
number of developers). It is big hard job to write a book, but who will
ever publish it?
Cheers,
Igor
Jonathan Michaels
Johannes Stratmann wrote in a message to All:
JS> Jonathan Michaels <j...@caamora.com.au> wrote in article
JS> <wgcid$13$g1000$h107$i0$j461...@caamora.com.au>...
JS> why is this thread QNX vs. Linux and not QNX & Linux ???
JS> why not an open FLEET network protocol that is understood by Linux
JS> or Windows ? why not a filesystem that can be read by OS/2 or
JS> Windows ?
JS> why is the driver architecture bound to QNX ? why Photon and not
JS> XWindows at all ?
JS> why no man pages ? why is the compiler support bound to watcom ?
JS> why no DCOM
JS> support when CORBA is much more expensive ? Where is Java ? Why to
JS> pay for a
JS> Internet suite when a lot of other systems support this for free ?
these are very good points johannes .. i an a fringe network dweller
and do not understand what makes a networrk tick over, but from my
point of view these are all very good points and would make life easier
from, at least this endusers (come beginging qn
x learner) poit of view.
JS> Where are the books
JS> about writing device drivers for QNX ?
thier was a good (good from the aspect a beginer understood what it was
all about) one put out by wiley, but that was 6 years ago, we used it
to do same basic look see at what was involved in serial (bothe rs232c
and rs422 or 488 stuff .. its too long ago
now sorry.
Geoff Roberts
On Wed, 12 Nov 1997 20:14:11 +0100, Johannes Stratmann
<jstra...@cww.de> wrote:
>Armin Steinhoff wrote:
>> >why is this thread QNX vs. Linux and not QNX & Linux ???
>>
>> good question ...
>
>> > why no DCOM support when CORBA is much more expensive ?
>>
>> DCOM is not an open standard ... it's a proprietary communication
>> platform from M$.
>
>parallel to the filesystem or network on QNX...
>
[snip]
>I think QSSL has a lot of customers that have to use both API's, and
>some would rather use Linux together with QNX.
Not this little black duck! :-)
I have a lot of friends who have Linux as they can't afford anything
else in the way of a UNIX, and based on their experience with it, I
wouldn't touch it with a barge pole. It's value I feel is in the fact
that it *does* teach people about UNIX per se, but as a serious
contender for industrial/high reliability (mission critical as they
say) applications, I personally rank it alongside NT. And that is not
very high.
Geoff Roberts.
>
>with kind regards, Johannes Stratmann
Paul J.Y. Lahaie
Geoff Roberts wrote:
> I have a lot of friends who have Linux as they can't afford anything
> else in the way of a UNIX, and based on their experience with it, I
> wouldn't touch it with a barge pole. It's value I feel is in the fact
> that it *does* teach people about UNIX per se, but as a serious
> contender for industrial/high reliability (mission critical as they
> say) applications, I personally rank it alongside NT. And that is not
> very high.
Perhaps your friends haven't read the HOWTOs or purchase cheap
hardware, but my experience with Linux is the opposite. I find it
remarkably stable (over 160 days of uptime on our main server).
It also has one of the best "bug" fix rates I've ever seen.
Ping-of-Death, Flood SYN, etc.. And as of today, it's one of a
few OSes that have fixes for the Pentium f00f bug (the one that
locks up your system because of a bug in Intel's chip).
Try it for yourself and see what it's like.
- Paul
Johannes Stratmann
Armin Steinhoff wrote:
> >why is this thread QNX vs. Linux and not QNX & Linux ???
>
> good question ...
> > why no DCOM support when CORBA is much more expensive ?
>
> DCOM is not an open standard ... it's a proprietary communication
> platform from M$.
parallel to the filesystem or network on QNX...
I've asked all this because Linux has brought new life to non-Windows
Systems. Of coarse, QNX is something because it is a realtime system,
but for some systems there is a need for realtime (or fast kernel) and a
GUI + Database. Now it depends on the relation of the RT Part and the
GUI if you decide for QNX or NT+SlaveCPU. QNX is much less known than NT
and even if there are technical advantages for QNX, someone may follow
the 'trend' and use NT. More difficult for the developer, but
(hopefully) easier for the end-user. This is true for our decision to
use NT+SlaveCPU.
When Linux is getting an accepted position for industrial applications,
its easier to vote for QNX (Realtime-Part) together with Linux (cheaper
GUI+additional Tools). But QNX (Posix API) + NT (Win32 API) are very
different worlds. You can connect both via TCP or SMB, but there are
many differences in detail and you will be busy enough to follow the
growing Win32 API's...
I think QSSL has a lot of customers that have to use both API's, and
some would rather use Linux together with QNX.
with kind regards, Johannes Stratmann
Geoff Roberts
On 16 Nov 1997 23:02:37 -0800, Vladimir Ivanovic
<vlad...@leonora.mri.com> wrote:
>g...@rtts.com.au (Geoff Roberts) writes:
>
>> ... but as a serious contender for industrial/high reliability
>> (mission critical as they say) applications, I personally rank it
>> [Linux] alongside NT. And that is not very high.
>
>Why?
If I were to answer that, I would undoubtably get emotional and
carried away, and start a flame war.
Besides, I don't have the time.
Anyway, there are people around who could answer much more eloquently
than myself.
And isn't this thread long enough now?
Geoff.
>
>-- Vladimir
>
>Vladimir G. Ivanovic home: (415) 328-5621
>2770 Cowper St. work: (408) 487-7242
>Palo Alto, CA 94306-2447 cellphone: (415) 987-8330
Truman Boyes
> Not this little black duck! :-)
>
> else in the way of a UNIX, and based on their experience with it, I
> wouldn't touch it with a barge pole. It's value I feel is in the fact
> contender for industrial/high reliability (mission critical as they
> very high.
>
> Geoff Roberts.
>
> >
> >with kind regards, Johannes Stratmann
And you speak on behalf of what OS? did I hear you correctly , that you
speak pro-UNIX? You say you want to run mission critical apps without a
problem... can you get the source for most of your apps?
--
_________
.--/ _____
\-----------------------------------------------------------------.
| (__) ___ (__) Truman Boyes III, President Sixmillion , Network
Admin. |
|Tru/ (___) \ \ tru...@defraz.org www.sixmillion.com
908-757-7823 |
`---\_______/_/----------------------------------------------------------------'
Pete Patterson
<SNIP>
> 3) Under the Linux development model, dozens to hundreds of desktop
> workstation
> advocates with no interest in realtime do the majority of development,
<SNIP>
Apparently, they churn out oodles of video drivers too.
Mike Davies
Even one for the Tecra 740 CDT ? :-)
Mike
Pete Patterson
> Perhaps your friends haven't read the HOWTOs or purchase cheap
> hardware, but my experience with Linux is the opposite. I find it
> remarkably stable (over 160 days of uptime on our main server).
>
... and your main server is serving ????
I assume it's an internet server. But if you've been up that long, Linux
must not have JAVA yet :-)
> It also has one of the best "bug" fix rates I've ever seen.
> Ping-of-Death, Flood SYN, etc.. And as of today, it's one of a
> few OSes that have fixes for the Pentium f00f bug (the one that
> locks up your system because of a bug in Intel's chip).
>
Wow! That's pretty neat. Our QA department would never let us go from
source to release that fast.
To be fair though, none of the items you mentioned are actually 'bugs', but
rather new requirements. If stealing manhole covers became a fad, you
wouldn't consider the fact that none of the existing ones have locks a bug,
would you?
> Try it for yourself and see what it's like.
Does it run Comanche 3.0?
Pete Patterson
Pete Patterson <pe...@qnx.com> wrote in article
<01bcfade$f097dfa0$651f35c6@pete>...
>
> >
> >
> > Even one for the Tecra 740 CDT ? :-)
> >
>
> Hey... if a Linux user owns one, then there is a video driver for it.
>
What am I thinking. A Linux user could never afford a laptop.
I retract my earlier comment.
Pete Patterson
Mike Davies <10061...@compuserve.com> wrote in article
<347bd97b...@news.compuserve.com>...
> On 26 Nov 1997 02:38:40 GMT, "Pete Patterson" <pe...@qnx.com> wrote:
>
> >
> ><SNIP>
> >> 3) Under the Linux development model, dozens to hundreds of desktop
> >> workstation
> >> advocates with no interest in realtime do the majority of development,
> ><SNIP>
> >
> >Apparently, they churn out oodles of video drivers too.
> >
>
> Even one for the Tecra 740 CDT ? :-)
>
Hey... if a Linux user owns one, then there is a video driver for it.
(your mileage may vary)
Paul J.Y. Lahaie
Pete Patterson wrote:
> ... and your main server is serving ????
>
> I assume it's an internet server. But if you've been up that long, Linux
> must not have JAVA yet :-)
175 days as of today and it's running:
Primary DNS, Dial-up, shell accounts for ~20 users (all running a decent
shell - bash), imapd, pop3, ftp, www, smtp and cached web,ftp,gopher
proxy.
It might be doing more, but that's what comes off the top of my
head.
All from a 486-66 w/ 32MB of RAM.
> Wow! That's pretty neat. Our QA department would never let us go from
> source to release that fast.
BSDI had a fix available the day before. I guess to them having an
OS that couldn't easily be crashed by a usermode program was more
important
to release as beta then to let their customers hanging on a limb.
> To be fair though, none of the items you mentioned are actually 'bugs', but
> rather new requirements. If stealing manhole covers became a fad, you
> wouldn't consider the fact that none of the existing ones have locks a bug,
> would you?
Ping-of-Death is a bug. It's not properly checking the size of an
ICMP
ECHO RESPONSE packet before putting it together. teardrop is a bug (not
doing
proper bounds checking on IP fragments). f00f is also a bug. By your
analogy,
if you drive over certain manhole covers with certain cars in certain
ways
it causes the vehicle to explode. Should you go replace those manhole
covers?
> Does it run Comanche 3.0?
I was unaware there was a QNX version.
- Paul