Where are we now?

[rectech]

From the cited reference below:

Q0.2.1: What does “negligible performance penalty” mean?

A: Well, lxrun is not really an emulator, in that it’s not really doing any
emulation work. You can think of it more as a layer that
sits between the Linux binary and the rest of the system doing a few translations
here and there where it’s necessary. When
are these translations necessary? When the Linux binary attempts a system call.
The rest of the time, lxrun is dormant and
does not affect the performance of your application at all.

Igor Kovalenko wrote:

Armin Steinhoff wrote:

Igor Kovalenko wrote:

[ clip ..]
lxrun is not emulator either.

Sorry it is an Linux emulator …

http://www.ugcs.caltech.edu/~steven/lxrun/lxrun-FAQ.html#Q0.0


The fact that somebody used the word ‘emulator’ to describe it does not
change anything. People often use words without paying attention to
their meaning. In some sense it is ‘emulator’ since it ‘emulates’ Linux
kernel behavior. But it does so not by running some kind of virtual
system (like VMWare). The term ‘emulator’ is inherently associated with
performance penalties paid to emulate something. That’s not the case
with lxrun, so I don’t think the term is correctly applied.

lxrun is more of a ‘Linux personality’ coexisting with native OS. For
example, OS/2 used to execute Windows programs, would you call it
‘emulator’ because of that?

It translates Linux systems calls into
equivalent system calls of supported OSes. Classicaly by trapping SIGSEGVs
and reconstructing calls, but they are moving toward direct execution (by
using very complicated loading techniques). Binary code is just executed
directly.

I would not call it ‘crappy’, not before writing something at least as
clever as that.

I have seen so many ‘crappy’ emulators or
converter-to-something-else in my life …
therefore I’m very sceptical about such solutions.

So I wouldn’t never get the idea to write such a
tool … and I have written much more usefull
stuff >

How do you know your stuff is much more useful?
Well, you sure have right to not show any respect to other people work.

• igor

[Igor_Kovalenko2]

Armin Steinhoff wrote:

Igor Kovalenko wrote:

[ clip ..]
lxrun is not emulator either.

Sorry it is an Linux emulator …

http://www.ugcs.caltech.edu/~steven/lxrun/lxrun-FAQ.html#Q0.0

The fact that somebody used the word ‘emulator’ to describe it does not
change anything. People often use words without paying attention to
their meaning. In some sense it is ‘emulator’ since it ‘emulates’ Linux
kernel behavior. But it does so not by running some kind of virtual
system (like VMWare). The term ‘emulator’ is inherently associated with
performance penalties paid to emulate something. That’s not the case
with lxrun, so I don’t think the term is correctly applied.

lxrun is more of a ‘Linux personality’ coexisting with native OS. For
example, OS/2 used to execute Windows programs, would you call it
‘emulator’ because of that?

It translates Linux systems calls into
equivalent system calls of supported OSes. Classicaly by trapping SIGSEGVs
and reconstructing calls, but they are moving toward direct execution (by
using very complicated loading techniques). Binary code is just executed
directly.

I would not call it ‘crappy’, not before writing something at least as
clever as that.

I have seen so many ‘crappy’ emulators or
converter-to-something-else in my life …
therefore I’m very sceptical about such solutions.

So I wouldn’t never get the idea to write such a
tool … and I have written much more usefull
stuff >

How do you know your stuff is much more useful?
Well, you sure have right to not show any respect to other people work.

• igor

[Armin_Steinhoff1]

Igor Kovalenko wrote:

Armin Steinhoff wrote:

Igor Kovalenko wrote:

[ clip ..]
lxrun is not emulator either.

Sorry it is an Linux emulator …

http://www.ugcs.caltech.edu/~steven/lxrun/lxrun-FAQ.html#Q0.0


The fact that somebody used the word ‘emulator’ to describe it does not
change anything.

The word emulator was introduced by the creator of
that piece of software.

People often use words without paying attention to
their meaning. In some sense it is ‘emulator’ since it ‘emulates’ Linux
kernel behavior. But it does so not by running some kind of virtual
system (like VMWare). The term ‘emulator’ is inherently associated with
performance penalties paid to emulate something. That’s not the case
with lxrun, so I don’t think the term is correctly applied.

lxrun is more of a ‘Linux personality’ coexisting with native OS. For
example, OS/2 used to execute Windows programs, would you call it
‘emulator’ because of that?

Ah … Windows is just a thick/fat binary layer
around the CPU … trying to emulate the behavior
of an operating system ) And you know how bad
it is …

It translates Linux systems calls into
equivalent system calls of supported OSes. Classicaly by trapping SIGSEGVs
and reconstructing calls, but they are moving toward direct execution (by
using very complicated loading techniques). Binary code is just executed
directly.

I would not call it ‘crappy’, not before writing something at least as
clever as that.

I have seen so many ‘crappy’ emulators or
converter-to-something-else in my life …
therefore I’m very sceptical about such solutions.

So I wouldn’t never get the idea to write such a
tool … and I have written much more usefull
stuff >

How do you know your stuff is much more useful?

Simply … it’s working in a productive
environment.

Igor, to avoid misunderstandings:
according the so called “Advanced”, the most used
European standard
dictionary for Oxford English, we have the
following definition:

useful adj.

1. helpful; producing good results: A spade is a
   useful tool
2. (colloq.) capable, efficient: He’s a useful
   member of a team

In this sense, useful software means for me
working in productive environment…

Well, you sure have right to not show any respect to other people work.

Igor, I’ve no reason not respecting other people
work … but I have a clear opinion about results.

OK … try to use X plus StarOffice on top of
lxrun (if it works at all?).
Makes it sense?

I’m afraid that this approach could end like the
other Windows emulation as mentioned at the
homepage of the Wine org.

Armin

[Igor_Kovalenko2]

Armin Steinhoff wrote:

The word emulator was introduced by the creator of
that piece of software.

I don’t think he wrote the FAQ himself.

lxrun is more of a ‘Linux personality’ coexisting with native OS. For
example, OS/2 used to execute Windows programs, would you call it
‘emulator’ because of that?

Ah … Windows is just a thick/fat binary layer
around the CPU … trying to emulate the behavior
of an operating system > > ) And you know how bad
it is …

How does that relate to my point above?

So I wouldn’t never get the idea to write such a
tool … and I have written much more usefull
stuff >

How do you know your stuff is much more useful?

Simply … it’s working in a productive
environment.

Igor, to avoid misunderstandings:
according the so called “Advanced”, the most used
European standard
dictionary for Oxford English, we have the
following definition:

useful adj.

1. helpful; producing good results: A spade is a
   useful tool
2. (colloq.) capable, efficient: He’s a useful
   member of a team

In this sense, useful software means for me
working in productive environment…

I know what ‘useful’ means. Trouble is, what you consider useful might
be not so for others. And what you consider crappy can be quite useful
for them.

Well, you sure have right to not show any respect to other people work.

Igor, I’ve no reason not respecting other people
work … but I have a clear opinion about results.

You’re free to have that opinion and free to express it, but there is
difference between ‘i consider that thing not useful’ and ‘that thing is
crappy and I wrote much more useful ones’. Opinions expressed in that
way sound very rude and unjustified. May be you don’t care, but being
polite is never wrong.

OK … try to use X plus StarOffice on top of
lxrun (if it works at all?).
Makes it sense?

For you not. Does not make it wrong for others.

I’m afraid that this approach could end like the
other Windows emulation as mentioned at the
homepage of the Wine org.

Wine was an attempt to emulate completely different and proprietary OS
with no official specs. Even then, it was successful enough to run large
number of applications. That project ended not because it was crappy,
but rather because Linux got enough applications to make Windows
emulation obsolete.

lxrun is different story. Specs are public and mapping can be reliably
done. Since Linux has more applications than any other Unix it makes
sense to run lxrun in some cases. In fact SCO went even farther and
introduced ‘Linux personality’ kernel module which I suspect is nothing
else but lxrun integrated directly into kernel. Unix kernels aren’t all
that different, at least those derived from AT&T code and nothing in
theory prevents them from being binary compatible. Even BSD can run some
Linux apps through iBCS.

Perhaps eventually we’ll see a unified Unix kernel interface, which
would allow all flavors to run apps of each other. And lxrun might well
be a starting point, due to popularity of Linux.

• igor

[Mario_Charest1]

I know what ‘useful’ means. Trouble is, what you consider useful might
be not so for others. And what you consider crappy can be quite useful
for them.

Well, you sure have right to not show any respect to other people
work.

Igor, I’ve no reason not respecting other people
work … but I have a clear opinion about results.


You’re free to have that opinion and free to express it, but there is
difference between ‘i consider that thing not useful’ and ‘that thing is
crappy and I wrote much more useful ones’. Opinions expressed in that
way sound very rude and unjustified. May be you don’t care, but being
polite is never wrong.

Could somebody pinch me, LOL!!!

Hey Igor I think it’s now obvious who you were
thinking of to carry on the t-shirt thingy.

When realities colide, it’s bond to make some sparks, hihi

• Mario

[Armin_Steinhoff1]

rectech wrote:

—> From the cited reference below:

Q0.0: What is “lxrun”?

A: It is a Linux x86 binary emulator for other x86
IX machines. Currently, the following platforms
are supported:
SCO OpenServer 5.0.x
SCO UnixWare 2.1. and 7.*
Sun Solaris 2.6 and 7 for x86

Armin

Q0.2.1: What does “negligible performance penalty” mean?

A: Well, lxrun is not really an emulator, in that it’s not really doing any
emulation work. You can think of it more as a layer that
sits between the Linux binary and the rest of the system doing a few translations
here and there where it’s necessary. When
are these translations necessary? When the Linux binary attempts a system call.
The rest of the time, lxrun is dormant and
does not affect the performance of your application at all.

Igor Kovalenko wrote:

Armin Steinhoff wrote:

Igor Kovalenko wrote:

[ clip ..]
lxrun is not emulator either.

Sorry it is an Linux emulator …

http://www.ugcs.caltech.edu/~steven/lxrun/lxrun-FAQ.html#Q0.0


The fact that somebody used the word ‘emulator’ to describe it does not
change anything. People often use words without paying attention to
their meaning. In some sense it is ‘emulator’ since it ‘emulates’ Linux
kernel behavior. But it does so not by running some kind of virtual
system (like VMWare). The term ‘emulator’ is inherently associated with
performance penalties paid to emulate something. That’s not the case
with lxrun, so I don’t think the term is correctly applied.

lxrun is more of a ‘Linux personality’ coexisting with native OS. For
example, OS/2 used to execute Windows programs, would you call it
‘emulator’ because of that?

It translates Linux systems calls into
equivalent system calls of supported OSes. Classicaly by trapping SIGSEGVs
and reconstructing calls, but they are moving toward direct execution (by
using very complicated loading techniques). Binary code is just executed
directly.

I would not call it ‘crappy’, not before writing something at least as
clever as that.

I have seen so many ‘crappy’ emulators or
converter-to-something-else in my life …
therefore I’m very sceptical about such solutions.

So I wouldn’t never get the idea to write such a
tool … and I have written much more usefull
stuff >

How do you know your stuff is much more useful?
Well, you sure have right to not show any respect to other people work.

• igor

[Armin_Steinhoff1]

Igor Kovalenko wrote:

Armin Steinhoff wrote:

The word emulator was introduced by the creator of
that piece of software.

I don’t think he wrote the FAQ himself.

However …
http://www.sco.com/skunkware/emulators/#lxrun

lxrun is more of a ‘Linux personality’ coexisting with native OS. For
example, OS/2 used to execute Windows programs, would you call it
‘emulator’ because of that?

Ah … Windows is just a thick/fat binary layer
around the CPU … trying to emulate the behavior
of an operating system > > ) And you know how bad
it is …
How does that relate to my point above?

Not directly … has probably something to do with
humor… ?

[ clip … ]

I know what ‘useful’ means. Trouble is, what you consider useful might
be not so for others. And what you consider crappy can be quite useful
for them.

OK … crappy may be a too strong word … but I
said never that my view is the only one.

[clip ..]

You’re free to have that opinion and free to express it, but there is
difference between ‘i consider that thing not useful’ and ‘that thing is
crappy and I wrote much more useful ones’.

It’s not the right interpretation of my
statement… my statement was related to your
polite(?) statement: “I would not call it
‘crappy’, not before writing something at least as
clever as that.”

Opinions expressed in that way sound very rude and unjustified.
May be you don’t care, but being polite is never wrong.

Reality and facts are often not polite … even if
there are brilliant ideas.
I believe there are lots of other open source
projects for which it makes more sense to support
them. However, excuse my usage of the word
‘crappy’ ..

OK … try to use X plus StarOffice on top of lxrun (if it works at all?).
Makes it sense?

For you not. Does not make it wrong for others.

I’m afraid that this approach could end like the
other Windows emulation as mentioned at the
homepage of the Wine org.


Wine was an attempt to emulate completely different and proprietary OS
with no official specs. Even then, it was successful enough to run large
number of applications. That project ended not because it was crappy,

AFAIK … Wine is still alife, but there are other
dead projects for M$ emulators.

but rather because Linux got enough applications to make Windows
emulation obsolete.

lxrun is different story. Specs are public and mapping can be reliably
done.

Yes … but the reality is also that lxrun has to
support a fast moving MULTI HEADED target (RedHat,
SUSE, Debian, Caldera, VALinux a.s.o).

So I see a lot of work with a bad effort/result
ratio … but the justification of that work would
lead again to the area of existentialism. (see
Camus/Mario

IMHO … it makes more sense to re-install the
XFree86 project than fiddle around with lxrun …
well, I express here only MY opinion.

[ clip ..]

Perhaps eventually we’ll see a unified Unix kernel interface, which
would allow all flavors to run apps of each other. And lxrun might well
be a starting point, due to popularity of Linux.

IMHO … the best starting point is
http://www.unix-systems.org. A single UNIX
specification would help to avoid lxrun.

OK, peace! You celebrate Christmas tomorrow.
Igor, Merry Christmas for you and your family,

Armin

P.S.
a UK guy told me recently in London that the
Americans and the British are splitted by their
commom English language…

[Igor_Kovalenko2]

Armin Steinhoff wrote:

Yes … but the reality is also that lxrun has to
support a fast moving MULTI HEADED target (RedHat,
SUSE, Debian, Caldera, VALinux a.s.o).

Don’t they all share the same kernel? lxrun does not care much about
other differences. Of course, if you want to run software designed for
Redhat you’d need to install Redhat libraries, but that it outside of
scope of lxrun, really.

Besides, SCO (main driving force behind lxrun) now belongs to Caldera
(which is why SCO krnel now will support Linux binaries directly).

IMHO … it makes more sense to re-install the
XFree86 project than fiddle around with lxrun …
well, I express here only MY opinion.

There are things for which source is not available. Besides, building
something from source is not always an easy exersize, even for
experienced porters. Sometimes is it just too time consuming and tedious
task. Certainly it is not a way for huge number of ‘ordinary’ users.

[ clip ..]
Perhaps eventually we’ll see a unified Unix kernel interface, which
would allow all flavors to run apps of each other. And lxrun might well
be a starting point, due to popularity of Linux.

IMHO … the best starting point is
http://www.unix-systems.org> . A single UNIX
specification would help to avoid lxrun.

OK, peace! You celebrate Christmas tomorrow.
Igor, Merry Christmas for you and your family,

Suddenly I feel a surge of orthodoxianism
Merry Cristmas to all ‘gloriously right’ (that’s how we ‘orthodoxes’
call ourselves in russian) >:}

For all those who does not know why do we celebrate cristmas at this
time of year, our Gloriously Right Church simply ignores the edict of
Pope (since he has no jurisdiction over us) which changed the calendar.
Thus, we’re 2 weeks behind. We ignored it even in real life, until 1918
when The Great Leader of Working Class comrade Lenin overturned that.
Which prompts me to think that not only he was a German agent (for those
who don’t know, Germany funded the Great October Socialist Revolution),
but a Vatican agent as well. However, he prefered to not enforce his
jurisdiction over our Gloriously Right Church (since he wanted priests
to become KGB agents) so here we are, still 2 weeks behind with Cristmas
(and so with Easter, obviously).

Armin

P.S.
a UK guy told me recently in London that the
Americans and the British are splitted by their
commom English language…

So now you’re british and I’m american

Two gentlemen under Big Ben are waiting for something. One asks another:
‘How much watch’? ‘Six much watch’ he answers. ‘Oh, you’re from Moscow
too!’…

• igor

[rectech]

So what is everyone’s stand on weather lxrun is worth working on for QRTP? I
will have sometime to work on it but not enough to do everything. Is there
other interest?

KenR

Chris McKillop wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

The project would be big enough, yes but so are benefits. Besides, once
initial porting is done it could be maintained by community (if you’re
indeed going to publish most of sources). The only thing we can’t
eficiently do ourselves is resolving all issues with integration.
Trapping all SIGSEGVs (in a classical lxrun way) is inefficient and
lxrun development is shifting away from it, but implementing other
methods requires intimate knowledge of OS which we do not have. You’re
essentially holding the ball in your court.


Okay igor - here is what I can offer you. I would love to work on this
but I don’t have time. But, what I will offer is to be the point man
@ QSSL when the intimate details need to be hashed out. So you get
some people going on this and I will help when you get stuck. How does
that sound?

chris (who wanted lxrun before he worked @ QNX too!)

–

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

[Stephen_Thomas]

rectech <rectech@iname.com> wrote in message
news:3A565DA4.20F0C335@iname.com…

So what is everyone’s stand on weather lxrun is worth working on for QRTP?
I
will have sometime to work on it but not enough to do everything. Is
there
other interest?

KenR

IMHO, lxrun is cool but there are MANY things I would prefer to see QNX
spend more time on, e.g.:

• QNet fully functional (ala QNX4 FLEET)
• Open Source availability
• DMA fsys drivers
• native ports of Linux apps
• docs
• legacy QNX4 support

I am not saying QSSL is doing a bad job at any of these things; I just would
throw more resources into any of these before I would Lxrun. If they would
hurry up and release their source this would not be an issue anyway!

Politely yours,
Stephen

Chris McKillop wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

The project would be big enough, yes but so are benefits. Besides,
once
initial porting is done it could be maintained by community (if you’re
indeed going to publish most of sources). The only thing we can’t
eficiently do ourselves is resolving all issues with integration.
Trapping all SIGSEGVs (in a classical lxrun way) is inefficient and
lxrun development is shifting away from it, but implementing other
methods requires intimate knowledge of OS which we do not have. You’re
essentially holding the ball in your court.


Okay igor - here is what I can offer you. I would love to work on
this
but I don’t have time. But, what I will offer is to be the point man
@ QSSL when the intimate details need to be hashed out. So you get
some people going on this and I will help when you get stuck. How does
that sound?

chris (who wanted lxrun before he worked @ QNX too!)

–


cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

[Armin_Steinhoff1]

Stephen Thomas wrote:

rectech <> rectech@iname.com> > wrote in message
news:> 3A565DA4.20F0C335@iname.com> …
So what is everyone’s stand on weather lxrun is worth working on for QRTP?
I will have sometime to work on it but not enough to do everything. Is
there other interest?

KenR

IMHO, lxrun is cool but there are MANY things I would prefer to see QNX
spend more time on, e.g.:

• QNet fully functional (ala QNX4 FLEET)
• Open Source availability
• DMA fsys drivers
• native ports of Linux apps

IMHO, the best and the fastest way to realize
native ports of LINUX apps is possible with
XFree86. The availablity of thread support for QNX
RTP opens up the door for the port of lots of
stable running X applications.

For instance, the debugger DDD works flawless with
XFree86 … but there are still problems with the
same DDD under Xphoton. That’s also the case with
lots of other X based development tools … e.g.
the Qt ‘designer’

----> If XFree86 makes sense … then for
QNX RTP <----

• docs
• legacy QNX4 support >

I am not saying QSSL is doing a bad job at any of these things; I just would
throw more resources into any of these before I would Lxrun. If they would
hurry up and release their source this would not be an issue anyway! >

Yes … it would also help to realize AGP support
for the graphics controllers for XFree86

Why do we need a ‘binary interpreter’ … when we
are able to recompile the (open source) LINUX apps
??

Armin

[Igor_Kovalenko2]

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A583812.69AF87F0@web_.de…

IMHO, the best and the fastest way to realize
native ports of LINUX apps is possible with
XFree86. The availablity of thread support for QNX
RTP opens up the door for the port of lots of
stable running X applications.

For instance, the debugger DDD works flawless with
XFree86 … but there are still problems with the
same DDD under Xphoton. That’s also the case with
lots of other X based development tools … e.g.
the Qt ‘designer’

Armin, did you try to answer yourself, what is it you’re trying to achive? I
mean the big picture…

Your personal goal is clear, you want rich development environment for your
(quite specific) needs and you don’t want to wait while it becomes available
under Photon. Neither you want to help with development of that stuff. You
simply don’t like the programming model of Photon and want to enjoy ‘true OO
programming’ offered by your favorite X tools.

However, this is QNX advocacy group and its general idea is to promote
concepts and development being of interest of the whole community. Let’s ask
what benefit QNX community will get if you convince enough people to switch
to X?

From end-users perspective it will become something very odd. Looks like
Linux but not quite there. Does not run Linux apps, ha! It will never become
better Linux than Linux. Meanwhile people will be distracted from Photon and
that will slow down its development since it is driven by demand.

From developers perspective there will be little sense to do development
under QNX at all, unless they are writing QNX drivers and need GUI just for
development, like yourself. Those writing GUI stuff will stick to Linux
since it is better for X anyway. Those writing for Photon will have hard
time since end users will be distracted.

From OEMs perspective, it will loose some of its value. I think OEMs doing
GUI stuff like Photon for its features. If they wanted X they’d will just go
with Linux. Believe you or not, Photon is selling point and a big one.

From QNX perspective, they might simply loose this whole game if OEMs will
turn them down. They are in a vulnerable position since they started the RTP
thing. Either win big time or loose big time.

Now what you will benefit if the above happens?

Why do we need a ‘binary interpreter’ … when we
are able to recompile the (open source) LINUX apps
??

Now it is ‘binary interpreter’? Come on Armin, this is ridiculous. Read the
white paper, not just FAQ.

• igor

[Armin_Steinhoff1]

Igor Kovalenko wrote:

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A583812.69AF87F0@web_.de…

IMHO, the best and the fastest way to realize
native ports of LINUX apps is possible with
XFree86. The availablity of thread support for QNX
RTP opens up the door for the port of lots of
stable running X applications.

For instance, the debugger DDD works flawless with
XFree86 … but there are still problems with the
same DDD under Xphoton. That’s also the case with
lots of other X based development tools … e.g.
the Qt ‘designer’


Armin, did you try to answer yourself, what is it you’re trying to achive?
I mean the big picture…

Lets go back to the original context.

:> IMHO, lxrun is cool but there are MANY things I
would prefer to see QNX
:> spend more time on, e.g.:
:> + QNet fully functional (ala QNX4 FLEET)
:> + Open Source availability
:> + DMA fsys drivers
:> + native ports of Linux apps

I did just a statement to the issue above … what
is wrong with it ?

Your personal goal is clear, you want rich development
environment for your (quite specific) needs

There are no ‘quite specific’ needs … but I
have to work efficently!

and you don’t want to wait while it becomes available under Photon.

So I have to stop my business for monthes …
years?
My customers and my competition don’t wait!
BTW … there are a lot of PhAB developers waiting
since years for the possibility to place text
vertically =:-/

Neither you want to help with development of that stuff.

Just a blanked statement …PhAB isn’t an Open
Source project.

You simply don’t like the programming model of Photon

Why do you got that idea?
However .. tell me why PhAB is not developed
further as the IDE for QNX?? The market is
asking for it!!

and want to enjoy ‘true OO programming’ offered by your favorite X tools.

Is it unethical to enjoy ‘true-OO programming’
??
Since more than 15 years .. lots of GUI developers
are enjoying OO-programming

However, this is QNX advocacy group and its general idea is to promote
concepts and development being of interest of the whole community.

That’s exactly, what I’m doing.
Since QSSL is ‘open source’ and ‘LINUX compatible’
… XFree86 is surely the interest of the
community. Isn’t it?? BTW, StarOffice is an X
application.

Do you believe ‘open source’ and ‘LINUX
compatibility’ is only a marketing hype?? … and
‘LINUX compatibility’ is only appreciated at
console level??

Let’s ask what benefit QNX community will get if you convince enough
people to switch to X?

Igor … every piece of software which supports
QNX RTP is absolutely positive for QNX RTP. I
consider it being positive because of the
customers of RTP have the choice between two
windowing systems … so they can choose the best
tool for their applications. Also … competition
is always positve even if it happens between two
windowing systems.

Also … you can hardly use X in embedded
applications … so nobody can simply ‘switch’ to
X. IMHO .. X is just the possibilty to build an
efficient self hosted development environment,
workstation applications and to penetrate the
LINUX market with hard real-time capabilities.

From end-users perspective it will become something very odd.
Looks like Linux but not quite there.

With XFree86 … it looks exactly like LINUX.
What’s your point ?

Does not run Linux apps, ha!

Not yet many … but with the port of KDE 2.0 to
QNX RTP there will be a lot of applications.

It will never become better Linux than Linux.

That’s clearly not the goal … even if RTP can
replace smoothly LINUX RT solutions The goal
is LINUX compatibility and the possibility to use
LINUX applications/tools with RTP. As you know …
every piece of software which works with RTP
should be considered as positive.

Also the ‘target positioning’ of QNX RTP and LINUX
is absolutely different … how can they compete
against each other?

Meanwhile people will be distracted from Photon and
that will slow down its development since it is driven by demand.

In my common sense … they have just to speed up
their Photon development in order to attract
OEMs and other people. (placing texts vertically,
animation, … IDE )

From developers perspective there will be little sense to do development under QNX at all,

Huh … you prefer to do cross development under
QNX4, M$, Solaris and LINUX? I can’t believe …
Makes it no sense to use PhAB under QNX??

unless they are writing QNX drivers and need GUI just for development, like yourself.

That’s a complete narrowed view of my business.
Yes, as you know I do system development, but I
have also to provide GUI based multi platform
apps, configuration tools and visualization tools
for IEC 61131-3 development packages etc.

Those writing GUI stuff will stick to Linux since it is better for X anyway.

Hm … I believe they will stick to ‘LINUX tools’.
So we have to provide these tools for QNX RTP.

Those writing for Photon will have hard time

I don’t think so … there are additional tools
available for Photon: Tilcon TRTD, CPhoton,
PyDACHS and others.
To avoid misunderstandings: “additional” doesn’t
mean “replacing” !

since end users will be distracted.

That’s mostly the case if a file manager doesn’t
support drag and drop and the task bar get lost
behind other windows!

From OEMs perspective, it will loose some of its value.

How can an OS loose of its value when there are
offered more applications and tools ?? Come on
Igor, it’s absurd.

I think OEMs doing GUI stuff like Photon for its features.
If they wanted X they’d will just go with Linux.

Sounds very pessimistic. X for RTP gives them just
the possibility to use X for RTP instead of using
LINUX.
BTW, do you know how many talks we have with Linux
guys who want reliable realtime by minimizing
their efforts to migrate to QNX RTP ???

Believe you or not, Photon is selling point and a big one.

You must have here some wrong ideas about what I
believe and what I don’t believe. Photon is a very
nice embeddable windowing system and not a
religion. Photon is obviouly a selling point …
but that’s not a reason to rest. It must be
developed further to attract new OEMs and
developers.

If Photon is really a strategic issue … where
is the DEMO DISK for QNX RTP?? Is nobody able at
QSSL to develop it again ??

From QNX perspective, they might simply loose this whole game if OEMs will turn them down.

That’s always the issue if a company rely on only
a few big customers.
So they have to open up other markets … to
survive.

What could really kill QSSL that’s their marketing
and sales strategy.

They are in a vulnerable position since they started the RTP
thing. Either win big time or loose big time.

X will surely strengthen their position …
because of applications which are available
immediateley!

Now what you will benefit if the above happens?

May be IBM, Cisco or Motorola are waiting to buy
that company ??

Why do we need a ‘binary interpreter’ … when we
are able to recompile the (open source) LINUX apps
??

Now it is ‘binary interpreter’? Come on Armin, this is ridiculous. Read the
white paper, not just FAQ.

I read the initial paper from M. Davidson … he
called his emulator a ‘binary interpreter’

Cheers,
Armin

If XFree86 makes sense … then for QNX RTP <<

[rectech]

These items are for QNX to work on lxrun is for us (outside of QNX) to work on.

Stephen Thomas wrote:

rectech <> rectech@iname.com> > wrote in message
news:> 3A565DA4.20F0C335@iname.com> …
So what is everyone’s stand on weather lxrun is worth working on for QRTP?
I
will have sometime to work on it but not enough to do everything. Is
there
other interest?

KenR

IMHO, lxrun is cool but there are MANY things I would prefer to see QNX
spend more time on, e.g.:

• QNet fully functional (ala QNX4 FLEET)
• Open Source availability
• DMA fsys drivers
• native ports of Linux apps
• docs
• legacy QNX4 support >

I am not saying QSSL is doing a bad job at any of these things; I just would
throw more resources into any of these before I would Lxrun. If they would
hurry up and release their source this would not be an issue anyway! >

Politely yours,
Stephen


Chris McKillop wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

The project would be big enough, yes but so are benefits. Besides,
once
initial porting is done it could be maintained by community (if you’re
indeed going to publish most of sources). The only thing we can’t
eficiently do ourselves is resolving all issues with integration.
Trapping all SIGSEGVs (in a classical lxrun way) is inefficient and
lxrun development is shifting away from it, but implementing other
methods requires intimate knowledge of OS which we do not have. You’re
essentially holding the ball in your court.


Okay igor - here is what I can offer you. I would love to work on
this
but I don’t have time. But, what I will offer is to be the point man
@ QSSL when the intimate details need to be hashed out. So you get
some people going on this and I will help when you get stuck. How does
that sound?

chris (who wanted lxrun before he worked @ QNX too!)

–


cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

[Igor_Kovalenko2]

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A59C066.9D0A0A48@web_.de…

:> IMHO, lxrun is cool but there are MANY things I
would prefer to see QNX
:> spend more time on, e.g.:
:> + QNet fully functional (ala QNX4 FLEET)
:> + Open Source availability
:> + DMA fsys drivers
:> + native ports of Linux apps

I did just a statement to the issue above … what
is wrong with it ?

I did not say anything is wrong. You expressed your view, I expressed mine.

You simply don’t like the programming model of Photon

Why do you got that idea?

I guess I got that impression from your statements about OO programming.
Photon is not OO, so you must not like it

However .. tell me why PhAB is not developed
further as the IDE for QNX?? The market is
asking for it!!

I don’t want to repeat others but market is asking for many things. USB
support is quickly becoming critical issue for example. And QNX is still
small company with limited number of developers. It is not easy to grow but
you are asking them to jump from 5 year old boy to a 20 year old overnight.

and want to enjoy ‘true OO programming’ offered by your favorite X
tools.

Is it unethical to enjoy ‘true-OO programming’
??

Where did I say that? I simply stated that you want it, I neither said nor
implied that it is wrong. To reaffrim you, there is nothing wrong with that
indeed.

Igor … every piece of software which supports
QNX RTP is absolutely positive for QNX RTP. I
consider it being positive because of the
customers of RTP have the choice between two
windowing systems … so they can choose the best
tool for their applications. Also … competition
is always positve even if it happens between two
windowing systems.

I disagree here. Having 2 (even 3) competing windowing systems for QNX4 is
our past experience. I don’t believe many people enjoyed it, especially
those who choosed ‘wrong’ system for their development, just to watch it
eventually die.

Such situation splits development efforts which are not enough even for one
system. It also splits users and thus makes market for each system smaller,
which makes development even more problematic.

Also … you can hardly use X in embedded
applications … so nobody can simply ‘switch’ to
X. IMHO .. X is just the possibilty to build an
efficient self hosted development environment,
workstation applications and to penetrate the
LINUX market with hard real-time capabilities.

That will however mean death of Photon. Nobody will even bother to write
apps for it if X becomes major desktop environment. There is no joy in
writing something for an environment you don’t live in everyday. It will
become ‘embedded-only’ and eventually will see the fate of QNX Windows.

From end-users perspective it will become something very odd.
Looks like Linux but not quite there.

With XFree86 … it looks exactly like LINUX.
What’s your point ?

Point is, it is not enough to just look like Linux. Many systems look like
Linux but neither has the same popularity. Think of FreeBSD.

Does not run Linux apps, ha!

Not yet many … but with the port of KDE 2.0 to
QNX RTP there will be a lot of applications.

I’m talking about Linux apps ‘in the box’ which you can already buy in
retail shops. They won’t run (unless of course lxrun will be fully
developed). Regular users just won’t bother with ‘configure; make; make
install’.

It will never become better Linux than Linux.

That’s clearly not the goal … even if RTP can
replace smoothly LINUX RT solutions > > The goal
is LINUX compatibility and the possibility to use
LINUX applications/tools with RTP. As you know …
every piece of software which works with RTP
should be considered as positive.

We’re talking about windowing system, not just ‘piece of software’. People
(normal people) DO NOT ‘run’ windowing systems. They very much consider it
part of OS and moreover they consider it ‘face’ of OS. Have you been ever
asked ‘who needs DOS when there is Norton Commander’? From their perspective
having 2 different windowing systems is confusion, not a benefit. Which
applications to buy, huh? Which means for developers ‘which applications to
write?’

Also the ‘target positioning’ of QNX RTP and LINUX
is absolutely different … how can they compete
against each other?

They can and they do. TiVO runs Linux, it could run NTO. Sony Playstation 2
as well. And Audrey could use Linux.

Meanwhile people will be distracted from Photon and
that will slow down its development since it is driven by demand.

In my common sense … they have just to speed up
their Photon development in order to attract
OEMs and other people. (placing texts vertically,
animation, … IDE )

Yes indeed, speed up development of Photon and meanwhile push X as
solution, right? So by the time Photon is ready noone needs it…

Huh … you prefer to do cross development under
QNX4, M$, Solaris and LINUX? I can’t believe …

You better believe. We do prefer Solaris cross development for number of
reasons.

Makes it no sense to use PhAB under QNX??

What for if major desktop environment is X, as you’re proposing?

That’s a complete narrowed view of my business.
Yes, as you know I do system development, but I
have also to provide GUI based multi platform
apps, configuration tools and visualization tools
for IEC 61131-3 development packages etc.

I see where your attraction to X comes from

Those writing GUI stuff will stick to Linux since it is better for X
anyway.

Hm … I believe they will stick to ‘LINUX tools’.
So we have to provide these tools for QNX RTP.

Let’s say one is writing a multiplatform code using POSIX/X interfaces. Show
me a single reason to do it on QNX when it can be done on Linux. If code
must run on other systems it can be as well developed on other systems.

That’s mostly the case if a file manager doesn’t
support drag and drop and the task bar get lost
behind other windows!

Ouch! Steve, this is all your fault!

From OEMs perspective, it will loose some of its value.

How can an OS loose of its value when there are
offered more applications and tools ?? Come on
Igor, it’s absurd.

Think about it. If OS vendor and user/developer base is split between 2
different environments and not enough efforts is being made for either one,
can it lead to OS loosing value or not?

In real life if enough users will be switched to X then Photon development
will pretty much freeze and Photon will sure loose its value. Which means
QNX will loose too. Is it such an absurd?

You must have here some wrong ideas about what I
believe and what I don’t believe. Photon is a very
nice embeddable windowing system and not a
religion. Photon is obviouly a selling point …
but that’s not a reason to rest. It must be
developed further to attract new OEMs and
developers.

We have different views on how to attract developers. I believe that people
do most exciting stuff just for fun and to have that fun they need to really
live in the environment they are working for. If they live in X, then we can
write off Photon.

X will surely strengthen their position …
because of applications which are available
immediateley!

I asked you already, but will again. Did the fact that OS/2 supported
Windows applications strengthen OS/2 position? It sure did strengthen
Windows position, that’s what I think

I read the initial paper from M. Davidson … he
called his emulator a ‘binary interpreter’ >

Hmm. Call it 1:0

• igor

[John_Doe]

“Bill at Sierra Design” <BC@SierraDesign.com> wrote in message
news:932fv4$sce$1@inn.qnx.com…
[…]

I don’t think that the royalty is for the data (movie) it is for the
protocol (DVD).
Still, your point is valid. We are paying twice. I believe that the
royalty should be paid by the DVD hardware manufacturers.

No. The MPAA “forced” (i.e. said that they wouldn’t release any content on
DVD unless the mfgs complied) the DVD manufacturers to pay them royalties on
each unit sold in order to compensate them for potential losses due to
illegal copying.

[…]

P.S. Of course I would never illegally copy anything!

Unless, of course, the MPAA ticked you off so much (by making you pay the
royalty twice, and not making Windoze users pay twice) you lost any remorse
you may have had… right

What really irritates me is that Windoze users don’t pay twice (or twice as
much) even though the vast majority or piracy occurs in that group…

btw: I saw a marvelous show on Discovery about Piranhas; some of the scenes
were great metaphores for the current napster/gnutella situation

[Bill_at_Sierra_Desig]

So again, where do I sign up for this class action law suit?


John Doe <john@csical.com> wrote in message news:93d7s6$90q$1@inn.qnx.com…

“Bill at Sierra Design” <> BC@SierraDesign.com> > wrote in message
news:932fv4$sce$> 1@inn.qnx.com> …
[…]

I don’t think that the royalty is for the data (movie) it is for the
protocol (DVD).
Still, your point is valid. We are paying twice. I believe that the
royalty should be paid by the DVD hardware manufacturers.

No. The MPAA “forced” (i.e. said that they wouldn’t release any content
on
DVD unless the mfgs complied) the DVD manufacturers to pay them royalties
on
each unit sold in order to compensate them for potential losses due to
illegal copying.

[…]

P.S. Of course I would never illegally copy anything!

Unless, of course, the MPAA ticked you off so much (by making you pay the
royalty twice, and not making Windoze users pay twice) you lost any
remorse
you may have had… right >

What really irritates me is that Windoze users don’t pay twice (or twice
as
much) even though the vast majority or piracy occurs in that group…

btw: I saw a marvelous show on Discovery about Piranhas; some of the
scenes
were great metaphores for the current napster/gnutella situation >

[Martin_Zimmerman]

Previously, John Doe wrote in qdn.public.qnxrtp.advocacy:

No. The MPAA “forced” (i.e. said that they wouldn’t release any content on
DVD unless the mfgs complied) the DVD manufacturers to pay them royalties on
each unit sold in order to compensate them for potential losses due to
illegal copying.

The silly thing about that, puts it (almost) in the same league as the
“tax” on blank audio tapes and blank CD-R/RW media in Canada. If you
are being forced to pay for the crime before it is even committed, or
actually on the chance that it might be commited, why not commit it?

If you make me pay and I haven’t done anything wrong, how can actually
doing that “wrong something” be any worse? Punishments are supposed to
deter you from committing the crime, not create an incentive for it.

Cheers,
Camz.

–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting

[Andrew_Thomas1]

Previously, Martin Zimmerman wrote in qdn.public.qnxrtp.advocacy:

The silly thing about that, puts it (almost) in the same league as the
“tax” on blank audio tapes and blank CD-R/RW media in Canada. If you
are being forced to pay for the crime before it is even committed, or
actually on the chance that it might be commited, why not commit it?

Actually, I think you could argue that if you have already paid for a
particular activity, and the vendor has set the price, then the vendor
has achieved what the lawyers call “satisfaction”, and there is no
crime. You are merely performing the act for which you have paid.
This is normal commerce.

The problem seems to arise if the information you are copying is owned
by a vendor who does not get any revenue from this “tax”. Just make
sure that the music you copy is produced by artists represented by the
MPAA.

Incidentally, I don’t think the tax on blank CDs ever came into effect
in Canada. I know you can buy CDs for $0.40 CDN (that’s $0.27 in real
money). My pet theory is that it may have been due to just this kind
of legal interpretation.

Andrew

[Andrew_Thomas1]

Previously, Armin Steinhoff wrote in qdn.public.qnxrtp.advocacy:

Igor Kovalenko wrote:

[ clip .. ]

If you force Photon to compete with X now, it might loose and die.
[…]
Nobody can prevent that available development
tools or widgets libraries for X will be ported
and be used under Xphoton. So everyone has the
possibility to port X apps or to build new X apps
using X tools.

It is just the choice of the customers which tools
they will (or can) use for their applications.

I think you are correct, Armin. User pressures will determine which
software survives and which does not.

To put my own interpretation on Igor (you can correct me if I’m
wrong, Igor), QSSL can only perform a finite amount of development,
and they must choose where that development should go. The user
marketplace can do a fine job of porting XFree86 and the assorted X
programs without any intervention from QSSL. Any effort in that
direction would be a diversion of scarce developers from other
activities, such as Photon development. Since Photon is a
differentiator for QSSL, it is paramount that it be developed so that
it can survive in competition with X, and therefore QNX can survive in
competition with Be, Red Hat, Microsoft, Wind River, etc.

By entering the “consumer” market, QSSL has altered their level of
dependence on third party software developers, whether companies or
amateurs. The acceptance of RtP will depend heavily on the software
that is available for it, and that software will depend on the
environments available for development. As users in this community,
we can influence people’s decisions as to which environments to
develop for. If we all start posting messages to the effect of “Use X
instead of Photon”, then new users will be swayed toward X. If we as
users generate enough drive in the direction of X, then the
preponderance of software development will be on X, and we will have
generated enough user pressure to make X the platform of choice. We
have the opportunity to do the same with Photon. I think if we split
the user community’s efforts between Photon and X, then we dilute both
environments rather than enhancing both (again, operating on the
theory that development effort is finite).

I think there are related effects to QSSL’s commercial customers.
QSSL has lost many potential sales in the past due to a lack of
software and a lack of qualified programmers for QNX4 and Photon.
Part of the RtP effort is to address these shortcomings. If we push
new users and developers away from QSSL’s real goal - to create a
strong user and programmer base for their market differentiators, then
we are doing QSSL a disservice. I would guess that trying to drive
adoption of X Windows within RtP is a fairly strong counter-pressure
to QSSL’s commercial goals.

So, to interpret Igor, the issue is not “X is better/worse than
Photon”, but rather that trying to influence user acceptance away from
Photon toward X is potentially damaging to QSSL and the rest of us.
As an “elder” in the QNX community, your voice is heard louder than
most, and your influence can be greater. That kind of power bears
some responsibility, and this thread is hopefully serving to point out
what that responsibility is.

Regards,
Andrew