nixpkgs VS nixos

Noticed it wasn't on Nixpkgs, so... https://github.com/NixOS/nixpkgs/pull/399843

https://github.com/nixos-bsd/nixbsd This is a very cool project that I hope will get upstreamed into NixOS proper, eventually.

I always thought InitWare would be good for that. See https://github.com/NixOS/nixpkgs/issues/26850 --- we've been discussing this before NixBSD existed, even!

If you are currently involved in managing packages for a Linux distribution, then you might want to use the instructions outlined in the GitHub repo to help you build packages for your distributions. My colleague James Ward has recently done this for NixOS (you can see his PR here)

You can do this with vanilla Firefox using policies.json[1]. Check out `DisableAppUpdate` attribute.

If you're using Firefox from nixpkgs this is already disabled by default[2].

[1]: https://support.mozilla.org/en-US/kb/customizing-firefox-usi...

[2]: https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/appli...

Ah, this is awesome! I currently run k3s on a decently spec-ed NixOS rig. I tried getting k3s to recognize my Nvidia GPU but was unsuccessful. I even used the small guide for getting GPU in k3s to work in nixpkgs[0], but without success.

For now I’m just using Docker’s Nvidia container runtime for containers that need GPU acceleration.

Will likely spend more time digging into your findings — hoping it results in me finding a solution to my setup!

[0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

- Method 1: doesn't really improve layer caching, but it provides a familiar way (via Dockerfile) to use Nix packages. As with any Dockerfile, the creator is in charge of creating layers and making sure those layers are as small (cleaning cache, ...).

- Method 2: Nix language is used to describe (in a declarative way) what the end image should look like. Layers are then calculated based on the dependency tree (or as Nix calls it, dependency closure). The algorithm that creates layers[1] makes sure that there is higher likelihood of cache hits without the user needing to worry about layers, but you can even roll-up your own algorithm that fits your project better.

- Method 3: Using Flox you would get sort of both. An easy way to configure the final docker image via toml configuration and using Method 2 under the hood.

There are other ways how to improve caching efficiency, but those are very use case specific (eg. big "builder" images) and would probably require a completely separate blog post.

[1] https://github.com/NixOS/nixpkgs/blob/63f0da03a3b2c323ea924b...

I spent a while messing around with https://github.com/ansiwave/nimwave, which I enjoyed but I haven't gotten very far. Though I've been avoiding the front end for so long, I don't know what reasonable feels like in that space anyway.

My Nim journey was stalled by this bug in its nix toolchain: https://github.com/NixOS/nixpkgs/issues/308593. I guess that's the price we pay for straying from the beaten path.

The build will actually fail if Gixy finds any issues.

[1]: https://github.com/NixOS/nixpkgs/blob/nixos-24.11/nixos/modu...

I don't know. Have been using colorbuddy for ages now and it has always done exactly what I want. I don't need the "instant reaload" that lush advertices, doing :source on the colorscheme file, does the same for me to preview changes instantly. This is my theme, in case you need something to start with: - https://github.com/pinpox/nixos/blob/main/home-manager/modules/nvim/lua/config/pinpox-colors.lua

I use this to serve a directory temporarily.

I can't remember why I put that workaround in there, might not be needed any more. The above config is part of my dotfiles, I use my Bose blueutooth headphones by connecting them via the blueman-applet if the don't pair automatically

Here is an example from my config : I'm using an external flake called "matrix-hook", which is a little tool I wrote and have put in a separate flake. It get's included here. I am then passing self to each of the nixosConfigurations here, this allows me to import the module from the external flake in the configuration.nix of the host where I want to use it.

Yep, I have two different modules with defaults for server and for desktop. Host-specific settings are set in the according /machines//configuration.nix file. Most stuff is modularized into modules that can be reuesed and enabled at will.

Yep, I'm using the toJSON function already. The problem I had, was that not all applications use JSON as configuration format. Also the nix code gets very long, if you have to write the whole template as a string, which I find quite unreadable. Mustache is a pretty simple frequently used templating language, here is an example template that get's rendered by the nix code above.

My system uses a uniform colorscheme defined here. Configs for all applications I use read that and use the same colors. The wallpapers are randomly generated by a tool I wrote, it also automatically matches the colorscheme. Icons and symbols are colored the same way for awesomeWM.

In case you are interested I use this and this to generate colorschemes, awesome config and a matching wallpaper

Check out wezterm it has replaced tmux for me. Very active development, fast and just the right amount of features for my taste. It is configured in Lua, so if you are doing that for neovim already, it's another plus. I use it in combination with awesomeWM. My (not very special) config is here if you need something to start with.