Came across a new nix wiki attempt. The announcement post is made on discourse with high skepticism.

But I really like it for two reasons:

• For now, its incredibly informal and the barrier to entry is low. And because I can make edits directly in the web interface, it felt easy to contribute.
• The creator mentions wanting this to be like the Arch wiki. In other words, contain information useful to nix users, but not necessarily nix specifically.

I was able to contribute a new article about distrobox, a tool I discovered and made a post about here a month or so ago.

Maybe we don't "need" another wiki, but the opportunity to contribute really made this one stand out to me. In case you all might want to contribute or learn something, I thought I would share.

I'm conflicted on what should handle my login manager, desktop environment, and window manager. What are the pros and cons of doing it from a nixos configurations versus a home manager configuration?

I want to use Plasma-manager in my system. I have enabled flakes in configurations. Now what to do to use it. The output generated by tool rc2nix can be copied through terminal but when i put that in home.nix , it says that plasma is not available which is true but then how do I use this tool. flake file.

I've made a fun little project inspired by this (except it's not updated any more).

It provides easy instructions for installing old versions of packages, it takes them straight from the official nixpkgs repo.

Example: https://history.nix-packages.com/package/dotnet-sdk_3/3.1.426 (.NET SDK 3.1 actually prompted the creation of this tool, I needed it for one old project).

Each detail page provides instructions on how to install the package using nix-shell, nix-shell with shell.nix file, configuration.nix and nix-env.

The design is based on https://search.nixos.org (because I suck at graphical design).

Do let me know what you think!

I made a post a while ago asking what you do when NixOS isn't cutting it. You need a package that isn't available as a flatpak/appimage or already in nixpkgs. You don't want to build from source, because it's either too difficult or too time consuming. One suggestion was containerization or virtual machines, but those seemed too cumbersome. Well, distrobox is the tool that fixes it.

Distrobox is a shell script that wraps over docker/podman to run a container of a distribution of your choice. But it does it behind a very high level API, and integrates the container environment seemlessly with your host environment. It is seriously as easy as this, if you need to install something with apt inside debian.

$ distrobox create -n my_debian --image debian:latest
$ distrobox enter my_debian

And bang, your in a debian container and it won't even feel like it. It automatically integrates your shell environment and maps your root directory inside the container (or something like that.) You seriously wouldn't know unless you neofetch. Best part is that since everything is in the nix store, every program in your environment should work, for the most part, inside this container. I've not noticed problems yet.

Tada! apt is available in this environment and you can install what you need. Then you can run it while inside the container. From the host machine, outside the container, you can run it directly too. Say you installed program X in debian:

$ distrobox enter my_debian -- X

And it will just run the command and send you back to the host machine.

In the case of docker, you can type docker ps and it will show you your debian image my_debian listed.

There's two more things I want to do to really polish this workflow. The first is to change my shell prompt so I know that I'm actually in debian without typing neofetch! Inside the box the variable CONTAINER_ID is set and the hostname is modified. I've adjusted my starship prompt to look like this when inside the box:

distrobox:my_debian ~ $

And lastly, I really want to blur the lines. If I install X in debian, I want to just call it directly from the host as X, not invoke my debian instance with distrobox enter.

When you type X and the program is missing, bash (and fish and zsh I'm sure) runs a hook that you can look at by typing

$ declare -p -f command_not_found_handle

By overriding this, you could first have it try the inside container if it can't find the application in the host container, like so.

command_not_found_handle () {
  distrobox enter my_debian -- $@
}

This is not a perfect solution, but I'm still experimenting with how to integrate this both seamlessly and also not accidentally run things inside debian and not realize it. If you have suggestions for how to improve handling calling commands from the outside environment, please share. Best case might just be adding aliases for programs explicitly. For example, `alias X=distrobox enter my_debian -- X.

Anyway, distrobox is the solution! This is one more barrier removed that was preventing me from moving my main computer over to NixOS. I'm so happy to have found this and wanted to share.

I was trying to use a flake with nix-pkg to set up a flutter dev environment but it just wouldn't stick, and a lot of the examples online are quite old and not documented well for a nix noob like myself.

Cheers folks!

I've been hearing a lot about it lately and I'm intrigued, but also utterly confused.

Is this a Linux distro I'd install on bare metal because it offers a new way of package management that addresses the issues other distros have?
Is it something I install in the distro I currently use?
How does it work and what does it do?

I've tried to read https://nixos.org/guides/how-nix-works but the first sentence is

"Nix is a purely functional package manager. This means that it treats packages like values in purely functional programming languages such as Haskell"

and that's where it lost me. Thanks for helping me understand!

My server is currently running fedora and it has a encrypted raid attatched. Now i wanna move my server to nixos but i cant find anything on how to automount it. Any advice ? Thanks for your time and have a nice day!

I've been spending a couple weeks unable to modify my system, because using my window manager was ungodly slow (like 1fps.) Luckily NixOS lets you pick a previous generation to load so I could make changes, build a new generation, and try again.

It took me too long to find, but I realized I had both the x session managed by both nixos and home manager. Removing this fixed the problem. I assume this had 2 xsessions open and they were competing for resources or something. Be cautious! :)

Every now and then I see a program that doesn't have a default.nix or flake.nix in the source, doesn't have an entry in nixpkgs, and otherwise can't find a derivation for. So I write them myself.

What's the best way to share these? Should I contribute to nixpkgs? (does this count if I'm making flakes?) Do I maintain a single repo for each program? Or do I create a repo with a collection of flakes? Something else?

Used nix last year but dropped it after home-manager decided to unlink the apps from the Applications directory.

How is the current situation on usability of nix-Darwin + home-manager + brew?

Packages still fails to get indexed correctly in spotlight? I really like a fully repro environment but the fact that the usu ability was low bothered me a lot.

I recently wanted to try out (aider)[https://aider.chat], and ran into a problem that I continually run into: how do I install one-off, experimental software into my environment, without being a nix master, or spending an extreme amount of time on every new package.

In this case, it is a new python package available in pip. It isn't available in nixpkgs, and isn't nixified. pip2nix doesn't work on arm64 Macs (bug here)[https://github.com/nix-community/pip2nix/issues/88], so I can't use that to try and create a flake that works with this package. It isn't using poetry, so poetry2nix is out.

How are you dealing with this problem? Are you all experts in nix, and writing flakes for every piece of software that you want to play around with? Do you have a "dirty" part of your environment that you install this kind of stuff into? (I looked into using pipx to install this, however that (also has a bug)[https://github.com/NixOS/nixpkgs/issues/171429] in nixpkgs.)

Thoughts?

Hi there! I'm trying to make php and composer work. I have this in environment.systemPackages:

    (pkgs.php82.buildEnv {
      extensions = ({ enabled, all }: enabled ++ (with all; [
        xdebug
        redis
      ]));
      extraConfig = ''
        memory_limit=2G
        xdebug.mode=debug
      '';
    })
    php82Extensions.redis

The problem is that while running php -m correctly prints that redis extension is installed, composer does not, because it uses a different php:

• file $(which php) prints the path /nix/store/igx8j4qjxy9jyj8kjyccwarnzqq5vsml-php-with-extensions-8.2.9/bin/php
• cat $(which composer) shows that it's a wrapper for '/nix/store/lv4prxa52zifr54ws56iz3b9kdhs1b5w-php-with-extensions-8.2.9/bin/php' --add-flags '/nix/store/avqj0662f4gg2s875zlbbjajx6fm6bl0-php-composer-2.5.5/libexec/composer/composer.phar'

Note that the path to php is different. Is there any way to correct it on my side? I'd like to avoid having to install composer manually

Hi all, I've been getting into nix lately (I've been posting here frequently) and wanted to know what projects everyone is working on. Are you trying to integrate nix into an existing project? Contribute to nixpkgs? Experiment with your configs?

Short video from Vimjoyer on how to setup a firefox install using home manager and flakes. In particular, the focus of this video was how to use an external flake as a source for firefox extensions, since they aren't available in nixpkgs.

I came across this article when wondering how to integrate the "building" aspect of nix (that is, not just a devshell) with static websites or other projects that involve some output that is not an executable.

This article also talks about adding inputs from GitHub that aren't necessarily flakes. I've used this myself to pull some example configurations for certain programs that I haven't felt like tinkering with myself yet.

I'm been wanting to move over my main desktop for almost a year now. But from 3+ years of tinkering, installing applications, and configurations Ive been super hesitant. The jump from Ubuntu to NixOS would be a big one. I have a laptop running nixos thats given me some exposure to the nix language, but when it comes to my main rig, I still have the worry of "what if something I need wont be available?" and "what if I forget something?"

Well I finally tried home manager and wow, its the absolute perfect way to slowly transition to nixos. I'm slowly going through my package managers (cargo, npm, pip, apt, snap) and checking for applications that I can just drop into my home.nix. And every now and then I see an app I cant install (say, vtracer from cargo, very cool app). Well, I just make a mark and eventually I'll build my own derivation around it.

Home manager has been easing my worries as I make the transition. For those of you also unsure, I recommend integrating with home manager. You can do such small jumps at a time, no need to go full blown nix all at once.

Interesting idea.

tl;dr image buildable with some patches

South California Linux Expo is looking for papers.

I have a config that I share on github. I share the whole thing and there are keys in it but they are obviously not the complete key (as is standard throughout the community). Just enough to point to the real key with Nix.

Anyway, I have finally gotten around to learning the power of git-crypt. Today, I went through my whole config and took everything out that could even remotely be used by a hacker to find out security holes in my config (permitted insecure packages, specific hardware ID's, github username and email address, for example all went into nix files into the secrets folder with imports where they used to reside) and put those files into a folder at top level called secrets. Then, I encrypted all of the files in that folder and pointed the rest of the config to them so they remain encrypted on my github but perfectly usable in evaluation and build of my config derivation.

My question is: Have I done something clever that will significantly decrease the chances of exploit or do you recommend that everyone does this and I'm just late to the security party?

If this technique is just standard, what else could one do to harden their system without causing difficult to solve issues on deployment of their config? For example, I now need to decrypt that folder when I use that config on a new system and anyone else building it wouldn't be able to get through the evaluation.

I've heard of Sops-Nix and other such security handlers. How can I use sops-nix to aid in that initial git-crypt setup when I spin up a new system, for example?