Regardless and despite this nordpool weirdness; with some rooftop & batteries I haven't been paying a cent for electricity outside of January so I don't need to care about prices in the market much at all.

I make a point to have my direct energy use be electric (e.g. for driving) so the recent jump in the pricing of molecules affects me relatively little. Unfortunately I don't have much say in indirect energy use (as used for food production) but I believe that people are rational and will figure they can do what I did sooner or later.

I am glad to personally be largely independent of molecule-sourced energy March to October. Hoping that the countries affected by oil instability take this as an opportunity to learn this lesson as well.

People have been modding theirs to make this contact, though. And been getting a significant performance boost out of it.

I got one from work that I don't use much outside of travel and haven't changed in any way past initial setup. It stays connected to WiFi and continuously broadcasts various discovery packets for the past month and a half since I last opened it up.

The wildly popular ESPHome is also driven by a superloop. On every iteration the main loop will call an update handler for each component which then is supposed to check if the timers have elapsed, if there is some data coming from a sensor, etc before doing actual work.

This pattern brings with it loads of pitfalls. No component ought to do more than a "tick" worth of work or they can start interfering with other components who expect to be updated at some baseline frequency. Taking too long in any one component can result in serial buffers overrunning in another component, for example.

How fancy does a network needs to be before this starts making sense? Who are the target audience for this project?

They almost never run 100%, though, and I have a recurring task set up to clean dust outta my filters, computers and servers.

Well before the npm attacks were a thing, we within the Rust project, have discussed a lot of using wasm sandboxing for build-time code execution (and also precompiled wasm for procedural macros, but that's its own thing.) However the way build scripts are used in the Rust ecosystem makes it quite difficult enforce sandbox while also enabling packages to build foreign code (C, C++ invoke make, cmake, etc.) The sandbox could still expose methods to e.g. "run the C compiler" to the build scripts, but once that's done they have an arbitrary access to a very non-trivial piece of code running in a privileged environment.

Whereas for Javascript rarely does a package invoke anything but other javascript code during the build time. Introduce a stringent sandbox for that code (kinda deno style perhaps?) and a large majority of the packages are suddenly safe by default.

This meant that instead of e.g. spawning some utility on a media key input, the compositor could directly stay connected to the dbus and control mpdris clients directly.

The way I see xmonad in retrospective today is that it is/was a "make your own compositor" library much like wlroots, smithay, etc, but it came with enough of the batteries included in the package that spinning up a nice and productive environment took barely any code. Something you can't really do with wlroots or similar.

That said I never had problems boarding with a PDF displayed on the phone screen. Unfortunate that they're going away.