Today I posted about #NixOS naively assuming the leadership didn't do anything, promoting the open letter. That was a mistake, I should've checked before. There has apparently been movement to correct the problems
I wonder if #Aux could end up being an opinionated, easy-onboarding, example-based "distro" of #NixOS. A sister distro that focuses on usability as a gateway for people who are really coming at the power of #NixOS with little to no technical background.
I'm not a marginalized person in any way whatsoever, so all I can do is, once again, thank all of the people who stood up, made their voices heard, demanded not to be marginalized, and, with their allies, made change happen.
(Now, in addition to the important cultural and ethical issues, let's get a Documentation working group assembled!)
A fundamental piece of #aux is the core package set. These packages are vital to the project and are used by all other areas of the ecosystem. If you have the expertise working with #nixos / #nixpkgs, please consider joining us!
Hey so I'm restraining myself from just boosting all his posts, but if you're interested in the future of computing, I would definitely recommend following @jakehamilton. #aux (#auxOS?) looks like it's going to be a real thing and while I have my problems with #nixLang I really do think in 20 years all operating systems will be based on the foundational ideas of #NixOS.
TIL you can use #Nix to run entire builds on a remote system, just by adding --build-host <hostname> to nixos-rebuild, as long as you have SSH access. I built a custom kernel for my Surface Pro on my server and it just worked. For all its faults and flaws, it's still a really amazing tool
I’ve just moved my workstations from #NixOS to #opensuse. Not because of the ruccus in the community or any political views (well… maybe a little, but because I want to enjoy computing, not be bombarded with negativity), but because it ate up too much of my time. 1 theming issue last night took me all night to iron out, and it’s just too much at this point. I love #NixOS on the server, but I’m moving back to “plain old” tumbleweed. (Thx @thelinuxcast …)
@buonhobo
As I understand it some people in the #nixos community disagree with the way the project is run. So as is common in open source, someone has started a fork. 🤷
In case you are wondering why #PythonPoetry is currently broken in #NixOS: Its dependency dulwich has been upgraded by accident. The commit has since been reverted, but that has not yet propagated to all channels. Keep an eye on https://nixpk.gs/pr-tracker.html?pr=307505
I like #Nix, I do not like what has happened to it. #NixOS is an incredible technology and it deserves better. Nobody else has started the process so I guess I have to be the one to do it. We are forking. I would rather try and fail alongside all the people who love Nix but were pushed away from the project than give up.
One aspect of #NixOS modules no one ever talks about: if you fetch and import modules written by someone else, you are effectively trusting them with root access to your machine
Thank you for the TPM2 #NixOSarticle@jnsgruk. I decided to give it a go last weekend, and it was a bit longer process than 10 minutes. For anybody who struggle to get rid of the password prompt for the LUKS volume, this setting is essential:
boot.initrd.systemd.enable = true;
The initrd must have systemd installed, so the settings defined with systemd-cryptenroll are available during the boot. Alternative way is to use Clevis to encrypt the LUKS password using the TPM module, and invoke it during boot. This is not super complex either, but I kind of like the systemd approach more.
Also the article didn’t mention much about the different PCR ids you can use with TPM. These define the system state when a secret key can be accessed from the TPM module. If any of the policies trigger, the TPM module will not output any secrets and the user needs to enter the LUKS password. The article uses three policies:
0: firmware updates
2: extended ROMs from pluggable hardware (e.g. USB)
7: secure boot disabled, or firmware certificates update
Additionally, one policy is needed to ensure an attacker cannot boot the system to a single user mode from the bootloader:
12: kernel config change, e.g. changing the boot parameters.
It is important to wipe the old slots with systemd-cryptenroll when changing the PCRs. Changing them is additional, and doesn’t modify the existing policies.
Edit: and do not wipe the password slot! This will render your disk unbootable.
With the nixos current situation maybe I should try to read Linux from scratch ? Does anyone has experience with it ? Would love to know how hard it is. :BlobhajfBlobbyHug: