NixOS

Meaning, VMs with Xen and hardware virtualization support

The system VM/Qube for USBs is isolated, the Network VM/Qube is separate and isolated, the windowing system and OS housing the qubes is isolated....

And being able to configure all of those with Nix would be a wet dream come true

cross-posted from: https://discuss.tchncs.de/post/22577290

Self-hosted photo and video management solution

cross-posted from: https://discuss.tchncs.de/post/22480304

cross-posted from: https://discuss.tchncs.de/post/22424459

cross-posted from: https://discuss.tchncs.de/post/22424275

NixOS Facter aims to be an alternative to projects such as NixOS Hardware and nixos-generate-config. It solves the problem of bootstrapping NixOS configurations by deferring decisions about hardware and other aspects of the target platform to NixOS modules.

cross-posted from: https://infosec.pub/post/15780978

Am I out of touch?

No, it's the forward-thinking generation of software engineers that want elegant, reliable, declarative systems that are wrong.

Had a lot of headaches the last week or two trying to optimize star citizen as well as fix a vulkan RHI bug which was affecting unreal engine games.

Apparently rolling release schedules (like NixOS23.05, 23.11, 24.05...) are better for servers since they're less prone to change, where as nightlies like for the unstable Branch are better for gaming since those latest drivers are likely the current ones for a newly released game

This idea is inspired by nixos-mailserver. It was so easy to spin up the mailserver after changing some DNS records and putting in some settings. I thought it might be a good idea to do the same for services that need public, decentralized infrastructure to support. Some ideas include

• Tor relay, or exit node
• Encrypted messaging nodes. It looks like SimpleX chat relies on SMP servers to relay communication
• Crypto miners (I know, I know, but you understand how it fits the "public contribution" usecase)
• Search engines like searxng (I currently use a public instance)
• Libredirect services, like proxy clients for social media

Maybe federated services, but those require more than just the software running on the public internet. Those require moderation and long term maintenance. Ideally, the services in this config would be ephemeral.

Does this sound like a good idea? Would you spin one of these up on a $10 VPS? I understand that this is the NixOS community, not necessarily the privacy community, but I figured thered be overlap.

What other services do you think would be applicable?

Went through the pain of packaging a python project on Nixos. Here's some issues I hit, and how I got lucky resolving them. I feel the most reliable way of doing this in the future is to use docker and just imperatively build.

Here's how I got web drivers, AI dependencies, gpu dependencies, and an api dependency bundled together into an ephemeral shell for python development, on NixOS 23.11

0. Enable Flakes

1. Start with setting up poetry2nix

2. Get the template flake by running nix flake init --template github:nix-community/poetry2nix

3. in the flake.nix, sometimes changing projectDir = self to projectDir = ./. fixed some issues

4. in your terminal, run nix develop . to build the poetry app with python packages described in pyproject.toml

5. By default, just poetry and python latest should be installed. the dependencies for the project (which gets reflected in the pyproject.toml) are updated with poetry add, such as poetry add numpy selenium scikit-learn

6. Exit out of the ephemeral shell from nix develop ., and rerun to have poetry2nix rebuild and link the newly declared packages

Poetry2nix has worked pretty well for the more obscure python packages, but failed in others. For example, sentence-transformers would depend on maturin, which would fail to link setuptools. If poetry doesn't work, you can try and get the package from nixpkgs, or specify sha256s from pypi.org

Here's an example of what I added to my flake.nix to get gpu acceleration, sentence-transfomers, firefox drivers for selenium, and other packages poetry failed to setup:

packages = [ pkgs.poetry pkgs.python311Packages.sentence-transformers pkgs.firefox 
            pkgs.python311Packages.openai pkgs.python311Packages.yt-dlp pkgs.python311Packages.pyopencl
];

was added to this flake.nix, as in,

{
  description = "Application packaged using poetry2nix";

  inputs = {
    flake-utils.url = "github:numtide/flake-utils";
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    poetry2nix = {
      url = "github:nix-community/poetry2nix";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
  outputs = { self, nixpkgs, flake-utils, poetry2nix }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        # see https://github.com/nix-community/poetry2nix/tree/master#api for more functions and examples.
        pkgs = nixpkgs.legacyPackages.${system};
        inherit (poetry2nix.lib.mkPoetry2Nix { inherit pkgs; }) mkPoetryApplication;
      in
      {
        packages = {
          myapp = mkPoetryApplication {
            projectDir = ./.;
          };
          default = self.packages.${system}.myapp;
        };
        devShells.default = pkgs.mkShell {
          inputsFrom = [ self.packages.${system}.myapp ];
          packages = [ pkgs.poetry pkgs.python311Packages.sentence-transformers pkgs.firefox 
            pkgs.python311Packages.openai pkgs.python311Packages.yt-dlp pkgs.python311Packages.pyopencl
          ];
          nativeBuildInputs = [(
            pkgs.python311Packages.buildPythonPackage rec {
              pname = "serpapi";
              version = "0.1.5";
              src = pkgs.python311Packages.fetchPypi {
                inherit pname version;
                sha256 = "b9707ed54750fdd2f62dc3a17c6a3fb7fa421dc37902fd65b2263c0ac765a1a5";
              };
            }
          )];
        };
      });
}

There was one package (serpapi), which was not in nixpkgs, and poetry failed as well. Adding this to native build inputs got serpapi installed

nativeBuildInputs = [(
            pkgs.python311Packages.buildPythonPackage rec {
              pname = "serpapi";
              version = "0.1.5";
              src = pkgs.python311Packages.fetchPypi {
                inherit pname version;
                sha256 = "b9707ed54750fdd2f62dc3a17c6a3fb7fa421dc37902fd65b2263c0ac765a1a5";
              };
            }
)];

All in all, it works, and I have no doubt I've made a reproducible environment. What attracts me is I've never had an easier time setting up cuda/cudnn/tensorrt/... system drivers have been near effortless, and much faster to setup than on debian. Tools like sentence-transformers and torch default to packages which leverage the GPU.

What pushes me away, is I've had failures in each of the three methods for specifying package dependencies, even though one of the three eventually was the fix for integrating the dependencies into my shell. For now, I'll stick with it, but it's hard for me to suggest to a team we use this in development

cross-posted from: https://feddit.de/post/7895009

I'm a semi-recent NixOS user and one thing that bothers me since the beginning is that when I change the Gnome theme (between light and dark), Firefox doesn't adapt. The system theme in Firefox is enabled, but it always displays the light theme, no matter what theme is selected in Gnome.

Internet search, including searching through NixOS discourse, packages, options and Nixpkgs repo surfaced a solution.

Any ideas or tips how to achieve system theme integration for Firefox on NixOS?

NixOS 23.11 / Gnome 45 / sway

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.