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.
“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.
“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.
\