@squirrelroad they cover different parts of forking efforts. Before the lix announcement the aux group was discussing how/what parts of nix and the nixcpp implementation of it would need to be forked. Apparently everybody there is very happy lix has been announced.
Personally I find the naming distinction very helpful. Instead of a NixOS system declared in nix (the language) and using nixpkgs package definitions all of these will have distinct names (auxpkgs, lix language)
@danct12 depends on how much you are using the keys. I've found phones with just one remaining volume key working very well (tap key, adjust on screen slider) and with both volume keys broken a lottle annoying but still feasible for everyday usage (search for the option in the status menu, adjust volume from there). But YMMV
"Anduril Industries, Inc. is an American defense technology company that specializes in advanced autonomous systems. It was founded in 2017 by inventor Palmer Luckey with investors and founders associated with Palantir and SpaceX."
Oooooh boy, I kinda understand why some people are upset. This reads like the Ultimate techbro company... 🤦♂️
My biggest enemy today in #Rust is the fact, that i cannot implement/extend traits from another crate. So i wanted to use structs from the #rbw crate since i am piggy-backing on their logic, but since i need Debug on those, because i am writing a #Relm4 app, i am screwed. Or am i missing something?
I mean i could just use my own types based on the rbw ones, since they are not likely to change (the crate looks feature-complete), but meh, is there a better way?
:boostRequest: :boost_ok: #RustLang
But I'd only use it if it was something meant for submission upstream or a temporary thing (getting more logging during development but not suitable for later stages of the project). Otherwise the wrapped type with custom debug trait implementation (like suggested by someone in a different reply to your post) sounds like the better approach.
looking for a robust, small, low-power, relatively cheap, preferably open hardware linux-capable (32 bit OK) SBC or SOM with ethernet and good mainline support. it's role is always-on remote management of another system over UART and GPIOs. so basically IOT without wifi and without non-linux OS.
