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

[Roland Hughes]

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