QNX 4.25 Patch G avaliable... again

[Martin_Walter]

As the Subjest says, QNX 4.25 Patch G is available again, this time with a
new installation proceedure.

This is the same patch that was available before.
If you have alreday installed it, and sorted out any problems you had, then
you don’t need this.
If you downloaded and never installed, grab the new install notes.

The problems that people encountered were due to an incompatability with the
previously released Security Patch, leaving users unable to login, and or
backdated /etc/login and /etc/passwd files.

-Martin.

[Anders_Larsen1]

Martin Walter wrote:

As the Subjest says, QNX 4.25 Patch G is available again, this time with a
new installation proceedure.

Any chance this patch will be made available to those of us who have
been around since long before the CD installer was introduced?
Patch E is the last patch available in the Quics tree

Cheers
Anders

[Martin_Walter]

These patches will not be available on the old QUICS, nor will they be
packaged for installation without using phinstall. Contact your sales rep
for an update CD then you’ll have phinstall.

Don’t relay on QUICS being around for too much longer. IS keeps telling me
everything will be moved soon and QUICS will be no more.

-Martin.


“Anders Larsen” <al@alarsen.net> wrote in message
news:pan.2003.04.08.19.14.05.234471.1573@alarsen.net…

Martin Walter wrote:

As the Subjest says, QNX 4.25 Patch G is available again, this time
with a
new installation proceedure.

Any chance this patch will be made available to those of us who have
been around since long before the CD installer was introduced?
Patch E is the last patch available in the Quics tree >

Cheers
Anders

[Bill_Caroselli1]

Martin Walter <martin@qnx.com> wrote:

These patches will not be available on the old QUICS, nor will they be
packaged for installation without using phinstall. Contact your sales rep
for an update CD then you’ll have phinstall.

Don’t relay on QUICS being around for too much longer. IS keeps telling me
everything will be moved soon and QUICS will be no more.

-Martin.

I don’t want to beat a dead horse, but this is a mistake.

QUICS, or at least ftp.qnx.com, was very easy to use to grab just
specific things that are required.

Still, I realize that QSSL won’t listen to reason on this. So
no reply is necessary. I’ve come to expect that things that
are convienent for the customer just wont ever happen again.

[liug4]

Bill Caroselli <qtps@earthlink.net> wrote:

Martin Walter <> martin@qnx.com> > wrote:
These patches will not be available on the old QUICS, nor will they be
packaged for installation without using phinstall. Contact your sales rep
for an update CD then you’ll have phinstall.

Don’t relay on QUICS being around for too much longer. IS keeps telling me
everything will be moved soon and QUICS will be no more.

-Martin.



I don’t want to beat a dead horse, but this is a mistake.

QUICS, or at least ftp.qnx.com, was very easy to use to grab just
specific things that are required.

Still, I realize that QSSL won’t listen to reason on this. So
no reply is necessary. I’ve come to expect that things that
are convienent for the customer just wont ever happen again.

worse yet, the files on the CD are in tarx format, which is
QSS’ proprietary format and you have to use Photon installer
to install it. the old files on quics were plain tar file and
you can use text based /etc/install to install them, or just
untar to get the file you want. I am sure there are many cases
that you can’t use gui installer …
unntar to get the file you want.

[Rob1]

I couldn’t agree more… Why after years of supplying installs/updates in
the tar.F format would anyone in their right mind go and change to a new
proprietary format & installation utility for a product line that has been
officially deadened? What new customers would one hope to attract with this
GUI install interface? None, I would guess. So why leave long time
customers holding the bag with a 3 year old boot/install CD that is
incapable of detecting or supporting newer hardware (e.g. no Fsys.aha8scsi
nor newer graphics, networking etc. drivers on the CD) as the base level for
new installs and subsequent updates? I’m beginning to believe that this not
only lunacy, but some form of sadistic punishment!

-Rob

“liug” <liug@mama.indstate.edu> wrote in message
news:b7f627$hij$1@inn.qnx.com…

Bill Caroselli <> qtps@earthlink.net> > wrote:
Martin Walter <> martin@qnx.com> > wrote:
These patches will not be available on the old QUICS, nor will they be
packaged for installation without using phinstall. Contact your sales
rep
for an update CD then you’ll have phinstall.

Don’t relay on QUICS being around for too much longer. IS keeps
telling me
everything will be moved soon and QUICS will be no more.

-Martin.


I don’t want to beat a dead horse, but this is a mistake.

QUICS, or at least ftp.qnx.com, was very easy to use to grab just
specific things that are required.

Still, I realize that QSSL won’t listen to reason on this. So
no reply is necessary. I’ve come to expect that things that
are convienent for the customer just wont ever happen again.

worse yet, the files on the CD are in tarx format, which is
QSS’ proprietary format and you have to use Photon installer
to install it. the old files on quics were plain tar file and
you can use text based /etc/install to install them, or just
untar to get the file you want. I am sure there are many cases
that you can’t use gui installer …
unntar to get the file you want.

[Bill_Caroselli1]

Rob <rob@spamyouself.com> wrote:

I couldn’t agree more… Why after years of supplying installs/updates in
the tar.F format would anyone in their right mind go and change to a new
proprietary format & installation utility for a product line that has been
officially deadened? What new customers would one hope to attract with this
GUI install interface? None, I would guess. So why leave long time
customers holding the bag with a 3 year old boot/install CD that is
incapable of detecting or supporting newer hardware (e.g. no Fsys.aha8scsi
nor newer graphics, networking etc. drivers on the CD) as the base level for
new installs and subsequent updates? I’m beginning to believe that this not
only lunacy, but some form of sadistic punishment!

-Rob

Hi Rob

I agree with your last comment.

BUT, let me offer some constructive help. I have a script that I use
to make custom QNX boot floppies. It isn’t too hard to make a boot
floppy that has all of the support that you require. Though you will
probibly have to remove support for things that you don’t require
because the boot disk is pretty full already.

Cut and paste the below script. It is pretty self explamitory.
NOTE: I put a boot floppy image under /boot/makeFloppies. Change that
line to anything that suits you. If necessary, take any existing boot
bloppy and make a file with that image. As in:
freeze < /dev/fd0 > /some_path/bootFloppy.F

#!/bin/sh

echo "
This shell script will make a QNX Boot floppy

You will need a pre-formated and dchecked 1.44MB floppy in /dev/fd0.

"
read ans?‘Insert a blank 1.44 MB diskette in /dev/fd0 and hit when ready’

umount /dev/fd0
melt < /boot/makeFloppies/bootFloppy.F > /dev/fd0

exit 0


Note: To update the boot floppy

1. cd /boot/makeFloppies

2. mount /dev/fd0 /fd0

3. From here you can add or delete files

4. To edit the install_setup:
   4a melt < /fd0/util.tar.F | pax -vr
   4b vedit ram/install_setup
   4c pax -vw ram | freeze > /fd0/util.tar.F
   4d rm -rf ram

5. umount /dev/fd0

6. To archive the changes:
   6a. freeze < /dev/fd0 > bootFloppy.F

[Bill_Caroselli1]

Ian Cannon <nospam@forums.openqnx.com> wrote:

This is all well and good, Bill, but I fail to see how it helps us decode the tarx files

Sorry. Your right. It doesn’t.

I was addressing the issue of making a boot floppy that had all of
the necessary drivers in a boot floppy. But your right, you do
have to get those drivers first.

Like I said at the onset of that post, I agree that QNX4 users are
being punished. Let’s face it, they don’t want anyone using QNX4
any more. But fear not, a decade from now, we’ll be facing the
same thing with QNX6.

[Ian_Cannon1]

This is all well and good, Bill, but I fail to see how it helps us decode the tarx files

[Rob1]

Thanks for the “constructive help” Bill

… I too have a whole set of custom boot floppies, methods, etc. for
dealing with installation and/or upgrade “lunacy”. AAMOF, I have just
recently been able to hammer a custom boot CD together that not only enables
a full blown Qnx4 System to be run off of the CD (including Photon,
Networking, boot build facilities, etc.)), but also the ability to
painlessly do installs/upgrades for our “new generation” of Qnx4 production
servers with the latest & greatest QNX 4 has to offer. All via a custom
install script and custom built .tgz packages.

BUT, as the other follow up posts have alluded to, none of this was made any
easier by .tarx installs/upgrades via the May 2000 CD. What use to be an
hour or two of work to upgrade our build/upgrade facilities (or next to no
work at all in the case of ‘install -u Whatever.tar.F’), has now become a
tedious and time consuming reverse engineering like project for each .tarx
upgrade. I won’t bore all of you with the details… but, having to
manually pour over ‘find’ generated file lists, after each install/upgrade
to try to figure out what exactly is in each .tarx file, is not my idea of
fun nor something I find particularly rewarding.

QSSL… IMHO, the Qnx4 CD and .tarx format were just a step along the road
to the “package manager” facilities of Qnx6. Consequently, the Qnx4 CD
facilities were never able to reach their full potential and are therefore a
‘not fully supported’ methodology e.g. the Qnx6 facilities have over the
years become far more complete, with manifests that document what is in each
package, the ability to access network repositories, utilities for building
custom packages and help documentation explaining how it all works… and a
new CD for each upgrade (something that’s kind of necessary for supporting
new hardware . Given all this, the Qnx4 CD facilities, again IMHO, are
certainly not worth the considerable development effort it would take to
raise them to the level of Qnx6 (since this is a deadened product line).

Don’t get me wrong… I sincerely appreciate the fact that you (QSSL) have
committed to adding/upgrading drivers and addressing bug fixes for Qnx4 for
the foreseeable future. And that you have followed through by making the
recent updates available. These are all very good things , thank you.
Further, this is appropriately where continuing Qnx4 development should be
concentrated. BUT, Please! Please! Please! Continue to do “very good
things”, by also supporting .tar.F updates that are a tried, true, complete
and fully supported methodology for installing these updates.

That’s my $.02 US

-Rob


“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b7hslv$m4v$1@inn.qnx.com…

Rob <> rob@spamyouself.com> > wrote:
I couldn’t agree more… Why after years of supplying installs/updates
in
the tar.F format would anyone in their right mind go and change to a
new
proprietary format & installation utility for a product line that has
been
officially deadened? What new customers would one hope to attract with
this
GUI install interface? None, I would guess. So why leave long time
customers holding the bag with a 3 year old boot/install CD that is
incapable of detecting or supporting newer hardware (e.g. no
Fsys.aha8scsi
nor newer graphics, networking etc. drivers on the CD) as the base level
for
new installs and subsequent updates? I’m beginning to believe that this
not
only lunacy, but some form of sadistic punishment!

-Rob

Hi Rob

I agree with your last comment.

BUT, let me offer some constructive help. I have a script that I use
to make custom QNX boot floppies. It isn’t too hard to make a boot
floppy that has all of the support that you require. Though you will
probibly have to remove support for things that you don’t require
because the boot disk is pretty full already.

Cut and paste the below script. It is pretty self explamitory.
NOTE: I put a boot floppy image under /boot/makeFloppies. Change that
line to anything that suits you. If necessary, take any existing boot
bloppy and make a file with that image. As in:
freeze < /dev/fd0 > /some_path/bootFloppy.F

#!/bin/sh

echo "
This shell script will make a QNX Boot floppy

You will need a pre-formated and dchecked 1.44MB floppy in /dev/fd0.

"
read ans?‘Insert a blank 1.44 MB diskette in /dev/fd0 and hit when
ready’

umount /dev/fd0
melt < /boot/makeFloppies/bootFloppy.F > /dev/fd0

exit 0


Note: To update the boot floppy

1. cd /boot/makeFloppies

2. mount /dev/fd0 /fd0

3. From here you can add or delete files

4. To edit the install_setup:
   4a melt < /fd0/util.tar.F | pax -vr
   4b vedit ram/install_setup
   4c pax -vw ram | freeze > /fd0/util.tar.F
   4d rm -rf ram

5. umount /dev/fd0

6. To archive the changes:
   6a. freeze < /dev/fd0 > bootFloppy.F

[Bill_Caroselli1]

Rob <rob@spamyouself.com> wrote:

[very good discussion deleted]

Don’t get me wrong… I sincerely appreciate the fact that you (QSSL) have
committed to adding/upgrading drivers and addressing bug fixes for Qnx4 for
the foreseeable future. And that you have followed through by making the
recent updates available. These are all very good things , thank you.
Further, this is appropriately where continuing Qnx4 development should be
concentrated. BUT, Please! Please! Please! Continue to do “very good
things”, by also supporting .tar.F updates that are a tried, true, complete
and fully supported methodology for installing these updates.

That’s my $.02 US

I completely agree.

QSSL has come out with several upgrades/bug fixes that I don’t have
because they were only offered on the silly ass .tarx CDs.

Let’s see a show of hands. Who else would like a traditional upgrade
option for their final version of QNX V4 software?

[Martin_Walter]

Wow… I don’t read news for a couple of days and look what I come back to!
I just read through this thread, and could have commented to each message,
but decided to just add a commnet to the end of the thread…

I couldn’t agree more…

/etc/install was simple and effective, it’s a shell script everyone can see
what’s going on.
QUICS, same thing simple and effective. The update system built a custom
environment for each user based on the product licenses they had registered
and gave them access to the appropriate updates. Guess what MyQNX accounts
will do? The exact same thing but with a pretty front end.

Unfortunately even the good things change. We went to a CD distribution
because floppies were getting too difficult to source, the quality was going
down, the number required was going up, and everyone wanted the product on
CD.
With the CD came the ability to keep track of the products that were
installed, and even un-install them. We changed the format to include
encryption so that a license was required for each product in order to be
able to install it, this enabled us to hand out CD’s with short duration
licenses as evals.

I could/should have addressed more o fteh questions/ and poinst that were
raised, but there’s no point in flogging a dead horse

BTW… I vote for /etc/install and keeping QUICS around

-Martin.


“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b7k7jt$d13$3@inn.qnx.com…

Rob <> rob@spamyouself.com> > wrote:

[very good discussion deleted]

Don’t get me wrong… I sincerely appreciate the fact that you (QSSL)
have
committed to adding/upgrading drivers and addressing bug fixes for Qnx4
for
the foreseeable future. And that you have followed through by making
the
recent updates available. These are all very good things , thank you.
Further, this is appropriately where continuing Qnx4 development should
be
concentrated. BUT, Please! Please! Please! Continue to do “very good
things”, by also supporting .tar.F updates that are a tried, true,
complete
and fully supported methodology for installing these updates.

That’s my $.02 US

I completely agree.

QSSL has come out with several upgrades/bug fixes that I don’t have
because they were only offered on the silly ass .tarx CDs.

Let’s see a show of hands. Who else would like a traditional upgrade
option for their final version of QNX V4 software?

[liug4]

Martin Walter <martin@qnx.com> wrote:

Unfortunately even the good things change. We went to a CD distribution
because floppies were getting too difficult to source, the quality was going
down, the number required was going up, and everyone wanted the product on
CD.
With the CD came the ability to keep track of the products that were
installed, and even un-install them. We changed the format to include
encryption so that a license was required for each product in order to be
able to install it, this enabled us to hand out CD’s with short duration
licenses as evals.

QSS has the ability/way to license the products long before the CD
was introduced, for permanent or short-term evel/beta licenses.
I don’t see why tarx format will help this. Maybe you think moving
the “license” from runtime to install time is better?

[Rob1]

Thanks for your reply Martin… I think we’re on the same page.

For the record, I don’t object to the concepts behind the CD. Actually, I
think it’s a pretty good idea having all the products available in one
compact/portable format. And, I’m not going to nitpick about the need for
the .tarx format… on the CD anyway It’s just that my primary concerns
are that you need to… 1) Make a new CD distribution available whenever
there is a new update released. So the bootable CD with the update will be
able to support installation on newer hardware. AND 2) Make new updates
also available in the tar.F format supported by ‘install’ for all the reason
previously stated.

If MyQNX is going to support product registration like QUICS did/does, I
would think that it would then be quite possible to have download facilities
available for both a CD .iso image and a .tar.F file format for each update
(The best of both worlds). I think you were probably hinting at that in
your response. Make it so… and I’ll be happy. I wouldn’t even object
(too much) if you charged a few bucks for it.

-Rob


“Martin Walter” <martin@qnx.com> wrote in message
news:b7kh70$sk$1@nntp.qnx.com…

Wow… I don’t read news for a couple of days and look what I come back
to!
I just read through this thread, and could have commented to each message,
but decided to just add a commnet to the end of the thread…

I couldn’t agree more…

/etc/install was simple and effective, it’s a shell script everyone can
see
what’s going on.
QUICS, same thing simple and effective. The update system built a custom
environment for each user based on the product licenses they had
registered
and gave them access to the appropriate updates. Guess what MyQNX
accounts
will do? The exact same thing but with a pretty front end.

Unfortunately even the good things change. We went to a CD distribution
because floppies were getting too difficult to source, the quality was
going
down, the number required was going up, and everyone wanted the product on
CD.
With the CD came the ability to keep track of the products that were
installed, and even un-install them. We changed the format to include
encryption so that a license was required for each product in order to be
able to install it, this enabled us to hand out CD’s with short duration
licenses as evals.

I could/should have addressed more o fteh questions/ and poinst that were
raised, but there’s no point in flogging a dead horse >

BTW… I vote for /etc/install and keeping QUICS around

-Martin.


“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:b7k7jt$d13$> 3@inn.qnx.com> …
Rob <> rob@spamyouself.com> > wrote:

[very good discussion deleted]

Don’t get me wrong… I sincerely appreciate the fact that you (QSSL)
have
committed to adding/upgrading drivers and addressing bug fixes for
Qnx4
for
the foreseeable future. And that you have followed through by making
the
recent updates available. These are all very good things , thank you.
Further, this is appropriately where continuing Qnx4 development
should
be
concentrated. BUT, Please! Please! Please! Continue to do “very good
things”, by also supporting .tar.F updates that are a tried, true,
complete
and fully supported methodology for installing these updates.

That’s my $.02 US

I completely agree.

QSSL has come out with several upgrades/bug fixes that I don’t have
because they were only offered on the silly ass .tarx CDs.

Let’s see a show of hands. Who else would like a traditional upgrade
option for their final version of QNX V4 software?

[system]

And can’t you distribute .pax.F files on the CDs instead .tarx ? or both ?

Andy

Martin Walter <martin@qnx.com> wrote:

Wow… I don’t read news for a couple of days and look what I come back to!
I just read through this thread, and could have commented to each message,
but decided to just add a commnet to the end of the thread…

I couldn’t agree more…

/etc/install was simple and effective, it’s a shell script everyone can see
what’s going on.
QUICS, same thing simple and effective. The update system built a custom
environment for each user based on the product licenses they had registered
and gave them access to the appropriate updates. Guess what MyQNX accounts
will do? The exact same thing but with a pretty front end.

Unfortunately even the good things change. We went to a CD distribution
because floppies were getting too difficult to source, the quality was going
down, the number required was going up, and everyone wanted the product on
CD.
With the CD came the ability to keep track of the products that were
installed, and even un-install them. We changed the format to include
encryption so that a license was required for each product in order to be
able to install it, this enabled us to hand out CD’s with short duration
licenses as evals.

I could/should have addressed more o fteh questions/ and poinst that were
raised, but there’s no point in flogging a dead horse >

BTW… I vote for /etc/install and keeping QUICS around

-Martin.



“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:b7k7jt$d13$> 3@inn.qnx.com> …
Rob <> rob@spamyouself.com> > wrote:

[very good discussion deleted]

Don’t get me wrong… I sincerely appreciate the fact that you (QSSL)
have
committed to adding/upgrading drivers and addressing bug fixes for Qnx4
for
the foreseeable future. And that you have followed through by making
the
recent updates available. These are all very good things , thank you.
Further, this is appropriately where continuing Qnx4 development should
be
concentrated. BUT, Please! Please! Please! Continue to do “very good
things”, by also supporting .tar.F updates that are a tried, true,
complete
and fully supported methodology for installing these updates.

That’s my $.02 US

I completely agree.

QSSL has come out with several upgrades/bug fixes that I don’t have
because they were only offered on the silly ass .tarx CDs.

Let’s see a show of hands. Who else would like a traditional upgrade
option for their final version of QNX V4 software?

[Martin_Walter]

I was just pointing out some of the value provided by the CD, and what we
used it for. I’m well aware of our ability to provide eval license long
before the CD.

The licensing was not “moved” from runtime to install, it was used in both
places.

-Martin.

“liug” <liug@mama.indstate.edu> wrote in message
news:b7kjtu$rdh$1@inn.qnx.com…

Martin Walter <> martin@qnx.com> > wrote:
Unfortunately even the good things change. We went to a CD distribution
because floppies were getting too difficult to source, the quality was
going
down, the number required was going up, and everyone wanted the product
on
CD.
With the CD came the ability to keep track of the products that were
installed, and even un-install them. We changed the format to include
encryption so that a license was required for each product in order to
be
able to install it, this enabled us to hand out CD’s with short duration
licenses as evals.

QSS has the ability/way to license the products long before the CD
was introduced, for permanent or short-term evel/beta licenses.
I don’t see why tarx format will help this. Maybe you think moving
the “license” from runtime to install time is better?

[Martin_Walter]

“Rob” <rob@spamyouself.com> wrote in message
news:b7mk1q$8hh$1@inn.qnx.com…

Thanks for your reply Martin… I think we’re on the same page.

In a perfect world…

This comment may have caused some confusion…

BTW… I vote for /etc/install and keeping QUICS around

Just because I “vote” for it, doesn’t mean it will change. I don’t make
the policies, just have a say, and ultimately follow them.

For the record, I don’t object to the concepts behind the CD. Actually, I
think it’s a pretty good idea having all the products available in one
compact/portable format. And, I’m not going to nitpick about the need for
the .tarx format… on the CD anyway > > It’s just that my primary
concerns
are that you need to… 1) Make a new CD distribution available whenever
there is a new update released. So the bootable CD with the update will
be
able to support installation on newer hardware. AND 2) Make new updates
also available in the tar.F format supported by ‘install’ for all the
reason
previously stated.

1. is not going to happen. Our goal is to release 2 patch releases per year
   when required. With one CD update per year. This means that if we do 2
   patches one will only be available on-line. If we only do one patch it will
   likely be available on-line, and then later on CD.

2. Our distribution format is ‘tarx’ weather it’s on CD, or on-line.
   You all have the ability to create your own tar.F archives to meet your own
   needs, and update your unique runtime installations. As previously
   mentioned our patches are ment to be applied to full development systems,
   and have only been tested with the latest version.

If MyQNX is going to support product registration like QUICS did/does, I
would think that it would then be quite possible to have download
facilities
available for both a CD .iso image and a .tar.F file format for each
update
(The best of both worlds). I think you were probably hinting at that in
your response. Make it so… and I’ll be happy. I wouldn’t even object
(too much) if you charged a few bucks for it.

No hidden hints in my message, I really don’t know much about MyQNX accounts
yet.
It’s also very unlikely that we’ll post .iso images. It all comes down to
resources, not just those required to create and test different formats, but
more significantly those required to support them.

My goal is to make sure that we keep providing updates to the QNX 4
products, and do so as frequently as possible with limited resources.


-Martin.

-Rob


“Martin Walter” <> martin@qnx.com> > wrote in message
news:b7kh70$sk$> 1@nntp.qnx.com> …
Wow… I don’t read news for a couple of days and look what I come back
to!
I just read through this thread, and could have commented to each
message,
but decided to just add a commnet to the end of the thread…

I couldn’t agree more…

/etc/install was simple and effective, it’s a shell script everyone can
see
what’s going on.
QUICS, same thing simple and effective. The update system built a
custom
environment for each user based on the product licenses they had
registered
and gave them access to the appropriate updates. Guess what MyQNX
accounts
will do? The exact same thing but with a pretty front end.

Unfortunately even the good things change. We went to a CD distribution
because floppies were getting too difficult to source, the quality was
going
down, the number required was going up, and everyone wanted the product
on
CD.
With the CD came the ability to keep track of the products that were
installed, and even un-install them. We changed the format to include
encryption so that a license was required for each product in order to
be
able to install it, this enabled us to hand out CD’s with short duration
licenses as evals.

I could/should have addressed more o fteh questions/ and poinst that
were
raised, but there’s no point in flogging a dead horse >

BTW… I vote for /etc/install and keeping QUICS around

-Martin.


“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:b7k7jt$d13$> 3@inn.qnx.com> …
Rob <> rob@spamyouself.com> > wrote:

[very good discussion deleted]

Don’t get me wrong… I sincerely appreciate the fact that you
(QSSL)
have
committed to adding/upgrading drivers and addressing bug fixes for
Qnx4
for
the foreseeable future. And that you have followed through by
making
the
recent updates available. These are all very good things , thank
you.
Further, this is appropriately where continuing Qnx4 development
should
be
concentrated. BUT, Please! Please! Please! Continue to do “very
good
things”, by also supporting .tar.F updates that are a tried, true,
complete
and fully supported methodology for installing these updates.

That’s my $.02 US

I completely agree.

QSSL has come out with several upgrades/bug fixes that I don’t have
because they were only offered on the silly ass .tarx CDs.

Let’s see a show of hands. Who else would like a traditional upgrade
option for their final version of QNX V4 software?
\

[Rob1]

“Martin Walter” <martin@qnx.com> wrote in message
news:b8676h$8en$1@nntp.qnx.com…

“Rob” <> rob@spamyouself.com> > wrote in message
news:b7mk1q$8hh$> 1@inn.qnx.com> …
Thanks for your reply Martin… I think we’re on the same page.

In a perfect world…

This comment may have caused some confusion…

BTW… I vote for /etc/install and keeping QUICS around

Just because I “vote” for it, doesn’t mean it will change. I don’t make
the policies, just have a say, and ultimately follow them.

OK… So we’re both looking at the same page… just interpreting it
differently

For the record, I don’t object to the concepts behind the CD. Actually,
I
think it’s a pretty good idea having all the products available in one
compact/portable format. And, I’m not going to nitpick about the need
for
the .tarx format… on the CD anyway > > It’s just that my primary
concerns
are that you need to… 1) Make a new CD distribution available whenever
there is a new update released. So the bootable CD with the update will
be
able to support installation on newer hardware. AND 2) Make new updates
also available in the tar.F format supported by ‘install’ for all the
reason
previously stated.

1. is not going to happen. Our goal is to release 2 patch releases per
   year
   when required. With one CD update per year. This means that if we do 2
   patches one will only be available on-line. If we only do one patch it
   will
   likely be available on-line, and then later on CD.

Well, that’s better than nothing at all. And, it is better to know what one
can or can’t expect, then to know nothing at all.

2. Our distribution format is ‘tarx’ weather it’s on CD, or on-line.
   You all have the ability to create your own tar.F archives to meet your
   own
   needs, and update your unique runtime installations. As previously
   mentioned our patches are meant to be applied to full development systems,
   and have only been tested with the latest version.

Sounds like a management decision to me

But, there is still something that is not being addressed here…
In order to build those custom archives, in whatever format, when a new
update comes out , one needs to start with detailed knowledge of what is
available and/or has changed in each .tarx package… and I’m not just
talking about technotes, but a detailed file list of everything in each
package e.g. a manifest. Under the ‘install/.tar.F’ facilities, generating
such a manifest was as simple as ‘fcat Whatever.tar.F | pax | sort’ and also
extracting and interpreting the ‘setup’ file. There is nothing like that
available via the .tarx facilities, that I’m aware of. Like I mentioned
before, it’s become something of a reverse engineering like project to try
to figure all this out. And, frankly, I consider that a giant painful step
backwards!

So, if QSSL is going to insist on the .tarx format, I would ask that you
please also provide a useful manifest for each .tarx update/package.

If MyQNX is going to support product registration like QUICS did/does, I
would think that it would then be quite possible to have download
facilities
available for both a CD .iso image and a .tar.F file format for each
update
(The best of both worlds). I think you were probably hinting at that in
your response. Make it so… and I’ll be happy. I wouldn’t even object
(too much) if you charged a few bucks for it.

No hidden hints in my message, I really don’t know much about MyQNX
accounts
yet.
It’s also very unlikely that we’ll post .iso images. It all comes down to
resources, not just those required to create and test different formats,
but
more significantly those required to support them.

My goal is to make sure that we keep providing updates to the QNX 4
products, and do so as frequently as possible with limited resources.


-Martin.

Well, when you do know more about MyQNX, let us all know, eh. And, I
certainly understand the difficulties involved in managing limited
resources. Thanks for the commitment to QNX 4 updates… Like I said
before, that’s a very good thing!

-Rob

[snip]

[Martin_Walter]

1. is not going to happen. Our goal is to release 2 patch releases per
   year
   when required. With one CD update per year. This means that if we do 2
   patches one will only be available on-line. If we only do one patch it
   will
   likely be available on-line, and then later on CD.
   
   
   Well, that’s better than nothing at all. And, it is better to know what
   one
   can or can’t expect, then to know nothing at all.

Note that this is in line with our QNX 4 Support Policy.
http://www.qnx.com/support/sd_qnx4.html

2. Our distribution format is ‘tarx’ weather it’s on CD, or on-line.
   You all have the ability to create your own tar.F archives to meet your
   own
   needs, and update your unique runtime installations. As previously
   mentioned our patches are meant to be applied to full development
   systems,
   and have only been tested with the latest version.
   
   
   Sounds like a management decision to me >

Isn’t everything

But, there is still something that is not being addressed here…
In order to build those custom archives, in whatever format, when a new
update comes out , one needs to start with detailed knowledge of what is
available and/or has changed in each .tarx package… and I’m not just
talking about technotes, but a detailed file list of everything in each
package e.g. a manifest. Under the ‘install/.tar.F’ facilities,
generating
such a manifest was as simple as ‘fcat Whatever.tar.F | pax | sort’ and
also
extracting and interpreting the ‘setup’ file. There is nothing like that
available via the .tarx facilities, that I’m aware of. Like I mentioned
before, it’s become something of a reverse engineering like project to try
to figure all this out. And, frankly, I consider that a giant painful
step
backwards!

So, if QSSL is going to insist on the .tarx format, I would ask that you
please also provide a useful manifest for each .tarx update/package.

Most if not all of this information is available under the product registry,
see
/registry/installed/qnx/4.25/01G.* for details on patch G.
I don’t know that the steup file is availabel on the system. If needed we
can certainly supply that. Worth noting is that a patch, ie. Patch G, is a
concatination of all patches since the initial release, so it contains
A,B,C,D,E, &G. It’s easy enough to determine just what changed in patch G
from the details in the changes file.

My goal is to make sure that we keep providing updates to the QNX 4
products, and do so as frequently as possible with limited resources.


-Martin.


Well, when you do know more about MyQNX, let us all know, eh. And, I
certainly understand the difficulties involved in managing limited
resources. Thanks for the commitment to QNX 4 updates… Like I said
before, that’s a very good thing!

I believe that when MyQNX is up and running properly they will let us all
know!

-Martin.

[QNX2]

Here is my hand up high on that notion Andy!!

David
<andy@microstep-mis.com> wrote in message
news:b83luu$4ca$1@charon.microstep-mis.sk…

And can’t you distribute .pax.F files on the CDs instead .tarx ? or both ?

Andy

Martin Walter <> martin@qnx.com> > wrote:
Wow… I don’t read news for a couple of days and look what I come back
to!
I just read through this thread, and could have commented to each
message,
but decided to just add a commnet to the end of the thread…

I couldn’t agree more…

/etc/install was simple and effective, it’s a shell script everyone can
see
what’s going on.
QUICS, same thing simple and effective. The update system built a
custom
environment for each user based on the product licenses they had
registered
and gave them access to the appropriate updates. Guess what MyQNX
accounts
will do? The exact same thing but with a pretty front end.

Unfortunately even the good things change. We went to a CD distribution
because floppies were getting too difficult to source, the quality was
going
down, the number required was going up, and everyone wanted the product
on
CD.
With the CD came the ability to keep track of the products that were
installed, and even un-install them. We changed the format to include
encryption so that a license was required for each product in order to
be
able to install it, this enabled us to hand out CD’s with short duration
licenses as evals.

I could/should have addressed more o fteh questions/ and poinst that
were
raised, but there’s no point in flogging a dead horse >

BTW… I vote for /etc/install and keeping QUICS around

-Martin.


“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:b7k7jt$d13$> 3@inn.qnx.com> …
Rob <> rob@spamyouself.com> > wrote:

[very good discussion deleted]

Don’t get me wrong… I sincerely appreciate the fact that you (QSSL)
have
committed to adding/upgrading drivers and addressing bug fixes for
Qnx4
for
the foreseeable future. And that you have followed through by making
the
recent updates available. These are all very good things , thank
you.
Further, this is appropriately where continuing Qnx4 development
should
be
concentrated. BUT, Please! Please! Please! Continue to do “very
good
things”, by also supporting .tar.F updates that are a tried, true,
complete
and fully supported methodology for installing these updates.

That’s my $.02 US

I completely agree.

QSSL has come out with several upgrades/bug fixes that I don’t have
because they were only offered on the silly ass .tarx CDs.

Let’s see a show of hands. Who else would like a traditional upgrade
option for their final version of QNX V4 software?