nixpkgs VS easyeffects

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...

> You also couldn't feasibly do that for derivations that actually build packages, [..] you would have to update all of the affected hashes.

You can actually, changes to stdenv are possible and "just" a lot of work. You will regularly see them between releases or on unstable and they cause mass rebuilds. This doesn't just affect a compiler but also all stdenv tooling as these changes tend to cause rebuilds across nixpkgs. This would be verifiable but it obviously multiples the amount of compute spent.

Hint: If you look at PRs for nixpkgs you will notice labels indicating the required amounts of rebuilds, e. G., darwin:1-10. See for example https://github.com/NixOS/nixpkgs/pull/377186 with the darwin:5001+ label.

https://github.com/NixOS/nixpkgs/pull/372170 is a promising step towards running multiple instances of a service with separate configurations.

That's why I asked about attitude, not anything else.

"I release my code under FOSS license, but if anyone distribute it in a way I consider not nice, I will re-license it just to screw them over." [1]

When I was considering using HA and was casually browsing community discussions, there were many posts gave me similar feeling like above case. There were other technical reasons that I decided to not to use HA, but this certainly left a really bad taste in my mouth.

1. https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...

Next, let's talk about what pkgs = import nixpkgs { inherit system; }; does. The import function takes in a path, and evaluates it if it is a path to a Nix file, or evaluates the default.nix file within the directory if it is a path to a directory (which is the case when a flake reference, like nixpkgs is passed to import), and returns the evaluation. Since nixpkgs points to the nixpkgs flake, which is a directory, it evaluates the default.nix file present within the flake, which in the case of nixpkgs returns a function accepting, among others, an argument for the current system, which is what we have passed to it. It then returns the set of packages for that system, which is what is bound to pkgs.

Linux: EasyEffects (free and open-source)

For DSP, we already can do that using something like Easy Effects[1][2].

The biggest issue is acquiring proper impulse-response data. In theory, it has to be tuned per-model, so turning basically require pro-grade equipment and a recording studio. However, apparently many people assume Dolby is using the same profile for all laptops, so just copy-paste the same file here and there. Not really sure which is the real case.

Anyways, Asahi can ship DSP turned on by default because the distro is specific to Apple. That's how Apple boosts the quality of its hardware, and the same applies to a distro dedicated to it.

[1]: https://github.com/wwmm/easyeffects

- Easy Effects: Effects for PipeWire applications; configure your speakers & microphones (e.g. noise reduction filter)

Easyeffects maybe.

EasyEffects could be a replacement for EqualizerAPO. You can do some gain staging there if you want, as well as a bunch of other stuff.

Is this a general comment meant to apply to anything or are you specifically talking about Easy Effects here?

It has installation instructions in the README, links to a wiki page with more information (https://github.com/wwmm/easyeffects/wiki/Package-Repositorie...), the application contains full documentation under the "Help" item in the menu (as many applications do) and they also have the same documentation online (https://wwmm.github.io/easyeffects/).

Not sure what more you could ask for?