LsCs is a cross platform C++ GUI library focused on Medical Devices

29 pointsposted 13 hours ago
by jandeboevrie
(lscs-software.com)

39 Comments

ijustlovemath

4 hours ago

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.

mikedelfino

4 hours ago

Could you give examples of your preferred stack of language and li raries?

zerr

3 hours ago

Siemens, Philips use .NET. Although, I believe it is mostly due to their partnership with Microsoft rather than the technical side of things.

jphoward

7 minutes ago

Are you sure? Philips' medical side have an in house GUI library (Qt-esuqe) called Sense and it's mainly implemented using C++.

ijustlovemath

3 hours ago

.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

refulgentis

an hour ago

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"

Palomides

an hour ago

anything that actually needs realtime does the realtime part in an MCU, not in linux

kombine

4 hours ago

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.

ranger_danger

3 hours ago

Agreed. And I don't understand why people keep thinking Qt is not 90% LGPL.

jeroenhd

16 minutes ago

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.

zerr

3 hours ago

Qt Company tries to hide that as much as they can.

ArtixFox

2 hours ago

What parts are closed off?

api

4 hours ago

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.

jenadine

3 hours ago

If only there was an existing gui library as mature at Qt4 written in these languages, so they could fork it.

api

3 hours ago

There are some good Go and Rust UI frameworks they could contribute to, but that would mean contributing to a common goal rather than forking endlessly.

ranger_danger

3 hours ago

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

IshKebab

2 hours ago

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

api

3 hours ago

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.

timeon

an hour ago

Honestly, what is your point?

lionkor

11 hours ago

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.

bborud

9 hours ago

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.

cyber_kinetist

9 hours ago

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.

tialaramex

10 hours ago

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

cue_the_strings

6 hours ago

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.

tialaramex

2 hours ago

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

spacechild1

8 hours ago

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

jenadine

3 hours ago

And in some year there will be "Modern Rust"

qsdf38100

9 hours ago

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.

tialaramex

11 hours ago

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.

kevin_thibedeau

2 hours ago

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.

gsliepen

9 hours ago

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

cyber_kinetist

9 hours ago

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

ben0x539

7 hours ago

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

AlotOfReading

3 hours ago

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.

oezi

5 hours ago

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.

ogoffart

6 hours ago

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)

dstanko

4 hours ago

In 10 years they will be rewriting React 15.0 from scratch because...