On 8/14/19 11:15 PM, Thiago Macieira wrote:
On Wednesday, 14 August 2019 12:09:02 PDT Roland Hughes wrote:
If you do not need the latest bells and whistles, drop back to Qt 4.8
No, don't. That is not receiving security fixes.
That's exactly what is happening in many places and it should be done. A
number of shops have their own forks of 4.8, some have shared forks.
"not receiving security fixes" is a bit of FUD. I'm not challenging you
or calling you a liar, it just is a bit of FUD. For many (possibly most)
embedded systems, at least in the FDA regulated world, it does not apply.
To start with, there is no version of OpenSSL which is secure. Whoever
is using Qt just because it makes using SSL easy(ier) shouldn't be using
Qt anyway because they are releasing an insecure app they incorrectly
feel is secure.
Most medical devices I've been exposed to don't even allow "the
application" to perform any communication. Yes, a patient monitor can
transmit but the application doesn't do it. A "Comm Module" which is not
field flashable and is written with some other tool set, usually running
an RTOS contains all of the communications and security. It can only
communicate with the host which has been "burned" into it if and only if
that host has the proper set of keys. You cannot take a vitals monitor
from Hospital A and have it "just work" at Hospital B because it has the
wrong "Comm Module."
A proprietary (and severely limited) API exists between the application
and the "Comm Module." The outside world generally cannot pull data from
the device, only announce that it is available and ready to receive.
When "the application" sends data to the "Comm Module" it munges it up
per the API and the "Comm Module" handles the multiple levels of
security between itself and the paired host module.
This optical isolation is done for many reasons, not the least of which
is that the "Comm Module" gets re-used on many different devices. When
you want to change something in the communication (add a 7 level book
code, 4 more encryption routines, whatever) it is an incredibly simpler
FDA approval process. You just have to prove you didn't change the
application API and that the "Comm Module" still communicates with the
"Host Module."
As far as the divide by zero error mentioned later in the thread, all of
the repeatable testing for a device will shake out if that is even in
any execution path. Depending on where it is, those classes may not even
be part of the application.
Pretty much everyone should be falling back to Qt 4.8 and staying there
until this ex-wife alimony licensing mentality gives Qt yet another new
owner. 99.9999999% of all companies refuse to pay royalties. No,
negotiating an up-front buy out for a license isn't paying royalties.
That's what my last customer did, but it was touch and go. They were
ready to kick Qt to the curb despite all of the proof of concept work
done with it.
In my new book with the working title "The Phallus of AGILE and Other
Ruminations" I have an essay titled "Royalties - Every Stupid Idea Comes
Around Again." It's pretty good. One of the case studies used is that of
RTLINK vs. Blinker. RTLINK was massively expensive. It had a lot of
library functions which could make things great, but it would only
overlay at the OBJ level. Blinker did wonderful things, was less
expensive and would overlay at the memory page level. RLINK decided it
wasn't making enough from its massively expensive (2-3 times the price
of Blinker) so it went to a royalty model. RTLINK basically went under,
got consumed by CA and rolled into Clipper before disappearing from the
marketplace. Blinker is still being sold and used in the embedded DOS
world today. There is even a cottage/niche desktop DOS industry.
Before anybody poo-hoos embedded DOS let me inform them that AGCO uses
embedded DOS in pretty much all its Combines. Possibly all of their ag
equipment, I only know about the combines designed in Kansas. They have
a $5+ Billion market cap.
https://finance.yahoo.com/quote/AGCO/
While we are on the royalty topic I'm fielding an increasing number of
contacts from companies looking for Qt consultants willing to port
projects OFF Qt because of the licensing.
There is a 6 month gig in St. Paul, MN for a system running on RHEL
where they are looking to dump Qt, ostensibly over the licensing.
Swanktek is shopping the gig around for those interested. I'm not. I
just got back from a winter project in Minnesota.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
