nagisa
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.
That said, it is entirely up to you how you would configure the system that the thread border router connects to. Thread specification uses local addresses for the thread devices, so in order for these devices to get access out into the public internet you would need to NAT the IPv6 pretty much (or the devices would have to be smart enough to figure out a globally routable IP address, via e.g. DHCP.) At the same time since it is all bog-standard IPv6, you also get full control with firewall rules, NAT/forwarding and such.
Overall you'd need either a very unusual device or a major misconfiguration off the beaten path to get thread devices talking on the public internet.
Food is a bad counter example here, as retailers are not prevented from adjusting their prices the further away you choose to live off major population hubs. OTOH electricity in many cases costs the same in the entire country (incl. UK.) This means that energy consumers are not incentivized by these expenses to consider the real costs of the grid. They will rather build a new factory/etc close to London where they might expect to have access to better workforce pool instead of in Scotland right next to the overproducing turbines.
NIMBYism against new grid infrastructure would also largely disappear overnight if the market actually made economic incentives (in a form of reduced electricity prices/fees) for people to accept infrastructure bringing that electricity to them. The way things stand today – when electricity costs the same to everybody in the country – of course you wouldn't want any works in your vicinity.
(At least for many EU based carriers.)
Outside of the fundamental window management differences, I find that a lot of stuff with niri is easier to make work, or just happens to work out of the box. Screen sharing with sway was always a problem for me[1], whereas for niri it works great (incl. sharing individual windows only[2].) I also found that niri is much better at letting hardware go to sleep (which saves 10W on my GPU.)
[1]: https://github.com/swaywm/sway/issues/7898 etc.
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3864
1%/h is just 0.5W (for a 50Wh battery) which isn't a lot, but fail to bring a component or two to shutdown or sufficiently low power state and you'll observe exactly this behaviour. Of course some drain is going to be almost inevitable just to keep memory contents sufficiently refreshed, but with proper power-saving states memory can go appreciably below 0.5W.
With 64-bit addresses, and the requirements for how invalid memory accesses should work, this is no longer possible. AND-masking does not really allow for producing the necessary traps for invalid accesses. So every one now needs some conditional before to validate that this access is in-bounds. The addresses cannot be trivially offset either as they can wrap-around (and/or accidentally hit some other mapping.)
As far as I know touchpad implementations just report finger locations and its up to software to interpret what a combination of these gestures means.