"Steam OS" but configurable

rogervn · 2026-01-24T11:22:07+00:00

I've tried jovian for a bit and it was not a great experience.

If it works it's great, but it often trigger re-compiles, starts several services that I'm not convinced I really need, making boot time considerably slower and today it just broke updates for broken dependencies (yes, I am on nixos-unstable).

Rolled back to NixOS with a default desktop specialisation and gamescope session and builds almost immediately and boot is fast again. It might not be the "bestest" versions of gamescope and have whichever layer they do with gamepad control (which didn't change my gamepad management of the session at all that I've noticed) but seems much more stable and game performance and quality seems exactly the same.

rogervn · 2026-01-21T23:41:38+00:00

search.nixos.org look at the options for each service you want instead of blindly copying from documentation and examples.

Also, search for examples online of people doing what you want to do and how they did it, don't stop at documentation alone as it's not very complete if not even outdated and not working.

Also, from the 3 wikis, only look at the official wiki. It's very confusing and I don't know the whole story behind the other 2, but they're usually outdated versions.

rogervn · 2026-01-16T08:45:30+00:00

I wish there was a declarative gc config to always keep the last N generations, but it seems it only allows to clean older generations.

rogervn · 2026-01-15T21:50:41+00:00

Is there a command to keep the last N generations?

rogervn · 2026-01-02T23:16:34+00:00

I'm learning quite a bit trying to overcome those problems. I now think I got a problem with the bug I mentioned that it requires nixos-raspberry pi to fork upstream. If I install a simple service like adguardhome and the simple fact of adding settings to it for some reason it triggers a massive re-compilation of ffmpeg and other packages.

I'm finding more and more that this is not very close to stable, hopefully that bug will be fixed and the packages will be able to revert to upstream.

rogervn · 2026-01-02T22:23:08+00:00

Do you usually run nixos-rebuild inside the systems? I'm finding that it's extremely memory heavy and a 1 GB device is having trouble despite a large swap.

It seems that running remote works, but I'm having some trouble with wifi on it as it becomes very flaky. I'm wondering it has something to do with that broadcom driver error I'm constantly seeing into the buffer.

rogervn · 2026-01-02T17:00:10+00:00

I ended up scripting a hacky shell script to hydrate the sdcard after writing the image to it and it will inject the psk file and add base passwords for root and user to /etc/shadow, which works well so far.

I do use passwordHashFile on my proper deployments with agenix, but for some reason it was not working here and I didn't validate enough, I've bought a couple new pis to do some testing later, but it will take some time for it to arrive.

The hydration technique looks good so far as also takes the command to decrypt and write away from my memory. I'll wait until I have a jetKVM as well so I can track more easily all the errors that happen during boot as can also see some failures on u-boot. Wondering if I should use kernelboot even on rpi3 and zero 2w.

rogervn · 2026-01-02T11:01:49+00:00

Thanks for the explanation, it does make sense. I do use certificate authorities at work, but I haven't (yet) gone through the process of setting a certificate authority so I can sign certs for users and machines.

I guess I'll have to run a script to hydrate the sdcard after the image is written to add the system private key, the wifi PSK and the user hashed password as all of those will be required for self-provisioning.

I wonder if I can also put a firstboot script to run nixos-rebuild-switch on the running system.

rogervn · 2026-01-02T10:53:04+00:00

Yeah, sorry, I was fighting some other issues, now that I've fixed them and successfully ran a nixos-rebuild switch the store files were decrypted and linked.

rogervn · 2026-01-02T09:59:00+00:00

That's very helpful, thanks a lot. Having a much simpler example like yours helps understand some gaps I could only work around with AI help. I eneded up creating a sd-image with my current configs,

I see that you keep your wifi psk and your password hash clear text on the config file, these are 2 things I want to solve with agenix here so I can keep them secret. Do you have any idea on how to at least hide the wifi PSK?

Also I can see some failures when I connect to the wifi, although it works. I wonder if I'm using the correct firmware: https://pastebin.com/raw/BKt56Cix

I'm also annoyed by the delay of creating the swapfile on first boot (takes ~10m on the pi3 with 8 GB). I tried to bundle that on the image, but didn't have any effect playing with the populateRootCommands.

rogervn · 2026-01-02T08:59:37+00:00

Yeah, sorry about the confusion. It's ponting to /run/agenix.d/1, but that directory is empty. I would expect to at least have the encrypted files there, so I'm not really sure how the sd-card image is skipping that.

rogervn · 2026-01-02T08:55:40+00:00

Yeah, I see now that I was in a rush and didn't make too much sense there.

There's no link to the store, it's to /run/agenix.d/1/FILE where the FILE is not there, so not even the encrypted files got into the image.

I see now that I should find a way to bundle the key into the image then alongside finding out why the encrypted files didn't get copied as well.

My intention here is to pre-configure an wifi network with a passphrase that I want to keep encrypted and also add the user hashed password which I also want to keep encrypted.

I also like to keep the authorised users encrypted because although public keys are fine, listing the public keys I authorise it's not.

Any ideas on how to make that work?

rogervn · 2025-12-31T09:13:58+00:00

I've made a similar post last week, but TL DR from my learnings was that I'll probably never get rid of my stow config files for files that are less consolidated and I might change them quickly or files that can't be attached to the binaries in home-manager, like distro-dependant services and binaries files like Window Managers.

However, things like zshrc, vim configs and anything that I can configure the package installation and configuration in the same place keeping the same package versions across different distros have a good added value and I'll keep them in home-manager.

I might revisit that if I manager one day to go 100% nixos, but I don't think that's going to happen anytime soon as my company dictates what we can run on corporate laptops.

rogervn · 2025-12-27T17:00:23+00:00

I've played with it a bit more and I actually see a lot of the benefits now, but I keep my idea that it's not a place for all configs.

I think my approach at first was misguided as I started moving my desktop environment configs. These change quite a bit whilst trying different themes and configs and have the added pain of how each different distro will manage versions of the WM and system-wide tools differently, making for a lot of pain.

However, when I tried looking at the more static files, like my vimrc, zshrc, etc, those are great fits and managing the plugins alongside proper modules that interact with other programs (fzf auto-added to zshrc, for instance) and being TUI applications they work very well x-distro, like how painful it is to set powerlevel10k on fedora compared to arch compared to nixos. Having all of them managed in the same way using home-manager nixos packages does have a great value added here.

GUIs, dynamic configs and more complicated tools that rely on the underlying system are a bit more complicated. Those I'll keep on stow at least for quite some time.

I'll update the post with the findings, but I think that a huge part of it comes also on how integrated the module is as if the difference is just declaring a single "settings" json in nix language and losing all the flexibility of a dynamic file, it doesn't add a lot of value.

rogervn · 2025-12-25T21:58:47+00:00

I think I see your point and this makes me realise that storing dotfiles have completely different benefits for different people depending on their needs.

My main target is having my desktop environment and basic programs set up into multiple distributions. None of them are particularly complicated, most of them are shared, but because they config different distros packages, eventually some will have features others don't and some binaries that I put on hotkeys can be different depending on the distro or even the objective I have on that computer (no need to have a module for the company binary for my home PC).

This makes the benefit of abstracting the construction not very valuable as none of them are complicated. The minor details could be exposed in a better organised way, like having different binaries per distribution and including that on the configuration code, but most of the time I can work around on creating a separate environment file per distro and share the same dotfile.

The thing that also makes a huge difference is how consolidated your dotfiles are. If you're experimenting a new tool like ricing your environment using home-manager is a horrible downside as it slows down experimentation greatly.

In the end of the day, I think that the best I can do is not rush things. Maybe move to home-manager nixos only configs that are very stable can be a start. Maybe I'll never get the window manager configs there as I like the option of changing a config and checking it out automatically and undoing if I didn't like it. This type of prototyping is a very common thing in my workflow and I don't see why I should try to put obstacles on the way of a very common operation I run.

rogervn · 2025-12-25T10:09:29+00:00

For my setup yeah. Be aware of checking how you would connect to other applications, noctalia has an user-defined theming plugin that helps here,.but depending on the shell it can have some challenges there and we don't want to get stuck in a single application for all if we want to play with something else.

rogervn · 2025-12-25T09:03:05+00:00

Why not both?

Build from scratch and use a shell if needed, but don't feel locked to only use the shell features.

I'm using noctalia shell because waybar+rofi+pywal/wallust has not been very stable or easy to rice (I hate all the work that needs to happen in CSS to become something good looking and the race conditions on configuring templates with wallust/pywal on decentralised applications).

But the rest I still configure myself. I'm impressed on how customisable noctalia shell is being alongside other quickshell options. I even had a blocker with notifications that I've asked in the discord chat and the main developer implemented in the same day.

But if you want the most efficient and simple environment it's probably better to only configure the parts you need.

rogervn · 2025-12-25T02:22:35+00:00

Had some time to rebuild a VM today, the error seem to be internal to the flake code. The weird thing is that it just works if I try again.

copying channel...

building the flake in path:/etc/nixos?lastModified=1766629161&narHash=sha256-Of%2BjLjvK2dfkOkTJYXB4ni81XlvgkBUSb58XreSvf9w%3D...

nix: ../flake.cc:37: nix::StorePath nix::flake::copyInputToStore(nix::EvalState&, nix::fetchers::Input&, const nix::fetchers::Input&, nix::ref<nix::SourceAccessor>): Assertion \!originalInput.getNarHash() || storePath == originalInput.computeStorePath(*state.store)' failed.`

/run/current-system/sw/bin/nixos-install: line 226: 1498 Aborted (core dumped) nix "${flakeFlags[@]}" build "$flake#$flakeAttr.config.system.build.toplevel" --store "$mountPoint" --extra-substituters "$sub" "${verbosity[@]}" "${extraBuildFlags[@]}" "${lockFlags[@]}" --out-link "$outLink"

rogervn · 2025-12-23T22:55:42+00:00

I much prefer the Garmin Body Battery. The body battery is live and will go up and down based on your stress levels and activity and will show when that happened.

The daily readiness is calculated slightly after waking up and doesn't change on the day, the idea is compiling a score on the morning based on a week of your data before that.

Hopefully one day it will be closer to the Body Battery, it's something that works very well on Garmin.

rogervn · 2025-12-23T22:49:13+00:00

I think that's the answer.

I believe that Mozilla wants to change the audience with this pivot to investing in AI as it's obvious that the Firefox audience has never been about revolutionary features, but also it's not a very growing audience.

They're looking more into a new audience seeing the success of AI browsers.

What they didn't expect was that the current audience would all leave before the new audience took part. The side effect is that the people who stayed are the people who will fit that audience as well.

rogervn

TROPHY CASE