On 3/23/2021 8:57 AM, Matthew Woehlke wrote:
On 23/03/2021 06.59, Roland Hughes wrote:
30 years is __nothing__ for production systems. It is ordinary for a
well developed system to run 10+ years without any modifications.
On that note, how many people are aware there's a computer that has
been running non-stop for almost 45 years? :-D
Oooooh. Another DEC-ky Techie. Shouldn't say that too loud. One minor
it, if that is the Irish Railway system. It's actually a cluster. Once
every so many years they take one of the nodes down for hardware and
other maintenance but the cluster operates the rail system 24x7x365 and
change. If memory serves, up for 10 years before the first node got
maintenance.
You kids and your uptime measured in hours...
+12
The Qt OpenSource model simply does not work. It cannot really be
made to work.
You can't pursue licensing from lone wolfs and shoestring startups
and expect well run legitimate companies to have any respect for you.
It's not going to happen.
The only thing that is going to work for the big ticket companies is
a 100% commercial product that happens to release its older stuff as
OpenSource and sometimes accepts software developed by others for
free. Nobody wants to hear that, but that is the only model that
works. With that model comes fixing all bugs inside 90 days. None of
this hoping someone in the OpenSource community fixes it for free.
Here, however, I'm going to have to disagree. I fail to see why the
open source version can't be the latest and greatest, so long as the
paid support *does* actually provide support, as you're saying.
(Dislaimer: This is my employer's business model. It seems to be
working quite well for us.)
*If* one is going to have a commercial license with full support, that
_has_ to be the tip of the tip. You have to actually get something for
the additional fee rather than Digia executives getting a new 'Cedes and
you the shaft which kind of feels like the business model now.
Now, the "commercial license" simply could be the Boot2Qt stuff with all
of Qt being 100% OpenSource. This would provide additional incentive to
rip QML out so it isn't bastardizing the rest of the product and QML
could then be its own commercial thing, just for phones. I have lost
track of other little things that Digia might have spun up for
additional cash.
What I think it broken is the commercial licensing model. Either pay
for support (and *get* support), or don't pay, and get whatever the
community gives you.
Okay, that's the point of disagreement. Kind of what I suspected.
The problem with that is one has to __START__ with all of the known bugs
fixed, not just deleted. Ripping QML out into its own universe will go a
long way to emptying the bug database *provided QML and JavaScript are
ripped out root and stem not just deleted leaving support in the class
and header code.*
I'm not actually convinced that paying Qt customers aren't getting the
support they paid for; that information is generally not going to be
publicly available.
Pull down a couple years worth of the interest archives and unzip them
into a directory. Let grep search for bug or customer.
https://lists.qt-project.org/pipermail/interest/
The complete information will never be publicly available but many
paying customers have come here to bitch about bugs open for over a year.
Hey! "That guy again" needs to chime in here. Unless his company has
also abandoned Qt as sooooo many have.
What *is* broken is the alimony licensing model and all the
fear-mongering around the licensing terms.
+12
*Proper* commercial support for open source products lets you try
before you buy with no punishment afterward, no penalties if you want
to drop support later, or drop it and pick it up again. You pay, you
get support, *period*.
+24
For that matter, it seems like Qt's commercial model is working just
fine *for them*, at least at the moment. Ironically, the arguments you
are making probably are *why* it's working. The problem is that
they're busy killing the community and doing severe, possibly
irreparable damage to Qt's reputation.
It is irreparable at this point. Whatever Qt becomes, it cannot have any
current or former Digia people involved. Deep pocket customers won't
come back. The Digia crew is 0 for 2.
It's highly doubtful that any company could pull in the staff to
maintain all of the markets and eliminate all of the bugs, but that
would have to be the starting point for such a venture.
Right, which is why we *need* a community, or a consortium, or
something of that nature. We need everyone that cares about what Qt
*could* be, without Digia's efforts to break it, to pool their resources.
I believe that if we could pull that off, Qt can still have a bright
future.
We can't.
The thing has to fork and split.
I like Jason. He's a nice guy, but he wants to use Qt on phones and to
have QML. He's not alone. That's how this got so busted in the first
place. That write-once-run-anywhere myth surrounding Java back in the day.
See, the "what it can be" definition changes depending on where you stand.
I just need desktop (not even fancy 4K desktop) and touch screen support
for embedded systems. The embedded systems will always be a Yocto Linux.
Nobody is going to pay to put Windows on it and end up with less. If
they really need their UI run by an RTOS they probably already own
WindRiver and will be using Zinc. Perhaps they have some other
commercial RTOS with its own UI? They certainly aren't going to wedge Qt
into an OS that prohibits dynamic memory allocation as most RTOS systems do.
While we are pie-in-the-skying
WebEngine needs to be trashed. Every piece of Qt that cannot be
statically linked into a single executable needs to be trashed and
replaced by things that can be statically linked without requiring
external CODECs and plugins that may or may not be found.
The OpenSource community was blind, deaf, and dumb when they railed
against Tivo locking down their devices and came up with all of these
poisoned pills in OpenSource licenses mandating users be able to modify
the software.
In medical devices, that's illegal.
In industrial control systems where SAFETY is mandated, that's illegal.
Change either of those and the regulators find out, you go to jail. A
person doesn't even have to get hurt or killed.
The browser piece is the real issue. You can static link most everything
until the client wants video help on the device. The dynamic linking is
why so many people are unable to package DEB and RPM files. They can
never keep the dependency list current.
A commitment to Qt being 100% statically linkable really is needed by
the embedded systems world.
Some of us still have some 32-bit targets we have to deal with as well.
Notably the older (and possibly current) Raspberry Pi. Many smaller
embedded customers are going to split-systems. Keeping their old single
board computer running the stuff in he machine and serial comm to a
Raspberry Pi running touch screen GUI.
Jason isn't wrong. You need a **lot** better wiki for Raspberry Pi cross
compile. The current instructions stay in the center of the center lane
and if you need anything else, like database support, fugedaboudit.
Because they don't have bugs that have been rotting for over a
decade, CopperSpice went to a support and consulting contract only
model. It seems to be working.
I haven't much looked into CS, but that sounds plausible. Again,
that's basically how my own employer works. It's a perfectly
functional business model for organizations with the commitment and
ethos to pull it off.
I'm also not sure how much I *want* to look into CS. The CoW stuff
scares me, and I think they've gone too far in throwing out the good
parts of Qt with the bad. There are quite a few changes in Qt5 that
are good (the new OpenGL framework for one, not to mention all the
C++11 related changes). Ditching MOC is IMO questionable, especially
when the overhead of MOC is so negligible these days.
They are forcing C++17. They definitely tossed out CoW. I'm not exactly
certain that was the reason behind the nearly 16 minutes to build that
QList. If I had been running on a Raspberry Pi instead of a gen-6 i7 I
would immediately jump to that conclusion. Dynamic memory duth sucketh
on the Pi.
It wasn't the overhead of MOC. It was the stale files that keep messing
up builds.
No, I don't for a moment think QML is on that list :-).
+1000
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
