Our customers (multi-national, semiconductor companies) often will not change OS's the moment a
chip design is started. They "may" patch security, but often, they simply limit access
to the outside world so connectivity security is not really their concern. The applications aren’t
"online" they are usually command line drive, with UI interfaces for debugging the issues
found.
We still had to support CentOS 5 until about 2 years ago, when our customer
finally was able to drop it in their process.
For CentOS 6, I understand it was for enhancements in the Qt functionality.
However, I think it’s a major mistake for any MAJOR version to drop an OS.
Adding is fine, but dropping shouldn’t happen.
If I were king for a day, if its "mostly source compatible" then the OS (and
compilers) should still be supported. In this case, unless it’s a patch required on the
compiler (to fix a bug) I should be able to build Qt 5.X even if it requires a dev-tools
patch. Same for Win7 and VS 2013.
Moving from Qt5 to 6, I am ok with dropping Win7 and/or CentOS 6. I disagree with Roland here. Yes, it would be "better", if I could easily build against the latest version of Qt, and build it for an ancient version of any particular OS. But in order to do that, I would expect the configuration options would go insane. Any item that doesn’t build for that OS (it might not have that functionality that code was added for a newer version of the OS) would have to be ifdef'ed out via configuration. It’s a possible but expensive solution.
However, I do think, and from a commercial license holder POV (which my current
company is), in general it is really painful when an OS is dropped from one LTS
to another. We are actually hitting that issue right now. We want to move to
5.15, but have a 20 million + a year, contract tied to CentOS 6. We really
can't even consider dropping centos 6, instead we have to port Qt to CentOS,
or stay on the last version of Qt that built on it. It’s a really crappy
position to be in.
Telling a customer such as us, for Qt 6, you cant build for CentOS 6, would
mean, we would simply stay on the Qt 5 tree even longer, and likely pay for
extended support until we could move off of CentOS 6. But we know of bugs,
that directly affect us that have been fixed in newer versions of Qt, and we
wind up having to back patch them to the Qt we are using, so we can still
support our OSes
Scott
-----Original Message-----
From: Interest [mailto:interest-boun...@qt-project.org] On Behalf Of Roland
Hughes
Sent: Thursday, June 11, 2020 4:57 PM
To: Sérgio Martins <iamser...@gmail.com>
Cc: Qt Project <interest@qt-project.org>
Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6
On 6/11/20 6:07 PM, Sérgio Martins wrote:
On Thu, Jun 11, 2020 at 9:51 PM Roland Hughes
<rol...@logikalsolutions.com> wrote:
On 6/11/20 1:47 PM, Michael Jackson wrote:
Windows 7 is EOL. Period. If it costs you, as a developer, additional money to
support an EOL'ed, unsupported version of an operating system then you will
need to pass that onto the customer. By still supporting Windows 7 we, as
developers, are just enabling those customers to keep from updating. There are
very few real reasons*not* to update to at least Windows 8. At some point the
customer needs to understand that they are not going to get any new features.
They current piece of software will keep working (Assuming a perpetual license)
but nothing new will be supported. I've had requests to back port our software
to CentOS 6 and once you explain the cost to them for us to maintain all the
extra development hardware, extra engineering to develop codes that are not
supported on the old compilers, it becomes cost prohibitive to maintain those
versions.
Personally I don't think anyone should be running a virus known as
Windows on any computer.
There are major corporations still running Windows XP, let alone 7,
because they have critical systems written and running on that OS.
They can continue to. And why would critical systems be ported to Qt 6 ?
Not ported, added to.
The
tool or whatever cannot port forward or costs massive amounts of
money to bring forward. Just today someone told me about one of GM's
factories in Europe is run by a highly customized "canned" factory
control system written in VB5. When people show up to the factory, it
makes vehicles every day.
You can't have rolling upgrades on critical systems, you just can't.
Then why would you want to port that to Qt 6 ?
Not ported to, added to.
Upgrading is a multi-million dollar cost adding nothing to the bottom
line. They really don't care if a third party developer's life is any
easier, that developer isn't on the payroll and they have an
auto-renewing can only be cancelled for non-payment support contract.
Windows 7 is EOL in marketing only.
Just like Qt 3, 4 and 5 will be used for many years.
I'm willing to bet CAT is still using WinCE. They were as of less
than a year ago because a contract hit my inbox.
Yes CAT for sure won't be ported to Qt 6. Why do you even mention it
on a thread about running Qt6 on Win7 ?
Because there seems to be a continuing focus here to only care about what Apple
is shipping tomorrow and what Best Buy is selling today.
That's not how it works in embedded systems.
I don't know how, but Agco has their own version of DOS and is
somehow using Qt.
And they can continue to, regardless of the outcome of this thread.
No, they can't. They won't be able to do enhancements.
As I said, I don't personally care about Windows. If Qt drops support
for Windows 7 going forward it will simply shove a big chunk of
current users (who aren't using QML and JavaScript) to CopperSpice
because it claims to still be supporting Windows via MinGW all the
way back to Windows Vista.
https://www.copperspice.com/docs/cs_overview/supported-platforms.html
You cannot force customers to "upgrade" but you can force them to leave.
So their systems are too critical to update software but a port to
CopperSpice is fine ?
All the examples you gave don't care about Qt 6, in fact many of them
don't even run on Qt > 5.6, which dropped support for WinCE and XP.
And that's OK, it's the software lifecycle.
Not port, add to.
You are still thinking in the home hobby x86 frame of mind. That's not how a
line works.
At some point on an assembly line you have a local control system.
Today they are making the GMC Sierra 2500 and at this point in the line there
is a welder hooked up. The worker loads the control program that runs the bead
on the left side of the truck welding the front cab post to the frame then
engages the rear cab post weld as the line crawls.
Next week that same spot on the line has a robotic grinder hooked up.
The worker loads the grinder control program for the vehicle model being made
that week.
For the 2021 model year, a shiny new type of machine needs to be at that spot
in the line. It needs a shiny new control program THAT MUST RUN ON THAT BOX.
Yeah, you can find people that still know the version that runs on there. How
about for the 2028 model year?
There is a medical device that Harman emails/calls about seems like every 18-36
months using Qt 3.x and OS/2. The problem for them isn't maintaining the
equipment and development tools, it's finding someone that doesn't have to
start from scratch learning Qt 3.x. They can get by with a shorter trial and
testing period if say, Qt 6 still compiled on
OS/2 because if you aren't changing out the OS there are different rules. A
full new product clinical trial would cost millions of dollars.
It's cheaper to play people like me off against one another trying to find someone
charging less than $180/hr knowing full well you are probably going to pay $225/hr for
on-site work than it is to do an OS and full tool set swap because now you have to go
through the full "new product" clinical trial (usually.)
So no. I'm not saying PORT. I'm saying they would switch new development (and
any support/royalty/licensing) contracts to a similar tool set that still
supported the platform.
If Qt is only chasing the last version shipped then it can kiss any hope of
royalties goodbye. What incentive is there to sign up and pay royalties when
the embedded system OS they used gets dropped like yesterday's newspaper?
I keep trying to explain it but it falls on deaf ears. Big business; real
systems at real companies; need 15-30 year (not month, year) support cycles.
But hey! If Qt Company doesn't collect one red cent from customers because
developers keep dropping the very platforms that just might pay big support
contracts, that's OK, it's the software lifecycle.
