[Interest] Chasing a standard

[Roland Hughes]

Quoting Elvis Stansvik:

====
Sorry to say it, but welcome to C++

No, mostly kidding. I think what you suggest sort of makes sense. If
Qt are to keep its containers, with a goal of offering an alternative
more convenient/Java-esque API, then a helper member function like you
suggest seems to fit that goal. Whether Qt still has this as a goal in
another matter. Maybe not to the extent that they once had?

For the pattern above, I guess one could make a generic helper in a
header of the application. I know e.g. Qt Creator has a bunch of such
helpers in its headers.
====

I would like to weigh in a vote for Qt keeping its containers. The
reason behind that vote is the ever present installed base. We already
lose droves of Qt developers every year when Qt keeps moving on but
medical devices, border security systems like cargo x-ray, train control
systems, etc. have to fork their own version of Qt because Qt keeps
moving on without a 5-8 year LTS.

At this point their are hundreds, thousands, perhaps millions of Qt
example programs scattered around the Internet, many of which don't
bother to name the Qt version they were written with, not to mention
"official" texts which will now mostly not work.

https://www.barnesandnoble.com/w/c-gui-programming-with-qt-4-2nd-edition-jasmin-blanchette/1101413840?ean=9780132354165


Granted that one actually names Qt 4 but programming languages as wells
as their libraries have a time honored tradition of just adding, not
dropping major components.

Okay, BASIC dropped IRREGARDLESS and C++ has _finally_ dropped
trigraphs, but neither were major components.

Yes, I have heard various young guns in here chanting the mantra "why
spend resources maintaining something std now does?" Well, the installed
base is the reason. Under the hood feel free to change them
dramatically, but, maintain the API. It doesn't matter if std:: is
adopting many Qt-esque things, we have always had levels of
compatability with std:: I mean QString has had it since I started with
Qt, seriously, back at 4.0. My 3.x time was just dabbling.

The second argument I will make in favor of keeping the containers is
the mantra which drew so many to Qt so many years ago.

All objects derived from QObject are cleaned up on exit.

Yes, that is very Java like. When we start mixing and matching QObject
containers with std:: we run the risk of going straight back to the dark
ages writing programs for feeble PC based operating systems which cannot
clean up behind a process. (Before anyone challenges that they need to
read up on OpenVMS, MVS, and Z/OS.)

I will cede the point that foreach will probably die a much deserved
death in the near future, even if it remains in the package. Range-based
for loops
https://en.cppreference.com/w/cpp/language/range-for
and especially for_each
https://en.cppreference.com/w/cpp/algorithm/for_each

The dark side of Qt's foreach was making a copy to operate on. Yes,
there were reasons for it, but, it was a stumbling block for more than
one developer new to Qt and in the embedded systems world, that copy
could be massively expensive.
--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

[Lars Knoll]

Post by Roland Hughes
====
Sorry to say it, but welcome to C++
No, mostly kidding. I think what you suggest sort of makes sense. If
Qt are to keep its containers, with a goal of offering an alternative
more convenient/Java-esque API, then a helper member function like you
suggest seems to fit that goal. Whether Qt still has this as a goal in
another matter. Maybe not to the extent that they once had?
For the pattern above, I guess one could make a generic helper in a
header of the application. I know e.g. Qt Creator has a bunch of such
helpers in its headers.
====
I would like to weigh in a vote for Qt keeping its containers. The reason behind that vote is the ever present installed base.

I think most people working on developing Qt are fully aware of this. As I said a couple of times, we do not intend to break APIs in any major way when moving towards Qt 6. That also implies that our container API is there to stay. But where we can streamline/align with standard C++ in good ways, we probably should try to do that.

Post by Roland Hughes
We already lose droves of Qt developers every year when Qt keeps moving on but medical devices, border security systems like cargo x-ray, train control systems, etc. have to fork their own version of Qt because Qt keeps moving on without a 5-8 year LTS.

Yes, the Open source and standard commercial versions come with a maximum of 3 years for LTS releases. But you can get longer support for Qt versions from The Qt Company though.

Post by Roland Hughes
At this point their are hundreds, thousands, perhaps millions of Qt example programs scattered around the Internet, many of which don't bother to name the Qt version they were written with, not to mention "official" texts which will now mostly not work.
https://www.barnesandnoble.com/w/c-gui-programming-with-qt-4-2nd-edition-jasmin-blanchette/1101413840?ean=9780132354165
Granted that one actually names Qt 4 but programming languages as wells as their libraries have a time honored tradition of just adding, not dropping major components.

For the largest part. But it’s important to realise that sometimes dropping some parts is required to keep things maintainable (as the number of people working on Qt is not growing infinitely), and to be able to adapt to a changing world. Of course we’ll have to be careful doing that.

Cheers,
Lars

Post by Roland Hughes
Okay, BASIC dropped IRREGARDLESS and C++ has _finally_ dropped trigraphs, but neither were major components.
Yes, I have heard various young guns in here chanting the mantra "why spend resources maintaining something std now does?" Well, the installed base is the reason. Under the hood feel free to change them dramatically, but, maintain the API. It doesn't matter if std:: is adopting many Qt-esque things, we have always had levels of compatability with std:: I mean QString has had it since I started with Qt, seriously, back at 4.0. My 3.x time was just dabbling.
The second argument I will make in favor of keeping the containers is the mantra which drew so many to Qt so many years ago.
All objects derived from QObject are cleaned up on exit.
Yes, that is very Java like. When we start mixing and matching QObject containers with std:: we run the risk of going straight back to the dark ages writing programs for feeble PC based operating systems which cannot clean up behind a process. (Before anyone challenges that they need to read up on OpenVMS, MVS, and Z/OS.)
I will cede the point that foreach will probably die a much deserved death in the near future, even if it remains in the package. Range-based for loops
https://en.cppreference.com/w/cpp/language/range-for
and especially for_each
https://en.cppreference.com/w/cpp/algorithm/for_each
The dark side of Qt's foreach was making a copy to operate on. Yes, there were reasons for it, but, it was a stumbling block for more than one developer new to Qt and in the embedded systems world, that copy could be massively expensive.
--
Roland Hughes, President
Logikal Solutions
[phone]
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Jean-Michaël Celerier]

Post by Lars Knoll
As I said a couple of times, we do not intend to break APIs in any major

way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do that.

It's not only about breaking APIs but also breaking current observable
behaviour - i.e. performance. Currently if you're passing data across
threads - e.g. compute something in a thread and pass the result to the
main thread to display it - you generally pass a QVector / QList /
QWhatever that does implicit sharing, because the signal-slot mechanism
will do a copy of the object in any case across threads and doing two
atomic operations for a QVector copy is cheaper than creating a new
std::vector, calling malloc, and copying 500 ints however you look at it.
What is the option if Qt opts out from this ? put everything in shared_ptr
?

Best,
Jean-Michaël

Post by Lars Knoll

Post by Roland Hughes
====
Sorry to say it, but welcome to C++
No, mostly kidding. I think what you suggest sort of makes sense. If
Qt are to keep its containers, with a goal of offering an alternative
more convenient/Java-esque API, then a helper member function like you
suggest seems to fit that goal. Whether Qt still has this as a goal in
another matter. Maybe not to the extent that they once had?
For the pattern above, I guess one could make a generic helper in a
header of the application. I know e.g. Qt Creator has a bunch of such
helpers in its headers.
====
I would like to weigh in a vote for Qt keeping its containers. The

reason behind that vote is the ever present installed base.
I think most people working on developing Qt are fully aware of this. As I
said a couple of times, we do not intend to break APIs in any major way
when moving towards Qt 6. That also implies that our container API is there
to stay. But where we can streamline/align with standard C++ in good ways,
we probably should try to do that.

Post by Roland Hughes
We already lose droves of Qt developers every year when Qt keeps moving

on but medical devices, border security systems like cargo x-ray, train
control systems, etc. have to fork their own version of Qt because Qt keeps
moving on without a 5-8 year LTS.
Yes, the Open source and standard commercial versions come with a maximum
of 3 years for LTS releases. But you can get longer support for Qt versions
from The Qt Company though.

Post by Roland Hughes
At this point their are hundreds, thousands, perhaps millions of Qt

example programs scattered around the Internet, many of which don't bother
to name the Qt version they were written with, not to mention "official"
texts which will now mostly not work.
https://www.barnesandnoble.com/w/c-gui-programming-with-qt-4-2nd-edition-jasmin-blanchette/1101413840?ean=9780132354165

Post by Roland Hughes
Granted that one actually names Qt 4 but programming languages as wells

as their libraries have a time honored tradition of just adding, not
dropping major components.
For the largest part. But it’s important to realise that sometimes
dropping some parts is required to keep things maintainable (as the number
of people working on Qt is not growing infinitely), and to be able to adapt
to a changing world. Of course we’ll have to be careful doing that.
Cheers,
Lars

Post by Roland Hughes
Okay, BASIC dropped IRREGARDLESS and C++ has _finally_ dropped

trigraphs, but neither were major components.

Post by Roland Hughes
Yes, I have heard various young guns in here chanting the mantra "why

spend resources maintaining something std now does?" Well, the installed
base is the reason. Under the hood feel free to change them dramatically,
but, maintain the API. It doesn't matter if std:: is adopting many Qt-esque
things, we have always had levels of compatability with std:: I mean
QString has had it since I started with Qt, seriously, back at 4.0. My 3.x
time was just dabbling.

Post by Roland Hughes
The second argument I will make in favor of keeping the containers is

the mantra which drew so many to Qt so many years ago.

Post by Roland Hughes
All objects derived from QObject are cleaned up on exit.
Yes, that is very Java like. When we start mixing and matching QObject

containers with std:: we run the risk of going straight back to the dark
ages writing programs for feeble PC based operating systems which cannot
clean up behind a process. (Before anyone challenges that they need to read
up on OpenVMS, MVS, and Z/OS.)

Post by Roland Hughes
I will cede the point that foreach will probably die a much deserved

death in the near future, even if it remains in the package. Range-based
for loops

Post by Roland Hughes
https://en.cppreference.com/w/cpp/language/range-for
and especially for_each
https://en.cppreference.com/w/cpp/algorithm/for_each
The dark side of Qt's foreach was making a copy to operate on. Yes,

there were reasons for it, but, it was a stumbling block for more than one
developer new to Qt and in the embedded systems world, that copy could be
massively expensive.

Post by Roland Hughes
--
Roland Hughes, President
Logikal Solutions
[phone]
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[r***@logikalsolutions.com]

Post by Lars Knoll

Post by Lars Knoll
As I said a couple of times, we do not intend to break APIs in any major

way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do that.
It's not only about breaking APIs but also breaking current observable
behaviour - i.e. performance. Currently if you're passing data across
threads - e.g. compute something in a thread and pass the result to the
main thread to display it - you generally pass a QVector / QList /
QWhatever that does implicit sharing, because the signal-slot mechanism
will do a copy of the object in any case across threads and doing two
atomic operations for a QVector copy is cheaper than creating a new
std::vector, calling malloc, and copying 500 ints however you look at it.
What is the option if Qt opts out from this ? put everything in shared_ptr
?

Very good catch.

Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512 MEG total
working RAM) data sets with sluggish allocation (if enough memory
exists at all) this is an extreme price.
--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

[Jason H]

Sent: Monday, November 05, 2018 at 9:42 AM
Subject: Re: [Interest] Chasing a standard

Post by Lars Knoll

Post by Lars Knoll
As I said a couple of times, we do not intend to break APIs in any major

way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do that.
It's not only about breaking APIs but also breaking current observable
behaviour - i.e. performance. Currently if you're passing data across
threads - e.g. compute something in a thread and pass the result to the
main thread to display it - you generally pass a QVector / QList /
QWhatever that does implicit sharing, because the signal-slot mechanism
will do a copy of the object in any case across threads and doing two
atomic operations for a QVector copy is cheaper than creating a new
std::vector, calling malloc, and copying 500 ints however you look at it.
What is the option if Qt opts out from this ? put everything in shared_ptr
?

Very good catch.
Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512 MEG total
working RAM) data sets with sluggish allocation (if enough memory
exists at all) this is an extreme price.

Medical and Space-based systems should use the NASA (JPL) coding standard. Chief of which is no dynamic memory after initialization. So all your container arguments are moot.
( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of course you're using mysmic memory after initialization in a medical device (But then, WHY!?))

I've also attributed failures on long-running commodity hardware (RaspberryPis) to the memory fragmentation issue of dynamic memory. Interestingly, this is why other languages (C#, Java) have dynamic memory consolidation capability (i.e. Mark & Sweep, "Handles" (^) in the .NET C++ CLR). But as the JPL standard shows, you do not need to create non-deterministic garbage collection in your language. While I attributed this to failures on a Pi, I have actually researched and concluded that this indeed was the case on an embedded application on a PPC 860. Removing dynamic memory and reverting to fixed-arrays eliminated the crashes after months of run-time. Unfortunately this is nearly impossible on a Pi with it's much larger software ecosystem.

[r***@logikalsolutions.com]

Post by Jason H

Post by r***@logikalsolutions.com
Very good catch.
Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512 MEG total
working RAM) data sets with sluggish allocation (if enough memory
exists at all) this is an extreme price.

Medical and Space-based systems should use the NASA (JPL) coding
standard. Chief of which is no dynamic memory after initialization.
So all your container arguments are moot.
( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless
of course you're using mysmic memory after initialization in a
medical device (But then, WHY!?))

I've never worked on a single medical device which utilized JPL. Not
one. Not saying there isn't one somewhere in the world, but, I've
never seen it. One could not use Qt in a medical device if strictly
adhering to JPL. Something simple like an error message to syslog
being built with a QString would violate such a standard. You couldn't
fill in the values with .arg().

No, the container issue in medical device world isn't moot. It's a
clear and present danger.
--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

[Jérôme Godbout]

I did a few medical application for orthopedic surgery, the coding standard is not a requirement, but only a simplest way to validate your software. I did used Qt into all of them and we manage to certify them for surgery room. It always depend on the level or risk your software lies on. Also if you can proof your software is robust enough (yeah it take a lot of testing and safe guard everywhere) you can pass the certification. JPL only make it easier to pass those since you proof in a easy way that it cannot goes wrong, that's about it.

JPL would be a good thing if you were to make a peacemaker for example. It's more for embedded C software where dynamic alloc is not allowed (just like car industries). If you plan on running C++ on a MCU with very limited resource, you are looking for trouble (it's doable, but the tests time will inflate more then what you will save from C to C++) and will need to take very much great care of the object you create and destroy. In other word, it's a bad idea, stick to C for embedded or critical component.

-----Original Message-----
From: Interest <interest-bounces+godboutj=***@qt-project.org> On Behalf Of ***@logikalsolutions.com
Sent: November 5, 2018 10:55 AM
To: Jason H <***@gmx.com>
Cc: interest <***@qt-project.org>
Subject: Re: [Interest] Chasing a standard

Post by Jason H

Post by r***@logikalsolutions.com
Very good catch.
Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512 MEG total
working RAM) data sets with sluggish allocation (if enough memory
exists at all) this is an extreme price.

Medical and Space-based systems should use the NASA (JPL) coding
standard. Chief of which is no dynamic memory after initialization.
So all your container arguments are moot.
( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of
course you're using mysmic memory after initialization in a medical
device (But then, WHY!?))

I've never worked on a single medical device which utilized JPL. Not one. Not saying there isn't one somewhere in the world, but, I've never seen it. One could not use Qt in a medical device if strictly adhering to JPL. Something simple like an error message to syslog being built with a QString would violate such a standard. You couldn't fill in the values with .arg().

No, the container issue in medical device world isn't moot. It's a clear and present danger.



--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

[r***@logikalsolutions.com]

Post by Jérôme Godbout
JPL would be a good thing if you were to make a peacemaker for
example. It's more for embedded C software where dynamic alloc is
not allowed (just like car industries). If you plan on running C++
on a

Stupid question, but if dynamic memory allocation is not allowed in
the automotive industry, how is it Ford is constantly looking for low
wage Qt developers? More a curiosity than anything else. Those
contracts pay less than 1/3 of my standard billing rate so the emails
and phone calls about them land in the virtual bit bucket.
--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

[Jérôme Godbout]

Qt is probably only used into a part of the Dashboard or entertainment system, the controller chip or embedded MCU and other safety controller are probably not using Qt nor C++. They follow some MISRA, AUTOSAR, CERT standard. They have a C++ standard, but seriously it prevent a good chunk of the language usage. Like in the medical, it always on which system critical part your software going to run, the radio with BLE phone that crash is one thing, the wheel control is another matter. If you don't follow those standard (which is possible), the burden of the proof of reliability false on you and you have to prove how your software can NEVER be a life threat.


-----Original Message-----
From: ***@logikalsolutions.com <***@logikalsolutions.com>
Sent: November 5, 2018 11:30 AM
To: Jérôme Godbout <***@amotus.ca>
Cc: Jason H <***@gmx.com>; interest <***@qt-project.org>
Subject: Re: [Interest] Chasing a standard

Post by Jérôme Godbout
JPL would be a good thing if you were to make a peacemaker for
example. It's more for embedded C software where dynamic alloc is
not allowed (just like car industries). If you plan on running C++
on a

Stupid question, but if dynamic memory allocation is not allowed in
the automotive industry, how is it Ford is constantly looking for low
wage Qt developers? More a curiosity than anything else. Those
contracts pay less than 1/3 of my standard billing rate so the emails
and phone calls about them land in the virtual bit bucket.
--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

[Roland Hughes]

Post by Lars Knoll

Post by Roland Hughes
We already lose droves of Qt developers every year when Qt keeps moving on but medical devices, border security systems like cargo x-ray, train control systems, etc. have to fork their own version of Qt because Qt keeps moving on without a 5-8 year LTS.

Yes, the Open source and standard commercial versions come with a maximum of 3 years for LTS releases. But you can get longer support for Qt versions from The Qt Company though.

Three years isn't a drop of water in Lake Michigan. A completely new
surgical robot will take a minimum of 4 years design and prototyping
followed by 1-3 years of development (which must also include the
_entire_ manufacturing process for certification.) Then it goes through
clinical trials which can last upwards of 7 years. Once released to the
field it will be in maintenance/minor enhancement mode for 10 years or
more. This entire time the tool set must be locked down.

While that may seem like a long time it pales in comparison with drug
manufacturing. Those manufacturing systems must be locked down from the
moment of certification until the drug leaves the market. Setting up a
new line with new tools requires a shiny new certification process. Just
this year a drug manufacturer in California fielded a job opening
looking for a PDP-11 systems manager familiar with hardware maintenance.
Some of you may recall that a PDP-11 was the machine C and UNIX were
developed on in the 1970s. It was _the_ midrange computer of its day but
hasn't been manufactured since the late 1980s. The drug(s) whose line(s)
it controls are obviously still on the market and obviously it is not
worth the cost and pain of retooling and recertification. This situation
happens with drugs to treat rare diseases. The market simply isn't large
enough to bring in competitors making generics.
--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

[Tomasz Siekierda]

Post by Roland Hughes

Post by Lars Knoll

Post by Roland Hughes
We already lose droves of Qt developers every year when Qt keeps moving on but medical devices, border security systems like cargo x-ray, train control systems, etc. have to fork their own version of Qt because Qt keeps moving on without a 5-8 year LTS.

Yes, the Open source and standard commercial versions come with a maximum of 3 years for LTS releases. But you can get longer support for Qt versions from The Qt Company though.

Three years isn't a drop of water in Lake Michigan. A completely new
surgical robot will take a minimum of 4 years design and prototyping
followed by 1-3 years of development (which must also include the
_entire_ manufacturing process for certification.) Then it goes through
clinical trials which can last upwards of 7 years. Once released to the
field it will be in maintenance/minor enhancement mode for 10 years or
more. This entire time the tool set must be locked down.

Since the tool is locked down, then it does not matter if Qt has moved
on or not, right? You're not allowed to upgrade/ change it anyway, you
have to stick to what you deployed. So there is no reason to complain
about lack of support here. That's the reality of such big and long
term projects. NASA also still keeps operational their computers from
1970 to handle Voyager missions. It does not mean that the
manufacturers of these PC are somehow obligated to support them
anymore.

Post by Roland Hughes
Just this year a drug manufacturer in California fielded a job opening
looking for a PDP-11 systems manager familiar with hardware maintenance.
Some of you may recall that a PDP-11 was the machine C and UNIX were
developed on in the 1970s. It was _the_ midrange computer of its day but
hasn't been manufactured since the late 1980s.

And you bring this up because PDP-11 is still supported by its
(non-existing by since 20 years) manufacturer just like Qt should?

[r***@logikalsolutions.com]

On Mon, 5 Nov 2018 at 13:35, Roland Hughes

Post by Roland Hughes

Post by Lars Knoll

On 4 Nov 2018, at 22:13, Roland Hughes
We already lose droves of Qt developers every year when Qt keeps

moving on but medical devices, border security systems like cargo
x-ray, train control systems, etc. have to fork their own version
of Qt because Qt keeps moving on without a 5-8 year LTS.

Post by Lars Knoll
Yes, the Open source and standard commercial versions come with a

maximum of 3 years for LTS releases. But you can get longer support
for Qt versions from The Qt Company though.
Three years isn't a drop of water in Lake Michigan. A completely new
surgical robot will take a minimum of 4 years design and prototyping
followed by 1-3 years of development (which must also include the
_entire_ manufacturing process for certification.) Then it goes through
clinical trials which can last upwards of 7 years. Once released to the
field it will be in maintenance/minor enhancement mode for 10 years or
more. This entire time the tool set must be locked down.

Since the tool is locked down, then it does not matter if Qt has moved
on or not, right? You're not allowed to upgrade/ change it anyway, you
have to stick to what you deployed. So there is no reason to complain
about lack of support here. That's the reality of such big and long
term projects. NASA also still keeps operational their computers from
1970 to handle Voyager missions. It does not mean that the
manufacturers of these PC are somehow obligated to support them
anymore.

This would be a gross missunderstanding of how the FDA "lockdown" is
actually applied. Minor bug fixes can have documentation generated via
an FDA approved process with dramatically reduced testing cycle since
it is mostly negative testing. (Negative testing being testing no
changes to other existing functionality.) The definition of "minor" is
totally within the purview of the FDA and argued case by case.

As far as manufacturers and obligations, see below.

Post by Roland Hughes
Just this year a drug manufacturer in California fielded a job opening
looking for a PDP-11 systems manager familiar with hardware maintenance.
Some of you may recall that a PDP-11 was the machine C and UNIX were
developed on in the 1970s. It was _the_ midrange computer of its day but
hasn't been manufactured since the late 1980s.

And you bring this up because PDP-11 is still supported by its
(non-existing by since 20 years) manufacturer just like Qt should?

There are quite a few places still providing support for the PDP-11
line. Quite a few companies stock piled 11/24 and 11/44 machines as
others moved to VAX, ALPHA, and ITANIUM. Ownership of the line moved
from DEC to Compaq to HP.

Shortly after Compaq consumed Digital Equipment Corporation, Microsoft
paid them a bunch of money to announce the death of OpenVMS in a bid
to get feeble Windows servers running on Compaq PCs into data centers
where they were previously barred. Some corporations started to make
the move. The NSA and DOD paid Compaq a Microsoft a visit. They showed
them the sales and support contracts making cessation of the platform
an act of treason and informed the leaders of both companies just how
lengthy their prison time would be. You see, Bill Gates could bribe
Bill and Hillary Clinton to make the Janet Reno investigation go in a
"don't put Bill in prison for wire and mail fraud" direction, but the
DOD and NSA weren't smiling and given their budgets, no interested in
any bribe either company could offer.

Compaq then announced they weren't killing off OpenVMS and Bill Gates
stepped out of the go-to-prison hot seat as part of the apology. The
other details I do not know. I do know there was much more than that
involved.

NASA had, and probably still has similar contracts.

These long term support contracts are why we have $12 wooden pencils
and $800 hammers. That __EXACT__ product has to remain available and
replacable for many many decades. Even if every tree of that type dies
on the planet, the vendor who signed the contract must still find a
way to make that __EXACT__ pencil with that __EXACT__ wood and other
components. There is still a vendor prodiving 8 inch floppies to the
DOD because they are used to boot the nuclear missile launch systems.
Given the short life of floppies, they aren' surviving on a eBay
stockpile. They are actually making them every so often.

If Qt wishes to play in the embedded world, it has to come to grips
with this reality. It's not a "chase the latest idiot phone trend"
world. This is why you are starting to see various companies who would
otherwise consider each other competitors banding together to maintain
the now abandoned Qt releases. Most every year or at least every other
year I get emails and calls about doing Qt 3 work on OS/2 from this
Harman (sp?) consulting firm. Minor changes to an existing medical
device whose systems were built using those tools.

One of my past clients had almost nothing to do with the DOD post
WW-II, but, they still have all of the equipment to make torpedos for
said boats and ships. They must keep it on site in good condition
until the contract ends. I've been told that contract doesn't end
until the last vessel of war capabile of firing said munitions is
scuttled. I have not personally seen the contract, nor do I wish to.
You will find every major manufacturer which existed during WW-II has
a similar contract for something else. These contracts don't expire
until the DOD deems what they manufactured non-strategic and disposes
of it.
--
Roland Hughes, President
Logikal Solutions
[phone]

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us