Perhaps dumb questions inbound ;)

I use Arch because I’m strapped for time and my system is always moving.

  • 2 minutes to install something? AUR probably has it.

  • Ten minutes of free time to look for a software that fits a new need? Try random AUR things (auditing PKGBUILDs is just twenty seconds or so).

  • If I need a tiny patch, I’ll just add a sed or patch file to the PKGBUILD. (Super easy, you barely learn any syntax cuz it’s intuitive shell.)

  • make && make install/meson blahblah usually just works.

  • Wiki does the thinking for me if I need something special (e.g. hw video acceleration)

Buuuut update surprises can be a pain (e.g. Pipewire explodes Saturday evening) and declarative rollbackable immutability sounds really freakin’ AWESOME, so I’m considering NixOS for my new laptop (old one’s webcam broke). So I ask:

  • How much can I grok in a week?
    • I need to know Nixlang, right? I have a ton of dotfiles and random homemade cpp commands in ~/.local/bin that I use daily
  • How quick is it to make a derivation?
    • I make install a lot, do I need to declare that due to non-FHS? Can I boilerplate the whole thing with someone else’s make install and ctrl+c ctrl+v? How does genAI fare? (Lemmy hates word guess bots, I know)
  • How quick is it to install something new and random?
    • Do I just use nix-shell if I need something asap? Do I need to make a derivation for all my programs? e.g. do I need to declare a Hyprland plugin I’m test-running?
  • How long do you research a new package for?
    • On Gentoo I always looked up USE flags (NOO my time); on Arch I just audit the PKGBUILD and test-run it (20 seconds); on Ubuntu I had to find the relevant PPA (2 minutes). What’s it like for Nix?
  • Can you set up dev environments quickly or do you need to write a ton of configs?
    • I hear python can be annoying. Do C++/Android Studio have header file/etc. issues?
  • What maintenance ouchies do you run into? How long to rectify?
  • Do I need to finagle on my own to have /boot encrypted?
    • I boot via: unencrypted EFI grub asks for LUKS password -> decrypt /boot, which then has a keyfile -> decrypt and mount btrfs root partition. But lots of guides don’t do it this way

Thanks for bearing with me ദ്ദി(｡•̀ヮ<)~✩‧₊

  • algernon
    23·
    2 months ago

    I’ve been daily driving NixOS for about a year now, switched from over two decades of running Debian. I’ll try to answer your questions from my perspective:

    How much can I grok in a week?

    If you have some experience with functional programming or declarative configs (think Ansible), then it’s a lot easier. You can definitely learn enough in a week to get started. One year in, my Nix knowledge is very light still, and I get by fine. On the other hand, there’s a lot of Nix I simply don’t use. I don’t write reusable Nix modules, and my NixOS configuration isn’t split into small, well manageable files. It’s a single 3k lines long, 130k sized flake.nix. Mind you, it’s not complete chaos: it is generated from an Org Roam document (literate programming style; my Org Roam files are 1.2mb in size, clocking in at a bit below 10k lines).

    With that said, it took me about a month of playing and experimenting with NixOS in a VM casually, a couple of hours a week, to get comfortable and commit to switching. It’s a lot easier once you switched, though.

    How quick is it to make a derivation?

    For most things, a couple of minutes tops. I found it easier to create derivations than creating Debian packages, and I was a Debian Developer for two decades, had a lot more and lot deeper understanding of Debian packaging practices. It’s not trivial, but it’s also not hard. The first derivation is maybe a bit intimidating, but the 10th is just routine.

    Regarding make install & co, you can continue doing that. I use project-specific custom flakes and direnv to easily set up a development environment. That makes development very easy. For installing stuff… I’d still recommend derivations. A simple ./configure && make && make install is usually very easy to write a derivation for. And nixpkgs is huge, chances are, someone already wrote one.

    How quick is it to install something new and random?

    With a bit of self control and liberal use of direnv & flakes, near instant.

    How long do you research a new package for?

    https://search.nixos.org/packages, you can search for a package, and you can explore its derivation. The same page also provides search for NixOS options, so you can explore available NixOS modules to help you configure a package.

    Can you set up dev environments quickly or do you need to write a ton of configs?

    Very easy, with a tiny amount of practice. Liberal use of flakes & direnv, and you’re good to go. I can’t comment much on Python, because I don’t do much Python nowadays, but JavaScript, Go, Rust, C, C++ have been very easy to build dev environments for.

    What maintenance ouchies do you run into? How long to rectify?

    None so far. If it builds, it usually works. I do need to read release notes for packages I upgrades, but that’s also reasonably easy, because I can simply “diff” the package version between my running system, and the configuration I just built: I can see which packages were upgraded, and can look up their release notes if need be. In short, about the same effort as upgrading Debian was (where I also rarely ran into upgrade/maintenance gotchas).

    Do I need to finagle on my own to have /boot encrypted?

    If you use the NixOS installer, then yeah, you do have to fiddle with that a bit more than one would like. If you install via other means (eg, build your own flake and use something like nixos-anywhere to install it), then it’s pretty easy and well supported and documented.

    Feel free to ask further question, I’m happy to elaborate on my experience so far.

    • a Kendrick fan
      3·
      2 months ago

      With that said, it took me about a month of playing and experimenting with NixOS in a VM casually, a couple of hours a week, to get comfortable and commit to switching. It’s a lot easier once you switched, though.

      yeah, OP should probably setup NixOS in a vm first and apply all their configs in there

    • fool@programming.devOP
      2·
      1 month ago

      So instead of commenting inside of nix files, you put nix files into .org documents and collate them so you can make your nix files an OS and a website and a zettelkasten-looking set of linked annotated nodes.

      That puts a stupid grin on my face (ᐖ )

      Dammit I was sure I was just going to stick with Arch until I saw this

      Questions:

      • You have home on tmpfs. Isn’t that volatile? Where do you put your data/pictures/random git projects? Build outputs? How’s your RAM? (Sorry if I’m missing something obv)
      • What’s your bootup like?
      • Another commenter mentioned difficulties in setting up specialized tools w/o containerizing, and another mentioned that containers still have issues. Have you run into a sitch where you needed to workaround such a problem? (e.g. something in wine, or something that needs FHS-wrangling)
      • algernon
        3·
        1 month ago

        So instead of commenting inside of nix files, you put nix files into .org documents and collate them so you can make your nix files an OS and a website and a zettelkasten-looking set of linked annotated nodes.

        Yup! And writing it in Org allows me to structure the configuration any way I like. It makes it a whole lot easier to group things that belong together close to each other, and I never have to fight the Nix language to do so. I can also generate easily browsable, rich documentation that explains what’s what and why, which helps me tremendously, because a year after I installed and configured something, I will not remember how and why I did it that way, so my own documentation will help me remember.

        Generating code from docs (rather than the other way around) also means that I’m much more likely to document things, because the documentation part is the more important part. It… kinda forces a different mindset on me. And, like I said, this allows me to structure the configuration in a way that makes sense to me, and I am not constrained by the limitations of the Nix language. I can skip a tremendous amount of boilerplate this way, because I don’t need to use NixOS modules, repeating the same wrapping for each and every one of them. Also feels way more natural, to be honest.

        You have home on tmpfs. Isn’t that volatile? Where do you put your data/pictures/random git projects? Build outputs? How’s your RAM? (Sorry if I’m missing something obv)

        It is volatile, yes, in the sense that if I reboot, it’s lost. I am using Impermanence, for both /home and /. The idea here is that anything worth saving, will be recorded in the configuration, and will be stored on a persistent location, and will get bind mounted or symlinked. So data, pictures, source code, etc, live on an SSD, and they get symlinked into my home. For example, the various XDG userdirs (~/Downloads, etc), I configured them to live under ~/data, and that dir lives on persistent storage and gets symlinked back.

        My root and /home are both set to 128Mb, intentionally small, so that if anything starts putting random stuff there, it will run out of space very fast, and start crashing and complaining loudly, and I’ll know that I need to take care of it: either by moving the data to persistent storage, or asking whatever is putting stuff there to stop doing that. My /tmp (where temporary builds end up) is 2Gb, and sometimes I need to remount it at 10gb (hi nerdfonts!), but most of the time, 2g is more than enough.

        I have 32Gb RAM, but only ~2.5g is used for tmpfs purposes (2g of it on /tmp itself), and most of the time, the majority of that is unused and as such, available for other things. My wife’s laptop with 16Gb RAM uses a similar setup, with 512mb for /tmp, and that works just as fine.

        I do have 64Gb of swap on a dedicated SSD, though, and that helps a lot. I currently have 3GB ram free, and 37G of swap used, but don’t feel any issues with responsiveness. I don’t even know what’s using my swap! Everything feels snappy and responsive enough.

        What’s your bootup like?

        A few seconds from poweron to logging in. By far the slowest part of it is the computer waiting for me to enter my password.

        ❯ systemd-analyze
Startup finished in 8.667s (kernel) + 29.308s (userspace) = 37.975s
graphical.target reached after 29.307s in userspace.

        Looking at systemd-analyze blame and systemd-analyze critical-path, most of that userspace time is due to waiting for the network to come online (18s), and for docker to start up (7s). Most of that is done parallel, though. Boot to gdm is waaay faster than that.

        Another commenter mentioned difficulties in setting up specialized tools w/o containerizing, and another mentioned that containers still have issues. Have you run into a sitch where you needed to workaround such a problem? (e.g. something in wine, or something that needs FHS-wrangling)

        I haven’t run into any issues with containers, and I’m using a handful of them. docker, podman, flatpak all work fine out of the box (after setting up permanent storage for their data, so they don’t try to pull 10gb containers into my 128mb root filesystem :D). Wine… I’m using Wine via Lutris to play Diablo IV, and it has worked without issues so far out of the box, I didn’t have to fight to make it work.

        I did run into a few problems with some stuff. AppImages for example require running them with appimage-run, but you can easily set up binfmt_misc to automatically do that for you, so you can continue your curl https://example.com/dl/Example.AppImage -o Example.AppImage && chmod +x Example.AppImage && ./Example.AppImage practices after that.

        There’s also cases where downloaded binaries don’t work out of the box, because they can’t find the dynamic linker. I… usually don’t download random third party binaries, so I don’t often run into this problem. The one case where I did, is Arduino tooling. I have a handy script in my (arduino-powered) keyboard firmware to patch those with patchelf. But if need be, there’s buildFHSEnv, which allows us to build a derivation that simulates an FHS environment for the software being packaged. So far, I did not need to resort to that. Come to think of it… using buildFHSEnv would likely be simpler for my keyboard firmware than the patching. I might play with that next time I’m touching that repo.