QSSL should change its policy

Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong, imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

You have my full support. Also, features that were available in 6.2.1
were removed from 6.3 into some TDK that you have buy, i.e. ipfilter. On
top of it all, I can download a 3rd party ipfilter but it does not work
on 6.3. Then I download the source to rebuild ipfilter just to discover
I need an include file which is only available in the TDK! Therefore I
am disallowed from using ipfilter on 6.3!

Francois

This is indeed a big problem, and one approached badly
by QSSL. When QNX 6.3 came out, it was not at all clear how much
functionality had been removed from the base package. One
by one, customers had to find out the hard way about the
copy protection, the licensing mess, features removed
from the base package, and which third-party vendors were dropping
QNX support.

Because the QNX market is now so tiny, there are no third party
books or journalists providing objective coverage of these issues.
QNX has fallen off the journalistic radar. (Type “QNX” into
Google News to verify this. Then try “real time Linux”.
Any questions?)

And with the demise of QNX NC and the “Open QNX” effort, there’s
very little entry-level interest. So nobody writes about QNX any
more. Open source programs no longer come with QNX builds. QNX
has become irrelevant outside a very tiny community.

We’ve discovered another side effect to this. Young people
want to avoid QNX. When recruiting, we find that as soon as we
mention that we use QNX, it turns young people off. They see
learning QNX as a dead end with negative career value. In
the last two years, this effect has become quite pronounced.

It’s unfortunate. QNX was a great technology.

John Nagle
Team Overbot

Alain Bonnefoy wrote:

Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong, imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

John Nagle <nagle@downside.com> wrote:

This is indeed a big problem, and one approached badly
by QSSL. When QNX 6.3 came out, it was not at all clear how much
functionality had been removed from the base package. One
by one, customers had to find out the hard way about the
copy protection, the licensing mess, features removed
from the base package, and which third-party vendors were dropping
QNX support.

Because the QNX market is now so tiny, there are no third party
books or journalists providing objective coverage of these issues.
QNX has fallen off the journalistic radar. (Type “QNX” into
Google News to verify this. Then try “real time Linux”.
Any questions?)

And with the demise of QNX NC and the “Open QNX” effort, there’s
very little entry-level interest. So nobody writes about QNX any
more. Open source programs no longer come with QNX builds. QNX
has become irrelevant outside a very tiny community.

We’ve discovered another side effect to this. Young people
want to avoid QNX. When recruiting, we find that as soon as we
mention that we use QNX, it turns young people off. They see
learning QNX as a dead end with negative career value. In
the last two years, this effect has become quite pronounced.

It’s unfortunate. QNX was a great technology.

See http://www.parse.com/~rk/kick_resmgr.html for an amplification
of this…

Cheers,
-RK

John Nagle
Team Overbot

Alain Bonnefoy wrote:
Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong, imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

Francois Joubert wrote:

You have my full support. Also, features that were available in 6.2.1
were removed from 6.3 into some TDK that you have buy, i.e. ipfilter. On
top of it all, I can download a 3rd party ipfilter but it does not work
on 6.3. Then I download the source to rebuild ipfilter just to discover
I need an include file which is only available in the TDK! Therefore I
am disallowed from using ipfilter on 6.3!

I have custom a board support package that I developed in house, and
when I wanted to upgrade to 6.3 found out that the flash library has
been moved into the “flash and embedding” tdk, which is now an optional
package. If QSSL wants to change their packaging approach that is fine
but it must not be retroactive. Any customer who has a working
application, and upgrades the O/S should be grandfathered in to the tdks
required to get their application working.

Rennie Allen wrote:

Francois Joubert wrote:

You have my full support. Also, features that were available in 6.2.1
were removed from 6.3 into some TDK that you have buy, i.e. ipfilter.
On top of it all, I can download a 3rd party ipfilter but it does not
work on 6.3. Then I download the source to rebuild ipfilter just to
discover I need an include file which is only available in the TDK!
Therefore I am disallowed from using ipfilter on 6.3!


I have custom a board support package that I developed in house, and
when I wanted to upgrade to 6.3 found out that the flash library has
been moved into the “flash and embedding” tdk, which is now an optional
package. If QSSL wants to change their packaging approach that is fine
but it must not be retroactive. Any customer who has a working
application, and upgrades the O/S should be grandfathered in to the tdks
required to get their application working.

My question is what will be next in a TDK?

Proposal: Photon packed in a GUI TDK! :slight_smile:

Cheers

Armin

Hi Rennie -

We took a fair bit of care to ensure that ‘legacy’ versions were available
for various TDKs that would give us a vehicle to deliver the relocated
functionality to existing customers that had purchased maintenance rights.
These legacy versions of the TDKs generally do not include source code
components delivered with the full TDK, and did not give any runtime
distribution rights (which would be included with the purchased TDK). If
you’d purchased 6.2.1 and had a current maintenance plan for 6.2.1 (i.e.
were entitled to updates), you should talk to your salesperson about
obtaining the legacy version of the appropriate TDK.

  • Eric

“Rennie Allen” <rnogspamallen@comcast.net> wrote in message
news:d580hr$bpf$1@inn.qnx.com

Francois Joubert wrote:
You have my full support. Also, features that were available in 6.2.1
were removed from 6.3 into some TDK that you have buy, i.e. ipfilter. On
top of it all, I can download a 3rd party ipfilter but it does not work
on 6.3. Then I download the source to rebuild ipfilter just to discover I
need an include file which is only available in the TDK! Therefore I am
disallowed from using ipfilter on 6.3!

I have custom a board support package that I developed in house, and when
I wanted to upgrade to 6.3 found out that the flash library has been moved
into the “flash and embedding” tdk, which is now an optional package. If
QSSL wants to change their packaging approach that is fine but it must not
be retroactive. Any customer who has a working application, and upgrades
the O/S should be grandfathered in to the tdks required to get their
application working.

Alain -

I’m sorry you ran into compatibility issues, but I think you’re jumping to
conclusions that the cause is a change of policy.
We put more effort into identifying and documenting changes between releases
now than we ever have in the history of the company. We strive to maintain
compatibility and also to document what has changed relating to documented
APIs (undocumented internal APIs of course could be changed at any time). On
occasion, we do miss things, but we’d need more specifics in order to find
out how that happened and if warranted change our processes or training to
prevent similar things from happening in the future. It sounds like we have
a problem area here that should be fixed. We’re as interested as you are in
identifying compatibility problems between versions, but improvements will
come with cooperation and communication about what happened, not ranting
about an imagined change of policy.

  • Eric

“Alain Bonnefoy” <alain.bonnefoy@rieter.com> wrote in message
news:d575pi$lev$1@inn.qnx.com

Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong, imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

Eric Johnson wrote:

Hi Rennie -

We took a fair bit of care to ensure that ‘legacy’ versions were available
for various TDKs that would give us a vehicle to deliver the relocated
functionality to existing customers that had purchased maintenance rights.
These legacy versions of the TDKs generally do not include source code
components delivered with the full TDK, and did not give any runtime
distribution rights (which would be included with the purchased TDK).

Hi Eric,

What do you mean that the legacy TDKs didn’t include runtime distribution rights ?

Our company has always negotiated distribution rights seperately from host development system. Are you implying that the new TDK
licensing model provides unlimited runtime distribution rights as part of the TDK purchase price ?

Does this mean unlimited distribution of all the add-ons (i.e. TDKs), and one (simple to negotiate) royalty for the core ? If so
this sounds much more convenient than negotiating runtimes for each module, and this should be shouted from the tree tops.

Rennie

Hi Rennie -

I guess the short answer is ‘yes’, with caveats. Your rights are always
specified with the combination of the TDK license certificate and in the
EULA, and some TDKs are sold with limited volume runtimes (the number of
units would be specified on the certificate). The runtime rights are for
just the technology in the specific TDK (not the whole RTOS). The license
certificate for these generally says (excerpted here)
“…Runtime components that are only provided in Technology Development
Kits, as well as derivative works created using Source Kits, are generally
re-distributable on a royalty-free basis. However, some exceptions apply
(e.g., products with 3rd party royalty-bearing components and Project
Software licenses with volume limits). These license terms are further
defined in the applicable end user license agreement. …”
As always you must review the actual license certificate and EULA to
determine your exact rights.

The upshot is that once you buy into the TDK, you don’t get nickeled and
dimed for the runtime modules relating to the TDK technology. That doesn’t
mean you can just buy one TDK and use it for every project for life. There
are different pricing levels for TDKs depending on whether you will be using
for just one project; multiple projects on 1 platform; or multiple projects,
multiple platforms in 1 field of use.

Sounds like you need to talk to our friendly salesfolks… :slight_smile:

  • Eric

“Rennie Allen” <rallen@csical.com> wrote in message
news:4278F4DA.1010004@csical.com

Eric Johnson wrote:
Hi Rennie -

We took a fair bit of care to ensure that ‘legacy’ versions were
available for various TDKs that would give us a vehicle to deliver the
relocated functionality to existing customers that had purchased
maintenance rights. These legacy versions of the TDKs generally do not
include source code components delivered with the full TDK, and did not
give any runtime distribution rights (which would be included with the
purchased TDK).

Hi Eric,

What do you mean that the legacy TDKs didn’t include runtime distribution
rights ?

Our company has always negotiated distribution rights seperately from host
development system. Are you implying that the new TDK licensing model
provides unlimited runtime distribution rights as part of the TDK purchase
price ?

Does this mean unlimited distribution of all the add-ons (i.e. TDKs), and
one (simple to negotiate) royalty for the core ? If so this sounds much
more convenient than negotiating runtimes for each module, and this should
be shouted from the tree tops.

Rennie

Eric Johnson wrote:

Sounds like you need to talk to our friendly salesfolks… > :slight_smile:

Not me. All I want to know is enough to tell my boss what components we need to order :wink: He negotiates with the salesfolk.


Rennie

Eric… you really believe that you guys are striving? As russians would
say, this makes even my shoelaces laugh. If even with all the striving this
level of backward compatibility is the best you can do, you guys should
consider another career.

This problem has been plaguing QNX for the entire decade that I’ve been
actively using it. Every and I mean EVERY release, even minor point
releases, inevitably broke something working. The magnitude of the problem
was such that it felt like it’s not just oversight. It felt like utter
disregard of your customers.

And enough bullshit about cooperation. As far as QNX is concerned
‘cooperation’ means ‘you do free regression testing and problem analysis for
us and you don’t get any say in our decisions anyway’. If you were giving it
for free, people would be pissed with that approach. But you’re charging for
it…

– igor

“Eric Johnson” <eric@qnx.com> wrote in message
news:d5ap4a$eb3$1@inn.qnx.com

Alain -

I’m sorry you ran into compatibility issues, but I think you’re jumping to
conclusions that the cause is a change of policy.
We put more effort into identifying and documenting changes between
releases now than we ever have in the history of the company. We strive to
maintain compatibility and also to document what has changed relating to
documented APIs (undocumented internal APIs of course could be changed at
any time). On occasion, we do miss things, but we’d need more specifics in
order to find out how that happened and if warranted change our processes
or training to prevent similar things from happening in the future. It
sounds like we have a problem area here that should be fixed. We’re as
interested as you are in identifying compatibility problems between
versions, but improvements will come with cooperation and communication
about what happened, not ranting about an imagined change of policy.

  • Eric

“Alain Bonnefoy” <> alain.bonnefoy@rieter.com> > wrote in message
news:d575pi$lev$> 1@inn.qnx.com> …

Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value
for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong,
imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

Dude… I did read your article. You really went out of your way to teach
people who have only known QNX how to use TCP/IP. I mean all 5 of them must
have found it really helpful :wink:

Seriously, the article is nice and I don’t mean to put you down. I just find
it really amusing that someone could have been so blind and ignorant to the
world outside QNX for so long to need that article now…

Cheers
– igor

“Robert Krten” <rk@parse.com> wrote in message
news:d58lfu$qfv$1@inn.qnx.com

John Nagle <> nagle@downside.com> > wrote:
This is indeed a big problem, and one approached badly
by QSSL. When QNX 6.3 came out, it was not at all clear how much
functionality had been removed from the base package. One
by one, customers had to find out the hard way about the
copy protection, the licensing mess, features removed
from the base package, and which third-party vendors were dropping
QNX support.

Because the QNX market is now so tiny, there are no third party
books or journalists providing objective coverage of these issues.
QNX has fallen off the journalistic radar. (Type “QNX” into
Google News to verify this. Then try “real time Linux”.
Any questions?)

And with the demise of QNX NC and the “Open QNX” effort, there’s
very little entry-level interest. So nobody writes about QNX any
more. Open source programs no longer come with QNX builds. QNX
has become irrelevant outside a very tiny community.

We’ve discovered another side effect to this. Young people
want to avoid QNX. When recruiting, we find that as soon as we
mention that we use QNX, it turns young people off. They see
learning QNX as a dead end with negative career value. In
the last two years, this effect has become quite pronounced.

It’s unfortunate. QNX was a great technology.

See > http://www.parse.com/~rk/kick_resmgr.html > for an amplification
of this…

Cheers,
-RK

John Nagle
Team Overbot

Alain Bonnefoy wrote:
Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they
no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s
arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value
for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as
deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong,
imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take
the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

Igor Kovalenko <kovalenko@comcast.net> wrote:

Dude… I did read your article. You really went out of your way to teach
people who have only known QNX how to use TCP/IP. I mean all 5 of them must
have found it really helpful > :wink:

:slight_smile:

Seriously, the article is nice and I don’t mean to put you down. I just find
it really amusing that someone could have been so blind and ignorant to the
world outside QNX for so long to need that article now…

Like I said, “the first step is admitting you have a problem…” :slight_smile:

Cheers,
-RK

Cheers
– igor

“Robert Krten” <> rk@parse.com> > wrote in message
news:d58lfu$qfv$> 1@inn.qnx.com> …
John Nagle <> nagle@downside.com> > wrote:
This is indeed a big problem, and one approached badly
by QSSL. When QNX 6.3 came out, it was not at all clear how much
functionality had been removed from the base package. One
by one, customers had to find out the hard way about the
copy protection, the licensing mess, features removed
from the base package, and which third-party vendors were dropping
QNX support.

Because the QNX market is now so tiny, there are no third party
books or journalists providing objective coverage of these issues.
QNX has fallen off the journalistic radar. (Type “QNX” into
Google News to verify this. Then try “real time Linux”.
Any questions?)

And with the demise of QNX NC and the “Open QNX” effort, there’s
very little entry-level interest. So nobody writes about QNX any
more. Open source programs no longer come with QNX builds. QNX
has become irrelevant outside a very tiny community.

We’ve discovered another side effect to this. Young people
want to avoid QNX. When recruiting, we find that as soon as we
mention that we use QNX, it turns young people off. They see
learning QNX as a dead end with negative career value. In
the last two years, this effect has become quite pronounced.

It’s unfortunate. QNX was a great technology.

See > http://www.parse.com/~rk/kick_resmgr.html > for an amplification
of this…

Cheers,
-RK

John Nagle
Team Overbot

Alain Bonnefoy wrote:
Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they
no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s
arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value
for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as
deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong,
imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take
the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

Hi Igor, I appreciate how you feel but I don’t agree with you. Any change at
all has the potential to break someone’s code that relies on some particular
behavior that may be undefined or that may have been coded in an attempt to
work around something that isn’t behaving correctly in the first place.
Those sorts of things happen all the time and can’t be avoided (though when
we’re aware they should be documented, and there have been times when we
didn’t adequately document such changes). Compatibility is a concern and
costs us a good deal of time and effort since we have to design to maintain
compatibility when often the more straightforward approach would break
existing applications.

  • Eric

“Igor Kovalenko” <kovalenko@comcast.net> wrote in message
news:d5esug$f19$1@inn.qnx.com

Eric… you really believe that you guys are striving? As russians would
say, this makes even my shoelaces laugh. If even with all the striving
this level of backward compatibility is the best you can do, you guys
should consider another career.

This problem has been plaguing QNX for the entire decade that I’ve been
actively using it. Every and I mean EVERY release, even minor point
releases, inevitably broke something working. The magnitude of the problem
was such that it felt like it’s not just oversight. It felt like utter
disregard of your customers.

And enough bullshit about cooperation. As far as QNX is concerned
‘cooperation’ means ‘you do free regression testing and problem analysis
for us and you don’t get any say in our decisions anyway’. If you were
giving it for free, people would be pissed with that approach. But you’re
charging for it…

– igor

“Eric Johnson” <> eric@qnx.com> > wrote in message
news:d5ap4a$eb3$> 1@inn.qnx.com> …
Alain -

I’m sorry you ran into compatibility issues, but I think you’re jumping
to conclusions that the cause is a change of policy.
We put more effort into identifying and documenting changes between
releases now than we ever have in the history of the company. We strive
to maintain compatibility and also to document what has changed relating
to documented APIs (undocumented internal APIs of course could be changed
at any time). On occasion, we do miss things, but we’d need more
specifics in order to find out how that happened and if warranted change
our processes or training to prevent similar things from happening in the
future. It sounds like we have a problem area here that should be fixed.
We’re as interested as you are in identifying compatibility problems
between versions, but improvements will come with cooperation and
communication about what happened, not ranting about an imagined change
of policy.

  • Eric

“Alain Bonnefoy” <> alain.bonnefoy@rieter.com> > wrote in message
news:d575pi$lev$> 1@inn.qnx.com> …

Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s
arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value
for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong,
imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.

\

“Eric Johnson” <eric@qnx.com> wrote in message
news:d5fqnt$765$1@inn.qnx.com

Hi Igor, I appreciate how you feel but I don’t agree with you. Any change
at all has the potential to break someone’s code that relies on some
particular behavior that may be undefined or that may have been coded in
an attempt to work around something that isn’t behaving correctly in the
first place. Those sorts of things happen all the time and can’t be
avoided (though when we’re aware they should be documented, and there have
been times when we didn’t adequately document such changes). Compatibility
is a concern and costs us a good deal of time and effort since we have
to design to maintain compatibility when often the more straightforward
approach would break existing applications.

Historicaly speaking QSS has NEVER been about compatibility or longterm
commitement to customer investment in the technology

QNX2-QNX4-QNX6
QNXWindows → Photon

In early QNX6 version, the incompatibility between various version of qnet
is a major faux-pas if you ask me.

Of course the past is not guarant of the futur, but…

  • Eric

“Igor Kovalenko” <> kovalenko@comcast.net> > wrote in message
news:d5esug$f19$> 1@inn.qnx.com> …
Eric… you really believe that you guys are striving? As russians would
say, this makes even my shoelaces laugh. If even with all the striving
this level of backward compatibility is the best you can do, you guys
should consider another career.

This problem has been plaguing QNX for the entire decade that I’ve been
actively using it. Every and I mean EVERY release, even minor point
releases, inevitably broke something working. The magnitude of the
problem was such that it felt like it’s not just oversight. It felt like
utter disregard of your customers.

And enough bullshit about cooperation. As far as QNX is concerned
‘cooperation’ means ‘you do free regression testing and problem analysis
for us and you don’t get any say in our decisions anyway’. If you were
giving it for free, people would be pissed with that approach. But you’re
charging for it…

– igor

“Eric Johnson” <> eric@qnx.com> > wrote in message
news:d5ap4a$eb3$> 1@inn.qnx.com> …
Alain -

I’m sorry you ran into compatibility issues, but I think you’re jumping
to conclusions that the cause is a change of policy.
We put more effort into identifying and documenting changes between
releases now than we ever have in the history of the company. We strive
to maintain compatibility and also to document what has changed relating
to documented APIs (undocumented internal APIs of course could be
changed at any time). On occasion, we do miss things, but we’d need more
specifics in order to find out how that happened and if warranted change
our processes or training to prevent similar things from happening in
the future. It sounds like we have a problem area here that should be
fixed. We’re as interested as you are in identifying compatibility
problems between versions, but improvements will come with cooperation
and communication about what happened, not ranting about an imagined
change of policy.

  • Eric

“Alain Bonnefoy” <> alain.bonnefoy@rieter.com> > wrote in message
news:d575pi$lev$> 1@inn.qnx.com> …

Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they
no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s
arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value
for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as
deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong,
imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take
the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.



\

Robert Krten wrote:

Igor Kovalenko <> kovalenko@comcast.net> > wrote:

Dude… I did read your article. You really went out of your way to teach
people who have only known QNX how to use TCP/IP. I mean all 5 of them must
have found it really helpful > :wink:

Seriously, the article is nice and I don’t mean to put you down. I just find
it really amusing that someone could have been so blind and ignorant to the
world outside QNX for so long to need that article now…

Like I said, “the first step is admitting you have a problem…” > :slight_smile:

Cheers,
-RK

That was a little strange. I thought that everyone serious
understood socket-level programming by now. The main problem
with it is that the responsiveness of that approach isn’t
very good. The great feature of QNX is that it really gives
you a subroutine call type interprocess communication
mechanism. Almost all other UNIX-like operating systems in current
use make you build interprocess calls out of stream I/O operations,
which both slows down and complicates the communication.

I’ve come to realize, after reading this newsgroup
for a while, that I’m one of the very few people who started
using QNX in this millenium and did anything extensive with it.
There’s a feeling of having bought into a legacy technology on
the way down.

The biggest problem I have with QNX right now is that it’s
a major drag on recruiting for Team Overbot. If we were using
a real-time Linux variant, we’d have far less trouble recruiting
young people. Most potential recruits already have some
Linux system at home. They already know Linux.

That’s how the demise of QNX NC is killing us.
In time, it will kill QSSL.

John Nagle
Team Overbot

I understand this may be how you personally feel. But we have yet to see any
rational explanation to some absurd steps QNX has taken, where it was
obvious that they are going to kill backward compatibility for no benefit
whatsoever.

For example, what bozo came up with the idea to change how offset argument
of mmap() is handled between 6.2 and 6.2.1? The result was major PITA for
people who cared to write any drivers for 6.2. And what was the benefit may
I ask? Just how exactly this ‘striving’ process worked in this case?

Let me see for other examples … fdisk command line options have been
f%^&ed with every release since NTO 2.0 I think. Who cared that I had custom
installer scripts relying on them… Did anyone even gave it a bloody
second thought before just arbitrarily changing arguments of a major
unitity?

Before that, remember the decision to change uname from nto to qnx? Did
anyone care that there are open-source packages ported to QNX4 which had
configure scripts looking for ‘qnx’? The result was that they picked up qnx4
patches and stuff did not work (and it would have worked with no match
generic branch btw). Those had to be ‘unported’ afterwards… Remember that
this was pointed out pretty early in the beta process? Remember how QNX
stubbornly ignored all rational arguments? Only to admit that they scrwed up
few month later and tell us ‘but alas, it is too late now’. What was the
benefit may I ask? Who was striving and for what?

What about that irrational refusal to fix the idiotic bug in the pci server
that returns SUCCESS and a handle to half-initialized structure for
non-transparent bridges? In that case I not only cooperated - I actually
made a fix. It was crude one-liner but it proved to work as several people
here can confirm. I said ‘ok, that fix is too crude for you (never mind that
PCMCIA bridges use the same fix), then at least make the server return
FAILURE so people won’t be scratching their heads about why their code does
not work’. But no, QNX was not gonna do that either - they would rather let
people trip over this bug over and over as was evident from reading
newsgroups.

And what about all the jerking with licensing/packaging? Striving to squeeze
few bucks from people who have already put their bets on QNX and can’t back
out easily? Guess what happens - people are watching this nonsense and
making conclusions.

But enough. Dan and Gord have done well for themselves. And as I have been
told ‘why don’t you start your own OS company and do it as you please’. Fair
enough. It’s been a good dream …

– igor

“Eric Johnson” <eric@qnx.com> wrote in message
news:d5fqnt$765$1@inn.qnx.com

Hi Igor, I appreciate how you feel but I don’t agree with you. Any change
at all has the potential to break someone’s code that relies on some
particular behavior that may be undefined or that may have been coded in
an attempt to work around something that isn’t behaving correctly in the
first place. Those sorts of things happen all the time and can’t be
avoided (though when we’re aware they should be documented, and there have
been times when we didn’t adequately document such changes). Compatibility
is a concern and costs us a good deal of time and effort since we have
to design to maintain compatibility when often the more straightforward
approach would break existing applications.

  • Eric

“Igor Kovalenko” <> kovalenko@comcast.net> > wrote in message
news:d5esug$f19$> 1@inn.qnx.com> …
Eric… you really believe that you guys are striving? As russians would
say, this makes even my shoelaces laugh. If even with all the striving
this level of backward compatibility is the best you can do, you guys
should consider another career.

This problem has been plaguing QNX for the entire decade that I’ve been
actively using it. Every and I mean EVERY release, even minor point
releases, inevitably broke something working. The magnitude of the
problem was such that it felt like it’s not just oversight. It felt like
utter disregard of your customers.

And enough bullshit about cooperation. As far as QNX is concerned
‘cooperation’ means ‘you do free regression testing and problem analysis
for us and you don’t get any say in our decisions anyway’. If you were
giving it for free, people would be pissed with that approach. But you’re
charging for it…

– igor

“Eric Johnson” <> eric@qnx.com> > wrote in message
news:d5ap4a$eb3$> 1@inn.qnx.com> …
Alain -

I’m sorry you ran into compatibility issues, but I think you’re jumping
to conclusions that the cause is a change of policy.
We put more effort into identifying and documenting changes between
releases now than we ever have in the history of the company. We strive
to maintain compatibility and also to document what has changed relating
to documented APIs (undocumented internal APIs of course could be
changed at any time). On occasion, we do miss things, but we’d need more
specifics in order to find out how that happened and if warranted change
our processes or training to prevent similar things from happening in
the future. It sounds like we have a problem area here that should be
fixed. We’re as interested as you are in identifying compatibility
problems between versions, but improvements will come with cooperation
and communication about what happened, not ranting about an imagined
change of policy.

  • Eric

“Alain Bonnefoy” <> alain.bonnefoy@rieter.com> > wrote in message
news:d575pi$lev$> 1@inn.qnx.com> …

Hello,
This is not the first time I complain that QSSL doesn’t improve its
commercial policy, far from that.

Today again, I didn’t digest the joke about the packages!

This is again with the 6.3 that’s the most obvious and I think that
everyone who had to rebuild a 6.2 Photon’s application in 6.3 should be
today a bit nervous.

Something has changed these last years in QSSL and it seems that they
no
more take care about their customer’s needs.

Unless I’m the only one to have some applications to maintain for years
which should be a bit surprising.

That’s said, I cannot understand that QSSL changes a function’s
arguments
list whithout changing its name, that QSSL remove some flags or some
functions without supplying any workaround.

Keeping the old function just to call the new one with a default value
for
the supplementary parameter is most of the time possible and won’t
multiply the library size by two!

What should be possible also, is to declare this function as
deprecated,
that’s very easy now with GCC 3, to be removed later but correctly.

What is the most frustrating here is that most of these changes are not
documented (PtResourceRec_t, PtGenListDrawString, PtGenListGetColors,
Pt_COMPOUND, etc…). So we have to build the application, evaluate the
damages, find sometimes in the doc or in the headers what’s wrong,
imagine
or ask to the support for a workaround.

It seems that QSSL doesn’t realize how much time we could waste in such
operations.

Based on our 6.3 experience, it’s almost sure now that we won’t take
the
risk to upgrade to the next release.

So, I really hope that QSSL will think a little bit more to their
customers in the future.

Regards,
Alain.



\

John Nagle wrote:

Robert Krten wrote:

Igor Kovalenko <> kovalenko@comcast.net> > wrote:

Dude… I did read your article. You really went out of your way to
teach people who have only known QNX how to use TCP/IP. I mean all 5
of them must have found it really helpful > :wink:


Seriously, the article is nice and I don’t mean to put you down. I
just find it really amusing that someone could have been so blind and
ignorant to the world outside QNX for so long to need that article
now…


Like I said, “the first step is admitting you have a problem…” > :slight_smile:

Cheers,
-RK


That was a little strange. I thought that everyone serious
understood socket-level programming by now. The main problem
with it is that the responsiveness of that approach isn’t
very good. The great feature of QNX is that it really gives
you a subroutine call type interprocess communication
mechanism. Almost all other UNIX-like operating systems in current
use make you build interprocess calls out of stream I/O operations,
which both slows down and complicates the communication.

That’s the reason why middleware like PVM and MPI have been created.
These packages are doing message passing on top of the socket lib.

I’ve come to realize, after reading this newsgroup
for a while, that I’m one of the very few people who started
using QNX in this millenium and did anything extensive with it.
There’s a feeling of having bought into a legacy technology on
the way down.

The biggest problem I have with QNX right now is that it’s
a major drag on recruiting for Team Overbot. If we were using
a real-time Linux variant, we’d have far less trouble recruiting
young people. Most potential recruits already have some
Linux system at home. They already know Linux.

IMHO … your ‘young people’ will get very fast grey hairs if they have
to deal with one of these RT Linux’es :slight_smile:


–Armin

That’s how the demise of QNX NC is killing us.
In time, it will kill QSSL.

John Nagle
Team Overbot

Igor Kovalenko <kovalenko@comcast.net> wrote:

For example, what bozo came up with the idea to change how offset argument
of mmap() is handled between 6.2 and 6.2.1? The result was major PITA for
people who cared to write any drivers for 6.2.

I don’t know who changed it, but it only burnt the bozos who decided
they could safely treat a signed value as unsigned, and pass out of
range values to the function.

-David