[Interest] The willy-nilly deletion of convenience, methods

Tue Mar 23 18:58:07 CET 2021

Shut up you fucking cunts
Dennis Bean
Director
Dennis B Building Contractors Ltd62 Athol SquareLondonE14 0NPTel: 0207 538 1437Fax: 0207 538 4957
dbeancoltd at aol.com

    On Tuesday, March 23, 2021, 04:48:10 PM GMT, Jason H <jhihn at gmx.com> wrote:  

 > 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.

QML is a binding environment, and a handy one at that. It is not just GUI.
I have Websocket servers that interact with non-visual classes with bindings
provided in QML. It's great. Yeah the QtQuick controls 1 were terrible and 2
are pretty bad, but I think things are getting better.

> > 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.

As a multiple-time commercial customer the bug/issue support has been great,
but the meta-narrative (previously Mobile in nature) was very lacking.
Lars/Digia is going to to do what they want, and Open Governance is a joke.

> 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.

Not just a year, try 3. I usually was able to come up with a work-around
so that I was not blocked for 3 years though. The more critical stuff did
get fixed timely.

> > 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 reparable. Such things can be fixed with a stroke of a pen, like
when Nokia LGPLd it. It's just that Digia/QtCo/Weyland-Yutani corp is
running Qt as an open source project into the ground. They (IMO) don't see
opensource as a way cultivate an ecosystem that pumps the sales pipeline.
And they won't question it until the big customers dry up, look to the
community and realize they turned everyone off from it and they already
went to HTML5, where HTML/JS people are cheap and plentiful. Meanwhile
their C++ tooklit gets them a steady decline:
https://www.tiobe.com/tiobe-index/cplusplus/ that peaked 20 years ago.

I liked QML as a way to get those JS devs into Qt. They are familiar
with JS bindings, be them React, Angular, Knockout, Vue, etc.
PySide seems to be well-informed because that's the only language
(Python) that is steadily increasing.

They do seem to know HTML5 is a threat (they have whitepapers on it)
but have yet to really take it on meaningfully.

> >> 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 really hate fragmentation. I'd rather convince Digia that their
licensing decisions are ultimately hurting the community and sales.

> 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.

As someone who has done it, it's not myth*
*for parts that Qt supports, but not nearly enough is supported on mobile.

> 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.

Not exactly. To use it comply with the license and you would have to
provide configuration management and source to generate the same binary.
However it would be a huge risk on their part to use products with
an unmatching file hash signature without also having the formal
validation/unit/system tests to qualify it as functioning
properly. The ability for the end user to compile the software isn't so
much so they can modify it (it definitely enables that though) but more to
verify that the code they think it is running is actually what it is running.

> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
_______________________________________________
Interest mailing list
Interest at qt-project.org
https://lists.qt-project.org/listinfo/interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210323/21fb6a07/attachment.html>