31–40 of 102 posts
Nix's language is a giant PITA. But the box runs quite solidly. Hell even my nvidia optimus works - for the first time on any distribution.
For things that don't work well, I shove them into a docker image. Like the arduino IDE.
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…
Why do you believe it makes Unix a single user machine??? I'm not aware of any reason for such statement, can you elaborate?
My reasoning was very simple. Nixos makes it easy to install packages on a per user basis. This would mean there is a lot of redundancy if another user also needs the same package. A snapshot/dedup filesystem will easily solve the problem.
I use NixOS since last spring and I adore it so much that I almost credit it with making me like computers again. It's a kind of bumpy ride sometimes but for me there's no other distribution that's even close. Packaging the Nix way does require patching upstream and that's probably inevitable. It would be nice to help with the documentation situation, though I'd note that the NixOS manual and the Nixpkgs manual are s…
NixOps deployment takes the server from scratch to finished clone of my laptop -- with a bit of server-specific configuration -- with zero manual intervention.
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,…
This is a common misunderstanding. Guix is not just a new config layer on top of Nix, it's a new implementation of the concepts pioneered by Nix. The only component that is shared between Nix and Guix is the daemon (written in C++), and they have diverged quite a bit at this point. Everything else about the core implementation (UI, the client for the daemon, recipe->derivation conversion, initial ram disk, init system, etc.) is implemented in Scheme and has pretty significant differences with Nix/NixOS. Even the Guix daemon will be written in Scheme eventually.
>People also think scheme is better than Nix as a language, but if you reason backwards from the requirements that's not at all clear to me. I think Nix-the-language would be better off with types, but the lazy, functional & pure parts are necessary for the concept.
This is another common misunderstanding. The part that is necessary for the concept is that the derivations, the things that the package recipes are transformed into to be built by the daemon, are computed lazily and act as pure functions. Guix certainly retains this quality. Also, if you look at the Scheme code in Guix you'll find that it's written in a purely functional style. I think Scheme's multi-paradigm nature is a strength, not a weakness.
Correct me if I'm wrong but isn't the better solution to this containerization? The application will in a literal sense own the system. You also get inherent security (unless someone figures out how to escape their vm). I member someone had a website talking about this. The use of a file system with revision tracking, containerization for security, and sending files between VMs to make things work.
Correct me if I'm wrong but isn't the better solution to this containerization? The application will in a literal sense own the system. You also get inherent security (unless someone figures out how to escape their vm). I member someone had a website talking about this. The use of a file system with revision tracking, containerization for security, and sending files between VMs to make things work.
Nix gets you a reproducible environment – which is just as applicable to building containers. Most containers on docker hub would be very hard to exactly reproduce, if you build them with nix you don't have that issue.
Earlier quoted context omitted.
Why do you believe it makes Unix a single user machine??? I'm not aware of any reason for such statement, can you elaborate?
I think I should have been clear. It does not make Unix single user machine but it is more useful for cases where a single user is the main user of a machine like the laptop user. My reasoning was very simple. Nixos makes it easy to install packages on a per user basis. This would mean there is a lot of redundancy if another user also needs the same package. A snapshot/dedup filesystem will easily solve the problem.
Earlier quoted context omitted.
Why do you believe it makes Unix a single user machine??? I'm not aware of any reason for such statement, can you elaborate?
I think I should have been clear. It does not make Unix single user machine but it is more useful for cases where a single user is the main user of a machine like the laptop user. My reasoning was very simple. Nixos makes it easy to install packages on a per user basis. This would mean there is a lot of redundancy if another user also needs the same package. A snapshot/dedup filesystem will easily solve the problem.
Earlier quoted context omitted.
> Symlinks have all sorts of weird semantics on different Unix machines. Is there any other implementation than posix in the wild these days?
http://www.weirdnet.nl/apple/rename.html Yes, I know it is fixed. But who knows what one runs into! And this: http://blog.moertel.com/posts/2005-08-22-how-to-change-symli...
Avid NixOSer here. While it's sad, that we're not there yet in terms of user-friendliness, I still think, given the radical approach, NixOS takes, it's increadibly feature-complete. I find it easy to tweak, too, but that might be due to previous experience with functional systems. For the specific suggestions in the article, I'm not convinced that they are possible, while retaining the same benefits: - Filesystem sna…