Qt 5.15 Standard Support for Legacy License Holders Ends Today
Comments
teruakohatu
tensor
As far as I know Qt is legit a standard for advance UI in automotive and other industrial applications. I think it's fair to say they contributed.
kramerger
vscode is now the standard editor for development at Tesla.
I don't see Microsoft making such claims.
sho_hn
I'd say it's fine. Tesla is widely praised for their software experience, and Qt sells a product with the value proposition of speeding up and enabling software development. Linking the two in a marketing message isn't crazy.
And frankly, there are some technical properties of Qt that do make it well-suited to the kinds of problems car makers need to solve. For example, Qt is quite good at offering customizability and extension points at low/mid/high levels of the toolkit. It's easy to subclass/extend/replace UI controls in various ways. When you need your UI controls to do unusual things not found on other kinds of systems, for example implement regional rules for driver distraction, that's useful.
At the end of the day, there's likely more EVs on the road with Qt on them than without.
TechBro8615
Isn't SpaceX using Chromium with a JavaScript app in their space capsule dashboards? It's interesting that they chose that while Tesla used Qt. Obviously the engineering teams aren't the same but I wonder if there is a story behind the two choices.
sho_hn
Cars are high-volume, mass-market products in a mature industry, so there's some amount of pressure to be efficient with resources. If you build a small series space capsule, presumably the extra cost of being able to run a heavy web-based UI isn't your biggest worry.
The Dragon dashboard is also mostly presenting information, it's not used to, say, pilot/operate the vehicle, change settings or other complex applications.
chungy
I think if you can afford to build a rocket, you can afford to build a computer capable of running Chromium.
Average people need not apply.
asddubs
the thought of having a javascript app control a spaceship is viscerally terrifying however
TechBro8615
Why? V8 is probably the most widely deployed and tested execution environment in the world.
asddubs
v8 maybe, but javascript isn't exactly a language known for having few footguns
TechBro8615
I can see why you wouldn't want it running your guidance controller. But for interactivity, is there really a better choice? I would argue physical knobs and buttons are better, but if you've decided to write a software dashboard, what's a better option than Chromium + JS for interactivity? There are no formally verified GUI frameworks (AFAIK), so the only available evaluation metric is "how battle tested is it?" Surely Chromium wins just by sheer scale of deployment.
What I'd be curious about is how they handle updates. The Web platform is a moving target, and it's not like Chromium engineers are pushing features with "astronomical" failure cases in mind. Even if the SpaceX software is perfectly tested, it could break in possibly uncovered ways with each new update. So does SpaceX keep it up to date and run the same battery of tests on each version? Or do they freeze the version and only update along with their normal SDLC?
EDIT: FWIW, it looks like the original source of the Chromium claim is a Reddit AMA [0] with more details from the SpaceX software team.
[0] https://old.reddit.com/r/spacex/comments/gxb7j1/we_are_the_s...
sam_bristow
Qt does have a functional safety certified renderer available[1]. My expectation though is that the passenger UI isn't safety critical on Dragon. A "crash and restart" model is probably fine for what it's doing.
asddubs
I don't think it's fair to equate a dashboard written in javascript running on chromium + v8 to chromium + v8. Qt is pretty battle tested as well, and more easily allows you to stick to built-in widgets which are equally battle tested. Although I think ultimately both suffer from the fact that they are moving targets with active development of new features.
chungy
Hey, when selling a toolkit/framework, they've gotta spin the data in their favor as much as possible. If I was in charge of Qt marketing, I'd do the same.
mtkd
It's also the gift that keeps giving when setting up capybara-webkit on a new box
steve1977
I guess it’s “contributed” in the same sense that many people use term in their CVs (as in “I happened to be in the same building when project x succeeded”)
sho_hn
Qt Company does also sell professional services and has engineers work directly on customer projects.
FloatArtifact
https://github.com/rochus-keller/LeanQt
A minimum and easy to build fork of QT
jeroenhd
I only know Qt as a requirement to install for some tools and libraries. Can someone explain the significance of this? Is there a reason people still wait for LTS updates for Qt 5 instead of upgrading to Qt 6?
Edit: thank you for your responses!
_0w8t
QT is used for embedded systems that may run for 10 and more years. If a device requires certification, one does not want to upgrade to a newer QT as that may require to certify the software again, while for security fixes the requirements are much more simpler.
EliRivers
Having recently seen a product move from Qt5 to Qt6, there sure are reasons! Off the top of my head, some of the things that had to be done:
Remove every use of the previous QRegExp class (no longer existed in QT6), which was always bad, and replace it with the similar but slightly different behaving QRegularExpression class. Different enough that it's not just a simple grep.
Rip out huge chunks of XML processing code that used QT5 XML libraries that were outright withdrawn, and replace them with alternatives.
Rewrite some sound generating code to switch away from Qt5 classes that straight up no longer existed, to something else.
Rip out uses of the QT5 web engine classes; I think I recall it was replaced wholesale in QT6, but it was nothing but trouble through its life so there was an outright rewrite of everything using it to just do something non-web instead.
Any others that were outright withdrawn we also must have replaced. Can't remember them all, but here's a list: https://doc.qt.io/qt-6/whatsnew60.html#removed-modules-in-qt...
Some of those have an extended life in a QT6 "QT5 compatability module", but that's clearly not going to get a lot of security and bugfixes and there's no telling when it might vanish.
Lots of very fiddly changes to the Qt metatype system had people trawling through weird and wonderful error messages working out what was going on and how they could replace it.
QT6 demanded to be built under C++17; after switching the compiler to that, there sure was a whole lot of old code that either didn't compile at all, or flashed heavily red when the compiler looked at it, that demanded a rewrite.
All this, and when you're done, you've got something that's probably functionally about the same as what you had beforehand, but the previous version of the software under QT5 had a decade of use testing and this is brand new.
No customer is going to pay for all this effort, so there is very little impetus on anyone to move from QT5 to QT6 if the QT5 version works and updates keep coming. It's only at the end that people are finally forced to make a move.
cbhl
This announcement mostly affects folks who are using Qt under paid commercial licenses. Qt 5 had "perpetual" licenses that you could buy, but for Qt 6 they switched to a SaaS monthly licensing model.
If you're using Qt applications purely in the open source world (e.g. KDE on some Linux distro) there's no new news here.
gettodachoppa
>If you're using Qt applications purely in the open source world (e.g. KDE on some Linux distro) there's no new news here.
A lot of small businesses use Qt for free under the LGPL license (allowing them to keep their application closed-source as long as the user is free to replace the Qt dynamic libraries). For the past several years many new modules are commercial or GPL only, preventing their use by LGPL users. For example, QtWayland, QML Virtual Keyboard, WebGL, Qt Quick 3D.
Some companies would bite the bullet and pay for Qt their exorbitant fee, then let the license expire and keep using the old version. As you say, this will no longer be possible.
I find Qt 6's license policy awful, I simply don't believe in "pay us forever even if you're happy with an old version". Early on Qt 6 even had a draconian commercial policy that wouldn't allow you to distribute an old binary after if your license was expired and you stopped new development, thankfully they walked this back.
ptx
There are related old news for the open source world, though, in that Qt 5.x LTS is no longer open source: https://news.ycombinator.com/item?id=25748335
sho_hn
It's a bit more complicated than that.
- The initial versions of LTS point releases (so e.g. something like a 5.15.0) are open source. The commercial-only begins a few point releases in, say with something like a 5.15.3.
- Due to the KDE Free Qt Foundation agreement, also those initially commercial-only point releases do become open source eventually, at a max 12 month delay.
This was indeed very controversial when it was done for the first time with Qt 5.15.*, since that is the last major version if Qt 5, which effectively meant no same-day open source maintenance releases for Qt 5 anymore after some point. Within the Qt 6 release series it's less of a big deal, in that by the time a 6.x.y is released commercial-only, usually the next 6.x is already around the corner.
t90fan
QT is used a lot in Embedded systems.
Years ago, I used to write software for medical devices which used QT, and those were supported in the wild for 10 years.
I think its also popular in cars and stuff nowadays.
throwaway2037
To be clear, this announcement is less scary that it sounds. Qt 5.0 was first released in 2012, and had its final release in 2023.
> Qt 5 has contributed to the largest disruption in this century in the automotive industry, making electric cars available to the masses.
That is quite a bold claim. Tesla used QT which I think they are referring to, but I don't think the choice of QT contributed to the disruption on the automobile industry.