<noonien>
tbh, i think more "hackers" should work on medical equipment, maybe not production equipment, but stuff that can that's not made to neccesarely keep people alive
<srk>
I'm not sure about that as a lot of people think they can just stuff arduinos into medical equipment and call it medical grade :)
<clever>
noonien: the part at end .... lol
<noonien>
yeah, poor girl didn't know what she signed up for, lmao
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever>
noonien: in half of his vids, it seems like the people around him do know what to expect
<clever>
like that camera that would taze people, so he would be the "tallest" in the photo, lol
<noonien>
yeah, lmao, or the electric wires on the ground because his roomies were making too much noise
<clever>
yeah
<noonien>
srk: have you seen the medtronic ventilator source code?
<noonien>
i'm sure they have a method to their, but it all seems pretty chaotic to me
<noonien>
i'm sure "medical grade" just means they test it extensively. if you have a simple apparatus, i don't see why an arduino wouldn't do. even though i hate it with passion (mostly that it's c++, and a shitty platform).
zupo has joined #nixos-aarch64
<srk>
because you typically don't control all the stack and rely on code of various qualities
<srk>
you need a solid foundation and ideally something that supports formal verification as well
<noonien>
yeah, i don't like "platforms" or "frameworks" either, for the same reason
<noonien>
how do you formally verify hardware?
<srk>
you don't but you can verify the CPU and fw running on it
<srk>
sel4 is also quite interesting in this regard
<noonien>
i'm skeptical. surely the physical processes that govern the CPU have enough errors, bugs, and uncertanty that formally verifying them produces any usable result
<srk>
if it would you wouldn't even be able to type messages here ;)
<srk>
or boot your system :D
<noonien>
hmm, i see your point, but i can't say i agree with it. or perhaps i'm mistaken, does "formally verify" not mean matematically prove that the system is working acording to its design?
<srk>
it is also extremely costly for vendors to recall CPUs due to hardware bugs found post-production
<srk>
it does, in _some_ scope, you can't model everything of course
<srk>
like IO :)
<noonien>
ah, well, given that, sure
<noonien>
I/O inside or outside the cpu?
<srk>
outside
<srk>
(more generally interfacing with outside world)
<noonien>
i'm not saying formal verification doesn't have any merit. i'm saying it's not an absolute proof that a system works as intended, perhaps that's not what you were arguing anyway
<noonien>
"proof" does sound rather absolute though
<srk>
formal verification merely ensures that the subject behaves according to the specification
<srk>
(or that you don't have bugs in the implentation but in the specification :D)
<srk>
it's not a silver bullet of course, it's just one of the techniques you need/want when you're building reliable things
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FRidh has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
lordcirth has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
lordcirth has quit [Remote host closed the connection]
lordcirth has joined #nixos-aarch64
nschoe has quit [Remote host closed the connection]
nschoe has joined #nixos-aarch64
lordcirth has quit [Read error: Connection reset by peer]