Re: [Interest] Roland Qml
And the erudite strikes again! > On 15 Jul 2020, at 22:49, Roland Hughes wrote: > > > On 7/15/20 1:36 PM, Jonathan Purol wrote: >>> As another has pointed out, this wasn't a jump, just a perfunctory >>> functional safety check. One of the things one does when working in an >>> FDA regulated or functional safety environment. You open the binary in a >>> standard text editor making certain nothing is obviously exposed. It's a >>> practice which evolved/occurs because at some point in history compiled >>> languages used to put some portions of the program in the binary in >>> "free text." With nothing more than a decent text editor in overstrike >>> mode someone with no real skills could change the "free text" and thus >>> put a life at risk. Traditionally this happened with hard coded strings. >>> While many could/would view that as "pranking" because someone could >>> tweak the help text in a funny way, it's life threatening if one has >>> maximum dose strings or tables and someone changes "Milligram" to >>> "Gram " or some such unit change. Yes, if it exists in text it is >>> usually an abbreviation, but the reality is the same. When the maximum >>> safe does is 9 Milligrams but now all of the validation logic believes >>> it to be 9 Grams, a fatality can, and probably will, occur. >> >> I agree with the point that QML and JavaScript aren't the right choice >> for something as critical as medical decides. I don't believe I brought >> that across sufficiently. >> Of course errors can happen everywhere, but the choice of the tool is >> just as important as the skill with said tool.As I mentioned in my >> previous email: I despise JavaScript and consider QML to be far too >> infantile to be used as a proper library for what I work in -- desktop >> application development. > > As you travel about the IT world you will learn management at big companies, > especially if it went to an MBA diploma mill, lives by one motto. > > "Cheaper is always better." > > Right now the cheapest pool of labor is JavaScript. At least that is what I > see in America and all of the off-shore companies that companies are talking > to about such projects. Just ghost around UpWork and sites of that ilk where > freelancers pay money to bid on contracts. You will see huge projects that > are obviously thousands of man hours being bid for $500 or less. I've seen > embedded systems projects on those sites from time to time and they too are > being bid ludicrously low. > > The problem is, a tool that is _only_ appropriate for phones is in the same > toolbox being sold to/used by embedded systems developers. When management is > looking to cut development costs they are going to hire developers who are > "priced right" and they are going to use QML and JavaScript because > JavaScript is what they know. > > What has stunned me is the number of people who private emailed completely > shocked that when you open the binary there is the JavaScript. I ran the spot > check because it has been an industry thing for eons; at least I thought it > was industry wide. Been warned about thinking before. > > QML, if it exists at all, should be optically isolated in a phone only > package. They might as well use JavaScript on there because Facebook is going > to shoot the phone out from under them anyway. > > https://www.msn.com/en-gb/finance/technology/facebooks-software-kit-to-blame-for-popular-apps-crashing/ar-BB16AW5Y > > Phones simply aren't secure and there are too many people hurling apps on > them to ever make a phone secure. Well, a flip or stick phone that cannot > install apps is secure. All you can do is make and receive phone calls and > keep a limited number of entries for quick dialing. The phone that lets you > have a life. > >>> I have no doubt you are correct about their being many many >>> programmers better than I. >> It wasn't my intention to imply anything about your skills here, quite >> the opposite: I have barely any knowledge about you as a person, and >> whilst your points are very clear and your knowledge is extensive in >> certain areas, I don't know just how far your skills reach, so I didn't >> want to draw any comparisons there. Pardon me if I didn't convey that >> correctly. > > I took no offense. Thick hide is mandatory in IT. Your statements about that > weren't even close to offensive. Live by the advice gun slingers used to give. > > No matter how fast you think you are; on any given day there is someone just > fast enough. > >> >> To me, personally, programming patterns, languages, mechanisms, >> principles, etc. are just a huge toolbox. You shouldn't use a bare piece >> of metal to fix an electric leak, just as you shouldn't use JavaScript >> to write core-essential software that is literally responsible to power >> life sustaining machines. > > It shouldn't be in the same toolbox so it can never be used. > > The "tool" that I and many others expected QML to be, given
Re: [Interest] Roland Qml
On 7/15/20 1:36 PM, Jonathan Purol wrote: As another has pointed out, this wasn't a jump, just a perfunctory functional safety check. One of the things one does when working in an FDA regulated or functional safety environment. You open the binary in a standard text editor making certain nothing is obviously exposed. It's a practice which evolved/occurs because at some point in history compiled languages used to put some portions of the program in the binary in "free text." With nothing more than a decent text editor in overstrike mode someone with no real skills could change the "free text" and thus put a life at risk. Traditionally this happened with hard coded strings. While many could/would view that as "pranking" because someone could tweak the help text in a funny way, it's life threatening if one has maximum dose strings or tables and someone changes "Milligram" to "Gram " or some such unit change. Yes, if it exists in text it is usually an abbreviation, but the reality is the same. When the maximum safe does is 9 Milligrams but now all of the validation logic believes it to be 9 Grams, a fatality can, and probably will, occur. I agree with the point that QML and JavaScript aren't the right choice for something as critical as medical decides. I don't believe I brought that across sufficiently. Of course errors can happen everywhere, but the choice of the tool is just as important as the skill with said tool.As I mentioned in my previous email: I despise JavaScript and consider QML to be far too infantile to be used as a proper library for what I work in -- desktop application development. As you travel about the IT world you will learn management at big companies, especially if it went to an MBA diploma mill, lives by one motto. "Cheaper is always better." Right now the cheapest pool of labor is JavaScript. At least that is what I see in America and all of the off-shore companies that companies are talking to about such projects. Just ghost around UpWork and sites of that ilk where freelancers pay money to bid on contracts. You will see huge projects that are obviously thousands of man hours being bid for $500 or less. I've seen embedded systems projects on those sites from time to time and they too are being bid ludicrously low. The problem is, a tool that is _only_ appropriate for phones is in the same toolbox being sold to/used by embedded systems developers. When management is looking to cut development costs they are going to hire developers who are "priced right" and they are going to use QML and JavaScript because JavaScript is what they know. What has stunned me is the number of people who private emailed completely shocked that when you open the binary there is the JavaScript. I ran the spot check because it has been an industry thing for eons; at least I thought it was industry wide. Been warned about thinking before. QML, if it exists at all, should be optically isolated in a phone only package. They might as well use JavaScript on there because Facebook is going to shoot the phone out from under them anyway. https://www.msn.com/en-gb/finance/technology/facebooks-software-kit-to-blame-for-popular-apps-crashing/ar-BB16AW5Y Phones simply aren't secure and there are too many people hurling apps on them to ever make a phone secure. Well, a flip or stick phone that cannot install apps is secure. All you can do is make and receive phone calls and keep a limited number of entries for quick dialing. The phone that lets you have a life. I have no doubt you are correct about their being many many programmers better than I. It wasn't my intention to imply anything about your skills here, quite the opposite: I have barely any knowledge about you as a person, and whilst your points are very clear and your knowledge is extensive in certain areas, I don't know just how far your skills reach, so I didn't want to draw any comparisons there. Pardon me if I didn't convey that correctly. I took no offense. Thick hide is mandatory in IT. Your statements about that weren't even close to offensive. Live by the advice gun slingers used to give. No matter how fast you think you are; on any given day there is someone just fast enough. To me, personally, programming patterns, languages, mechanisms, principles, etc. are just a huge toolbox. You shouldn't use a bare piece of metal to fix an electric leak, just as you shouldn't use JavaScript to write core-essential software that is literally responsible to power life sustaining machines. It shouldn't be in the same toolbox so it can never be used. The "tool" that I and many others expected QML to be, given what we were told, was a "free text" thing that pre-compiled to Widgets before the actual compile. They were just transitioning away from the XML file that is a .UI. You couldn't have programming logic in it. You could establish some connections just like you can in the XML, but that was it.
Re: [Interest] Roland Qml
On 7/15/20 5:00 AM, Cristián Maureira-Fredes wrote: I'm pretty sure you understand how your message breaks our Code of Conduct, and making those generalized bias comments about developers using other programming languages from different countries is not admitted in this mailing list. I'm certain The Qt project has many people that come from different backgrounds, and not because they didn't have "a formal CS education" means that they will produce bad code or harm any project You can find JavaScript people for absolutely no money. Simply look at sites like UpWork and see what they bid to do projects. Not having a formal education is actually a yardstick for measuring potential quality of work. That is why you see "B.S. in Computer Science or related technology" on s many job postings. To do really good work, or at least avoid tragedy, you need a solid grounding in the fundamentals. Reading one language specific book and hanging out a shingle then working on AGILE projects without The Four Holy Documents written up front really does mean they are going to produce bad solutions if not "bad code" and harm the project. When a human goes from infancy to adulthood, along the way they are taught not to play with matches, the meaning of hot, especially around a stove and other basic fundamentals of navigating life. Without being taught these fundamentals we get burned badly and sometimes perish. A formal CS education provides an infant developer that transitional knowledge to "young adulthood." It teaches them many fundamentals to avoid getting burned and having their career perish. When working with actual Software Engineering one can get by with only knowing only syntax and having the ability to read. Software Engineering requires The Four Holy Documents be created up front. All significant design decisions are made for you, "simply" code and test them. (Yes, it is not always simple or fast but you don't have to do a lot of deep thought.) Here's a real life example for you which should paint the picture perfectly. This happened with an all on-shore team too. All either self-taught or having gone to non-rigorous schools, also called diploma mills in the states. The product the company was making was a livestock barn monitoring and control system. All fans, curtains, misters, feed augers, waterers, lights, heaters, etc. 24/7 monitoring and control without being there. The team tried to do much/most/far too much of said system in JavaScript and QML. At the core of this system were many sensors for temperature, light, feed and water levels, even working on a methane sensor I believe. Said product got installed in a barn that was soon filled with freshly weened young livestock. Seemed to work well for about two days then in the middle of the night it, via the watchdog, when into a perpetual reboot cycle, exercising the equipment for roughly seven seconds before entering another reboot cycle. Roughly 14 hours and an unknown (to me) number of dead animals, the storage SD card was replaced "because it must have went bad." The system believed it was write protected. This happened again a few days later; and again. I joined the project roughly at the time this started. Remember the sensors? The self-taught team stored their readings in a directory tree by sensor type, one JSON file for each sensor. Many of the sensors had 5 readings per second coming back. Each reading required the JSON file to be read, data appended, and file rewritten. It took roughly two days for the file to get large enough that it could not complete being written to "disk" before it had to be read for data storage again. This caused a series of error flags in the disk device driver which well and truly believed it had a disk in trouble at the other end of the connection and put it into write-protect mode to save it from further harm. Failed writes in turn triggered the watchdog which attempted to correct things via reboot. Neither the disk driver or the watchdog were at fault. They did exactly the jobs they were designed to do. They simply couldn't fix a design error brought about by lack of both formal training and The Four Holy Documents. Had someone with formal training been involved at the beginning JSON would have never been chosen. No file storage method with an ever increasing write time would have ever been chosen. Even if the I/O could have happened fast enough, the SD card was way larger than physical RAM and there were multiple sensors with that reading speed. The files would have gotten too large to fit into RAM, especially multiples of them being processed by multiple threads. Formally trained individuals would have reached instinctively for a relational database, an indexed file, or even a sequential file, where the application could always just write the new record and go. Peer review never brought this up. By the time I was brought in there were
Re: [Interest] Roland Qml
On 7/15/20 5:00 AM, interest-requ...@qt-project.org wrote: I haven't followed the entirety of this thread (as it's split into a few different threads for some reason). That reason would probably be because I get this in digest form and don't always remember to change the subject line when responding in Thunderbird. My apologies there. I can understand some disdain against the "dumbing-down" of programming nowadays and I'm personally not fond of QML (in it's current state) either. But you suddenly jump from "JavaScript is insecure" to "medical devices running JavaScript will kill patients". Making mistakes can happen in every language, and I'm sure quite a few people have died because of technical issues in c++ code as well. JavaScript might be more error prone -- of course -- but I wouldn't really blame QML for that. If you use JavaScript in QML for anything other than visual logic, without any validation, unit tests, fuzzing, QA, etc. then you're a bad coder. As another has pointed out, this wasn't a jump, just a perfunctory functional safety check. One of the things one does when working in an FDA regulated or functional safety environment. You open the binary in a standard text editor making certain nothing is obviously exposed. It's a practice which evolved/occurs because at some point in history compiled languages used to put some portions of the program in the binary in "free text." With nothing more than a decent text editor in overstrike mode someone with no real skills could change the "free text" and thus put a life at risk. Traditionally this happened with hard coded strings. While many could/would view that as "pranking" because someone could tweak the help text in a funny way, it's life threatening if one has maximum dose strings or tables and someone changes "Milligram" to "Gram " or some such unit change. Yes, if it exists in text it is usually an abbreviation, but the reality is the same. When the maximum safe does is 9 Milligrams but now all of the validation logic believes it to be 9 Grams, a fatality can, and probably will, occur. The team attempted to use JavaScript for everything because that is what they knew. We weren't assigned developers comfortable with C++. By and large this "could" have been okay with sufficient testing as you state. It certainly wouldn't be efficient on a tiny battery powered device that had to run everything from one battery, but it "could" have been okay. When I opened the binary, there was the JavaScript code. In the binary that would be installed. You could easily change it in overstrike mode without changing the size of the binary. This is insecure. It's also one of the biggest fears when it comes to functional safety. Under most operating systems you can change a file timestamp back to what it was, at least that has been my experience. Most embedded systems don't add safety code to image loaders that verify a hidden checksum before loading and executing a binary. Even when they do many keep all of the checksums in a single directory or file that can also be changed. Why this is of such concern is that many people can die long before this is found. There is lots of regulatory testing on file to prove the device cannot have failed in the suspected manner. If someone manages to park said new binary at a field service site, it can distribute wide as part of routine maintenance. Yes, there is lots of security that is supposed to prevent such things but the operative word is "supposed". Security can be breached with enough time and intent. You are supposed to not make it easy for them to hurt you once they are in. Yes, someone "could" be good with a disassembler as in this conversation. https://stackoverflow.com/questions/5125896/how-to-disassemble-a-binary-executable-in-linux-to-get-the-assembly-code but now you are at a level that is above easy. Compared to tweaking multi-threaded C++ program that has been disassembled tweaking JavaScript is easy. Tweaking the former requires someone with quite a bit of skill and/or training who practiced a lot. Change the distance of a single branch and everything can crash, or at least it could in the x86 days which had near and far branches. http://spot.pcc.edu/~wlara/asmx86/asmx86_manual_6.pdf I have no doubt you are correct about their being many many programmers better than I. My golden era was from about 22 to just shy of 35. There wasn't a system of any size (and I worked on some really big ones) that I couldn't put in my head, design, and deliver. I subscribed to and religiously read Rex Jaeschke's blue standards booklet/magazine http://rexjaeschke.com/ as well as the "Programmers Journal," "The C Gazzette," and "The C/C++ User's Journal." I lived, breathed, and thought in code. BASIC, FORTRAN, COBOL, DIBOL, C/C++, it didn't matter, I did it all. I even wrote far too much Cognos PowerHouse. Those days are in the rear view mirror. For the
Re: [Interest] Roland Qml
> As another has pointed out, this wasn't a jump, just a perfunctory > functional safety check. One of the things one does when working in an > FDA regulated or functional safety environment. You open the binary in a > standard text editor making certain nothing is obviously exposed. It's a > practice which evolved/occurs because at some point in history compiled > languages used to put some portions of the program in the binary in > "free text." With nothing more than a decent text editor in overstrike > mode someone with no real skills could change the "free text" and thus > put a life at risk. Traditionally this happened with hard coded strings. > While many could/would view that as "pranking" because someone could > tweak the help text in a funny way, it's life threatening if one has > maximum dose strings or tables and someone changes "Milligram" to > "Gram " or some such unit change. Yes, if it exists in text it is > usually an abbreviation, but the reality is the same. When the maximum > safe does is 9 Milligrams but now all of the validation logic believes > it to be 9 Grams, a fatality can, and probably will, occur. I agree with the point that QML and JavaScript aren't the right choice for something as critical as medical decides. I don't believe I brought that across sufficiently. Of course errors can happen everywhere, but the choice of the tool is just as important as the skill with said tool.As I mentioned in my previous email: I despise JavaScript and consider QML to be far too infantile to be used as a proper library for what I work in -- desktop application development. > I have no doubt you are correct about their being many many > programmers better than I. It wasn't my intention to imply anything about your skills here, quite the opposite: I have barely any knowledge about you as a person, and whilst your points are very clear and your knowledge is extensive in certain areas, I don't know just how far your skills reach, so I didn't want to draw any comparisons there. Pardon me if I didn't convey that correctly. To me, personally, programming patterns, languages, mechanisms, principles, etc. are just a huge toolbox. You shouldn't use a bare piece of metal to fix an electric leak, just as you shouldn't use JavaScript to write core-essential software that is literally responsible to power life sustaining machines. I'm merely trying to argue that the aforementioned bare metal rod *still* has its uses, even if it seems completely nonsensical to use in certain situations. Then again, I've been a programmer for less than a tenth of what you've been in the metier for, so my opinion is bound to grow regarding this as well. Right now I work as an indie developer on a passion project of mine and have been for quite some while. We've struggled to find a proper GUI toolkit, as I refuse to touch Chromium or anything in that area even if it would be a lot easier and more profitble. We've gone from JavaFX to Dear ImGui to Qt and are now investigating GTK, simply because Qt just has a lot of things I dislike the more I use it (then again that happens with everything that isn't tailored to you personally when you use it for a while). Among my adventures in trying to find a toolkit better suited to our situation ( 1. One GUI developer 2. Two developers total 3. A funding in the 2 digit numbers each month via donations ) I stumbled across QML. Now as I mentioned before, QML didn't cut it for us. I've encountered three bugs in things that I consider essential and fundamental a GUI program within mere hours of trying it (bugs with textinputs, buttons, and scrollpanes) - unacceptable for a toolkit that's supposed to power an application for a few years. But I did like working with it, and I saw some project that did just what you mentioned, take QML and let it generate QtWidgets code from it (https://www.kdab.com/declarative-widgets/) which would be just about what I would ideally want to have from Qt. My point is, that there is a place for QML in this world, and for the JavaScript within too. Blaming the tool for being used inappropriately instead of the worker or the system that creates the worker's interest in doing shoddy but profitable work is something I personally disagree with. You don't sue knife companies simply because some maniacs use them to commit atrocities either (maybe comparing JavaScript to murder is a bit of a stretch.. just maybe). Btw: Qt6 promises to make JavaScript optional, improve QML performance, and hopefully make it a lot more mature: https://www.qt.io/blog/2019/08/07/technical-vision-qt-6 sincerely, Jonathan Purol ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
> Some of the best programmers I know Knowing how to program is not important. Knowing software engineering methods is important. This is something I have learned the hard way when working in a functional safety company for more than three years. It seems regarding functional safety Roland knows what he is talking about. -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
On 14/07/2020 13:24, Roland Hughes wrote: > They have no formal education with respect to computer science. So you're implying that CS education has anything to do with the ability to write good code? Some of the best programmers I know, far beyond the capabilities of me, perhaps you, and a vast majority of other coders on this planet, have no "formal education [in] computer science". And having taught programming to people at universities, having worked with people who graduated as a CS bachelor or master from universities, I can 100% assure you that education and skill form nothing more than a correlation, and drawing the causation the way you did (amidst some very biased generalisations) is a logical fallacy at best, and harmful misdirection at worst. I haven't followed the entirety of this thread (as it's split into a few different threads for some reason). I can understand some disdain against the "dumbing-down" of programming nowadays and I'm personally not fond of QML (in it's current state) either. But you suddenly jump from "JavaScript is insecure" to "medical devices running JavaScript will kill patients". Making mistakes can happen in every language, and I'm sure quite a few people have died because of technical issues in c++ code as well. JavaScript might be more error prone -- of course -- but I wouldn't really blame QML for that. If you use JavaScript in QML for anything other than visual logic, without any validation, unit tests, fuzzing, QA, etc. then you're a bad coder. You're a bad coder *not* because you're from an off-shore country, *not* because you're using JavaScript, and *not* because you're using QML. You're a bad coder because you have made bad decisions and that happens in every language. I've witnessed enough bad c++ Qt coders in my life to conclude that. sincerely, Jonathan Purol ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
On Tuesday, 14 July 2020 04:35:28 PDT Roland Hughes wrote: > On 7/14/20 5:00 AM, Thiago Macieira wrote: > >> When QML was first pitched back in the Nokia days, it was supposed to be > >> a script that ran through a pre-compiler generating the C++ widget code. > > > > No, it wasn't. > > Yes it was. I got that exact pitch. It was supposed to replace the > problem prone XML based UI files and buggy designer of the day. At that > time the designer was notorious for corrupting UI files forcing one to > open them with a different editor to fix. Having a plain text "language" > that was easy to code and would pre-compile to widget code was a great > selling point. Again, no, it wasn't. I was there. I was the product manager in question. You're confusing the QtDeclarative library and QML with the previous attempt called WidgetsNG (which in turn was a re-iteration of a previous effort called ItemViewNG). WidgetsNG was based on QGraphicsView and its stated intent was to bring proper widgets onto QGraphicsView, with support for animations and transformations. It had an XML language that, like with uic, would compile to C++ at build time. QtDeclarative never had compilation to C++. I don't remember if the file format was XML back then or whether it was already JS based, but by the time the Oslo team was involved in the effort the whole thing was processed at runtime. This was before anything was sent outside of Nokia. > That's what the Nokia developers were talking about in the Chicago area. > They were going to get rid of XML, giving us something that looks much > like QML, having no logic capabilities, just screen layout, that would > be 100% compiled. > > What we got was an interpreted language massive security risk. I don't know who you were talking to. There were no Qt development offices in the Chicago area. Either you were talking to sales people or you were talking to Nokia developers who had nothing to do with Qt. It might have been a customer-meeting trip where product managers (like me back then) would have been present to gather customer input, but not with the actual developers. Trips from Australia are mighty expensive. If that was the case, then nothing was sent in stone. It might even have been WidgetsNG time, which was presented in one session at one Qt Developer Days I think. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
Il 14/07/20 13:35, Roland Hughes ha scritto: When QML was first pitched back in the Nokia days, it was supposed to be a script that ran through a pre-compiler generating the C++ widget code. No, it wasn't. Yes it was. I got that exact pitch. Are you calling the person who has maintained QtCore for the last 10+ years, who has worked directly first under Trolltech and then Nokia, who has been the release manager for a number of Qt releases (just before 4.7, which publicly introduced Qt Declarative) a liar? It was supposed to replace the problem prone XML based UI files and buggy designer of the day. At that time the designer was notorious for corrupting UI files forcing one to open them with a different editor to fix. Having a plain text "language" that was easy to code and would pre-compile to widget code was a great selling point. "Notorious" is hearsay and unwarranted. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
On 7/14/20 1:24 PM, Roland Hughes wrote: On 7/14/20 5:00 AM, interest-requ...@qt-project.org wrote: (snip) When I was at a client site just over a year ago they were using an off-shore team that tried to do 100% of the project in QML and JavaScript because you can find those people for absolutely no money. They have no formal education with respect to computer science. Just read half a "Teach Yourself How to Be Totally Useless or Less in 24 Hours" type book on JavaScript and hung out a shingle. I opened the binary with, I think SublimeText, perhaps KATE, doesn't matter, just a text editor. There it was. All the JavaScript code. I know because in the other frame I was looking at the actual source. The developer sitting beside me didn't believe me. He used Eclipse for everything. Ba-da-bing ba-da-boomb there it was. (snip) Hello Roland, I'm pretty sure you understand how your message breaks our Code of Conduct, and making those generalized bias comments about developers using other programming languages from different countries is not admitted in this mailing list. I'm certain The Qt project has many people that come from different backgrounds, and not because they didn't have "a formal CS education" means that they will produce bad code or harm any project. As someone from an "off-shore" country, I kindly ask you to stop generalizing your own experiences, and maybe find a different platform to share those thoughts. Cheers -- Dr. Cristian Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
On 7/14/20 5:00 AM, Thiago Macieira wrote: When QML was first pitched back in the Nokia days, it was supposed to be a script that ran through a pre-compiler generating the C++ widget code. No, it wasn't. Yes it was. I got that exact pitch. It was supposed to replace the problem prone XML based UI files and buggy designer of the day. At that time the designer was notorious for corrupting UI files forcing one to open them with a different editor to fix. Having a plain text "language" that was easy to code and would pre-compile to widget code was a great selling point. That's what the Nokia developers were talking about in the Chicago area. They were going to get rid of XML, giving us something that looks much like QML, having no logic capabilities, just screen layout, that would be 100% compiled. What we got was an interpreted language massive security risk. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
On 7/14/20 5:00 AM, interest-requ...@qt-project.org wrote: Let us not forget that QML+JavaScript is completely insecure in the OpenSource world. All of that JavaScript gets stuffed into the binary you ship as free text. Anyone with a decent text editor can read/extract your super secret proprietary algorithms. Worse yet, anyone with enough patience can change a binary in the field. Then use some filesystem-level protection mechanism like dm-verity. That will prevent replacing the binaries altogether, whether done by the way of editing some text inside or by recompiling. PS: QML is usually not found in clear text inside the binary because rcc attempts to compress and text compresses really well. You need to actually reverse engineer to find the compressed text content. It's not very difficult, but it is one step up from trivial. When I was at a client site just over a year ago they were using an off-shore team that tried to do 100% of the project in QML and JavaScript because you can find those people for absolutely no money. They have no formal education with respect to computer science. Just read half a "Teach Yourself How to Be Totally Useless or Less in 24 Hours" type book on JavaScript and hung out a shingle. I opened the binary with, I think SublimeText, perhaps KATE, doesn't matter, just a text editor. There it was. All the JavaScript code. I know because in the other frame I was looking at the actual source. The developer sitting beside me didn't believe me. He used Eclipse for everything. Ba-da-bing ba-da-boomb there it was. This is the identity theft (or worse) security breach Qt has unleashed upon the world. There is no safety in the environment. Things have been dumbed down so people with no formal training can purchase a license and ticking time bombs are being released every day. I lay awake at night filled with complete dread about the medical devices previously and currently being developed using dirt cheap low skilled off-shore teams because they are "priced right" trying to do the entire thing in QML and JavaScript. A token few will even believe that one & done OpenSource security is actually secure so they won't optically isolate network communications from the actual device via an I/O appliance with its own processor and memory. They get in, open up the binary with a text editor, change what the JavaScript does, then save the binary. To the doctors and nurses it looks like the 100+- other of these devices the hospital has. This one, at random intervals, kills patients. It will be months and perhaps thousands of dead patients before anyone suspects anything, depending on the device. Something like a ventilator people don't have high survival rates being on in the first place. An infusion pump for a cancer patient would attract slightly more suspicion by offing cancer patients where the disease was caught early. All because the JavaScript was brought along in the binary as text. How about all of those "apps" in the app stores written by people with no formal training "because they can" with QML? They won't kill people, but they could make the Equifax breach look small time. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
On Monday, 13 July 2020 07:44:24 PDT Roland Hughes wrote: > When QML was first pitched back in the Nokia days, it was supposed to be > a script that ran through a pre-compiler generating the C++ widget code. No, it wasn't. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
On 7/13/20 9:10 AM, Jérôme Godbout wrote: Hi, If you write your algo into Javascript or you can edit it, you are so doing Qml wrong! leave your algo into C++ please, your model/controler too shall be be C++. Qml is for the GUI layer only, it so simple it is temping to add more logic into it, but that's an error that will bit you in the long run. When QML was first pitched back in the Nokia days, it was supposed to be a script that ran through a pre-compiler generating the C++ widget code. Given the designer back then had a nasty habit of corrupting XML files, this was welcomed news. Most of today's "Qt developers" attempt to work exclusively in QML and JavaScript. I recently worked on a medical device where the off-shore team tried to do 95+% of the device in QML and JavaScript. Eventually that will pass FDA testing and be out in the field. I won't ever let it be used on me. How many other devices have already rolled into the field with that kind of code base? I certainly don't want any of them being used on me at any point in the future but I have no way of identifying them. Personally, I have __never__ walked into a shop that was using QML and wasn't trying to do everything in JavaScript. I don't even speak with clients that list QML as a requirement anymore because I already know the train wreck I will be walking into. If you have never rewrite any part of the code to allow better architecture to take place you must be a coding god that can write code flawless or something must horrible into those API. Needs and requirements evolved, code need to evolve with them. In the FDA medical device world you have to create The Four Holy Documents up front before you begin coding. There is no hacking on the fly and you don't make sweeping changes partway through. You create a bullet proof medical device and then it has a 10-30 year life in the field. Periodically you have to add support for some new sensor, but no big sweeping changes. I don't know what that medical device is that Harman keeps reaching out about every 18 months or so, but it uses Qt3 under OS/2. According to this article https://www.americanbanker.com/news/os-2-sunset-with-big-atm-base-ibm-is-taking-it-slow 95% of ATMs were also running OS/2 in 2003. How often do you think banks want to replace ATMs? -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Roland Qml
Hi, If you write your algo into Javascript or you can edit it, you are so doing Qml wrong! leave your algo into C++ please, your model/controler too shall be be C++. Qml is for the GUI layer only, it so simple it is temping to add more logic into it, but that's an error that will bit you in the long run. You can compile Qml and with Qt6 convert Qml to C++, so I wonder what would be more a problem, do you ship any library into your software or you do static compiling of everything so nobody can inspect your lib? Cause, exposing API from a lib or any other languages is not hard to reverse used in any way. You do not protect code by obfuscation, but protect code with your license. Javascript engine was just a practical way at the time, probably a new engine will come one day, there is some Qml without Javascript engine coming into Qt6 paving the way for it. Qml, is just a widgets rendering way to declare the GUI in a much simpler and cleaner way. If you want to stick to QWidgets, please do, there is no shame into QWidgets, he just have a limited future for expansion. The multiple rendering engine the embedded and Qt/Qml lite will be more then welcome for me. I have switch to Qml and could easily range it from big 3D CAD medical software, mobile tools and some development on embedded device. I haven't any issue and could reuse code for that whole range (both Qml and C++). Nothing in the world will make you change your idea, I known that and I do not expect anything to change from you. IMO your are stuck in the past, but if you like so much those old version, I'm sure they are still working just like they did back then, nobody force anybody to use the latest version as far as I can see, Qt4 is still useable if you truly want to keep it that way. Break into API happen for a good reason, to remove bad API or to allow better possibility. If you have never rewrite any part of the code to allow better architecture to take place you must be a coding god that can write code flawless or something must horrible into those API. Needs and requirements evolved, code need to evolve with them. I for one, really enjoy Qml and the Qt Meta, wish I could get ride of the Moc, but this will wait until C++ get more reflexion built-in. QWidgets, ditch it and never been more happy since then, I had to maintain a few applications, it now feel cumbersome when I touch them. This only reflect my own opion, sorry for all the noise to other users, Jerome -Original Message- From: Interest On Behalf Of Roland Hughes Sent: July 13, 2020 8:31 AM To: interest@qt-project.org; rjvber...@gmail.com; Donald Carr Subject: Re: [Interest] rebooted QtWebKit for Qt4?? On 7/13/20 5:00 AM, interest-requ...@qt-project.org wrote: > I also didn't complain about stability, but coming from fundamental research > I can relate to the feeling that API breakage of the type Qt3 -> Qt4 -> Qt5 > (and who knows what Qt6 has in stock) happens too fast, too soon. Kittens swatting at bright shiny objects. Let us not forget that QML+JavaScript is completely insecure in the OpenSource world. All of that JavaScript gets stuffed into the binary you ship as free text. Anyone with a decent text editor can read/extract your super secret proprietary algorithms. Worse yet, anyone with enough patience can change a binary in the field. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
