[HN Gopher] Qt Group Buys IAR Systems Group
___________________________________________________________________
Qt Group Buys IAR Systems Group
Author : shrimp-chimp
Score : 60 points
Date : 2025-10-20 12:09 UTC (10 hours ago)
(HTM) web link (www.qt.io)
(TXT) w3m dump (www.qt.io)
| joezydeco wrote:
| Two companies with horrendous licensing methods and prices.
| They'll do great together.
| rrgok wrote:
| Everytime a QT post comes someone bitch about the licensing
| model. And every time I google and try understand what is wrong
| with the licensing model. And everytime I end up confused about
| it.
|
| Could you kindly ELI5 me what is wrong with QT licensing model?
| joezydeco wrote:
| If you get confused by it then that's all that needs to be
| said. The rest has been discussed over and over. I've dropped
| Qt for other front-end tech and I'm happier now.
| CoastalCoder wrote:
| I'm curious what you settled on and why. Care to elaborate?
| ogoffart wrote:
| Not OP, but some users migrated from Qt to Slint and are
| happy with it. [https://slint.dev] (I'm one of the Slint
| developers.)
| joezydeco wrote:
| I work on equipment that can't open itself under LGPL3
| rules. So I had to stop Qt use at 5.15, which went under
| maintenance support over 3 years ago.
|
| I've switched to vanilla web technologies. Node, React,
| etc. It's painful and it sucks but hardware keeps getting
| faster and cheaper. I can find contractors easily and I
| don't need an increasingly expensive
| subscription^H^H^H^Hcontract with Qt to keep my developer
| seat hot. They tried multiple times to get me to abaondon
| my Qt5 license to switch to their new revenue model. I
| told them to fuck off.
| HeyLaughingBoy wrote:
| Replying to this post because the thread's getting too
| deep.
|
| What was painful about switching to web tech for UI? I've
| proposed it at work a few times for exactly the same
| reasons: get away from Qt and ease of finding developers.
| Since our GUIs all run on Linux (we usually do the realtime
| stuff on an external ARM processor) it seemed like an easy
| transition, but I've been shot down every time.
|
| Would be nice to hear what the downsides are.
| markfeathers wrote:
| From my perspective they spread FUD about open source
| licensing. QT core is LGPL3. Many applications would be fine
| with using LGPL3 in commercial applications. Read QT's
| landing page on licensing, and fossa has a good block post on
| requirements.
|
| https://www.qt.io/qt-licensing
|
| https://fossa.com/blog/open-source-software-
| licenses-101-lgp...
|
| >And everytime I end up confused about it.
|
| I think this is the point. If you're making a real
| application you may pay for the licensing to avoid the
| uncertainty/risk.
| michaelsbradley wrote:
| It's LGPL mostly, with some non-core libraries that are GPL
| or use other licenses:
|
| https://doc.qt.io/qt-6/licensing.html
|
| Over the years it has been noted by many that Qt's wording
| and warnings about the LGPL amount to spreading FUD or
| outright misinformation in what seems like an attempt to
| scare managers and C-suite folks into buying commercial
| licenses "just in case".
| bradfa wrote:
| Qt (the company) releases _MOST_ of their code under open
| source licenses, but not all. Qt4 was LGPLv2.1, Qt5 and
| beyond are under LGPLv3.
|
| In every major Qt release, there's a handful of super useful
| but kind of niche widgets which aren't released under open
| source licenses, presumably as a sales tactic as buying
| licenses gets you these widgets and sometimes that is cheaper
| than building them yourself, but unless you need these, you
| probably don't care about this.
|
| Although my experience attempting to buy licenses from Qt is
| about a decade out of date now, the way it roughly worked was
| you paid a per-seat-per-year fee to get a developer license
| or build-machine license. Then you bought bundles of
| deployment licenses, and the bigger the bundle then the lower
| the cost per license. If you are buying a bundle of a few
| thousand devices then you pay more per license than if you're
| buying a bundle of a few million. Either way, it is a
| significant chunk of cash you have to front to get your block
| of licenses and normally embedded projects are _EXTREMELY_
| sensitive to per-unit costs.
| seba_dos1 wrote:
| Nothing's wrong with their licensing model, but they've been
| known for misrepresenting their licensing model in order to
| steer people towards their commercial offerings.
| bobmcnamara wrote:
| > And every time I google and try understand what is wrong
| with the licensing model. And everytime I end up confused
| about it. Could you kindly ELI5 me what is wrong with QT
| licensing model?
|
| This right here! We customers and users alike are often
| confused by QTs piecemeal licensing model.
| freedomben wrote:
| I could be misunderstanding, but my read of the GP is that
| they aren't confused about the licensing model, they're
| confused by the hate for it
| linhns wrote:
| Because it's unclear and incomplete. Always prone to some KDE
| whims.
| Macha wrote:
| KDE is an independent project from Qt and the only say they
| have is they have the right to release Qt under a BSD
| license if Qt Group removes the GPL option (
| https://kde.org/community/whatiskde/kdefreeqtfoundation/ )
| rcxdude wrote:
| A big one that I've heard, is that they are funny about you
| developing with it under an open source license and then
| buying a commercial license. I.e. if you would potentially
| want to use something that's under the commercial license
| then you need to buy it when you start development instead of
| when you find you want the commercial side. I don't know if
| this is still the case, though.
| vintagedave wrote:
| I'm familiar with the normal MSVC/Clang/GCC/EDG C++ compilers,
| but not IAR's. They seem to make C++ compilers for embedded
| systems. Does anyone know if these are their own, or based on
| something like Clang?
|
| Their supported standards list 'libc++' [1] which implies LLVM
| and potentially Clang. I could not find info online.
|
| "IAR Embedded Workbench C++ is dialectal and contains some
| features not part of standard C++." [2] Their extensions seem to
| be to relax some awkward syntax, and for embedded systems support
| such as memory positioning (?)
|
| Qt is huge in the embedded space, such as automotive, where I see
| IAR is as well. Makes sense as an acquisition. I used to work as
| the C++Builder product manager, which has custom C++ language
| extensions, and I always personally (not a statement from my
| prior employer in any way) wondered if Qt might someday look to
| that toolchain too -- it does not target embedded computing, but
| it has excellent expertise in custom compiler changes including
| extensions to address exactly the same problems (as I understand)
| that Moc tries to solve. In general especially with the state of
| the C++ committee, and Qt dealing with some custom handling, I
| would expect owning a compiler toolchain with a willingness to
| customise the language to be highly beneficial for them.
|
| [1] https://www.iar.com/embedded-development-tools/iar-
| embedded-...
|
| [2]
| https://en.wikipedia.org/wiki/IAR_Systems#IAR_Embedded_Workb...
| thadt wrote:
| It's been a few years since I've slung code with it, but I'm
| pretty sure IAR had their own compiler (along with it's own
| special occasional bugs). Of the IDE's I've used, it wasn't
| that bad. But QT Creator was better. Bringing together IAR's
| tech and reach with QT's expertise does make a lot of sense.
| Palomides wrote:
| I'm not sure there's much overlap in use cases, considering the
| two very separate classes of 'embedded'; Qt is used on Linux
| capable devices and IAR is MCUs
|
| why would Qt want to customize a compiler when they still need
| to support llvm/gcc/msvc?
| ndiddy wrote:
| There's a class of high-spec microcontrollers that have a ton
| of RAM and flash and built-in support for stuff like
| touchscreens. It looks like Qt is able to run on these:
| https://www.qt.io/platform/develop-software-
| microcontrollers... . I'm not sure how much of their business
| is people targeting bare-metal microcontrollers, but there is
| at least _some_ overlap.
| HeyLaughingBoy wrote:
| Maybe better tooling to manage both? My $DAYJOB builds
| systems where we use Qt as the Linux GUI, with real-time
| processing outsourced to a microcontroller and the toolkit on
| that side is usually IAR. It's a pretty common configuration
| across industry, TBH.
|
| My first thought is that they can extend Qt's test library to
| also manage test data across a pipe to the embedded
| processor.
| bobmcnamara wrote:
| IAR has their own backend and I believe front-end as well.
|
| They routinely smoked GCC and Clang, and sometimes ARMs tools
| on a variety of tasks.
|
| I'm not sure I see the advantage on Qt owning a compiler though
| - one of Qt's strengths is portability.
| bluGill wrote:
| The advatage might be they can ensure the compiler supports
| the new features qt wants to use.
|
| reflection could replace moc, (likely c++29 needed) but if
| compilers don't implement that part of reflection qt can't
| use it. If qt can get compilers updated that helps them.
| maleldil wrote:
| Relevant link regarding Qt moc and reflection
| https://wiki.qt.io/C%2B%2B_reflection_(P2996)_and_moc
| p0w3n3d wrote:
| I have a C++ seasoned colleague who says that It framework went
| behind the current C++ standard, however I remember Qt Framework
| much cleaner than C++ itself (by making a sort of a enhanced
| subset), and would prefer use it. What are your opinions?
| freedomben wrote:
| Take this with a grain of salt because it's been about 10 years
| since I slung serious C++. Just my opinion of course, but if
| you go all-in with the Qt libraries, it's a lot better (and
| safer). Most people only think about Qt as a GUI framework, but
| it's much, much more than that. It's a very rich set of
| libraries that do way more than just UI. We actually used Qt
| for our server too!
|
| So I agree with you, Qt tends to be a lot cleaner than standard
| C++ (or even C++ with Boost). I highly value consistency in a
| codebase, and Qt really makes that possible.
| bluGill wrote:
| Modern c++ does some things better than qt, others it is
| still worse. Just unique ptr is better than qt's parent-child
| object model (memory management only, parent child is useful
| for other things)
| thegrim33 wrote:
| It kind of drives me crazy trying to have a modern C++
| codebase which uses smart pointers everywhere, yet every
| touch point with Qt involves manually allocating memory and
| passing the pointers into some magical Qt blackbox which
| hopefully frees the memory when appropriate.
| bluGill wrote:
| Most of the time you don't need to do that as qt will
| work with smart pointers so long as you have create and
| destroy in the same order. But i agree is annoying. I
| brought this up with qt last time they visited (my
| company is one of their larger customers)
| rurban wrote:
| I once tried to get a IAR C++ embedded codebase to compile with
| g++ and it's stdlib on a very small chip. It eventually compiled
| but never worked. I'll have to rewrite it in C instead.
|
| There were many hacks, like filling the stack with sentinels to
| detect it at run-time. The linker script was horrible. Rewrote
| everything from scratch. The resulting code was many KB too large
| for the available space, it would have needed to slim down the
| stdlib. Even with the much better optimizations and LTO it was
| still too big.
|
| Nice for that time, but essentially unusable. The company needed
| 10 years for that code, my plan is to rewrite it in 2 weeks.
| ndiddy wrote:
| If IAR was able to make the existing C++ codebase fit in the
| chip's flash and GCC wasn't, that seems like a win for IAR. If
| you're selling products in volume, the cost of the IAR license
| is dwarfed by the amount of money you save by using a part with
| less flash.
| delfinom wrote:
| Depends on what volume means. I would argue most people
| aren't working on projects in the million of units volume
| where that cost savings isn't worth it.
| RealityVoid wrote:
| Lots of people are. It's usually small systems. Think PIC
| or RL78, 16 bit MCU's maybe some Cortex M. But they're
| everywhere and sold in the millions and you never even
| think about it unless something goes wrong and then you
| cuss at them.
| estimator7292 wrote:
| Honestly I'd be willing to blame GCC for that one. IME its
| output is _atrocious_ for embedded stuff. Few optimizations for
| the chips I use and absolute nonsense assembly trying to
| emulate CPU instructions GCC doesn 't know exist in hardware.
| Binaries are regularly 3x larger than they should be. It's so
| awful I had to end up writing my tight loops in straight
| assembly because GCC couldn't handle incrementing a damn
| pointer in a sane way.
| rcxdude wrote:
| I haven't found that it's that bad but I have seen that IAR
| is a bit better at optimising for code side, to the tune of
| ~10-20% or so.
| RealityVoid wrote:
| Methinks you were targeting some wierd-ish ISA that had
| near/far addressing and a larger memory space than the but core
| could address directly. Those have all sorts of quirks needed
| to make code work properly, quirks GCC probably never bothered
| to implement or optimize for. It's also probably why it never
| worked. Oh... you have a pointer? That's nice, but this is a
| near pointer and the data is outside of how much it can
| express.
| rurban wrote:
| No, that's a company firmware we bought with sourcecode to be
| able to extend it.
|
| I'm pretty sure it's the stdlib, IO probably, which is only
| needed for debugging anyway.
| RealityVoid wrote:
| Their compiler(s) are... fine, I guess. Maybe it makes fast code
| (didn't do a whole lot of profiling), but compiling with it is
| slow as hell.
|
| Their IDE is horrendous.
| 2c0m wrote:
| Used to work at a big IAR shop. Compiler is whatever, it works.
| Hated supporting that IDE. We supported way too many versions.
| HeyLaughingBoy wrote:
| There's a VSCode IAR plugin that makes life a bit less painful.
| oblio wrote:
| Somewhat related but not quite:
|
| Why is Qt support so poor on mobile (and especially PyQT)?
| They're basically just 2 OSes at this point, they've been around
| for 15+ years. They do change, but they're also quite backwards
| compatible.
|
| I would imagine that Qt would want to target such a huge market.
| zxspectrum1982 wrote:
| IAR C was my first embedded compiler, a long time ago, and it
| just worked flawlessly.
___________________________________________________________________
(page generated 2025-10-20 23:01 UTC)