Live data from Hacker News

Reflections on NixOS

zenhack.net

71–80 of 102 posts

Re: Reflections on NixOS

#71
post #52

Earlier quoted context omitted.

> Packaging the Nix way does require patching upstream and that's probably inevitable. Not to familiar with Nix, can you explain why? Anything that can't be handled simply by applying small patches to the upstream during packaging?

"patching upstream" in this context means "applying patches to the upstream during packaging". Nix and Guix require programs to work with a directory layout that differs significantly from the standard. Simple things like `#!/bin/python` don't work anymore, because they aren't explicit enough.

Ah ok, that clarifies things. Thanks.

Re: Reflections on NixOS

#72

As a NixOS user I've certainly encountered some of these issues. While Nix and NixOS are really nice, the first thing I'd recommend to a new user would be to learn the Nix language, as it's pretty much a requirement for getting anything done. I agree with the author that per-user configuration is a bit overkill for the common use-case of a single user machine, but you have to go out of your way to use it (via the "ni…

Love NixOS. I spend about a month in it. While it did feel very complete, I did end up reverting to Arch just for lack of time. I agree that you have to learn the nix packaging language in order to make good use of the system. When I have more time, I will get back to it.

Another issue I had was around config methodology - specifically for the desktop use case. For example, in Gnome I wanted to tune my brightness and mouse sensitivity. In most desktop cases you want to adjust those things every session and have that remembered between reboots. But that violates the Nix config system. Perhaps there is a middle ground where those session specific configs can be stored instead of putting them in the global config.

Also the Nix package manager is great - mostly that it is platform agnostic, but the real power is in NixOS's global config file - which is essential for SERVER stability.

I will say that it was an enlightening experience as a whole and some of these concepts are being taken very seriously in other projects. I cant wait for non-deterministic build systems like Puppet and Salt to be a thing of the past. Nix, Guix, Snap packages (and the like), and Docker are much safer and dependable.

Re: Reflections on NixOS

#73

People need to stop thinking of NixOS as another Unix-alike, because it isn't, in very much the same way that MacOS used to be a Unix-alike, but isn't any more, either. NixOS is rebuilding important pieces of the foundation. Why? To address a basket of problems we have been complaining about with Unix for a very long time. Is it worth the hassle? Well, have you ever lived through a kitchen remodel in your house? That…

Why isn't macOS a Unix-like anymore?

Re: Reflections on NixOS

#74
post #25
post #9

Earlier quoted context omitted.

I would love to hear your thoughts on Guix.

Guix comes up on every Nix thread on HN and it's a bit frustrating. Guix runs on Nix technology with a new config language for packages & a different philosophy about what can go into its core package set (it's a GNU project). My personal take is that the difference isn't large enough to warrant a new distribution and if you want to choose you should go with the momentum and that's with core Nix (10-30x contributors,…

> Guix comes up on every Nix thread on HN

Sorry, and thanks for taking the time answering.

Re: Reflections on NixOS

#75
post #58

Earlier quoted context omitted.

While some things are fundamental for Nix's architecture, user interfaces are not. You don't even have to force people to learn the language, you can get apt-getish experience for generating .nix files with git-like commits or whatever. There are no limits in making it user-friendly and respecting people's habits and familiarity (which is actually a core concept for interfaces, that you seem to confuse with new techn…

Faking destructive package management on top does exist, and we do plan on making it better, but it's lot harder to get right than you might think.

I have some UI ideas of my own and could've helped, but I don't think investing time into Nix would be smart at this point. I feel like Nix lacks a clear vision of its future, focuses on desktop systems, while package management is not a big problem there, but it is on servers, and yet apart from Linux no other server systems are officially supported. No FreeBSD, OpenBSD, NetBSD.

Re: Reflections on NixOS

#76

People need to stop thinking of NixOS as another Unix-alike, because it isn't, in very much the same way that MacOS used to be a Unix-alike, but isn't any more, either. NixOS is rebuilding important pieces of the foundation. Why? To address a basket of problems we have been complaining about with Unix for a very long time. Is it worth the hassle? Well, have you ever lived through a kitchen remodel in your house? That…

"The same way that MacOS used to be a Unix-alike, but isn't any more, either."

The Open Group would disagree.

Re: Reflections on NixOS

#77

Disclaimer: I'm core NixOS developer It's great to see such articles as they dive deep into psychology when it comes to new technology. It's really hard to unlearn. It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work.

> It takes effort to realize that the promised gain is bigger than the pain coming from doing what we're used to doesn't work. This could almost be the subtitle for "Functional Languages: Those Things Your Manager Won't Allow You To Use Yet" I think that a day will come when everyone will realize, and we'll have the tools to do, "functional" all the way to the metal. I like to quote John Carmack from http://www.gamas…

> I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution.

I would argue that, with Docker, you may or may not have a known state. You certainly have a fixed state, but whether or not the state is "known" depends on how you generated it. If you use something like Nix (or Guix) to create the image, then you have a chance of knowing the state and being able to understand it. But if you build the image in some other way, there's a good chance that you won't be able to understand the relationships between the components, and that you won't be able to change the relationships safely and effectively later on.

Re: Reflections on NixOS

#78

People need to stop thinking of NixOS as another Unix-alike, because it isn't, in very much the same way that MacOS used to be a Unix-alike, but isn't any more, either. NixOS is rebuilding important pieces of the foundation. Why? To address a basket of problems we have been complaining about with Unix for a very long time. Is it worth the hassle? Well, have you ever lived through a kitchen remodel in your house? That…

Why isn't macOS a Unix-like anymore?

Because, with the popularity of Linux, people have forgotten how varied unix-like OSes once were. I'm sure the grandparent poster will mention things like how it stores configuration differently, etc, but that's only not-unix-like to someone who hadn't used a handful of different commercial Unices back in the 1990s.

Re: Reflections on NixOS

#79
post #61

Earlier quoted context omitted.

I don't think many NixOS users use desktop environments, generally speaking, and NixOS users tend to wind up being NixOS contributors as it stands right now. XFCE's available, though, for something lightweight.

I mean, the Live-CD has KDE running by default, so I kind of assumed that was the standard.

It had to have something, right?

There's no 'standard', but KDE is used more often and therefore has fewer bugs. XFCE works fine. If you want Gnome, well, I haven't tried it, but they always welcome patches.

Re: Reflections on NixOS

#80
Not sure if I'm reinventing the wheel, but incidentally I've been working on this lately:

https://github.com/CyberShadow/aconfmgr

It's like basic traditional configuration management, but it's two-way: it takes the difference between the user-managed configuration and the current system state, and rectifies this difference by either editing the configuration or the system. A second invocation is a no-op. If your configuration is in version control, this allows easily tracking any unaccounted changes to the system.

Post reply on HN