Probably the closest thing I remember existing to this was (in its "modern"-ish form) https://github.com/autc04/executor

Not quite what you're looking for I think but it was a Wine-style reimplementation of MacOS.

I think that is basically exactly what I've been looking for. Thank you!

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.

All of which is irrelevant to GPS users. I can't remember the last time I checked the math that my GPS was performing, to be sure it was mapping to a rough sphere.

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.

It's also annoying that macOS doesn't already have at least basic per-app volume mixing.

So much pain in macOS is in areas like this, trying to hack basic features back into the anemic OS.

Apple's "OS" updates typically focus on end-user applications that I don't use and never intend to. Meanwhile the core of the OS, and even the desktop environment, feels stagnant compared to many Linux distros.

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.

Does task_done not do what you want?

https://docs.python.org/3/library/queue.html#queue.Queue.tas...

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.

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

TinyCC supports cleanup[1], onramp[2] supports C2y defer (which is a superset), slimcc[3] supports both.

[1] https://godbolt.org/z/hvj9vcncG

[2] https://github.com/ludocode/onramp

[3] https://github.com/fuhsnn/slimcc

It still exists at https://archive.org/details/music_202007 .

The archive.org variation appears to be missing both samples and descriptions.

A ported version got made over at: https://ishkur.kenxaj.cyou/

Appears to have all the music files and descriptions from a cursory inspection, although missing Tools, Samples, and Sounds.

Gives credit to Ishkur, recommends checking v3, and was made using: https://github.com/igorbrigadir/ishkurs-guide-dataset/

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.

Yeah it depends on where the producer expects the CD to be played.

99% of music is made to be played on radio / in car etc., a noisy environment, where you don't want to be adjusting the volume knob all the time. So the dynamics are stripped in mastering phase.

Music that gets pressed on vinyls isn't mastered for car-play, but home stereo equipment, so it makes more sense to have larger dynamic range.

CDs have objectively lower noise floor (less hissing), and more dynamic range (difference between loudest and quietest note), but it's the mastering that usually destroys the sound. And nothing can be done about it on consumer end. Except find a less remastered version of the album in a thrift store that isn't scratched to oblivion.

There's really no reliable way to tell if a CD is going to have high dynamic range, except perhaps niche audiophile studios like https://www.stockfisch-records.de/sf12_start_e.html, but https://dr.loudness-war.info/ has fantastic list of records with their dynamic ranges, so you can check before you buy, and you can also explore and find new stuff to use to listen to your speakers ;)

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

Qtile. It has the corresponding layouts, too.

https://docs.qtile.org/en/stable/manual/ref/layouts.html#mon...

> If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.

At least i3's (and I imagine sway's) config is sufficiently flexible for that. Here's a shell function that brings the workspace you specify to your current output:

  i3_bring_workspace_to_focused_output() {
    local workspace="$1"
    i3 "
      workspace $workspace 
      move workspace to output $(
        i3-msg -t get_workspaces |
        jq -r '.[]|select(.focused).output'
      )
    "
  }

You can turn that into an executable and have it be called through a keybinding.

> If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.

This is due to a limitation of X11 where a window can't be in two places at once. In theory, Wayland compositors can duplicate the desktop (at the cost of, like, not letting applications know their own window coordinates which seems pretty bad).

> at the cost of, like, not letting applications know their own window coordinates which seems pretty bad

I'm pretty sure Wayland applications already don't know their coordinates.

Exactly.

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

Sway can more or less do it, and I've switched from XMonad to Sway but configured similar to XMonad's default method of operation.

I haven't managed to get it quite right though. For example Sway doesn't seem to be willing to move a workspace to a different monitor if it is empty.

Yeah, I switched from XMonad (which I used for over a decade) to Sway a few years back. Spent some time trying to duplicate the XMonad behaviour but eventually just realized that spending a few hours getting used to the Sway approach and slightly changing my workflow was a lot easier.

I just taught myself to look at the end of the UUID, rather than the beginning.