My primary sources are:

• 7digital (who AIU primarily run white-label music sales platforms, but also have direct per-country shops like https://uk.7digital.com/). Reasonably simple interface, reasonable prices, good general coverage.
• hyperion records for everything classical.
• If everything else fails, Amazon Music; the way you get the music out of it varies over time, but in the end it has been DRM free for some time.

There are sanitary reasons to keep a minimum regular temperature in hot water lines; temperatures below 51°C promote the growth of legionella.

The German wikipedia has lots of background; to summarize, it’s a game of trade-offs around energy, storage, hygiene and safety.

Can only speculate as a bystander, but here’s what I think needs to happen before a Linux port (which is probably the end game here):

• The project has to survive Nintendo’s attention.

• Any component close to hardware needs to be ported to a PC equivalent: Graphics to OpenGL, flash writes to file access, etc.

  This can be assisted by using / linking in an existing emulator (a bit like qemu became more and more usable for KVM stuff), but that’ll be some work to give a native game experience. (The game is probably already playable well in emulators).

• Players will either need to have the ROM (eg. read with a USB cartridge reader), or completely new artwork will need to be created.

  Compared to OpenRTC & OpenTTD, the former is much more complex (drives for the CDs the original games were shipped with are still somewhat widespread), as is the latter. The latter is not without precedent (OpenArena), but it’d likely feel more like a game on the OoT engine than the same thing.

It’s weird how decompiling games is a legal gray area. In my understanding it would be clear copyright infringement, but it seems from how OpenRCT and OpenTTD got away with it, a decompiled game can be freed even without going through the painstaking clean room development approach.

As a fan of all these three, I’m happy to see this.

And it is :-)

Update: One of the optimizations can now be observed, further exploration is indicated.

It looks way more complicated than it is.

Maybe I should have rather linked to the “please participate” slide of when I presented this at Rust meetups: https://christian.amsuess.com/presentations/2020/crev/#/step-14

Not directly (at least without admin intervention or transfer of the crate to someone like rust-bus).

What I’d encourage you to do is to create a cargo crev review of the crate, marking it as unmaintained. crates.io won’t show reviews (yet, I hope), but lib.rs has a tab that shows all known reviews (eg. on https://lib.rs/crates/typenum), and statements like “people note in their reviews that this is unmaintained” should show up there.

Looking forward to using .then(), this brings back nice memories of smalltalk.

At least for my use cases it’s already there; especially the ecosystem around embedded-hal is already way ahead of what’s there in C.

The lack of maturity in terms of still developing modules is partially made up for by cargo’s ability to manage different crate versions in dependencies – if some internal part needs v1 of a crate that is now developed in a v3, it can still work (as long as you have a good grasp on its security implications).