Skip to content

Instantly share code, notes, and snippets.

@PgBiel

PgBiel/how-i-would-improve-nixos.md

Last active August 22, 2024 22:18
Show Gist options
  • Save PgBiel/adbb1660e390f479806d6d2887432b0f to your computer and use it in GitHub Desktop.
Save PgBiel/adbb1660e390f479806d6d2887432b0f to your computer and use it in GitHub Desktop.
Download ZIP
How I would improve NixOS
Raw
how-i-would-improve-nixos.md

How I would improve NixOS (2024-08-22)

Hello! I'm Pg (GitHub: PgBiel). I wanted to share some thoughts about NixOS and Linux to the world - originally to the Gleam community, but this got a bit longer than I expected, so I made this Gist.

Normally this would be a blog post or similar, but I don't have a blog at the moment and I really wanted to write this down, so a Gist will do for now :)

I'll assume the reader is minimally familiar with concepts related to Linux distributions. You can learn more about NixOS here: https://nixos.org/

Observations

I've recently been thinking a bit about NixOS and the state of Linux distros in general and, in many ways, it seems like NixOS has several ideas which are far ahead of other distros. Most importantly:

  • Package management is basically solved, thanks to the Nix package manager - no conflicts, full reproducibility, easy rollback etc. due to immutability and separation between packages
  • Declarative and centralized system config is a great way to manage system settings, especially because it's easy to reverse bad changes, and of course it also becomes much easier to migrate your system configs elsewhere
    • As a result, system settings are more integrated and don't rely on multiple config files and their syntaxes
    • It also allows (at least in theory) for easy sharing of system config modules, e.g. I could write a module for easy installation and configuration of a certain program or certain drivers and anyone could (again in theory) easily add and configure this module in their system
    • As I see it, this is the killer feature that sets NixOS apart from immutable distros like Fedora Silverblue1 and OpenSUSE MicroOS2, which offer less flexibility in principle.
  • The NixOS community is very active and it's difficult to find a match in the software world to the huge amount of frequent contributions to nixpkgs. You can be sure most of your system will stay up-to-date.

On the other hand, at least for desktop usage, it has some pretty well-known problems, usually related to UX. I won't go into too much detail, but here's what I want to highlight here:

  • Onboarding: Getting started with the distro can be a pretty frightening endeavor, as you need to learn Nix and several concepts related to it (and the Nix ecosystem is huge, including nixpkgs, flakes etc., so it can be hard to gauge what you need and don't need to learn), whereas the learning resources are pretty spread out across blogs, wiki, forums, Gists and so on.
    • In general, Nix has a lot of non-trivial quirks and, while the amount of good community-made learning materials has only been increasing (including high-quality manuals, books3 and the newly-refreshed wiki4), I personally think great improvements to the onboarding experience are still needed, related not only to the discoverability of those materials, but also coverage of topics and specific use cases.
    • Ideally, many of the quirks would be automatically handled by the distro on install or have a ready-to-use / 1-click solution as well, where possible. For example, nix-ld5, which allows for wider compatibility with programs made for other Linux distros when using NixOS, could be enabled by default for desktop (i.e. non-server) installs.
    • It's worth mentioning that Nix doesn't necessarily take the blame for all of its quirks - oftentimes this is just inevitable friction due to how it works differently from the rest of the Linux world.
  • The Nix Language: Nix (the language) is relatively simple and works quite well for simple K=V system config, but as soon as slightly more complicated logic is needed (which is not usually what typical end users do, but rather mostly power users and those who write system config modules), it can prove itself unwieldy - it has Haskell-like syntax and interesting functional programming concepts, but the lack of static typing, tail-call optimization for recursion, and all other goodies from FP really hinder dev experience.
    • This means people have less of an incentive - and even less tools - to write high-quality shareable system configuration. Nix language servers, for example, have been evolving over time (with the latest developments happening in the impressive nixd tool), but still can't be compared to a full-blown statically-typed language LSP in terms of autocomplete, correctness, speed etc., mostly due to limitations in Nix itself.
    • It is worth mentioning that there is some merit in avoiding having too strict of a type system for a configuration language, but I'm thinking more of the experience when writing system modules with conditional logic, reusable components and the like. This problem also presents itself when writing shell.nix / flake.nix files for projects in general as well, but this isn't directly related to NixOS (my current focus) in principle.
    • One important aspect of this problem, which can affect typical end users, is the debugging experience - sometimes an external module is misconfigured or some workaround suggested online has subtle problems, which can lead your system configuration to have a very hard to debug "infinite recursion" error, or some other configuration error with a long stack trace. I've found Nix's errors to be quite obtuse in general.
  • Time and effort: Overall, what I've noticed as a consequence is that, if you want to use NixOS' amazing capabilities to their full extent, having a lot of patience and dedication, as well as time available, is essential.
    • I've observed a few people I had previously recommended NixOS to feel forced to abandon or otherwise not use it because they felt they were "holding it wrong"6 and just couldn't find the time to navigate the wiki, forums etc. in order to solve their problems in a satisfactory way, which is part of my concern here.
    • In my own NixOS setup, I have personally optimized for the least maintenance possible by using Flatpak (which simulates typical Linux distros' environments) and sometimes containers or VMs, avoiding using Nix for several tasks, while keeping the base OS fully specified in my config. This allows me to reap most of NixOS's advantages, while also having less headaches related to incompatible programs and whatnot.
    • The initial setup took about two weeks to get to a minimally comfortable position, which to be fair can be considered a bit inevitable (learning things takes time), but could certainly have been faster and easier with the right tools available.

Still, despite all of NixOS' problems, I'm satisfied with my setup and consider my efforts towards it to have been worth it - I have my own system installation instructions which are pretty easy to follow (the hardest parts are partitioning and cloning the configuration), I enjoy the flexibility in the configuration, the peace of mind of being able to update and easily rollback if needed is great, and so on. But, I believe we can do better!

Wishes

As a result of the points above, I feel like NixOS, having taken a very important step among Linux distributions by introducing its innovative package management and configuration system, still hasn't reached the peak of its potential. Here are some potential steps forward I'd like to highlight.

The first and most important point would be improving UX for less (and more) technical users. I consider NixOS to be a distro suited for more "enthusiastic" and "tinkerer" Linux users due to the amount of technical knowledge required (which isn't something inherently bad, of course), but I think there are some nice ways to at least reduce the initial learning curve and overall make the distro more welcoming and friendly to more users.

In this sense, I consider graphical user interfaces (GUIs) to be essential. While Nix is a very powerful tool and should be treated as such, I'm all for reducing its usage as much as possible, restricting powerful tools to use cases where they fit best. Most new users are used to imperative configuration through GUIs, and I think NixOS could have built-in GUIs tailored for common use cases without giving up its principles, where possible. Two existing projects come into my mind here:

  1. SnowflakeOS7: This project has lots of good ideas here, including a GUI for easy and visual modification of your Nix configuration, an "App Store" for Nix packages, and so on. Its progress seems to be hindered by the low amount of maintainers, but I'd love to see a project like this gain traction (and, more importantly, funding).
  2. VanillaOS8: A novel, user-friendly immutable distro. I've only heard of this project recently, so I can't vouch for its quality yet, but the blog post on the release of Vanilla OS 2 left me particularly impressed.9 The GUIs and UX features shown are exactly the kind of thing I would want for a more user-friendly NixOS setup. The easy installation of external programs into containers (for compatibility) by double-clicking .deb or .apk files, as well as the GUI for easy management of their "APX" tool (which seems to be a distrobox alternative, i.e. a tool to manage containers where you can install other Linux distros for compatibility purposes), caught my attention. All that without sacrificing immutability and declarativeness too much (though that would naturally be harder to achieve in NixOS, as its declarative capabilties are much superior).

In addition to the examples above, I'd love to see a graphical tool to search for and install user-made system modules as well. Something like Flakehub10 or Nix Flake search11, but specific to NixOS settings modules, integrated to the OS itself and compatible with a configuration management GUI. I envision being able to search for something like "Configs for (INSERT BRAND) GPU users", find a helpful module made by another user, perhaps change a few settings, install and rebuild the system config. If done well, this would attract even more contributors to the community, and, combined with a graphical settings manager, could make changing and reusing NixOS configuration a breeze for both technical and non-technical users!

Still, GUIs don't solve everything. Users who want to write and share their own reusable system config modules are still going to have to write code at some point (in this case, Nix code), and that's OK: that's what code is made for. But this can't be done without improving the Nix development experience. I consider myself to be a power user, and this is one of the biggest hurdles when trying to harness the full power and greatness of Nix's immutability, declarativeness and flexibility. Having better language servers, better errors and some form of static typing would go a long way for Nix.

That is why I have started my own side-project in an attempt to improve this situation: the Glistix project.12 Currently incomplete (the base functionality is there, but needs improvements, lacks an ecosystem etc.), it aims to make it possible to transpile code written in the simple yet powerful Gleam language13 into Nix by adding a Nix backend to the Gleam compiler. Gleam (whose first stable version was released earlier this year) is a functional and statically-typed language with familiar and very easy syntax, has a great built-in language server, and is overall a breeze to work with. By creating "islands" of statically-typed code (with good DX, as a consequence), I believe Glistix would shine the most for Nix packages and NixOS modules which need to use functions and complex logic to produce config, as it would help catch many errors ahead of time, among other dev-related improvements. I hope to be able to grow my project to the point where I can replace most of my config with Gleam code some day (consider contributing if you're interested!). More generally, a good config development experience is an essential step towards fostering more community contributions, as well as leading to more reliable OS configurations by reducing developer mistakes, so I hope this particular area receives a lot of attention in the near future.

Finally, one important item in my wishlist is a better security story for NixOS. As someone curious about technologies such as sandboxing (see e.g. bubblewrap14, sandboxing tool used by Flatpak) and virtualization, I am mildly disappointed that NixOS's great declarative abilities don't seem to be usable yet for the purpose of having isolated, but integrated, apps and tools with user-friendly permission controls (similar to Flatpak and Flatseal, but in a broader scale). Two projects are currently interesting to me in this regard:

  1. nixpak15: Attempts to bring declarative Flatpak-like sandboxing and environment control to apps specified through Nix, which is the kind of usage I'd expect for Nix's declarative capabilities. I haven't used this project yet myself, but it seems to be very much aligned with my thoughts.
  2. SpectrumOS16: A reasonably ambitious project which aims to create a more secure Linux-based OS based on configurable and flexible per-app compartmentalization, using packages from NixOS's nixpkgs (but not directly based on NixOS17). The premise is similar to that of QubesOS18, but differs in that there would be one lightweight VM per application instead of several heavy VMs. It'll definitely be interesting to see where this project goes!

Conclusion

To summarize my thoughts, I'm a huge fan of NixOS and the innovations it brought to the table in the Linux world. Its reproducible and declarative aspects (both in package management and system configuration), as well as its extremely active community of contributors, truly make NixOS a very special distribution, being basically perfect for servers. However, given some of its most pressing problems on the desktop - including a difficult onboarding process and the not-so-great experience of developing Nix code -, I think it's time for NixOS to take several necessary steps for it to reach its full potential, which includes (but is not limited to) creating graphical system config tools, improving Nix's dev experience (which I'm trying to contribute to through my own project, Glistix12), as well as harnessing Nix's power for security.

I conclude mentioning that it's unreasonable to expect all of those goals to be fully met. After all, NixOS and its adjacent projects are maintained by volunteers, for the most part, who have been doing an excellent job so far. It's possible that only a new distribution could effectively meet those goals (e.g. by creating its own, perhaps more ergonomic config language, giving much more priority to GUI from the start, and so on). Regardless of where we're headed to, I hope to at least contribute in some way to moving my ideas forward. Thank you very much for reading :)

This post is licensed under CC-BY-SA 4.0

Footnotes

  1. Fedora Silverblue: https://fedoraproject.org/atomic-desktops/silverblue/ ↩

  2. MicroOS: https://get.opensuse.org/microos/ ↩

  3. NixOS & Flakes Book (example of a high-quality book/guide): https://nixos-and-flakes.thiscute.world/ ↩

  4. New NixOS wiki: https://wiki.nixos.org/wiki/NixOS_Wiki ↩

  5. nix-ld: https://github.com/nix-community/nix-ld ↩

  6. "Apple's Response to iPhone 4 Antenna Problem: You're Holding It Wrong": https://www.wired.com/2010/06/iphone-4-holding-it-wrong/ ↩

  7. "SnowflakeOS - Creating a GUI focused NixOS-based distro": https://discourse.nixos.org/t/snowflakeos-creating-a-gui-focused-nixos-based-distro/21856 ↩

  8. VanillaOS (landing page): https://vanillaos.org/ ↩

  9. "Vanilla OS 2 Orchid - Stable Release": https://vanillaos.org/blog/article/2024-07-28/vanilla-os-2-orchid---stable-release ↩

  10. Flakehub: https://flakehub.com/ ↩

  11. Nix Flake search: https://search.nixos.org/flakes ↩

  12. Glistix: https://github.com/glistix/glistix ↩ ↩2

  13. Gleam: https://gleam.run/ ↩

  14. Bubblewrap: https://github.com/containers/bubblewrap ↩

  15. nixpak: https://github.com/nixpak/nixpak ↩

  16. SpectrumOS: https://spectrum-os.org/ ↩

  17. SpectrumOS (Design): https://spectrum-os.org/design.html ↩

  18. QubesOS, a security-focused operating system: https://www.qubes-os.org/ ↩

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment