phs2501

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.

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.

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

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.

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.

Related blog post: https://daltondur.st/syno_btrfs_1/

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.

Why does this still have the ridiculous iMac chin? Surely they can fit everything behind the screen at this point.

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)

Good info though; thanks!

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.

It was horrible.

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

CMUCL's interpreter evaluated IR1 (the first intermediate representation of its compiler) IIRC, so it wasn't possible to have a truly compilerless CMUCL _and_ a functional EVAL. I believe this IR1 interpreter was dropped from SBCL very early on. When SBCL gained an interpreter again it was a simple metacircular evaluator a la SICP that was unrelated to anything inherited from CMUCL. (This is all as of 15 or so years ago, I'm sure things have evolved since then!)

I had my own take on this concept[1], though with considerably less language magic involved. I imagine there's a lot of these kind of things running around. My criteria were:

a) let me write actual SQL, not a python DSL that generates SQL

b) be placeholder-safe

c) be composable

Though it was somewhat intentionally limited to what I needed to support for my own needs at the time.

[1] https://github.com/bdowning/sql-athame

Pretty sure residential 3-phase in Europe is 400V phase-to-phase, it's 220V phase-to-neutral.

This is how traditional Emacs undo is implemented as well. I like it but it seems to be not the norm; it does take a little bit to get used to. (There's plenty of packages to transform Emacs undo into something more like a tree structure, though I don't personally use them because I'm used to the above behavior.)

A naive translation (not checking facts in any way):

Converting 100% of power generation in the US to (deuterium-tritium) fusion would result in 200,000 cubic meters of helium generated per year. But the US currently consumes 40,000,000 cubic meters per year.

Nitpicky: for a lot of parts that would have actually been 70Hz (from the 320x200 VGA mode 13h), and having run the demo back in 1993 it definitely was not as smooth as in the video above on my 486/66MHz (and the Pentium had only been out for a few months at the time).

Is this an AltGr thing? On my (US, in Linux) keyboard right-alt-left-arrow works fine, and I'm pretty sure I do the same thing in Windows (again, US keyboard layout).

What? That's not how Git works, even ignoring packfiles.

(And yes I have no idea what Github's backend does, but I can't imagine "duplicate all data for every commit" would be a feasible implementation strategy.)

They (digital calipers) are also a lot more convenient in mixed-unit environments (e.g. PCB layout, which is why I purchased mine) than analog ones. Granted since I live in the US everything is mixed unit whether I like it or not. :)

> I don't know a ton about low level performance, but I'd find it surprising if it's not true. How can interpreted bytecode outperform direct machine instructions?

No production Java/.NET runtime directly interprets bytecode, it gets dynamically compiled into machine code. And as a result it can dynamically _recompile_ it if it discovers runtime profiling patterns that mean a different compilation can run faster, it can dynamically inline functions into the compilation if pertinent, etc.

This does not mean that Java/.NET code _will_ always run faster than native static compilation (a quick gander at the real world shows that optimized production code is usually pretty close either way), but it explains how it _can_ run faster.