Additional information regarding Home Assistant:
The sun component (which should be enabled by default) already computes the sun position for you.
Elevation and azimuth are available as standalone sensors sensor.sun_solar_azimuth (might be disabled by default) or as attributes on the sun.sun entity.
Cushy is an experimental Graphical User Interface (GUI) crate for the Rust programming language. It features a reactive data model and aims to enable easily creating responsive, efficient user interfaces. To enable easy cross-platform development, Cushy uses its own collection of consistently-styled Widgets.
The 44.1% battery failure figure is regarding the "starter" battery (12V) and is combined from all vehicles in the study (EV and ICE).
The HV Battery for the traction drive is grouped together with any kind of motor failure and comes in at 22.8 %. But this figure also includes ICE vehicles ejecting piston rods etc.
The only EV vs ICE numbers stated directly are the total breakdowns per 1000 vehicles at 1.9 (EV) and 3.6 (ICE).
I'd be really interested in a chart showing the failure categories separated by EV and ICE.
For context they seem to be specifically referencing the 12V "starter" battery not the HV battery used for the traction drive in EVs with that 44.1% figure. Additionally this figure seems to include all vehicles in the statistic, so some part of that is contributed by ICE vehicles.
You can use their online web-editor (similar to OverLeaf for LaTeX) or download the open-source engine and run it locally (there are extensions available for many text editors).
Compared to LaTeX I find it much more comfortable to work with. It comes with sane, modern defaults and doesn't need any plugins just to generate a (localized) bibliography or include links.
Since Typst is very young compared to LaTeX I'm sure that there are numerous docs / workflows that can't be reproduced at the moment but if you don't need some special feature I'd recommend giving it a shot.
The uom crate implements this for Rust.
The core functionality is based on generics but there are some macros for defining custom measurement systems.
I suspect that if you were to cut the screen at the rounded edges, the sensor island and the onscreen nav buttons you'll be left with a 16:9 screen.
In other words its a 16:9 screen with some margin for curves and controls.
Getting the configs to work with my personal devices was already a little finicky but doing that for not-so-technical family members was starting to be a bit too much work for me.
I'm hoping that Headscale will cut that down to pointing their app at the server and having them enter their username and password.
Was running Wireguard and am now in the process of changing over to Tailscale (Headscale).
It uses Wireguard for the actual connections but manages all the wireguard configs for you.
Found this comment with some links. Couldn't find anything from an admin during my short search.
The exact same problem arose for Voyager users in March when Voyager dropped support for Lemmy 0.18.