2 ms·

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

by 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.
- kohlerm 5y ago
  Another approach is to use a main stream distribution in combination with the nix package manager. You can then always fall back to the distributions native packages.
CyberShadow 5y ago
> I just can’t go back to Debian or Arch after this, I’ve tried. I tried to solve many of the same problems in Arch Linux with aconfmgr. It attempts to achieve reproducibility by using a model where the state of the entire system must be represented in the configuration file, and it helps transcribe any changes back to the configuration (unlike classic configuration managers, which only manage what is declared).
- jchw 5y ago
  Thanks, this is cool. I still have one machine running Arch, maybe I’ll give this a spin some time.

by jchw 5y ago

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.

kohlerm 5y ago
Another approach is to use a main stream distribution in combination with the nix package manager. You can then always fall back to the distributions native packages.

CyberShadow 5y ago

> I just can’t go back to Debian or Arch after this, I’ve tried. I tried to solve many of the same problems in Arch Linux with aconfmgr. It attempts to achieve reproducibility by using a model where the state of the entire system must be represented in the configuration file, and it helps transcribe any changes back to the configuration (unlike classic configuration managers, which only manage what is declared).

jchw 5y ago
Thanks, this is cool. I still have one machine running Arch, maybe I’ll give this a spin some time.