which way to go? Linux or QNX?

QNX Newsgroups (Archives) qdn.public.qnxrtp.advocacy
21

I will agree across the board with Rick’s comments.

I will add this: QNX4 is a better performer IF it offers all of the
features you require.
QNX6 is definitely more versatile.

All that aside, new development on QNX4 has ended. There won’t be any new
device drivers written unless someone pays for it. This alone can be a show
stopper. But if you can develop an application with generic off the shelf
components then QNX4 is my choice. I can develop a sophisticated
application with graphics and networking using QNX4 in 16 MB. I can’t
(hardly) log in in text mode in QNX6 in 16 MB.

“Rick Duff” <rick@astranetwork.com> wrote in message
news:3D88908A.217A9919@astranetwork.com…

Kris Warkentin wrote:

Superior thread and SMP support, better Posix compliance, better
development
tools (Eclipse), more hosts (Windows, Solaris, Linux, RTP), more targets
(x86, arm, sh4, xscale, mips, powerpc), better networking support…
I’m
sure others could list more yet.


I was considering holding back my reply to this, but since it IS in the
advocacy group, I just had to reply. > :slight_smile:

Superior thread and SMP support.

Given there was only application level threading in QNX4 and no SMP, it
make it easy to be superior.

better Posix compliance

True.

better development tools (Eclipse)

Not in 1000 years. I will give you the gcc route is better only because
of the portability issues, not because it is a better compiler. Anyone
who thinks Eclipse is better is only thinking that because they believe
any IDE is better than no IDE. Since I can still stick with command line
tools, I will continue to do so.

More hosts

One of QNX’s strength (IMHO) has always been self hosting. Since this
is true for both versions, it only matter to those who want to give up
the advantages of self hosting.

more targets

Yes, this is definitely a great advantage. It allows you to postpone
the hardware choice (in some designs) til later in the process, thus
choosing the latest processor, regardless if it was even the same family
that you started with.

better networking support

In that you have a newer tcp stack and support IPv6, true. I am not
convinced you have either the stability or performance that you had in
QNX4. And certainly QNET is no where near as useful in QNX6 as it is in
QNX4.

Other advantages of QNX6 include documented DDK’s and BSP’s. It is very
easy (in relative terms) to bring QNX up on any new board which has
adequate documentation.

On the other hand, QNX6 has neither the stability or performance that we
came to expect with QNX4.

Having said all of that, I have used QNX4 since it was still an alpha
quality product which forced you to reboot back to QNX2 in order to
report bugs and have used QNX6 since it was only Neutrino 1.0. On a day
to day basis, I develop in QNX6 and will continue to do that for any
projects I have a choice over. It has it’s issues, but it is well on
it’s way to be the superior product that QNX4 is.

Rick…

Rick Duff Internet: > rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL:
http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479

22

camz@passageway.com wrote:
: Alain Magloire <alain@qnx.com> wrote:
:> Your choice, the command line tools will not go away anytime soon.

: They should not go away EVER.

No one is suggesting this.

:> But the IDE will still improve and provide ergonomic ways to do things
:> like System Information, Profiling, Tracing, Debuguing etc …
:> True, the IDE is still young, there is on going work to make it
:> a first class environment.

: There is one HUGE, MASSIVE issue with ALL IDEs and that is that they
: force a particular “work flow”. If the work flow they enforce matches
: how you develop then the IDE will seem very intuitive, and very useful.
: If your personal work flow differs from what the IDE enforces, then you
: have problems. In this scenario, the IDE is seen to be non-intuitive,
: and the cause of much frustration as well as forcing additional and/or
: unnecessary steps.

: The painful reality is that we do not all work in the same way, so an
: IDE can NEVER satisfy everyone. The Eclipse IDE can actually exaggerate
: this furthur due to it’s plug-in design. Each plugin can have its own
: work flow, which may or may not be “compatible” with the end user’s
: work flow, or even with other plug-ins. That means that as more and more
: plugins become available for Eclipse, the effort of making them all
: consistent can be quite daunting or simple impossible with multiple
: vendors are involved.

Yes, very, very good points.

: Providing basic development functionality exclusively in the IDE is a
: HUGE mistake IMHO. The debugger is a prime example of this. Customers
: that have purchased PE can use the debugger in Eclipse which works the
: way most of us expect a debugger to. Customers that have purchased SE
: are no better off in terms of debugger usability that those using NC,
: this is hardly a differentiator for the commercial SE offering.

: QSS needs to be very careful that they do not lock required development
: functionality exclusively into the IDE.

:> In any case, what your saying goes the opposite of what customers/sales etc …
:> been saying; to get better integrated tools. Arcane command line, a la
:> Unix hacker is hardly sufficient.
:>
:> Lots of youngster out of school seems to be lost, if they do not have
:> Windows or visual basic.
:> </off topic>

: We never said the IDE was not important.
: I agree that many inexperienced developers seem lost without an IDE
: to guide them. That is a sad situation, but with experience the dependance
: on such tools declines unless no alternatives are provided. Blindingly
: following the requests of the newest/least experienced developers as the
: strategic plan is destined for failure. Pay heed to the comments from the
: experienced camp. We are not always making noise because we no not like
: change. We embrace change, but only when it provides value.

Same here, we(I) never said that there was a favorism to a particular group.
It is about choice. If you choose to use the command line tools, because
it is faster and more efficient for you, do.


: The reality of the “get better integrated tools” is more a requirement to
: make the QNX development environment easier to compare with those from
: your competitors. Don’t forget that QNX offers an option for development
: that they do NOT provide, namely self-hosted. This should not be overlooked.
: If the only way to develop for your OS is xdev from windows, then command
: line tools are not a viable option, you HAVE to provide an IDE, or leverage
: an existing one. That means that most QNX competitors can not viably offer
: command line tools. This is an advantage that QNX has, and it should be
: leveraged, promoted, and marketed as such. I realise that QSS has seen
: a significant number of requests for xdev, to the point were the value of
: self-hosted is ignored by the marketing materials. This is a mistake, QSS
: needs to get it through their heads that self-hosted is one of the BIGGEST
: differentiators that QNX has over it’s competitors, the promotional
: materials should indicate the advantage of this. There IS a measurable
: increase in productivity in the self-hosted environment.

Fine points. But there are demands for xdev and those tools have to
be as stable as the stand-alone counterpart, so effort was refocus to
this. But saying that standalone will be abandonned, …?

: And don’t confuse self-hosted with the IDE either, it’s available there too.

??
Not sure where you get that I’m confusing IDE with self-hosted. My main focus
was command line tools vs IDE usual religious war.
Same old same old, whether you are on GNU/Linux, Solaris or QNX.
Do not know if on windows this is an issue.

23

Rennie Allen <rallen@csical.com> wrote:
: Alain Magloire wrote:
:> Rennie Allen <rallen@csical.com> wrote:
:>
:> Eclipse JDT(Java developement) is probably one of the best out there,
:> and getting better(see Eclipse-2.0.1).

: My experience is with Eclipse 1.0, 2.0, and 2.0.1 when I refer to it’s
: capabilities I am refering to the latest and greatest.

Did you notice there was a … COBOL DT ! :sunglasses:
chaperon by fujitsu, they released some snapshots.
I heard about ADA and SmallTalk too :sunglasses:

:> : PS: one can only be more productive in Eclipse after it’s loaded :wink:
:>
:> :sunglasses:, touche’!
:> At this moment, it’s not a priority, maybe the gcj(Gcc Java compiler) will
:> help in the very long run :sunglasses:

: I leave Eclipse running all the time. The only problem with that, is
: the memory usage; but, memories cheap, so I am not suggesting changing
: priorities (a complete CDT definately is what I see as the #1 prio).

Agreed.

24

Robert Krten <nospam83@parse.com> wrote:
: camz@passageway.com wrote:
:> Alain Magloire <alain@qnx.com> wrote:
:>> Your choice, the command line tools will not go away anytime soon.

:> They should not go away EVER.

: I’ll second that!

:>> But the IDE will still improve and provide ergonomic ways to do things
:>> like System Information, Profiling, Tracing, Debuguing etc …
:>> True, the IDE is still young, there is on going work to make it
:>> a first class environment.

:> There is one HUGE, MASSIVE issue with ALL IDEs and that is that they
:> force a particular “work flow”. If the work flow they enforce matches
:> how you develop then the IDE will seem very intuitive, and very useful.
:> If your personal work flow differs from what the IDE enforces, then you
:> have problems. In this scenario, the IDE is seen to be non-intuitive,
:> and the cause of much frustration as well as forcing additional and/or
:> unnecessary steps.

: Not only that, but IDEs (and GUIs in general) are impossible to automate.
: You can’t write a script that moves the mouse, clicks on “File”, pulls down
: a menu, and clicks on a selection at 2 am based on a cron script!
: This means that for automated build, regression testing, and a host of
: other issues (which can be the basis of a flamewar) GUI-based tools
: are completely useless. Hence, we need command lines to be guaranteed
: to be around forever.

:sunglasses: finally the truth … it’s all about job security.

Wrong example, wrong tool. If you want to automate you do not need a GUI, but
to write the script that automates the build, a GUI could come handy!
How many times, I’ve &$#^&#^ on Solaris when doing “crontab -e”
to find myself in the “advanced” and very “ergonomic”
“ex” editor, &$##^ piece of &$*&#^).

25

Alain Magloire wrote:

Rick Duff <> rick@astranetwork.com> > wrote:
: Kris Warkentin wrote:
:
:> Superior thread and SMP support, better Posix compliance, better development
:> tools (Eclipse), more hosts (Windows, Solaris, Linux, RTP), more targets
:> (x86, arm, sh4, xscale, mips, powerpc), better networking support… I’m
:> sure others could list more yet.
:

: I was considering holding back my reply to this, but since it IS in the
: advocacy group, I just had to reply. > :slight_smile:

Same here > :sunglasses:

…

:> better development tools (Eclipse)

: Not in 1000 years. I will give you the gcc route is better only because
: of the portability issues, not because it is a better compiler. Anyone

The Integrated Developement Environment(IDE) will use whatever tools to do
the job. You have issues with gcc, ok, but not the same problem.

: who thinks Eclipse is better is only thinking that because they believe
: any IDE is better than no IDE. Since I can still stick with command line
: tools, I will continue to do so.

Your choice, the command line tools will not go away anytime soon.
But the IDE will still improve and provide ergonomic ways to do things
like System Information, Profiling, Tracing, Debuguing etc …
True, the IDE is still young, there is on going work to make it
a first class environment.

My impression is that not only the eclipse IDE is still young … also
the FILE SYSTEM is still in a ‘Kinder Garten’ state.

I have build a platform independend PROFIBUS DP configurator based on
Python 2.2.1/PyQt which works under QNX 6.2. SUSE LINUX and Win NT.
Importing of Python modules take remarkable longer under QNX6.

Loading is 4 times slower compared with LINUX, 10 times slower compared
with Win NT !!

Loading of JAVA archives/ modules is real pain … that’s make the IDE
realy clumsy.

What about improvements of the FILE SYSTEM … not to mention the
fs-cifs ???

Cheers

Armin


In any case, what your saying goes the opposite of what customers/sales etc …
been saying; to get better integrated tools. Arcane command line, a la
Unix hacker is hardly sufficient.
off topic
Lots of youngster out of school seems to be lost, if they do not have
Windows or visual basic.
/off topic

PS:
BTW, I’m an “old” Unix hacker, and will not touch anything but vi/make
but will not push my way of working on others.

Of course:
#include “disclaimer.h”
etc …

26

Armin <a-steinhoff@web.de> wrote:
: Alain Magloire wrote:
:> Rick Duff <rick@astranetwork.com> wrote:
:> : Kris Warkentin wrote:
:> :>
:> :> Superior thread and SMP support, better Posix compliance, better development
:> :> tools (Eclipse), more hosts (Windows, Solaris, Linux, RTP), more targets
:> :> (x86, arm, sh4, xscale, mips, powerpc), better networking support… I’m
:> :> sure others could list more yet.
:> :>
:>
:> : I was considering holding back my reply to this, but since it IS in the
:> : advocacy group, I just had to reply. :slight_smile:
:>
:> Same here :sunglasses:
:>
:> …
:>
:> :> better development tools (Eclipse)
:>
:> : Not in 1000 years. I will give you the gcc route is better only because
:> : of the portability issues, not because it is a better compiler. Anyone
:>
:> The Integrated Developement Environment(IDE) will use whatever tools to do
:> the job. You have issues with gcc, ok, but not the same problem.
:>
:> : who thinks Eclipse is better is only thinking that because they believe
:> : any IDE is better than no IDE. Since I can still stick with command line
:> : tools, I will continue to do so.
:>
:> Your choice, the command line tools will not go away anytime soon.
:> But the IDE will still improve and provide ergonomic ways to do things
:> like System Information, Profiling, Tracing, Debuguing etc …
:> True, the IDE is still young, there is on going work to make it
:> a first class environment.

: My impression is that not only the eclipse IDE is still young … also

Yes, the IDE is young, and still need or rather will be improve.
But when it comes to finding the “right” look & feel to please
all, just changing the color seem to bring a flow of agressivity/feedback.
Everyone knows the “right” way to do GUI … which is different to
anyone else.

I’ll trade for a kernel debugging session any day.

: the FILE SYSTEM is still in a ‘Kinder Garten’ state.

: I have build a platform independend PROFIBUS DP configurator based on
: Python 2.2.1/PyQt which works under QNX 6.2. SUSE LINUX and Win NT.
: Importing of Python modules take remarkable longer under QNX6.

: Loading is 4 times slower compared with LINUX, 10 times slower compared
: with Win NT !!

: Loading of JAVA archives/ modules is real pain … that’s make the IDE
: realy clumsy.

: What about improvements of the FILE SYSTEM … not to mention the
: fs-cifs ???

: Cheers

: Armin


:>
:> In any case, what your saying goes the opposite of what customers/sales etc …
:> been saying; to get better integrated tools. Arcane command line, a la
:> Unix hacker is hardly sufficient.
:>
:> Lots of youngster out of school seems to be lost, if they do not have
:> Windows or visual basic.
:> </off topic>
:>
:> PS:
:> BTW, I’m an “old” Unix hacker, and will not touch anything but vi/make
:> but will not push my way of working on others.
:>
:> Of course:
:> #include “disclaimer.h”
:> etc …
:>
:>

27

Alain Magloire <alain@qnx.com> wrote:

Robert Krten <> nospam83@parse.com> > wrote:
: > camz@passageway.com > wrote:
:> Alain Magloire <> alain@qnx.com> > wrote:
:>> Your choice, the command line tools will not go away anytime soon.

:> They should not go away EVER.

: I’ll second that!

:>> But the IDE will still improve and provide ergonomic ways to do things
:>> like System Information, Profiling, Tracing, Debuguing etc …
:>> True, the IDE is still young, there is on going work to make it
:>> a first class environment.

:> There is one HUGE, MASSIVE issue with ALL IDEs and that is that they
:> force a particular “work flow”. If the work flow they enforce matches
:> how you develop then the IDE will seem very intuitive, and very useful.
:> If your personal work flow differs from what the IDE enforces, then you
:> have problems. In this scenario, the IDE is seen to be non-intuitive,
:> and the cause of much frustration as well as forcing additional and/or
:> unnecessary steps.

: Not only that, but IDEs (and GUIs in general) are impossible to automate.
: You can’t write a script that moves the mouse, clicks on “File”, pulls down
: a menu, and clicks on a selection at 2 am based on a cron script!
: This means that for automated build, regression testing, and a host of
: other issues (which can be the basis of a flamewar) GUI-based tools
: are completely useless. Hence, we need command lines to be guaranteed
: to be around forever.

:sunglasses: > finally the truth … it’s all about job security.

Not quite… :slight_smile:

Wrong example, wrong tool. If you want to automate you do not need a GUI, but
to write the script that automates the build, a GUI could come handy!

Yes, “could” come in handy; provided you then have the wherewithall to edit the
(possibly) horrible output the GUI generated into something that’s maintainable
by mere humans, and fixup any inadequacies introduced by the GUI.

I said “GUIs in general” – there are too many programs out there
that have a GUI-ONLY interface. Bad. Very bad. (In fact, you could reverse your
argument and state almost equivalently, “if you want to automate you need a command
line” – this is the “I’ll second that” part of my original comment above :slight_smile:)

How many times, I’ve &$#^&#^ on Solaris when doing “crontab -e”
to find myself in the “advanced” and very “ergonomic”
“ex” editor, &$##^ piece of &$*&#^).

Are you suggesting that crontab -e should be GUI-ized? How would that look?
To take an extreme example, let’s GUI-ize VI’s regular expressions :slight_smile: “Please
select a beginning match pattern from the following, or if you do not wish
to have an anchored expression, or if you wish to not match a pattern”.
And that’s just the first freakin’ character! :slight_smile: Unless you want to “defeat”
the whole style and spirit of the gui and just have people enter a command line
anyway :slight_smile:

There are far too many people who’ve been GUI-ized into thinking that everything
that’s possible to do with a tool has to involve some kind of clicking and
pull-down menus. Bah! Show me an editor that’s as powerful as VI where the
main interface is done with a GUI. Microsoft Word doesn’t even come close (as
an editor; as a word processor it’s a different kettle of fish).

My main gripe comes from when I was doing the video training. The “video editor”
program, which one would say “excellent example of a thing that should be based on
a GUI”, (and also, to an extent, an “IDE for Video Editing”) had the following problems:
a) unable to select an import order for a whack of files. The only choice
was to click, scroll, and click to “select all” (or a subset). By adding
more grief to the GUI developer, I would have been able to select
“import from file list”, but it still would have involved some non-GUI
“editor” to massage the list in the first place.
b) file size limit was 2G; thus in order to create the 55G file I needed,
I had to manually select 2G worth of stuff, click, save to file, wait
2.5 hours, select the next 2G worth of stuff, click, save to file,
wait 2.5 hours… Totally un-automatable. Since the attitude taken
by the developers of this tool was “the GUI is the be-all and end-all
interface”, there was no way to batch this process.

And that’s just the tip of the iceberg.

Another counter-argument, is that earlier in this thread, it was stated that
(paraphrasing, accurately I hope) “the amount of time spent learning a GUI
is not one day, it’s somewhat equivalent to the amount of time spent learning
the command line tool”. Ok, but as I understand it, the whole point of the
GUI was so that you could learn it in one day. If that’s not the case,
why do I need two interfaces to the same thing?

Flame away!

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

28

Rennie Allen <rallen@csical.com> wrote:

Robert Krten wrote:

Not only that, but IDEs (and GUIs in general) are impossible to automate.

Impossible is a strong word.

Ok, “impossible given today’s level of AI” :slight_smile:
Or, “impossible on most implementations of GUI-based products” :slight_smile:

You can’t write a script that moves the mouse, clicks on “File”, pulls down
a menu, and clicks on a selection at 2 am based on a cron script!

Actually, you can (at least on Windows). Rational has a tool called
Visual Test that does exactly that. We use it here and it performs well
for us. Could we theoretically use it to do automated builds ? Yes.
Would it be the easiest and most convenient way to do automated builds ?
No.

I think I’m gonna hurl! :slight_smile:

This means that for automated build, regression testing, and a host of
other issues (which can be the basis of a flamewar) GUI-based tools
are completely useless.

Again, “completely useless” is a strong phrase. Visual Test is most
definately not “completely useless”.

Ok, “completely useless to me” :slight_smile: (I did say “flamewar”, right? :slight_smile:)

Hence, we need command lines to be guaranteed
to be around forever.

Forever is a very long time > :slight_smile:

“Forever or until such time as curmudgeons like RK are around” :slight_smile:

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

29

Robert Krten <nospam83@parse.com> wrote:

This means that for automated build, regression testing, and a host of
other issues (which can be the basis of a flamewar) GUI-based tools
are completely useless.

Again, “completely useless” is a strong phrase. Visual Test is most
definately not “completely useless”.

It will be interesting to know if they support QNX, or any rational
tools support qnx.

frank

Ok, “completely useless to me” :slight_smile: (I did say “flamewar”, right? :slight_smile:)

30

All that aside, new development on QNX4 has ended. There won’t be any new
device drivers written unless someone pays for it. This alone can be a show
stopper. But if you can develop an application with generic off the shelf
components then QNX4 is my choice. I can develop a sophisticated
application with graphics and networking using QNX4 in 16 MB. I can’t
(hardly) log in in text mode in QNX6 in 16 MB.

And I can’t find a COTS PC today with less then 128M, most come with 256M.
And the implication you are making is that Neutrino is unable to run in a
system with networking, graphics, and applications in less then 16M. This
is untrue. Check http://qnxzone.com/eQip/ - a full PDA environment with
kernel, flash filesystem, serial drivers, audio system, networking,
system services (hotswap and the like), photon, handwriting recognition,
PDA front-end and a webbrowser running in about 12M. This is stock
Neutrino and Photon 2 with no effort to reduce memory useage.

chris

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

31

Robert Krten wrote:

Ok, but as I understand it, the whole point of the
GUI was so that you could learn it in one day. If that’s not the case,
why do I need two interfaces to the same thing?

Why do you need 2 interfaces to do the same thing ?

Why does one use both a hammer and a screwdriver when building a house ?

… because although one can embed a screw into a stud with a hammer,
it lacks efficiency, and the results are not typically satisfactory.

Screwdrivers were not developed to make fastening easier (or faster) to
learn than with hammers; screwdrivers were developed to create bindings
a different way than those created with hammers.

For CLI and GUI development tools the goal is the same (as it is with
nailing and screwing), however, the properties of the process are
different, and lend themselves differently.

Surely you are trolling, Rob :slight_smile:

Rennie

32

Alain Magloire wrote:

Armin <> a-steinhoff@web.de> > wrote:
: Alain Magloire wrote:
:> Rick Duff <> rick@astranetwork.com> > wrote:
:> : Kris Warkentin wrote:
:> :
:> :> Superior thread and SMP support, better Posix compliance, better development
:> :> tools (Eclipse), more hosts (Windows, Solaris, Linux, RTP), more targets
:> :> (x86, arm, sh4, xscale, mips, powerpc), better networking support… I’m
:> :> sure others could list more yet.
:> :
:
:> : I was considering holding back my reply to this, but since it IS in the
:> : advocacy group, I just had to reply. > :slight_smile:
:
:> Same here > :sunglasses:
:
:> …
:
:> :> better development tools (Eclipse)
:
:> : Not in 1000 years. I will give you the gcc route is better only because
:> : of the portability issues, not because it is a better compiler. Anyone
:
:> The Integrated Developement Environment(IDE) will use whatever tools to do
:> the job. You have issues with gcc, ok, but not the same problem.
:
:> : who thinks Eclipse is better is only thinking that because they believe
:> : any IDE is better than no IDE. Since I can still stick with command line
:> : tools, I will continue to do so.
:
:> Your choice, the command line tools will not go away anytime soon.
:> But the IDE will still improve and provide ergonomic ways to do things
:> like System Information, Profiling, Tracing, Debuguing etc …
:> True, the IDE is still young, there is on going work to make it
:> a first class environment.

: My impression is that not only the eclipse IDE is still young … also

Yes, the IDE is young, and still need or rather will be improve.
But when it comes to finding the “right” look & feel to please
all, just changing the color seem to bring a flow of agressivity/feedback.
Everyone knows the “right” way to do GUI … which is different to
anyone else.

The GUI is completely uninteresting when we talk about Eclipse.( → SWT)

Any comments about the file system ??

pfm take hours to copy the contents of a directory from one system to an
other. It takes few seconds with an equivalent tar file :slight_smile:

Armin


I’ll trade for a kernel debugging session any day.

: the FILE SYSTEM is still in a ‘Kinder Garten’ state.

: I have build a platform independend PROFIBUS DP configurator based on
: Python 2.2.1/PyQt which works under QNX 6.2. SUSE LINUX and Win NT.
: Importing of Python modules take remarkable longer under QNX6.

: Loading is 4 times slower compared with LINUX, 10 times slower compared
: with Win NT !!

: Loading of JAVA archives/ modules is real pain … that’s make the IDE
: realy clumsy.

: What about improvements of the FILE SYSTEM … not to mention the
: fs-cifs ???

: Cheers

: Armin


:
:> In any case, what your saying goes the opposite of what customers/sales etc …
:> been saying; to get better integrated tools. Arcane command line, a la
:> Unix hacker is hardly sufficient.
:> Lots of youngster out of school seems to be lost, if they do not have
:> Windows or visual basic.
:> </off topic
:
:> PS:
:> BTW, I’m an “old” Unix hacker, and will not touch anything but vi/make
:> but will not push my way of working on others.
:
:> Of course:
:> #include “disclaimer.h”
:> etc …
:
:

33

“Chris McKillop” <cdm@qnx.com> wrote in message
news:amc0vj$4gv$1@nntp.qnx.com…

All that aside, new development on QNX4 has ended. There won’t be any
new
device drivers written unless someone pays for it. This alone can be a
show
stopper. But if you can develop an application with generic off the
shelf
components then QNX4 is my choice. I can develop a sophisticated
application with graphics and networking using QNX4 in 16 MB. I can’t
(hardly) log in in text mode in QNX6 in 16 MB.

Who gives a shit about how much RAM it takes to develop software.
Come on Bill get over it.

As far as memory required for a target QNX6 needs more ram then QNX4,
but not that much.

From what I know VxWorks uses less RAM then QNX4, I haven`t seen
you use that argument against QNX4 :wink:

And I can’t find a COTS PC today with less then 128M, most come with 256M.
And the implication you are making is that Neutrino is unable to run in a
system with networking, graphics, and applications in less then 16M. This
is untrue. Check > http://qnxzone.com/eQip/ > - a full PDA environment with
kernel, flash filesystem, serial drivers, audio system, networking,
system services (hotswap and the like), photon, handwriting recognition,
PDA front-end and a webbrowser running in about 12M. This is stock
Neutrino and Photon 2 with no effort to reduce memory useage.

chris

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

34

Armin <a-steinhoff@web.de> wrote:

Any comments about the file system ??

pfm take hours to copy the contents of a directory from one system to an
other. It takes few seconds with an equivalent tar file > :slight_smile:

Armin, I’m not sure what your issue is, but you need to learn how to
interpret the results you get. If pfm takes a long time and tar does
not, well… they BOTH use the filesystem, so that means that it is NOT
the problem.

Cheers,
Camz.

35

Rennie Allen <rallen@csical.com> wrote:

Robert Krten wrote:

Ok, but as I understand it, the whole point of the
GUI was so that you could learn it in one day. If that’s not the case,
why do I need two interfaces to the same thing?

Why do you need 2 interfaces to do the same thing ?

Why does one use both a hammer and a screwdriver when building a house ?

… because although one can embed a screw into a stud with a hammer,
it lacks efficiency, and the results are not typically satisfactory.

Screwdrivers were not developed to make fastening easier (or faster) to
learn than with hammers; screwdrivers were developed to create bindings
a different way than those created with hammers.

For CLI and GUI development tools the goal is the same (as it is with
nailing and screwing), however, the properties of the process are
different, and lend themselves differently.

Surely you are trolling, Rob > :slight_smile:

But of course; people were complaining about how quiet the newsgroups
were lately, so I was just doing my bit to help out :slight_smile:

Cheers,
-RK

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

36

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

“Alain Magloire” <> alain@qnx.com> > wrote in message

Wrong example, wrong tool. If you want to automate you do not need a GUI,
but
to write the script that automates the build, a GUI could come handy!
How many times, I’ve &$#^&#^ on Solaris when doing “crontab -e”
to find myself in the “advanced” and very “ergonomic”
“ex” editor, &$##^ piece of &$*&#^).

Don’t hold back Alain. Let it all out. You’ll feel better.

Yes, and then tell us more Alain, about how you’re a “vi and make”
man and then go ahead and complain about “ex” :slight_smile: :slight_smile:

[For the “vi” challenged; from “ex” you just type “vi” and you’re
in visual mode; I missed that last night in my rant :slight_smile:]

Cheers,
-RK


\

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

37

“Alain Magloire” <alain@qnx.com> wrote in message

Wrong example, wrong tool. If you want to automate you do not need a GUI,
but
to write the script that automates the build, a GUI could come handy!
How many times, I’ve &$#^&#^ on Solaris when doing “crontab -e”
to find myself in the “advanced” and very “ergonomic”
“ex” editor, &$##^ piece of &$*&#^).

Don’t hold back Alain. Let it all out. You’ll feel better.

38

%% nospam83@parse.com (Robert Krten) writes:

rk> “Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

“Alain Magloire” <> alain@qnx.com> > wrote in message

Wrong example, wrong tool. If you want to automate you do not
need a GUI, but to write the script that automates the build, a
GUI could come handy! How many times, I’ve &$#^&#^ on Solaris
when doing “crontab -e” to find myself in the “advanced” and very
“ergonomic” “ex” editor, &$##^ piece of &$*&#^).

Don’t hold back Alain. Let it all out. You’ll feel better.

rk> Yes, and then tell us more Alain, about how you’re a “vi and make”
rk> man and then go ahead and complain about “ex” :slight_smile: :slight_smile:

What I don’t get is how a “vi and make” man doesn’t know about
$EDITOR…?

:slight_smile:

–

Paul D. Smith <pausmith@nortelnetworks.com> HASMAT–HA Software Mthds & Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad Scientist

These are my opinions—Nortel Networks takes no responsibility for them.

39

Paul D. Smith <pausmith@nortelnetworks.com> wrote:
: %% nospam83@parse.com (Robert Krten) writes:

: rk> “Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

: >> “Alain Magloire” <alain@qnx.com> wrote in message

: >>> Wrong example, wrong tool. If you want to automate you do not
: >>> need a GUI, but to write the script that automates the build, a
: >>> GUI could come handy! How many times, I’ve &$#^&#^ on Solaris
: >>> when doing “crontab -e” to find myself in the “advanced” and very
: >>> “ergonomic” “ex” editor, &$##^ piece of &$*&#^).

: >> Don’t hold back Alain. Let it all out. You’ll feel better.

: rk> Yes, and then tell us more Alain, about how you’re a “vi and make”
: rk> man and then go ahead and complain about “ex” :slight_smile: :slight_smile:

ex is to vi, a lada to a porshe^H^H^H^H^HSubaru.

: What I don’t get is how a “vi and make” man doesn’t know about
: $EDITOR…?

Usually it was: EDITOR=/usr/bin/vi crontab -e
But my sysadmin habits was not the point of the post.
This was on SunOS-4.1(.3), there version of “ex” was … enough said.

I see you bullies are trying to raise my blood pressure …
… Don’t worry be happy.

40

It makes sense that copying one large file across qnet is going to take
a lot shorter time than recursively copying numerous short files. There
are many more control messages to be sent.

Now I’m not claiming that pfm is doing this in as efficient manner as it
could be, but you see my point.

But even on qnx4 doing something like

tar -cf - srcdir | (cd destdir; on -f10 tar -xvf -)

was much faster than cp -cRvp . Perhaps pfm should use a similar mechanism?

Armin <a-steinhoff@web.de> wrote:

camz@passageway.com > wrote:
Armin <> a-steinhoff@web.de> > wrote:

Any comments about the file system ??


pfm take hours to copy the contents of a directory from one system to an
other. It takes few seconds with an equivalent tar file > :slight_smile:


Armin, I’m not sure what your issue is, but you need to learn how to
interpret the results you get.

Well … you have to learn to interpret (or to understand) my statements
in a logical way.

If pfm takes a long time and tar does not, well…

You have to differenciate between the tar command and a tar file.
I thought it is evident that a tar file means usually a *.tar file.

they BOTH use the filesystem, so that means that it is NOT
the problem.

Again … the problem is that a COPY/PASTE action on a directory
take hours between two QNET nodes … the copy of a previous built tar
archive of the same directory takes seconds.

Hope this is understandable ??

Oh … I just forgot to mention that this recursive copy between two
nodes works also incomplete. Lots of subdirectories has not been not copied.

Selecting a bunch of files for deletion doesn’t work … only one file
will be deleted if the rigth mouse button has been used.

pfm shows not all directories if a file filter is set …

Is it possible to port the pfm from Photon 1.14 ??
This beast works …

Armin



PS.: this is written with the Xlib Mozilla 1.1 + XPhoton.
Works great!!



–
cburgess@qnx.com