Oh absolutely, I wouldn't use this for any production system. It would be a toy hobby project. I just find the notion of turning a no-degradation failure mode into a gradual-degradation one fascinating for some reason.
> the failure mode is the opposite of graceful degradation. It’s not like there’s an increasing percentage of requests that fail as you get closer to the deadline. Instead, in one minute, everything’s working just fine, and in the next minute, every http request fails.
This has given me some interesting food for thought. I wonder how feasible it would be to create a toy webserver that did exactly this (failing an increasing percentage of requests as the deadline approaches)? My thought would be to start failing some requests as the deadline approaches a point where most would consider it "far too late" (e.g. 4 hours before `notAfter`). At this point, start responding to some percentage of requests with a custom HTTP status code (599 for the sake of example).
Probably a lot less useful than just monitoring each webserver endpoint's TLS cert using synthetics, but it's given me an idea for a fun project if nothing else.
As far as I've seen, it's generally just the WASM modules that crash, and not a full sim crash to desktop (CTD). But considering the WASM modules are usually running all of the aircraft logic, systems, flight control computers, etc. then it tends to mean a complete flight loss since you can't... well... control the aircraft anymore. I'm not sure what kind of automatic restart logic exists for crashed WASM modules, if anything. It would be interesting to see if module crash recovery is possible.
One of the biggest factors for any flight simulation add-on is performance, and so most of the major add-on developers are building C++ modules (compiled to WASM) to eek out as much performance as possible. My understanding is that it's also possible to write some things in JavaScript (and perhaps TypeScript), but performance takes a hit. I would assume Lua falls into that same performance trap, as I know Lua can be used for X-Plane add-on development, but it's (again) considered the less performance-centric approach as compared to C++.
I recall at least one add-on developer for X-Plane (Zibo [1]) migrating some of their Lua code over to C++.
DLSS also blurs the cockpit displays quite badly when there's anything moving on them (airspeed/altitude tape, etc.). It looks like temporal blur, which is interesting because the same blur doesn't happen with their TAA (*temporal* anti-aliasing) implementation.
Especially if you use a small amount of detergent in the pre-wash compartment. Most people (at least in Europe) just use a single tablet in the main wash section. I've seen a massive improvement by putting a teaspoon amount of detergent in with the pre-wash. The ever-wonderful Technology Connections sent me down this path.[1]
Without detergent in the pre-wash compartment, only water is used to pre-soak the dishes.