6 ms·

I can see the utility of using Nix for managing dependencies of software you're developing, because that can be horrific to deal with and Nix makes it fairly el

by jpe90 5y ago

I can see the utility of using Nix for managing dependencies of software you're developing, because that can be horrific to deal with and Nix makes it fairly elegant to do, depending on what ecosystems it's being used with. Using NixOS to manage your whole system, on the other hand, I don't think I'll ever get behind. Maintaining reproducible builds of my system, while being nice to have, doesn't really solve any problem that I actually have. On the other hand, it introduced a myriad of problems that plagued me on a regular basis before I switched away from it. The first problem I had was that it added steps to a number of tasks I had on a regular basis. For example, updating or adding new extensions to VS code. Because NixOS is immutable, you don't get to benefit from just running a single update or install command within VS code like you would on a normal system. It becomes an annoying series of steps you have to carry out for each operation, all in the name of being convenient to hypothetically down the line. Multiply this by all the tools you use and it gets tiresome. The other issue is that you raise the barrier of entry for every new piece of technology you want to experiment with. Now, in addition to learning how to use any tooling involved with the ecosystem, you have to figure out how to get it to play nicely with Nix. This works very well for some ecosystems, like Haskell, and not well at all for others. I was just getting started with Android development at the time, and just when I thought I had it working nicely with Nix, I would run into a new problem that would need investigation and band-aids. I wish NixOS was more convenient to use than it was in my experience, because it's nice when it works well. But in my case it created more problems than it solved.

jchw 5y ago
I just use VSCode largely like you normally would, with the augmentation that I start it from a nix-shell invocation. It’s not perfectly immutable, but I’m here to do work, not to perfect ideals. I can understand why some wouldn’t like this, it’s definitely not ideal. I think it’s not too bad though, at least for my workflow. I don’t have issues with my configuration breaking. My NixOS configuration hasn’t broken due to updates in months. I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it. My biggest problem with NixOS is the complexity. Nixpkgs is maintenance hell, and the Nix filesystem is so different from standard UNIX-likes that a lot of software plays kinda weirdly with it. The real game changer is definitely the reproducibility though. At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management. If an upgrade does break, being able to rollback at boot is nice. But what is much nicer is simply the feeling of safety I have going in extreme tangents. I can try setting up Pipewire as my system audio daemon, and if I don’t like it, I can revert it like nothing ever happened. If I run into a bug that has a reasonably good patch stuck in code review hell, I can pull it into my local setup with overlays, replaceDependency and fetchpatch. Setting up IOMMU PCI-e forwarding to a VM is pretty hard, and it sucks that the configuration is basically stored in no specific place, not to mention having to memorize everything you touched to get there; on NixOS, this relatively arduous task was reduced down to about 30 lines of Nix combined with finding some IDs for my secondary GPU. Everyone knows that Linux has some serious super powers if you can exploit them; it is truly crazy what Linux is really capable of. With NixOS, I feel like I’ve gotten a lot better at utilizing the super powers Linux has to offer. I just can’t go back to Debian or Arch after this, I’ve tried. Maybe NixOS isn’t the final answer, but I’ll be damned if it’s not a preview of the future.
- jpe90 5y ago
  > It’s not perfectly immutable, but I’m here to do work, not to perfect ideals. I can understand why some wouldn’t like this, it’s definitely not ideal. I think it’s not too bad though, at least for my workflow. This was my train of thought at the time, too. But now you're just using software normally, but with an extra step, and no NixOS benefit. > I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it. It's true, escape hatches exist. But they are solutions to problems you are _creating by using nixos_, which did not occur on a normal FHS system, and require time and energy investments to solve them. And those problems are landmines lurking in every piece of software you will ever adopt in the future. > At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management. I don't doubt this is true. But there is a cost of time and energy to get deep enough in it, and I was unable to convince myself that it was worth it during my time using the OS. I really wish that weren't the case, I love the idea of NixOS, I just can't justify learning it for a singular personal system, because it forces you to have a deep understanding of the Linux-y systems you're encapsulating, and the Nix-y layer on top.
  - jchw 5y ago
    That is fair. And I’d say the last thing I’m trying to do is convince people to use NixOS, rather just explain why I can’t escape it. I definitely understand that it is imperfect and an enormous time investment.
- microtonal 5y ago
  I just can’t go back to Debian or Arch after this, I’ve tried. I have had this feeling for some time as well. NixOS puts you on a power trip -- you can bring up and tear down systems in seconds; you can relentlessly experiment without repercussions; your repositories work reproducibly. But I also learned that whether using NixOS is productive very much depends on what software ecosystems you are working in. When I was primarily doing Rust for work in Emacs, it worked marvelously. When I switched to CLion (for various reasons), cracks started to show. CLion does not work well in combination with nix-shell, so when you switch often between projects, you end up with projects that don't build because you are not in the right environment. Currently, I am doing more Python development, and that is an absolute pain with Nix. You end up needing different sets of package versions (which are not packaged in nixpkgs) in different environments. If you need to change multiple packages in tandem, you want mutable state. The best you can do is to make a FHS environment with buildFHSUserEnv, which kind of works, but is not very smooth. At which point you realize that you are basically fighting the system. Then there are the niches that are not well-covered. Over the past year or so, I have had to do GPU profiling more recently. Last time I tried, the usual NVIDIA tools (e.g. Nsight Systems) worked very badly on NixOS. Of course, it's a big proprietary blob with all kinds of FHS assumptions, but you need to get work done. These are not all failings of Nix or NixOS, it is more that there are a lot of software ecosystems out there that are not really prepared (yet) for an non-FHS, immutable world. but I’ll be damned if it’s not a preview of the future I think for most Linux users, Fedora Silverblue is probably more of a preview of the future. It doesn't have all the features that NixOS provides, but it does have many that matter (immutable base system, atomic upgrades/rollbacks), while going further than NixOS in other departments (verified boot, SELinux, git-like store of blobs). It sticks to FHS, so a lot of existing software continues to work. Edit: this comment is about NixOS on the desktop. I think the server is a completely different story.
Datagenerator 5y ago
Maybe weird, but as NixOS user my dotfiles stay unmanaged. I VFS cache mount an S3 bucket using rclone(1) which gives the same home directory experience on all machines. Normally that would be something NFSv4 could provide, however the advantages of this setup are a) I can access HTTPs from most places without firewall issues b) takes just one binary. (1) https://rclone.org/commands/rclone_mount/ https://rclone.org/commands/rclone_mount/
- jpe90 5y ago
  I ultimately went with unmanaged dotfiles as well, it seemed like the most sane option. I host all mine on github so on NixOS machines I would just clone the repo and symlink to it as needed like I do on regular FHS systems.
pimeys 5y ago
I, like many other NixOS users, fully understand your sentiments. Let me explain why I stick with it and use it in all of my computers. First off, I have a quite special environment for work. I like to customize many aspects of my desktop, and having my environments on other machines to work similarly is a tedious task, especially when having more than two computers you use daily. NixOS solves this issue very well. What makes it hard is how docs are not that great for Nix or NixOS. What all of us have to do is to read other people's dotfiles and the nixpkgs monorepo to understand how things work and what can you do with it. It is extremely hard in the beginning, even for people like me with over 20 years of Linux experience. It took me about six months to finally being able to get it. There are some new terms you hear when you first start using NixOS. One is flakes, that is very vague and academic at first, but when you understand what it does it is almost as hard to go back to Nix without them as it is for seasoned NixOS user to go back to using other operating systems. With flakes, you have two files: - `flake.nix` lists inputs, such as git repositories, of nix build instructions for fetching packages and functions to your system. - `flake.lock` is like your normal `Cargo.lock` that sets the exact commits of all inputs, freezing the versions of all software in your system. This means I can mix things really nicely in my system. I can use the master branch of Sway, the pgtk version of Emacs with Wayland support from the emacs version control (not even master branch) and mix and match things from different NixOS versions. I can even fork the NixOS monorepo, do some changes and add them to all of my systems before my PR gets merged. The `flake.lock`, which I commit to my repository, forces every single computer I have to use exactly these versions of the software with the configuration I give. It will always lead to the exact same result when I `nixos-rebuild switch`. When I want to update my packages, I go to the repo and say `nix flake update`, then switch to the new versions and only if everything worked with the new packages, I commit the `flake.lock` and it works everywhere else the same. The other nice thing I learned, is while at first the nixpkgs feels like a crazy mess and hard to grasp, it is actually one of the best package repositories I've used. Being a package maintainer is easy and a PR that follows good coding standards gets merged to the main repository no matter how experienced Nix developer you are. See my first package I started to maintain: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/pscale/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen... These 23 lines of nix will fetch the package with the given tag from GitHub, check the file download SHA256 sum matches the given, check the vendored libraries SHA256 sum matches the given and then will just use the system `buildGoModule` function to compile the package and put it to your system. When their CI catches changes here, it will build a binary cache for the derivation, so most users won't even need to compile anything, but get a binary derivation with exactly the same result as compiling it by themselves. And it's easy to see what gets added to your system. You can see the repo and read the code. You can use your editor, go on top of `buildGoModule` call and jump to definition, and you can read the definition what the function does. Now some users are running bots that just go through many packages in the nix repo, change the versions and SHA sums if they have updates and automatically generate pull requests, saving the maintainers the work to do it manually. I understand this is not for everyone. But I hope I also could make you understand why there is no way of going back to systems like Arch Linux, Ubuntu, Windows or macOS after getting some proper taste how to do things with NixOS. Here's my config so far: https://github.com/pimeys/nixos https://github.com/pimeys/nixos I'd like to see other configs from nix users too if you're still here!
danielheath 5y ago
I wonder whether a “chrooted distro” would solve that elegantly; essentially, having a debian install where you can put the things it packages well.
- chriswarbo 5y ago
  I run Debian's Chromium package on a 32bit NixOS machine, since cache.nixos.org stopped providing non-essential builds for 32bit a few years ago and I building Chromium from source myself was too slow. My solution was to fetch a Debian filesystem, chroot into it (using proot) and run 'apt-get install chromium'. The result is an immutable Debian with Chromium installed. My chromium executable is then a script which chroots into that filesystem (again using proot) and runs chromium. It's not reproducible, but it's simpler than maintaining a list of all the required .deb files and their SHA256.
- kaba0 5y ago
  You sort of have that with NixOS as well, with eg. steam-run that provides a debian-like chroot and can run most executables. (You can also modify it to include any dependency you like, that will get installed to standard locations)
- d_tr 5y ago
  I have used debootstrap on Arch to install and run Xilinx's Vivado inside an Ubuntu chroot and it worked fine without any configuration.

by jpe90 5y ago

jchw 5y ago

I just use VSCode largely like you normally would, with the augmentation that I start it from a nix-shell invocation. It’s not perfectly immutable, but I’m here to do work, not to perfect ideals. I can understand why some wouldn’t like this, it’s definitely not ideal. I think it’s not too bad though, at least for my workflow. I don’t have issues with my configuration breaking. My NixOS configuration hasn’t broken due to updates in months. I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it. My biggest problem with NixOS is the complexity. Nixpkgs is maintenance hell, and the Nix filesystem is so different from standard UNIX-likes that a lot of software plays kinda weirdly with it. The real game changer is definitely the reproducibility though. At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management. If an upgrade does break, being able to rollback at boot is nice. But what is much nicer is simply the feeling of safety I have going in extreme tangents. I can try setting up Pipewire as my system audio daemon, and if I don’t like it, I can revert it like nothing ever happened. If I run into a bug that has a reasonably good patch stuck in code review hell, I can pull it into my local setup with overlays, replaceDependency and fetchpatch. Setting up IOMMU PCI-e forwarding to a VM is pretty hard, and it sucks that the configuration is basically stored in no specific place, not to mention having to memorize everything you touched to get there; on NixOS, this relatively arduous task was reduced down to about 30 lines of Nix combined with finding some IDs for my secondary GPU. Everyone knows that Linux has some serious super powers if you can exploit them; it is truly crazy what Linux is really capable of. With NixOS, I feel like I’ve gotten a lot better at utilizing the super powers Linux has to offer. I just can’t go back to Debian or Arch after this, I’ve tried. Maybe NixOS isn’t the final answer, but I’ll be damned if it’s not a preview of the future.

jpe90 5y ago
> It’s not perfectly immutable, but I’m here to do work, not to perfect ideals. I can understand why some wouldn’t like this, it’s definitely not ideal. I think it’s not too bad though, at least for my workflow. This was my train of thought at the time, too. But now you're just using software normally, but with an extra step, and no NixOS benefit. > I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it. It's true, escape hatches exist. But they are solutions to problems you are _creating by using nixos_, which did not occur on a normal FHS system, and require time and energy investments to solve them. And those problems are landmines lurking in every piece of software you will ever adopt in the future. > At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management. I don't doubt this is true. But there is a cost of time and energy to get deep enough in it, and I was unable to convince myself that it was worth it during my time using the OS. I really wish that weren't the case, I love the idea of NixOS, I just can't justify learning it for a singular personal system, because it forces you to have a deep understanding of the Linux-y systems you're encapsulating, and the Nix-y layer on top.
- jchw 5y ago
  That is fair. And I’d say the last thing I’m trying to do is convince people to use NixOS, rather just explain why I can’t escape it. I definitely understand that it is imperfect and an enormous time investment.
microtonal 5y ago
I just can’t go back to Debian or Arch after this, I’ve tried. I have had this feeling for some time as well. NixOS puts you on a power trip -- you can bring up and tear down systems in seconds; you can relentlessly experiment without repercussions; your repositories work reproducibly. But I also learned that whether using NixOS is productive very much depends on what software ecosystems you are working in. When I was primarily doing Rust for work in Emacs, it worked marvelously. When I switched to CLion (for various reasons), cracks started to show. CLion does not work well in combination with nix-shell, so when you switch often between projects, you end up with projects that don't build because you are not in the right environment. Currently, I am doing more Python development, and that is an absolute pain with Nix. You end up needing different sets of package versions (which are not packaged in nixpkgs) in different environments. If you need to change multiple packages in tandem, you want mutable state. The best you can do is to make a FHS environment with buildFHSUserEnv, which kind of works, but is not very smooth. At which point you realize that you are basically fighting the system. Then there are the niches that are not well-covered. Over the past year or so, I have had to do GPU profiling more recently. Last time I tried, the usual NVIDIA tools (e.g. Nsight Systems) worked very badly on NixOS. Of course, it's a big proprietary blob with all kinds of FHS assumptions, but you need to get work done. These are not all failings of Nix or NixOS, it is more that there are a lot of software ecosystems out there that are not really prepared (yet) for an non-FHS, immutable world. but I’ll be damned if it’s not a preview of the future I think for most Linux users, Fedora Silverblue is probably more of a preview of the future. It doesn't have all the features that NixOS provides, but it does have many that matter (immutable base system, atomic upgrades/rollbacks), while going further than NixOS in other departments (verified boot, SELinux, git-like store of blobs). It sticks to FHS, so a lot of existing software continues to work. Edit: this comment is about NixOS on the desktop. I think the server is a completely different story.

Datagenerator 5y ago

Maybe weird, but as NixOS user my dotfiles stay unmanaged. I VFS cache mount an S3 bucket using rclone(1) which gives the same home directory experience on all machines. Normally that would be something NFSv4 could provide, however the advantages of this setup are a) I can access HTTPs from most places without firewall issues b) takes just one binary. (1) https://rclone.org/commands/rclone_mount/ https://rclone.org/commands/rclone_mount/

jpe90 5y ago
I ultimately went with unmanaged dotfiles as well, it seemed like the most sane option. I host all mine on github so on NixOS machines I would just clone the repo and symlink to it as needed like I do on regular FHS systems.

pimeys 5y ago

I, like many other NixOS users, fully understand your sentiments. Let me explain why I stick with it and use it in all of my computers. First off, I have a quite special environment for work. I like to customize many aspects of my desktop, and having my environments on other machines to work similarly is a tedious task, especially when having more than two computers you use daily. NixOS solves this issue very well. What makes it hard is how docs are not that great for Nix or NixOS. What all of us have to do is to read other people's dotfiles and the nixpkgs monorepo to understand how things work and what can you do with it. It is extremely hard in the beginning, even for people like me with over 20 years of Linux experience. It took me about six months to finally being able to get it. There are some new terms you hear when you first start using NixOS. One is flakes, that is very vague and academic at first, but when you understand what it does it is almost as hard to go back to Nix without them as it is for seasoned NixOS user to go back to using other operating systems. With flakes, you have two files: - `flake.nix` lists inputs, such as git repositories, of nix build instructions for fetching packages and functions to your system. - `flake.lock` is like your normal `Cargo.lock` that sets the exact commits of all inputs, freezing the versions of all software in your system. This means I can mix things really nicely in my system. I can use the master branch of Sway, the pgtk version of Emacs with Wayland support from the emacs version control (not even master branch) and mix and match things from different NixOS versions. I can even fork the NixOS monorepo, do some changes and add them to all of my systems before my PR gets merged. The `flake.lock`, which I commit to my repository, forces every single computer I have to use exactly these versions of the software with the configuration I give. It will always lead to the exact same result when I `nixos-rebuild switch`. When I want to update my packages, I go to the repo and say `nix flake update`, then switch to the new versions and only if everything worked with the new packages, I commit the `flake.lock` and it works everywhere else the same. The other nice thing I learned, is while at first the nixpkgs feels like a crazy mess and hard to grasp, it is actually one of the best package repositories I've used. Being a package maintainer is easy and a PR that follows good coding standards gets merged to the main repository no matter how experienced Nix developer you are. See my first package I started to maintain: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/pscale/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen... These 23 lines of nix will fetch the package with the given tag from GitHub, check the file download SHA256 sum matches the given, check the vendored libraries SHA256 sum matches the given and then will just use the system `buildGoModule` function to compile the package and put it to your system. When their CI catches changes here, it will build a binary cache for the derivation, so most users won't even need to compile anything, but get a binary derivation with exactly the same result as compiling it by themselves. And it's easy to see what gets added to your system. You can see the repo and read the code. You can use your editor, go on top of `buildGoModule` call and jump to definition, and you can read the definition what the function does. Now some users are running bots that just go through many packages in the nix repo, change the versions and SHA sums if they have updates and automatically generate pull requests, saving the maintainers the work to do it manually. I understand this is not for everyone. But I hope I also could make you understand why there is no way of going back to systems like Arch Linux, Ubuntu, Windows or macOS after getting some proper taste how to do things with NixOS. Here's my config so far: https://github.com/pimeys/nixos https://github.com/pimeys/nixos I'd like to see other configs from nix users too if you're still here!

danielheath 5y ago

I wonder whether a “chrooted distro” would solve that elegantly; essentially, having a debian install where you can put the things it packages well.

chriswarbo 5y ago
I run Debian's Chromium package on a 32bit NixOS machine, since cache.nixos.org stopped providing non-essential builds for 32bit a few years ago and I building Chromium from source myself was too slow. My solution was to fetch a Debian filesystem, chroot into it (using proot) and run 'apt-get install chromium'. The result is an immutable Debian with Chromium installed. My chromium executable is then a script which chroots into that filesystem (again using proot) and runs chromium. It's not reproducible, but it's simpler than maintaining a list of all the required .deb files and their SHA256.
kaba0 5y ago
You sort of have that with NixOS as well, with eg. steam-run that provides a debian-like chroot and can run most executables. (You can also modify it to include any dependency you like, that will get installed to standard locations)
d_tr 5y ago
I have used debootstrap on Arch to install and run Xilinx's Vivado inside an Ubuntu chroot and it worked fine without any configuration.