Yes but the math (which happens in the receiver, so can be replicated by a user with an open source receiver) would be very different. You actually wind up with a 3D position relative to the Earth's center, which then needs to be mathematically mapped to lat/lon - that's what the WGS84 datum is for.
More annoying is when you use something like SoundSource (a paid app which adds per-app volume control and input/output redirection to macOS... a feature that by all rights should be built in in any reasonable OS) you get a permanent purple dot indicating a third party tool is intercepting audio.
Again, I get it, but as a power user this kind of stuff is just infuriating.
Not really. It's certainly intended for the basic "fan out m tasks to n workers, and the fanout producer wants to know when they're all done" and can be abused for some more, but I don't think it does anything to help with the "consumer died, I want the producers to be able to know this rather than just continuing to push messages into a queue forever" case.
I've written wrappers to handle things the way I want, but it always feels like a bit of a hack. (Usually I use a stop sentinal internally and reach inside to unbound the queue before I send it to avoid blocking). Just wish it were built in.
For one thing, static vs dynamic RAM. Static RAM (which is what's used for your typical CPU cache) is implemented with flip-flops and doesn't need to be refreshed, reads aren't destructive like DRAM, etc.
The one thing I wish stock python queues had an option for (async or otherwise) was some kind of explicit termination. e.g. be split into producers and consumers, and have consumers indicate iteration complete when all producers have finished (and vice versa - signal producers that all consumers have gone away). You can kind of kludge around it in one direction with stop sentinals but it's a lot more awkward to deal with - especially if your queues are bounded as then you can get into the situation where you block trying to push the stop sentinal onto the queue as it's full.
I highly doubt (and some quick checks seem to verify that) any of the tiny CC implementations will support the cleanup extension that most of this post's magic hinges upon.
Does anyone know of a Wayland WM/compositor that does multi-screen like XMonad? Preferably out of the box but I'll take configurable.
For those unaware, though I doubt you're reading this thread if so, I want n desktops that are shared between all screens, not desktops _assigned_ to particular screens. If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.
Ideally also does layouts kind of like xmonad too, not "here's a tiling tree structure and a bunch of commands to manually manage it".
I believe Synology runs btrfs on top of regular mdraid + lvm, possibly with patches to let btrfs checksum failures reach into the underlying layers to find the right data to recover.
For something that's literally designed to sit on a desk, yes... it's ridiculous to make it thinner in a dimension you never see vs one that you see all the time.
Yeah it was specifically the (presumed) lack of Rust's "fearless" concurrency that I was referring to... i.e. we can ram this data through a parallel map, but is it actually safe to do?
(And of course the flip side of Rust here is that you need to be able to figure out how to represent your code and data to make it happy, which provides new and interesting limitations to how you can write stuff without delving into "unsafe" territory... something something TANSTAAFL)
Rust is a step sideways if anything. Yeah, you don't have manual memory management headaches in .NET, but you also don't have Rust's fairly strong compile-time guarantees about memory sharing and thread safety.
Which enables stuff like rayon where you can basically blindly replace map with parallel map and if it compiles, it _should_ be safe to run.
(I'm not super familiar with the .NET ecosystem, so it's quite possible there's equivalent tooling for enforced thread safety. I haven't heard much about it though, if so.)
A local station had (I think past tense, though it made it a lot less likely for me to go there to check) their pumps playing ads in "attract mode" when nobody was using them. So going there late at night and filling up involved listening to a poorly-timed round of "BUY NOW" utterances from eight different sources (because of course they weren't synchronized). And you couldn't really mute it because it was all the other pumps.
Same, which is one reason I'm dreading the eventual Xpocalypse, as I have not found a drop-in replacement for Xmonad in the Wayland universe. (Particularly, the way Xmonad deals with multiple monitors and desktops just makes sense to me.)
Not quite what you're looking for I think but it was a Wine-style reimplementation of MacOS.