GNU Guix 0.8.2 released(savannah.gnu.org)
savannah.gnu.org
GNU Guix 0.8.2 released
https://savannah.gnu.org/forum/forum.php?forum_id=8273
4 comments
Nice new site design too: https://www.gnu.org/software/guix/
Apparently 1024x768 is considered mobile nowadays. I can't stop smiling.
Zooming out to 90% turned the full-screen menu into a 'normal' one.
Zooming out to 90% turned the full-screen menu into a 'normal' one.
Why the extra effort on the GNU Project's part to create Guix? What are the advantages over just adopting Nix? Doesn't this mean that everything the Nix project packages has to be repackaged for Guix, and vice-versa?
I found this comparison at http://sandervanderburg.blogspot.com/2012/11/on-nix-and-gnu-...
I found this comparison at http://sandervanderburg.blogspot.com/2012/11/on-nix-and-gnu-...
>Why the extra effort on the GNU Project's part to create Guix?
There are a couple reasons:
1) We believe that unifying the entire system using a general purpose programming language that allows for the creation of embedded domain specific languages (Scheme) is better than using a domain specific language (the Nix language) and a multitude of other languages behind it (C++, Perl, Python, Bash). Our build scripts and client side code is written in Scheme. Our package and system services are written in Scheme. Our init system is written in Scheme. Our initial RAM disk is written in Scheme. This allows us to have good interoperability and reuse a lot of code in different places.
2) We are committed to providing a fully free GNU/Linux distro as defined by the FSF. NixOS includes proprietary some components.
>What are the advantages over just adopting Nix?
I think that our user and programming interfaces are better. We give more care to making sure package test suites pass and we don't use pre-built binaries from third parties (no blobs, no pre-built minified JavaScript, etc). We have really nice Emacs integration. It's nice to have a system that is fully free by default.
>Doesn't this mean that everything the Nix project packages has to be repackaged for Guix, and vice-versa?
Yes.
With that said, I need to mention that I think Nix is great. Really great. I just like the Guix implementation and philosophy more. Hope this helps.
There are a couple reasons:
1) We believe that unifying the entire system using a general purpose programming language that allows for the creation of embedded domain specific languages (Scheme) is better than using a domain specific language (the Nix language) and a multitude of other languages behind it (C++, Perl, Python, Bash). Our build scripts and client side code is written in Scheme. Our package and system services are written in Scheme. Our init system is written in Scheme. Our initial RAM disk is written in Scheme. This allows us to have good interoperability and reuse a lot of code in different places.
2) We are committed to providing a fully free GNU/Linux distro as defined by the FSF. NixOS includes proprietary some components.
>What are the advantages over just adopting Nix?
I think that our user and programming interfaces are better. We give more care to making sure package test suites pass and we don't use pre-built binaries from third parties (no blobs, no pre-built minified JavaScript, etc). We have really nice Emacs integration. It's nice to have a system that is fully free by default.
>Doesn't this mean that everything the Nix project packages has to be repackaged for Guix, and vice-versa?
Yes.
With that said, I need to mention that I think Nix is great. Really great. I just like the Guix implementation and philosophy more. Hope this helps.
Guix is a GNU project, meaning it will adhere to a higher code of software freedom ethics. (For instance Nix ships Adobe Flash Player with Firefox if I remember correctly.)
Guix uses Guile Scheme APIs/EDSLs for package recipes, build systems, etc., giving you the power of a proper programming language (and a lisp at that) as opposed to the special-purpose Nix language and arguably dirty Bash and Perl code.
The Guix System Distribution uses a Guile-based init system, DMD, instead of systemd, which again should give a lot of power and flexibility. (systemd being implemented in C instead.)
That's all off the top of my head. I haven't used Nix and someone who did might be able to point out many more differences that aren't obvious at first.
Guix uses Guile Scheme APIs/EDSLs for package recipes, build systems, etc., giving you the power of a proper programming language (and a lisp at that) as opposed to the special-purpose Nix language and arguably dirty Bash and Perl code.
The Guix System Distribution uses a Guile-based init system, DMD, instead of systemd, which again should give a lot of power and flexibility. (systemd being implemented in C instead.)
That's all off the top of my head. I haven't used Nix and someone who did might be able to point out many more differences that aren't obvious at first.
"The Guix System Distribution
* Liberating. GuixSD is an advanced distribution of the GNU Operating System developed by the GNU Project —which respects the freedom of computer users."
GNU Operating System? Has the FSF moved past calling it GNU/Linux to just calling it GNU? Have they switched back to the Hurd? What's going on here?
GNU Operating System? Has the FSF moved past calling it GNU/Linux to just calling it GNU? Have they switched back to the Hurd? What's going on here?
When we refer to the GNU Operating System, we're referring to the entire collection of GNU software. One of GuixSD's goals as an official GNU project is to integrate all GNU software nicely. The distro is GNU/Linux only right now, but Hurd support is being worked on, too.
See our "about" page for more info: https://www.gnu.org/software/guix/about/
See our "about" page for more info: https://www.gnu.org/software/guix/about/
This is off-topic but I personally prefer to just say "GNU" these days for what most people call "Linux" (excepting systems that somehow use Linux without GNU of course). It makes sense when you consider that:
- GNU has always been a project to make a whole OS, and the name of said OS is GNU. Linux on the other hand is explicitly a project to make a kernel only. When talking about a system consisting of GNU components for everything but the kernel, that would simply be the GNU OS using a third-party kernel.
- In terms of components implementing the base Unix system (see e.g. POSIX for a formal description of this "base system"), GNU components and Linux are probably roughly equivalent in size (don't underestimate Glibc and the whole userland Unix toolbox, not to mention compiler toolchain), so just "GNU" might downplay the importance of Linux and thus "GNU/Linux" would be the most correct term, but we all know it's cumbersome especially in speech, and if I'm going to shorten it then GNU is the obvious choice in line with point 1. It certainly makes more sense than "Linux".
Some people like to point out that GNU components can be replaced. So can Linux, as evident from e.g. Debian GNU/kFreeBSD, so that's not an argument. You can even use GNU on top of Windows via Cygwin. :-P
Of course the reason I bother is that I want GNU to be more widely known. It deserves at least equal respect with Linux if you ask me, yet 98% of everyone I met who had heard of "Linux" never heard of GNU; some knew the GPL but not GNU. And I work at an IT company...
- GNU has always been a project to make a whole OS, and the name of said OS is GNU. Linux on the other hand is explicitly a project to make a kernel only. When talking about a system consisting of GNU components for everything but the kernel, that would simply be the GNU OS using a third-party kernel.
- In terms of components implementing the base Unix system (see e.g. POSIX for a formal description of this "base system"), GNU components and Linux are probably roughly equivalent in size (don't underestimate Glibc and the whole userland Unix toolbox, not to mention compiler toolchain), so just "GNU" might downplay the importance of Linux and thus "GNU/Linux" would be the most correct term, but we all know it's cumbersome especially in speech, and if I'm going to shorten it then GNU is the obvious choice in line with point 1. It certainly makes more sense than "Linux".
Some people like to point out that GNU components can be replaced. So can Linux, as evident from e.g. Debian GNU/kFreeBSD, so that's not an argument. You can even use GNU on top of Windows via Cygwin. :-P
Of course the reason I bother is that I want GNU to be more widely known. It deserves at least equal respect with Linux if you ask me, yet 98% of everyone I met who had heard of "Linux" never heard of GNU; some knew the GPL but not GNU. And I work at an IT company...
Guix should hypothetically support Linux, HURD, *BSD, etc. since it's based on Nix.
Linux has been the de facto kernel for GNU ever since Linus switch from a non-commercial license to the GPL; at which point HURD became a research project.
Linux has been the de facto kernel for GNU ever since Linus switch from a non-commercial license to the GPL; at which point HURD became a research project.
Linux-libre is GNU software: https://gnu.org/s/#allgnupkgs
Guix is really cool, but I wish that it used Common Lido instead of Scheme. Still, much as with Emacs, a Lisp is better than no Lisp.
>Common Lido
Slipped by one column on your keyboard? :-D
I agree that a Lisp is better than no Lisp; I'd be more or less equally content if Guix used CL. Major Scheme implementations don't have much lacking compared to CL though, and the core is somewhat cleaner with less historic baggage, so I'm most happy with Scheme. (The standardization though ... sigh)
Slipped by one column on your keyboard? :-D
I agree that a Lisp is better than no Lisp; I'd be more or less equally content if Guix used CL. Major Scheme implementations don't have much lacking compared to CL though, and the core is somewhat cleaner with less historic baggage, so I'm most happy with Scheme. (The standardization though ... sigh)
Yeah, stupid phone keyboard and stupid me not noticing:-)
That's one major issue with Scheme: sure, anything can be achieved in a Turing-complete language, but each Scheme does things a little differently. Common Lisp, meanwhile, actually standardised all that important stuff.
And while Scheme is conceptually cleaner, CL feels a lot more well-engineered as a language.
That's one major issue with Scheme: sure, anything can be achieved in a Turing-complete language, but each Scheme does things a little differently. Common Lisp, meanwhile, actually standardised all that important stuff.
And while Scheme is conceptually cleaner, CL feels a lot more well-engineered as a language.
I wonder what makes you say CL feels more well-engineered? I can't think of any reasons, unless you simply mean Scheme's under-specification.
Scheme is not just "conceptually" cleaner if you ask me. It's very concretely cleaner. The naming conventions for one ("rplaca" anyone?), the clear-cut orthogonal APIs, the numeric tower with exactness/inexactness, and [insert pun about "hygienic" macros being "cleaner"...]
Scheme is not just "conceptually" cleaner if you ask me. It's very concretely cleaner. The naming conventions for one ("rplaca" anyone?), the clear-cut orthogonal APIs, the numeric tower with exactness/inexactness, and [insert pun about "hygienic" macros being "cleaner"...]