I know this thread is old but I’ve been out sick for a while. But I did
want to throw my two cents in.
We all need to consider several factors.
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 > 
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…” >
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.