LsCs is a cross platform C++ GUI library focused on Medical Devices(lscs-software.com)
lscs-software.com
LsCs is a cross platform C++ GUI library focused on Medical Devices
https://lscs-software.com/index.html
47 comments
As a medical device founder, I personally wouldn't start any new projects in C++, unless I had realtime requirements. Embedded computers are performant enough today that you can easily write app code in safe languages with great tooling, and wont have to worry about complying with increasingly stringent V&V and memory safety standards from the FDA. And if I had to write c++, I'd use libraries and toolchains that were actually verified and had really great FDA quality documentation, which this project does not.
There was a discussion on real time Linux this week and I was SHOCKED to see comments from people who work on embedded devices that "real time" is vibes. i.e. a stack that tries to be predictable but isn't necessarily.
I'm curious for your expertise on that: my guess is some people can get away with that, but if you're operating ex. a medical laser, you gotta take it more seriously and actually guarantee ex. "This code will be delayed at most 8 ms, it's thread is guaranteed to get CPU time by then"
I'm curious for your expertise on that: my guess is some people can get away with that, but if you're operating ex. a medical laser, you gotta take it more seriously and actually guarantee ex. "This code will be delayed at most 8 ms, it's thread is guaranteed to get CPU time by then"
This is the difference between soft and hard realtime. For something that's heavy on signal processing, with some softer comms requirements (eg a B115200 serial interface for commanding/uploading programs), I'd probably reach for an FPGA + Linux MCU (a vendored Linux made for these kinds of applications).
I certainly would never describe a product as real time if there was not a true realtime component to it, but I think people think it sounds cool and slap it on anything that's high performance. Happy to answer any specific questions on my email, see the profile.
I certainly would never describe a product as real time if there was not a true realtime component to it, but I think people think it sounds cool and slap it on anything that's high performance. Happy to answer any specific questions on my email, see the profile.
anything that actually needs realtime does the realtime part in an MCU, not in linux
Could you give examples of your preferred stack of language and li raries?
.NET is pretty popular! We use a combination of Kotlin, Python, and Rust. Because of the V&V burden of extra libraries, we tend to only use standard libraries
Somebody has a bee in their bonnet about a decision in C++ 20 and so we get a project to "fork" some apparently important C++ library so as to fix everything they don't like about it. It's years of rants about how the modern kids just don't understand, condensed into this one fork proposal, so I guess that's efficient at least.
C++20 did screw up their holy war against volatile augmented assignment. I'm glad they were forced to revert that foolish change. There are people with influence over the committee who genuinely don't have a clue outside their little bubble.
Volatile compound assignments are nonsense. This incident is up there with std::span when it comes to illustrating how unserious WG21 are when it comes to improving software quality.
The deprecation would get you a warning for this nonsense in new C++ versions. It would still compile as before, but you'd get a warning so that maybe you can write something which isn't nonsense instead - an opportunity to express what you actually meant. But this was unacceptable of course.
You can see some of the same wailing for uninitialized access. Currently draft C++ 26 will just silently initialize your variable to some agreed bit pattern so that you don't incur Undefined Behaviour for uninitialized access by default. This seems to make many of the same people very angry.
The deprecation would get you a warning for this nonsense in new C++ versions. It would still compile as before, but you'd get a warning so that maybe you can write something which isn't nonsense instead - an opportunity to express what you actually meant. But this was unacceptable of course.
You can see some of the same wailing for uninitialized access. Currently draft C++ 26 will just silently initialize your variable to some agreed bit pattern so that you don't incur Undefined Behaviour for uninitialized access by default. This seems to make many of the same people very angry.
Thats a lot of red flags to put on your landing page.
Modern C++ standards are the bare minimum you should enforce in terms of software safety and correctness.
Modern C++ standards are the bare minimum you should enforce in terms of software safety and correctness.
I would have expected to see some examples of how the GUIs look. Clicked around for a bit and didn't see one single example. This doesn't look serious at all.
It's mainly a Qt preservation project (The fully open-source parts of Qt, but without the MOC compiler / QML / Qt Declarative) - so not that much different from it.
So, just like Copperspice?
"Modern C++" is the same rewrite costs as if you Rewrote It In Rust, except that at the end you still have C++ and are still on the same treadmill and will be doing this again next time. It makes sense for C++ trainers to promote this, it's repeat business.
Every three years there will be another iteration of "Modern C++" (it seems like some want to now call C++ 20 and C++ 23 "Contemporary C++" instead of "Modern C++" but it's the same again) and you're back to do more rewrites.
Every three years there will be another iteration of "Modern C++" (it seems like some want to now call C++ 20 and C++ 23 "Contemporary C++" instead of "Modern C++" but it's the same again) and you're back to do more rewrites.
This couldn't be farther from the truth.
Not only will a Rust rewrite take 5-20x longer, you'll also be supporting 2 versions (C++ and Rust) for a long time, while doing the rewrite and migration, and that will eat up a lot of dev hours.
I've done incremental C++ migrations and they are not nearly as complex or stressful, especially when you leverage libtooling or Python bindings to write AST-rewriting scripts for those large refactorings.
Not only will a Rust rewrite take 5-20x longer, you'll also be supporting 2 versions (C++ and Rust) for a long time, while doing the rewrite and migration, and that will eat up a lot of dev hours.
I've done incremental C++ migrations and they are not nearly as complex or stressful, especially when you leverage libtooling or Python bindings to write AST-rewriting scripts for those large refactorings.
> Not only will a Rust rewrite take 5-20x longer
If "Modern C++" really was a static target you could imagine performing the transition to "Modern C++" and you're done. If that existed it would compare to the Rust rewrite, maybe it would be 5-20x faster. But "Modern C++" isn't a static target, if we understand "Modern C++" this way (say, as C++ 17) obviously it's unsuitable for such safety of life software.
Instead the "Modern C++" transition is like a worse version of one of Zero's paradoxes. We never arrive at our intended destination and are always instead asked to perform another transition, the work never ends.
If "Modern C++" really was a static target you could imagine performing the transition to "Modern C++" and you're done. If that existed it would compare to the Rust rewrite, maybe it would be 5-20x faster. But "Modern C++" isn't a static target, if we understand "Modern C++" this way (say, as C++ 17) obviously it's unsuitable for such safety of life software.
Instead the "Modern C++" transition is like a worse version of one of Zero's paradoxes. We never arrive at our intended destination and are always instead asked to perform another transition, the work never ends.
> Modern C++" is the same rewrite costs as if you Rewrote It In Rust
Certainly not! The update can be done incrementally as pre-modern C++ is (almost) fully compatible with modern C++.
Certainly not! The update can be done incrementally as pre-modern C++ is (almost) fully compatible with modern C++.
That’s a weird take. I would expect it not being the same cost to do a rewrite in Rust, like, not at all.
You can do it incrementally with C++, not to mention not needing to hire a team of rust developers. I don’t think you want to let a team of C++ devs that are just learning Rust do a full rewrite as their first big project experience.
Also, when switching from, say, C++20 to C++23, thinking it’s the same amount of work as a full rewrite in Rust is laughable.
You can do it incrementally with C++, not to mention not needing to hire a team of rust developers. I don’t think you want to let a team of C++ devs that are just learning Rust do a full rewrite as their first big project experience.
Also, when switching from, say, C++20 to C++23, thinking it’s the same amount of work as a full rewrite in Rust is laughable.
And in some year there will be "Modern Rust"
From their manifesto:
> Long ago there was an OpenSource library called Qt. When it was C++ and Widgets, it was great. Then the library lost its way and became focused on phones. It also became dramatically less "open" and much more "you have to buy a license." The C++ Widgets side of the library withered as resources were poured into a non-typesafe worthless thing called QML. This was well after making a play for the medical device market. You can't use non-typesafe junk when lives are on the line.
Their writing style is a serious turn-off.
> Long ago there was an OpenSource library called Qt. When it was C++ and Widgets, it was great. Then the library lost its way and became focused on phones. It also became dramatically less "open" and much more "you have to buy a license." The C++ Widgets side of the library withered as resources were poured into a non-typesafe worthless thing called QML. This was well after making a play for the medical device market. You can't use non-typesafe junk when lives are on the line.
Their writing style is a serious turn-off.
If being non-typesafe is a turn-off they should not be using C++. They should be using Go, Rust, or some other memory-safe language with better type safety.
The latest crazy Windows IP stack RCE pushed me wholly over into the "nothing new should be written in C/C++" camp. It's clear that secure reliable software can't be done in these languages, at least at scale.
The macho counter-argument of "but I can do it!" doesn't work. Maybe you can. It doesn't matter. Code will be worked on by more people than just you if it lives for a long time. Code "rots" and acquires bugs, and having the compiler catch the worst ones (memory errors, type errors) is a huge win.
The latest crazy Windows IP stack RCE pushed me wholly over into the "nothing new should be written in C/C++" camp. It's clear that secure reliable software can't be done in these languages, at least at scale.
The macho counter-argument of "but I can do it!" doesn't work. Maybe you can. It doesn't matter. Code will be worked on by more people than just you if it lives for a long time. Code "rots" and acquires bugs, and having the compiler catch the worst ones (memory errors, type errors) is a huge win.
even safer languages like rust still do not prevent against many problems, such as: logic errors, stack overflows, out of memory errors, bitflips, memory leaks, unrecoverable errors (panic's), memory safety related issues in an unsafe context
That's not quite true. Stronger type systems such as in Rust, OCaml and Haskell do help prevent logic errors. Also Rust can provide very precise control over memory allocation so that can help with OOMs.
No language that I'm aware of protects against bit flips or claims to have memory safety in its memory unsafe escape hatches (kind of the point).
No language that I'm aware of protects against bit flips or claims to have memory safety in its memory unsafe escape hatches (kind of the point).
It's like saying seat belts, air bags, and crumple zones do not prevent all automobile deaths. They don't, but they help a whole lot. Prevention of all bugs converges with artificial superintelligence and/or solving the halting problem (which is impossible).
There are formal languages that do more than Rust, but they're a lot less practical. Working on making a more practical one would be a useful exercise.
You can forbid unsafe at the Cargo.toml level in Rust. You can also just search a project for the keyword "unsafe" to subject all unsafe code to extra levels of scrutiny. Some orgs set commit rules where commits containing "unsafe" must be approved by more people or must pass through a security audit team.
There are formal languages that do more than Rust, but they're a lot less practical. Working on making a more practical one would be a useful exercise.
You can forbid unsafe at the Cargo.toml level in Rust. You can also just search a project for the keyword "unsafe" to subject all unsafe code to extra levels of scrutiny. Some orgs set commit rules where commits containing "unsafe" must be approved by more people or must pass through a security audit team.
Honestly, what is your point?
Agreed. And I don't understand why people keep thinking Qt is not 90% LGPL.
For the people that Qt doesn't work it, it may as well be 100% proprietary; (L)GPL does not play well with super-duper-proprietary hardware. That's not a bug, it's (L)GPL doing what it was designed to do. These companies just aren't fans of providing their customers the code to the applications they sell.
I've heard about CopperSpice before, but I've never personally seen any project use it. Still, it seems they have some passionate developers behind it and actual users. Forking it just because you don't like some newer compiler standard seems a rather bad reason. Do the LsCs developer(s) have the same passion and resources to keep their fork up to date? How are their getting users? Are they going to stick with C++17 forever while the rest of the world moves on? While forks sometimes are a good thing, I'd first try to help the original developers to achieve "creat[ing] something prepackaged and widely usable".
The author states that it's because old UNIVAC mainframes are still being used in the medical world and they don't have 2's complement, which makes it incompatible with C++20. But the machines were discontinued a long time ago with the company finally moving to Intel Xeon CPUs in 2015 [0] - and I'm not even sure if people actually run GUIs with these legacy mainframes (plus the author's stating this will primarily support Linux, but are these mainframes even capable of running it?)
[0] https://www.theregister.com/2015/05/26/unisys_finally_weans_...
[0] https://www.theregister.com/2015/05/26/unisys_finally_weans_...
> and I'm not even sure if people actually run GUIs with these legacy mainframes (plus the author's stating this will primarily support Linux, but are these mainframes even capable of running it?)
The next parapgraph sounded like they're concerned about bugs from not having the same integer representation as those systems:
> Passing 2's complement data to backend systems or front end sensors expecting 1's complement causes catastrophes.
I don't really understand their concern though--surely all actual C++ implementations that build QT apps and the platforms that run them are using twos complement anyway? Like, the C++ standard change is not making anyone change their integer representation, it's just telling the not-twos-complement people that they're on their own, right?
Of course I'm not surprised not to be following the logic since I have to count myself among "those who never went to college for Computer Science".
The next parapgraph sounded like they're concerned about bugs from not having the same integer representation as those systems:
> Passing 2's complement data to backend systems or front end sensors expecting 1's complement causes catastrophes.
I don't really understand their concern though--surely all actual C++ implementations that build QT apps and the platforms that run them are using twos complement anyway? Like, the C++ standard change is not making anyone change their integer representation, it's just telling the not-twos-complement people that they're on their own, right?
Of course I'm not surprised not to be following the logic since I have to count myself among "those who never went to college for Computer Science".
It's a lot easier to write a wrapper converting two's complement values to one's complement and vice versa than a GUI framework appropriate for safety critical systems. I have no idea why you'd choose to do the latter.
Unisys mainframes (not UNIVAC).
I am one of the very "passionate developers" of the CopperSpice project. Roland is the single person behind this fork. He was angry with Qt for not listening to his demands and his hope was that our team would agree to everything he wanted modified. Yes, he told us we had to stay on C++17 and never migrate. He also demanded we provide 20 years of ABI stability while providing new features.
There is of course a much larger back story but I think this speaks volumes about the situation.
Barbara Geller CopperSpice Co-Founder
There is of course a much larger back story but I think this speaks volumes about the situation.
Barbara Geller CopperSpice Co-Founder
[deleted]
Why is it a good idea for a GUI library to behave like a framework-of-all-things, from basic data structures, OpenGL library, XML library, Javascript engine etc.? CopperSpice does this, and it seems so does Qt and probably this new LS-CS fork of CopperSpice.
This is a great question. We do not consider or want CopperSpice to be a framework and one of our goals has been to transition our code base to a clean set of C++ libraries.
Our understanding is that Qt wants to remain a framework. No clue what Roland might be considering, but he did give us an "ear full" of bike shedding.
Barbara Geller CopperSpice Co-Founder
Our understanding is that Qt wants to remain a framework. No clue what Roland might be considering, but he did give us an "ear full" of bike shedding.
Barbara Geller CopperSpice Co-Founder
Good luck!
I developed a successful medical device on Qt 4.8 and can attest that it was a joy to work with.
Not sure about how the FDA would feel about an old framework. I don't think they would care too much or it would become anymore easy to provide software verification.
I developed a successful medical device on Qt 4.8 and can attest that it was a joy to work with.
Not sure about how the FDA would feel about an old framework. I don't think they would care too much or it would become anymore easy to provide software verification.
So that's a fork of a ~10 years old fork of Qt. Copperspice originally forked, in part, because Qt was not close enough to the C++ standards, and now this (outdated) GUI library is being forked because they make use of a 4 years old C++ standard.
Someone should fork LsCs to add support for mobile or new C++ standard. Looking forward to see this happen in 10 years (/s)
You are correct that we did the fork many years ago. Since then we have back ported a significant portion of Qt 5. Piece by piece our team has been improving the foundation and adding new functionality. We leverage C++ classes using inheritance and composition when possible.
A decision was made to move to C++20 and we are keeping an eye on when to make the next jump. We welcome contributors and friendly conversations.
Barbara Geller CopperSpice Co-Founder
A decision was made to move to C++20 and we are keeping an eye on when to make the next jump. We welcome contributors and friendly conversations.
Barbara Geller CopperSpice Co-Founder
In 10 years they will be rewriting React 15.0 from scratch because...