barbara wrote: ↑Mon Jun 29 2020 11:05 pm
CandL wrote: ↑Mon Jun 29 2020 10:49 am
Of course this is all up for discussion, but it may *start* to address seasoned-geek's concerns.
But to be fair seasoned-geek, this is asking a lot of Copperspice ... based on the "promise" of a cash stream. I believe the Copperspice team to have the integrity not to promise what they have no intention of delivering. I also know large companies got to be large by charging a lot and paying very little.
Getting Copperspice to commit to what you are asking for without substantial financial backing is just ludicrous. If they were to commit I would personally be quite suspicious. Maybe if KDAB made these statements it would have credibility... they, KDAB have been around longer and are larger... nothing against the Copperspice folks.
We will in due time offer an LTS version of CopperSpice, but I am not sure if this is what seasoned-geek is looking for. With a paid subscription policy we can keep that version "alive" forever. Ok, but what happens when someone finds a bug in that LTS version? Not all bug fixes can be back ported. So how do we keep the old API perfectly in place and yet offer new fixes?
Sorry for delayed response. Internet has been down since a week ago Friday. Still down now. Had to run out and buy one of those Elipses (sp?) things from Verizon as infrastructure may not be fixed until Thursday at the earliest. On the plus side, the lack of distractions has let me get quite a bit of coding done on Diamond. I hope to do lots more today as obligations on the family farm are now behind me.
There are actually many ways to do it. This "bug fixes" concept is almost always a Red Herring. The medical device world in particular cannot use any of the networking API. External communications has to be optically isolated from the "device" itself. A consumer may only see a single unit, but the communications portion is its own world. Nothing can come in through it and reach into the device itself. It's part of the government oversight mentioned in another post.
The medical device world also has external QA working from The Four Holy Documents when creating test plans. They have tested every possible randomly generated input combination. Any bugs in the implementation have already been designed around if not outright fixed. This was true of the Qt 4.8 medical device I worked on that is still isolated on 4.8. There are many issues in 4.8. While annoying, they are of no real concern. What is a concern is compiling that code under Qt 6, 7, 8, having it still compile and pass the original QA testing with exactly the same results. A class method which has disappeared or has non-optional new parameters is a major problem.
What we have is a difference of cultures. Those from the home hobby x86 world want continuously changing source code. Those from the big systems and the long life products world want stability. More importantly they want to be able to hire new developers who learned the latest version of the API and have them still be functional with the subset that exists in the much older version. This is currently not possible with Qt. You can't take a current Qt 5.x developer and drop them into Qt3 with any real hope of a positive outcome.
Industrial controls is a different, yet similar market. The vast majority of these devices are on air-gapped networks. There are not external intruders to worry about, only human error and industrial noise. Once they have a functioning network protocol established, it doesn't matter if there are obscure vulnerabilities or other uglies in the underlying library. The mill still produces paper. Someone has to physically get into the mill and find an open network port to even try exploiting any such vulnerabilities.
Warehouse management does use wifi. It is also on local loops. The wifi is for the barcode scanners. They also have built in storage because the signal doesn't reach the entire warehouse.
Might I ask, just how many bug fixes has Qt3 on OS/2 gotten in the past 10 years?
The problem isn't the bug fixes, it's the labor force and the massive expense a single API change imposes in a world where human/animal life is at risk. What we have now is a lot of companies maintaining their own forks of Qt because the OpenSource community chose to chase shiny objects. That choice was easy. The "free labor" was only interested in playing with a new shiny object, so that is what they contributed. Much of that free labor has either not worked in the real world for any length of time.
barbara wrote: ↑Mon Jun 29 2020 11:05 pm
For what we can tell he does not want us to modify anything, ever, in the API once it has been added. This sounds decent on paper but not practical in reality. At times it does make sense to jump from version X to version Y and make good changes. Our documentation is updated all the time and we have migration docs to help users move forward. That is the right thing to do and what we would want from a project.
CopperSpice has evolved massively over the past few years and there is so much we want to change and make better. We are very actively working on ideas and trying to figure out how to offer a solution for some API stability. There is no no one size fits all but something I can promise is that our team will listen and be a part of the discussion.
Barbara
The other part has only worked in the short life consumer market. Thiago (sp?) is a great example. I respect him a lot. He is very active in the Qt world and works at Intel. He believes two years is as long as anything should be supported because that is what Apple does. He blissfully ignores the fact I can compile C/C++ targeting a 386 and have that binary run on this i7-gen7 I'm typing on right now. Despite Intel's killing off of chips every few years, the 386 opcodes are still supported. They may not be the most efficient, but they have not been completely abandoned. True, there are certain things that will not work, like a call to get available system memory because the API cannot return the byte count for the 24Gig of RAM currently in the box, but if I designed around that to start with, my code still compiles and runs.
One thing that has always stunned me about certain OpenSource projects, Qt in particular, is that sweeping changes need to be rolled in rather than forked. CopperSpice is a fork of Qt based on 4.8 or some 4.x version yet it appears to be clinging to the same qt philosophy of rolling everything in. Once it has achieved some milestone for "better" it could easily fork say CoQ10, the flavor for medical devices and industrial controls. Said version would keep a stable API for 20+ years only adding support under the hood for newer touchscreen and graphics drivers. It would probably also drop all networking because the medical device world is already mandating that be optically isolated. (You could call it MedSpice or anything you wanted. I just took CoQ10 this morning so it was on my mind.) This would need the serial port support. Most devices use a serial connection to the I/O unit. Some do use PPP over that. Not all, but some. One would have to canvas targeted companies to determine the subset. You want to poll Medtronics, Baxter, https://www.hillrom.com/ and a token few other current Qt customers facing ever increasing license and royalty fees. Find out the exact subset of Qt that they would want to see in CoQ10/MedSpice. It won't be anywhere near what is currently in Qt.
An add-on fork could be IndustrialSpice. This would use the CoQ10 spice as its base adding in some of the networking that is not needed in MedSpice/CoQ10. It would most likely add CanBus and some other industrial specific things.
What is needed is a tree.
MedSpice/CoQ10 - the core of the core with a stable API for at least 30 years. Things can be added, but nothing abandoned.
IndustrialSpice - add-ons for MedSpice suitable for industrial control community. This can change more. Not as heavily regulated. Can probably get by with 5-10 years of API stability in this fork.
WebSpice - add-ons for MedSpice that are focused completely on Web front/back-end development. Will probably include much of the networking from IndustrialSpice. This can change willy-nilly
Dave's Suicide Sauce - Since they changed the name you can probably use it
https://store.davesgourmet.com/ProductDetails.asp?ProductCode=DAIN
This is where the bright shiny objects get chased. It will burn you in an instant. Shiny new classes for various things get added here. After 10-30 years a token few of them might find their way into one of the other packages.
I would humbly (though many might say I'm not humble enough) submit the project focus on what is required to achieve the MedSpice/CoQ10 fork. Right now and for the foreseeable future, that is where the money is. IndustrialSpice type fork was hot for a bit with the automotive world, but much of that has been moving to JavaScript to get cheaper developers. At some point it will settle down to just the long term industrial controls. Major flaws were introduced into Qt when it attempted to chase the automotive market. Qt went off the rails when it added QML attempting to chase the phone market and retain a toe hold in the automotive world that was migrating towards JavaScript.
Admittedly, CopperSpice is a long way from achieving the MedSpice/CoQ10 fork. I'm saying that given the comments I've read here about changes developers want to make to the API and the fact the project does not yet have its own CsCreator IDE.
Ah, that reminds me. One of the biggest money makers for Qt company is the combination of Boot-to-Qt (however they spell it now) and the fact they will, for a significant fee, set up a yocto cross compile build environment for you targeting your current processor/device. I've worked at many companies that paid for that. It allowed them to set up developer desktops quickly and enabled remote debugging. Very few people, including myself, are any good at that task. It is one thing companies eagerly pay for, especially if it doesn't come with commercial licensing and never ending royalties. I do not know for certain, but I have heard some companies pay $20-$80K just for that. Just so they can have something to install in Ubuntu (they all seem to use Ubuntu) and get developers started.
... By the way the last Vax I saw was on a farmers flat bed going to the scrap yard, and our HP9000 HP-UX machines we can't even find used parts on E-Bay (lost the source)