phs2501

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.

(Agree on your other points for what it's worth.)

That's what I get for stopping at the front page after it looked just like I remember. :/

Thanks for the other link.

Usually that means the record was mastered differently (because you literally physically can't make a record as "loud" as a CD).

It's not the CD's fault, it's the mastering engineers.

That's... fine, and a cool trick I guess, but I don't actually want that behavior.

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 just taught myself to look at the end of the UUID, rather than the beginning.

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.