On 3/26/21 6:00 AM, Hamish Moffatt wrote:
I really don't understand your arguments Roland. You say you need Qt
support for 15 years, but you can't actually change one bit of your
software without FDA approval, so presumably this means you aren't
upgrading Qt anyway. Then after 15 years you want to work on a new model
of the device, starting with your existing code, and you expect it to
compile with the latest Qt unchanged?
Stable API.
By definition a Stable API only has additions. In incredibly rare
isolated cases things get deleted ___AFTER__ they have a direct or
mostly direct replacement.
I was involved in a discussion a couple months ago with someone who just
that morning cracked open 50 year old FORTRAN that compiled with the
latest FORTRAN compiler just fine. The code had been running in
production unchanged for 50 years. That's ordinary in the deep pockets
world, not an exception, the rule.
Someone else was talking about support for RHEL 6. Why do you expect to
use the latest Qt with an ancient OS? Is it reasonable to expect to use
new Qt with an ancient OS?
Qt actively pursued these markets and then abandoned them. Multi-million
dollar investments (if I remember what Scott wrote correctly, a billion
with a B dollar investment) on long term projects. Well, ordinary term
for our worlds but beyond the Arc of Time for what Qt now pursues. These
investments got made because the stuff was supposed to be supported for
the duration.
Our worlds last longer than a gallon of milk and they were actively pursued.
I see that the latest Microsoft Visual C++ compiler toolset (v142)
doesn't support building for Windows XP. You can still use an older
compiler. That seems like a reasonable compromise.
When you come from a short lived world, that would seem reasonable. We
walk in worlds where stuff routinely runs 30-50 years. It's a requirement.
The gist of this thread seems to be, from Thiago and others, is that
those who need Qt to be a viable product with a stable API need to fork
it into a completely separate project that doesn't delete anything
without querying the installed base. You want to see how viable
companies and products are managed.
=======
Hi Roland,
We'll soon be making decisions about Synergy/DE product direction in a
number of areas, as well as about potential new products, and we're very
interested in your input. Please complete this brief survey to help us
determine our priorities and future development direction.
Start Survey
Or use this link: https://survey.sogosurvey.com/k/QsQWSXRSsRWsSUXUSWVQTsP
SURVEY DEADLINE: Tuesday, March 30 (end of day)
Everyone who completes the survey will be entered into a raffle to win a
$250 gift card.
Thank you for participating,
The Synergex Team
=======
I haven't done squat with DIBOL in years. I did write Synergex a nice
"how to use it on VMS" chapter some years ago that they are free to use
however they want. Every time they are ready for major changes one of
these things comes out. They understand that the care and feeding of the
installed base is what keeps a roof over their head and food on their
table. That once you pursue an industry and get it to invest in your
product, you don't abandon it.
The mantra from the Qt project, and Digia for that matter, is "Sucks to
be you!"
You want the Cliff Notes response?
Qt as a community and commercial product pursued the medical device and
SAFETY industries because of their deep pockets. They pursued these
industries knowing full well that, baring a product with adverse
outcomes, 15 years would be the soonest redevelopment would happen.
From time to time we get hit with new industry regulations and have to
tweak something. During those times we tend to update any libraries
because we are going to have to bite the bullet on some level of
approval anyway. We can successfully do this when we have a stable API.
What you can't generally do is slip in a new OS.
Here is a real life real world example.
Most every medical device manufacturer that had touch screens on their
devices had super secret field service screens on the device. When the
devices had an external USB or other connection it was customized to
have extra pins and those screens couldn't be accessed unless you had
the "key" so to speak. In addition to the "key" you had to know the
field service access code. Usually a 4-6 digit code. For devices that
didn't have external ports you had to have the proper tool to crack up
the case so you could install the field service card that had the port.
Most considered bifurcated security good enough. Everybody overlooked
the fact that XYZ corporation's products all used 1709 as their access
code and Harry Widgets medical devices all used 4591. Not just one
model, all models.
In the Post 9/11 cyber security changes that started coming down the FDA
decided that each customer should be able to set their own field service
code and that field service would need to request it from the
administrators.
Every major customer decided they wanted that code pre-configured so
their people could just unbox a new one and start using it.
Every little customer wanted to set the code themselves as part of the
initial setup.
Pretty obvious a lot of new screen work had to happen when you consider
it impacted every device ever made that had field service screens.
Devices currently in the field had to be retrofited as well.
Almost every manufacturer updated what they were using for screen
libraries at this time. Even the device manufacturers using Qt 4.8 and
sharing fixes with other manufacturers did this. Some tried to go to the
latest Qt only to find the journey perilous.
I will let Scott and others give examples from their worlds if they choose.
There is a huge embedded device industry that doesn't make disposable
products. It appears the Qt project is only pursuing disposable products
at this point.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
