8 ms·

NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1] Earlier Nix had a

NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1] Earlier Nix had additional NixOps but that too now is available with Guix deploy. I am waiting when I can run Guix within a lxd container, shepherd init still has some rough edges with LXD container init. Both are great piece of software and a new take on building OS and distribution. They are ahead of their time might take another 4-5 years before they become more mainstream. [1] https://guix.gnu.org/help/ https://guix.gnu.org/help/

eadmund 7y ago
How is Shepherd broken with LXC? Is it sufficient to run Guix atop another distribution, or run Guix SD in a qemu VM?
- dragonsh 7y ago
  GuixSD does not work without making changes within a LXD container (not VM). One of the details on how to do it is in mailing list. [1] [1] https://lists.gnu.org/archive/html/help-guix/2018-10/msg00062.html https://lists.gnu.org/archive/html/help-guix/2018-10/msg0006...
throwaway894345 7y ago
Our organization tried Nix for many years. Most of our problems were around usability, lack of documentation (including zero docstrings or type annotations in nixpkgs), and the overt unfamiliarity of the Nix expression language (asking a whole organization to learn something that seems deliberately cryptic isn't a recipe for success), and a long tail of other things. Still, at its core Nix for package management seems like the future; I just have no confidence that they're going to iron out those issues in the next 4-5 years. Of course, none of that speaks to Guix as I haven't used it, but hopefully it's awesome and solves all of those problems.
- lidHanteyk 7y ago
  To me, this is a success story; your organization wasn't sufficiently flexible to adopt new technologies which require rethinking the fundamentals of package management. Take this as a warning sign and re-orient your organization. I do wonder about the "deliberately cryptic" nature of Nix's expression language. It is, in fact, deliberately designed for simplicity, to be a basic syntax for a language that is purely functional and lazy but not much else ([0] p69). When folks complain about the Nix expression language, as they often do, I ask them: What would you change? How would you do it? I think that it is bad that an entire team does not have the bandwidth to learn an entirely new language, but good that the team is not willing to spend time on things which they don't think are important. [0] https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf
  - rkangel 7y ago
    Do you have any evidence to support your assertion that it was an issue with an organisation rather than the technology? Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.
    - lidHanteyk 7y ago
      Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability. Moreover, there are lots of folks having professional success with Nix, and having consumed enough of their stories, I think that the stumbling blocks that the parent identified are faults of their organization and not of Nix in particular. To see this, first replace "Nix" with "Brand X" and note that the complaints are generic to any community-developed software which doesn't have B2B resellers. Then, consider your own experience learning Nix, and note that usability, poor documentation, and a feeling that things are deliberately cryptic are all common to learning any new tool or programming language. We can comfortably conclude that Nix did not prevent itself from being adopted by the parent's organization. Indeed, it would seem that Nix made itself extremely attractive and adoptable, else it would not have been under consideration!
rauhl 7y ago
Guix looks really cool. I wish that it used Lisp rather than Scheme (because IMNSHO Lisp is better-suited to this kind of system software), but that ship has sailed. It’s a real shame that rms had such a dislike of Common Lisp. The mind boggles at where the cutting edge of computing would be today had Emacs upgraded from Elisp to Common Lisp twenty or thirty years ago. Instead GNU has spent 27 years trying to turn Scheme into a sufficient systems programming language, once again illustrating the truth of Greenspun’s Tenth Law: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I would add a corollary: this also applies to any sufficiently complicated Scheme program.
- flavio81 7y ago
  RMS dislike of CL was purely due to personal factors: He felt cheated by the Lisp machine industry.
  - gjvc 7y ago
    Never heard this before -- quite plausible. Do you have any references out in the wider world?
kalium-xyz 7y ago
I don't see why you say that NixOS does not have enough documentation, a commonly cited problem is the lack of tooling rather than the lack of documentation which would be fair. NixOS has the most extensive documentation out there for any linux distribution which I've used [0] and each package is documented and contains the information of any option it offers from the nix code itself and the tooling [1]. Furthermore I do not think you can compare Guix to Nix for commercial work as Nix is LGPL [2] with the packages being MIT [3] where Guix is GPL [4] allowing for Nix derivative work to be used commercially with little restriction. I wish Guix had stayed as a guile layer for Nix and not gone off in its own direction because of the licensing ambiguity (as far as I can tell this is the reason) in Nix packages. If anyone has more insight on why this split happened or the possibility of making such layers for Nix I'm very interested in this topic. [0] https://nixos.org/learn.html https://nixos.org/learn.html [1] https://nixos.org/nixos/packages.html?channel=nixos-19.09 https://nixos.org/nixos/packages.html?channel=nixos-19.09 [2] https://github.com/NixOS/nix#license https://github.com/NixOS/nix#license [3] https://github.com/NixOS/nixpkgs/blob/master/COPYING https://github.com/NixOS/nixpkgs/blob/master/COPYING [4] https://guix.gnu.org/about/ https://guix.gnu.org/about/
- dragonsh 7y ago
  In the blog post if you read the person complained about it, so said can give a try to Guix. I think both Nix and Guix are good, personally I like Guix being familiar with lisp and scheme feels very natural to work with Guix, with Nix need to learn new declarative syntax. Linux kernel itself is GPL, so not sure what’s the issue with Guix. Obviously Guix package repository only support libre software, but if you need to use proprietary repository try Guix-nonfree[1]. I am happy Guix and GuixSD exist. Check the gnu Guix mailing list archive both have same roots but are sufficiently different[2]. [1] https://github.com/guix-users/guix-nonfree https://github.com/guix-users/guix-nonfree [2] https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00235.html https://lists.gnu.org/archive/html/guix-devel/2019-09/msg002...
  - ymse 7y ago
    The vanilla Linux kernel contains many proprietary firmware blobs, which is why GNU and Guix uses the "Linux-Libre" fork. There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
ymse 7y ago
GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 https://news.ycombinator.com/item?id=22877788 :-) Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.
- rudolph9 7y ago
  It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.
  - ymse 7y ago
    It's one of the things you just can't do without once you become accustomed to it. I can not imagine going back to needing root privileges just to install or try a package, or being unable to roll back to earlier revisions. I hear Nix even works on macOS too! :-)
  - mouldysammich 7y ago
    nix doesn't have a package on OpenSUSE so you need to manually instlal, guix does have one though
    - takeda 7y ago
      Nix doesn't really come with packages to be installed, you can create one though. You install it by running this installation script: https://nixos.org/nix/install https://nixos.org/nix/install It should work on any Linux and OS X.
  - slightwinder 7y ago
    How does using nix on other distributions work? Can it access their local packagemanagers and install the distribution-packages, or is it a parallel world that just happens to live on the same machine?
    - 7y ago
downerending 7y ago
I recently read that Guix was dropping support for the Linux kernel, but apparently that was a Apr 1 joke. Argh. https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/ https://guix.gnu.org/blog/2020/deprecating-support-for-the-l...

eadmund 7y ago

How is Shepherd broken with LXC? Is it sufficient to run Guix atop another distribution, or run Guix SD in a qemu VM?

dragonsh 7y ago
GuixSD does not work without making changes within a LXD container (not VM). One of the details on how to do it is in mailing list. [1] [1] https://lists.gnu.org/archive/html/help-guix/2018-10/msg00062.html https://lists.gnu.org/archive/html/help-guix/2018-10/msg0006...

throwaway894345 7y ago

Our organization tried Nix for many years. Most of our problems were around usability, lack of documentation (including zero docstrings or type annotations in nixpkgs), and the overt unfamiliarity of the Nix expression language (asking a whole organization to learn something that seems deliberately cryptic isn't a recipe for success), and a long tail of other things. Still, at its core Nix for package management seems like the future; I just have no confidence that they're going to iron out those issues in the next 4-5 years. Of course, none of that speaks to Guix as I haven't used it, but hopefully it's awesome and solves all of those problems.

lidHanteyk 7y ago
To me, this is a success story; your organization wasn't sufficiently flexible to adopt new technologies which require rethinking the fundamentals of package management. Take this as a warning sign and re-orient your organization. I do wonder about the "deliberately cryptic" nature of Nix's expression language. It is, in fact, deliberately designed for simplicity, to be a basic syntax for a language that is purely functional and lazy but not much else ([0] p69). When folks complain about the Nix expression language, as they often do, I ask them: What would you change? How would you do it? I think that it is bad that an entire team does not have the bandwidth to learn an entirely new language, but good that the team is not willing to spend time on things which they don't think are important. [0] https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf
- rkangel 7y ago
  Do you have any evidence to support your assertion that it was an issue with an organisation rather than the technology? Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.
  - lidHanteyk 7y ago
    Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability. Moreover, there are lots of folks having professional success with Nix, and having consumed enough of their stories, I think that the stumbling blocks that the parent identified are faults of their organization and not of Nix in particular. To see this, first replace "Nix" with "Brand X" and note that the complaints are generic to any community-developed software which doesn't have B2B resellers. Then, consider your own experience learning Nix, and note that usability, poor documentation, and a feeling that things are deliberately cryptic are all common to learning any new tool or programming language. We can comfortably conclude that Nix did not prevent itself from being adopted by the parent's organization. Indeed, it would seem that Nix made itself extremely attractive and adoptable, else it would not have been under consideration!

rauhl 7y ago

Guix looks really cool. I wish that it used Lisp rather than Scheme (because IMNSHO Lisp is better-suited to this kind of system software), but that ship has sailed. It’s a real shame that rms had such a dislike of Common Lisp. The mind boggles at where the cutting edge of computing would be today had Emacs upgraded from Elisp to Common Lisp twenty or thirty years ago. Instead GNU has spent 27 years trying to turn Scheme into a sufficient systems programming language, once again illustrating the truth of Greenspun’s Tenth Law: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I would add a corollary: this also applies to any sufficiently complicated Scheme program.

flavio81 7y ago
RMS dislike of CL was purely due to personal factors: He felt cheated by the Lisp machine industry.
- gjvc 7y ago
  Never heard this before -- quite plausible. Do you have any references out in the wider world?

kalium-xyz 7y ago

I don't see why you say that NixOS does not have enough documentation, a commonly cited problem is the lack of tooling rather than the lack of documentation which would be fair. NixOS has the most extensive documentation out there for any linux distribution which I've used [0] and each package is documented and contains the information of any option it offers from the nix code itself and the tooling [1]. Furthermore I do not think you can compare Guix to Nix for commercial work as Nix is LGPL [2] with the packages being MIT [3] where Guix is GPL [4] allowing for Nix derivative work to be used commercially with little restriction. I wish Guix had stayed as a guile layer for Nix and not gone off in its own direction because of the licensing ambiguity (as far as I can tell this is the reason) in Nix packages. If anyone has more insight on why this split happened or the possibility of making such layers for Nix I'm very interested in this topic. [0] https://nixos.org/learn.html https://nixos.org/learn.html [1] https://nixos.org/nixos/packages.html?channel=nixos-19.09 https://nixos.org/nixos/packages.html?channel=nixos-19.09 [2] https://github.com/NixOS/nix#license https://github.com/NixOS/nix#license [3] https://github.com/NixOS/nixpkgs/blob/master/COPYING https://github.com/NixOS/nixpkgs/blob/master/COPYING [4] https://guix.gnu.org/about/ https://guix.gnu.org/about/

dragonsh 7y ago
In the blog post if you read the person complained about it, so said can give a try to Guix. I think both Nix and Guix are good, personally I like Guix being familiar with lisp and scheme feels very natural to work with Guix, with Nix need to learn new declarative syntax. Linux kernel itself is GPL, so not sure what’s the issue with Guix. Obviously Guix package repository only support libre software, but if you need to use proprietary repository try Guix-nonfree[1]. I am happy Guix and GuixSD exist. Check the gnu Guix mailing list archive both have same roots but are sufficiently different[2]. [1] https://github.com/guix-users/guix-nonfree https://github.com/guix-users/guix-nonfree [2] https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00235.html https://lists.gnu.org/archive/html/guix-devel/2019-09/msg002...
- ymse 7y ago
  The vanilla Linux kernel contains many proprietary firmware blobs, which is why GNU and Guix uses the "Linux-Libre" fork. There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix

ymse 7y ago

GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 https://news.ycombinator.com/item?id=22877788 :-) Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.

rudolph9 7y ago
It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.
- ymse 7y ago
  It's one of the things you just can't do without once you become accustomed to it. I can not imagine going back to needing root privileges just to install or try a package, or being unable to roll back to earlier revisions. I hear Nix even works on macOS too! :-)
- mouldysammich 7y ago
  nix doesn't have a package on OpenSUSE so you need to manually instlal, guix does have one though
  - takeda 7y ago
    Nix doesn't really come with packages to be installed, you can create one though. You install it by running this installation script: https://nixos.org/nix/install https://nixos.org/nix/install It should work on any Linux and OS X.
- slightwinder 7y ago
  How does using nix on other distributions work? Can it access their local packagemanagers and install the distribution-packages, or is it a parallel world that just happens to live on the same machine?
  - 7y ago

downerending 7y ago

I recently read that Guix was dropping support for the Linux kernel, but apparently that was a Apr 1 joke. Argh. https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/ https://guix.gnu.org/blog/2020/deprecating-support-for-the-l...