Not quite, at least 50% of rescue costs will be paid via normal mandatory health insurance (just like when you need an ambulance car). Or 100% if you have a supplementary health insurance for transport.
For CHF 40 you can become a Rega patron and then they will usually pay whatever the insurance didn't cover, I think, but technically they don't have to.
I found this a bit odd. The intro seems to assume the reader doesn't know what "I/O" stands for. Okay, everyone has to learn this from somewhere, but... what is the audience for a "deep dive" article?
It goes on to assert how everything is I/O bound, and how bad threads are for that. Fair. What follows an intro to tokio, with focus on how you span a CPU-bound task, how work stealing works, and then how you should use SIMD for your CPU-bound tasks. Huh.
I mean, if you have a mostly CPU-bound task and also the occasional I/O socket, you can keep things much simpler by using threads and std::sync. Especially if you are in the audience of that article, then you don't know yet how much more complicated things can get when you need to use async in Rust. And how much Rust's safety model actually changes the past wisdom of "threads are evil, period" in favour of threads again.
You'd think removing friction on the software side for someone who already bought their hardware would be in their interest. Especially for students and hobbyists, who will want use what they already know once they enter the industry.
Why care about continuous sync? When I was in small robotics startup we had a separate motor controller driving each axis. A customers complained that the precision was getting worse after running for a few days non-stop. Guess what? Each axis had its own CPU clock based timer defining how long a segment should take. The difference is negligible but it accumulates over time. It was no issue for other customers who had a pause somewhere in their motion.
Why nanoseconds though? Usually a sub-microsecond sync is good enough. I can only think of some specialized phase measurements, really, like when you need to know from which direction a radio signal is coming based on timing of two antennas.
Happened to me twice (a decade ago, though) that I had some niche project (one a serial terminal, another a laser cutter firmware) that was on github with users left but the maintainer long gone.
I was able to pull the graph and collect patches and bugfixes from forks, like from a fablab somewhere using the same hardware, pushing to their fork with all their other location-specific stuff. In one case I discovered like four different forks with a different fix for the same problem.
Now you could argue the "social" part wasn't working if people fixed the same issue multiple times without knowing about each other. But at least github made it possible for me to collect everything there is, review and merge it into my own repo, and then drop a comment at the original issue tracker. (Which would have gone 404 had it been self-hosted, or with registrations closed due to spam.) In both cases I eventually got feedback from other people who found my branch and used it.
I know some European "automatic scribe" projects of the government sector. Their IT buys a physical GPU server hosted locally. Pretty sure it wouldn't be accepted otherwise (or maybe I'm just naive, but it sure is a topic they care about). The software stack is mostly open source, I think. It sure as hell doesn't talk to a big American cloud provider. (Well, the transcription service doesn't. Who knows what they do with the automated transcript. Probably the same thing they did with the manual transcript.)
Well said. There is a social context, there is a process and a struggle that can be more important than the result. It is sad to reduce art to the final product, or to approach it with an industrial mindset: maximizing commercial value while minimizing effort.
For CHF 40 you can become a Rega patron and then they will usually pay whatever the insurance didn't cover, I think, but technically they don't have to.
reply