Live data from Hacker News

Reflections on NixOS

zenhack.net

91–100 of 102 posts

Re: Reflections on NixOS

#91

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?

For me, they key pieces are: 1) frameworks. when traditional search paths don't find executables and dyn libs the way you expect, it isn't unix-alike. 1a) when the execution environment has changed enough that the build needs to be modified beyond a few simple config variables, it isn't Unix-alike. 2) unconventional init system. although BSD is moving to something similar to launchd, so I think that idea is evolving toward mainstream. 3) unconventional cron, see launchd/BSD.

So dll dependencies are crazy-making, and Nix is attacking that. traditional init is getting creaky, launchd and systemd are attacking that.

With respect to systemd, I love how it has motivated people to try to come up with something better than both traditional init and systemd.

Re: Reflections on NixOS

#92
post #89

Earlier quoted context omitted.

Why isn't macOS a Unix-like anymore?

macOS is BSD Unix under the hood with the Mach kernel [1]. I'm tired of hearing this nonsensical talking point that macOS has strayed too far to be considered Unix. What does that even mean? Perhaps someone should inform The Open Group who controls the official Unix specification that they are wrong. Even though it shells like a unix, users like a unix, signals like a unix, files like a unix, networks like a unix, st…

A kernel is not an OS.

I'm thinking perhaps some measure of porting effort is the appropriate metric. There is a reason Mac users can't simply point to a bsdports repo.

Re: Reflections on NixOS

#93
post #17

I used nixos for a few weeks and then went back to Debian. * I share the concern of the author on symlinks farm. It is scary! I would like it to be dealt with in the filesystem layer (Plan 9 had a snapshot based filesystem - fossil - years ago). Symlinks have all sorts of weird semantics on different Unix machines. * Another of my gripe with nixos is that it makes Unix, a single user machine! Sure, packages need not…

Regarding licenses, most (all?) packages in the official nixpkgs repo have license metadata, and you can set your configuration to forbid/allow proprietary packages (the "allowUnfree" option), or use a whitelist (e.g. forbid everything except Flash). Guix is a GNU project, and doesn't allow proprietary packages in their collection at all.

Yes. But the amount of information in the debian/copyright file is a lot more than just one scalar flag. I think that level of detail on the licenses is extremely important.

Re: Reflections on NixOS

#94
post #58

Earlier quoted context omitted.

Because that's fundamental to Nix. We're giving up on some current habits to get the freedom we want. This won't ever change, but people might. I'm not blaming them, I feel their pain. This is common in technology all around, think about driving a car for 25 years with manual transmission and then trying automatic transmission.

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…

And that's exactly when shit hits the fan. Now they expect everything will work out with commands managing a language.

At one point, sooner or later, you have to tell them they just need to learn the language.

I'd rather spend time explaining the language than teaching them workarounds.

Having said this, we already do have ways to dodge the language for example using imperative package management. But that's exactly how another such blog post could be written how it doesn't always work due to "freedom" that Nix tries to provide.

Lesson learned here is: pick your fights carefully.

Re: Reflections on NixOS

#95
post #75

Earlier quoted context omitted.

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.

This statement is completely wrong and ignorant.

Please don't say things if you don't know about them.

Just to prove my point, we've recently merged a branch for hardened compiler flags. This is mainly for server security.

https://github.com/NixOS/nixpkgs/pull/12895

Re: Reflections on NixOS

#96
post #21

Earlier quoted context omitted.

I love that Guix chose a nice, clean (i.e., S-expression-based) representation for all of its code and data, but it's unfortunate that they chose Scheme instead of Lisp.

I much prefer Scheme (and Racket) to the other Lisps I've tried (Common Lisp and Emacs Lisp), since it emphasises functional programming. Since the ideas of Nix come from functional programming (e.g. conceptually, the Nix store contains all packages, the "install" commands just force their evaluation) Scheme seems like a closer fit.

Functional programming is cool, and it's possible in Lisp, but I prefer multi-paradigm. Sometimes one wants functions, sometimes procedures, sometimes objects & methods; sometimes one just wants to declare stuff.

Re: Reflections on NixOS

#97
post #89

Earlier quoted context omitted.

macOS is BSD Unix under the hood with the Mach kernel [1]. I'm tired of hearing this nonsensical talking point that macOS has strayed too far to be considered Unix. What does that even mean? Perhaps someone should inform The Open Group who controls the official Unix specification that they are wrong. Even though it shells like a unix, users like a unix, signals like a unix, files like a unix, networks like a unix, st…

A kernel is not an OS. I'm thinking perhaps some measure of porting effort is the appropriate metric. There is a reason Mac users can't simply point to a bsdports repo.

Uh, yes it is. It is a very core part of an OS. Without it, the OS does not function.

Re: Reflections on NixOS

#98
Trying to set NixOS on a armv7 board (NVIDIA Jetson Tegra K1), There is a customized linux 3.10 kernel that comes with the board and I'd like to know how to integrate that on NixOS. Currently I managed to boot the board using a generic armv7 image which runs on SD card I got from this page - https://nixos.org/wiki/NixOS_on_ARM . But I cannot activate any services like ssh or install drivers like nvidia, cuda iwlwifi and bluetooth on Nix. Any support will be appreciated. NixOS manual doesn't explicit between different architectures and I think it's mainly written for running NixOS on amd64 PCs or similar architecture but not arm. What am I missing here, where should I look into or read about to set a properly running system on my arm board? Thank you!

Re: Reflections on NixOS

#99

Earlier quoted context omitted.

A kernel is not an OS. I'm thinking perhaps some measure of porting effort is the appropriate metric. There is a reason Mac users can't simply point to a bsdports repo.

Uh, yes it is. It is a very core part of an OS. Without it, the OS does not function.

Kernel is necessary, not sufficient. Nobody ships just a kernel and calls it an OS.

Re: Reflections on NixOS

#100

Earlier quoted context omitted.

Uh, yes it is. It is a very core part of an OS. Without it, the OS does not function.

Kernel is necessary, not sufficient. Nobody ships just a kernel and calls it an OS.

Right, linux never just ships as a kernel for others to consume.
Post reply on HN