15 ms·

Guix: An advanced operating system

313 points by Ambrevar 8y ago

vemv 8y ago
Exciting stuff. There's been bit of a Lisp renaissance over the last 5-10 years (thanks to the Emacs packaging system, Clojure) so this could be the next logical step for someone who writes parens for a living.
eadmund 8y ago
I do really wish that Guix used Lisp rather than Scheme.
- draven 8y ago
  You mean Common Lisp ? Because Scheme is a Lisp. Guix is from GNU, Scheme is their official extension language (with Guile as the implementation.)
  - darkpuma 8y ago
    It's a tedious fruitless argument that goes back years. Some people in the "Common Lisp camp" believe that Common Lisp has the "rights" to the 'Lisp' "trademark."
    - delish 8y ago
      As someone who programs in Clojure--and therefore has no justification for weighing in--I _believe_ that it's a cultural or generational difference. That is, for certain programmers (working in the 1980s? 1990s?) "Lisp" (capital-L, lower-case isp) meant Common Lisp, and many agreed. I am sure that people tediously, fruitlessly argue about it. But it's also true that for a wide swath of programmers, Lisp is Common Lisp. I wonder if hn's lisper or lispm could weigh in...
      - darkpuma 8y ago
        Arguments about labels are always tedious and fruitless. They don't advance anybody's understanding of anything important, like the substance of the whatever those labels might apply to. Arguing about whether or not "Lisp" means "Common Lisp" doesn't advance anybody's understanding of Common Lisp.
        delish 8y ago
        I agree with everything you said. The argument is tedious and fruitless. My point is an empirical one: Programmers of a Certain Age were more likely to use "Lisp" than programmers of other ages.
        kazinator 8y ago
        The sentence at the root of this subthread, namely "I do really wish that Guix used Lisp rather than Scheme" isn't an argument about labels.
        darkpuma 8y ago
        No, but the terminology of the root was plainly coming from the camp of "Scheme isn't Lisp, Common Lisp is Lisp." The child comment was confused by that peculiar terminology, so I provided context for that terminology in a way that I hoped would head off yet another argument about labels. It was my intent to stop the argument before it began.
        deleted 8y ago
        [deleted]
        kazinator 8y ago
        The terminology is troublesome because "Scheme" more specifically determines the language than "Lisp", so "I'd prefer to use Lisp over Scheme" or vice versa is somewhat "apples versus vegetables".
        lispm 8y ago
    - paulddraper 8y ago
      What do those campers prefer for what others would have called "Lisp"?
      - darkpuma 8y ago
        In my experience they often prefer that scheme/etc ceased to exist at all. I've had conversations with CL fanatics who accuse Scheme/etc of diluting Lisp by merely existing, and thereby harming CL. Others aren't so extreme and just want people to stop saying "scheme is type of lisp."
        zeveb 8y ago
        I don't mind that Scheme exists, but I do mind that enthusiasts naively use it to build production systems, because they end up wasting time & energy re-implementing things the Common Lisp standard already specifies rather than spending that time & energy on the problems that they're actually trying to solve. Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things. Meanwhile, the ecosystems of non-Lisp-family languages grow ever-larger, and hence ever-more-appealing, which is a problem because while Scheme-the-language is better than Python-the-language or Go-the-language, Scheme-the-fractured-ecosystem is worse than Python-the-healthy-ecosystem or Go-the-astoundingly-robust-ecosystem, which means more people use Python & Go, which means fewer people use Lisp-family languages … it's a vicious cycle. Which means the world is a worse place, stuck in a local maximum of C-family languages and unable to break out to the Lispy global maximum.
        rekado 8y ago
        > Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things. I find this list a little funny, because we do have generic functions, packages, and the ability to extend the reader. In Guix we use reader extensions for G-expressions, for example. I grant you the separate namespaces thing, because, well, we really don't want to have a separate namespace for variables and procedures :)
  - eadmund 8y ago
    I do mean Common Lisp. I think that it'd be preferable for Guix to use it because Lisp is more production-ready than Scheme: it standardises things that Scheme — even R7R2 large — doesn't; it's a pragmatic production language into which a lot of experience went. And of course there's CLOS, which is absolutely awesome. Even better, a well-written Guix-Lisp would be portable between multiple Common Lisp implementations; it's extraordinarily difficult to write a real system in Scheme, precisely because Scheme is so under-specified: really, Guix isn't written in Scheme; it's written in Guile Scheme. Scheme is neat, and pretty, and very elegant, but it's not (even in its largest, most recent version) really meant for serious use on large systems. And I don't agree that it's a Lisp: it has only a single namespace, it breaks (car nil) → nil and (if nil "true" "false") → "false". I'm aware that rms dislikes Lisp and wants Scheme to be GNU's extension language; IMHO he's wrong, and his attitude has really held back GNU, Emacs and the Lisp world at large. Had it not been for that attitude, we might have a Common Lisp Emacs by now, we might have a Common Lisp GNU userland by now, we might have a GNU which really is Not Unix, instead of a mess of C, security bugs & hacks.
    - kazinator 8y ago
      Note that MacCarthy's Lisp didn't have (car nil); it was an error. I'm reluctant to insist that a language in the Lisp family must have (car nil), since that means that Lisp 1 and Lisp 1.5 aren't Lisp! See this text in Steele and Gabriel's The Evolution of Lisp: In the end only a trivial exchange of features resulted from "the great MacLisp/Interlisp summit": MacLisp adopted from Interlisp the behavior (CAR NIL) -> NIL and (CDR NIL) -> NIL, and Interlisp adopted the concept of a read table. However, whether or not (car nil) works, it should express "the first element of the empty list, which is also false", rather than "the first element of a symbol that isn't related to lists and isn't Boolean false".
dman 8y ago
Any pointers to an opinionated install guide that does not require me to configure every aspect of the system? Something that yields a working gnome/kde desktop with less than 10 minutes of effort would be ideal.
- Ambrevar 8y ago
  A more user-friendly installer is in the works and should hit Guix with 1.0. Currently, Guix comes with pre-filled operating system declarations so that beside filling out the hostname and a few other options, there is little to do but run `guix system init`. While Guix install is completely different from any other system (except Nix), it is suprisingly easy with nothing else but 2-3 steps (if you have Linux-libre compatible hardware, that is to say).
  - dman 8y ago
    Thanks - really looking forward to moving my workstations to something like GUIX, the productivity gains will be immense.
hardwaresofton 8y ago
Guix seems interesting but I almost stopped reading when I read "Nix". For all the benefits the Nix ecosystem provides, they haven't crossed the usability gap for me. First was naming their packages so confusingly, Nix the language vs NixOS vs Nix the package manager. Then there's the whole promise of it being usable from multiple platforms ("you don't even have to use NixOS, just use the package manager for awesome builds") -- It was supposedly amazing for building some software packages, but the reality was always so sticky and never quite panned out. To be fair I have seen/heard lots praise it a lot for delivering stability to the servers they manage, but in this day and age, I'm not sure it's even worth trying to learn something to manage servers when the cattle approach is so much better (just shoot it). Even when stateful applications get involved, distributed storage is springing up to make it easier than ever to take down a server but have the data it had still be accessible, granted it was replicated, and sync if/when the machine ever comes back up. If the world evolves in that direction, it seems like people will only care about packages at VM/container/whatever base layer build time. Don't want to be the downer here but I don't think it's likely that Guix is going to cross the usability chasm. I've invested a lot of time/interest/effort in projects that were better, but never crossed the usability/mindshare chasm and while I hope I'm wrong, this feels like some of the other ones. Completely unrelated to that though, this quote rang true to me: > Guix is a fork of Nix and addresses the main issue that Nix didn’t get right: instead of comming up with a homebrewed domain-specific language (DSL) with its own set of limitations and idiosyncrasies, Guix uses a full-fledged programming language. (And a good one at that, since it’s Guile Scheme, a Lisp-based language.) I think Hashicorp has this problem with HCL (see the recent updates[0] announced at the last HashiConf, the `for` keyword is now in HCL) -- though I'm not recommending they fix the problem with lisp, people need to stop making DSLs then bridging the gap between their DSL and a full programming language. I much prefer the Pulumi[1]'s approach -- though it leaves devs lots of rope to hang themselves with ("recursive infrastructure building functions...why not?"). [0]: https://www.hashicorp.com/resources/keynote-terraform-free-saas-tier-hcl-upgrades https://www.hashicorp.com/resources/keynote-terraform-free-s... [1]: https://pulumi.io/reference/how.html https://pulumi.io/reference/how.html
- sterlind 8y ago
  NixOS fangirl here... you're totally right about usability! Git was self-hosting from day 3, but consisted only of a few pieces of exposed plumbing. As more porcelain was bolted on, it got to the point where flashy UIs could exist. Porcelain isn't all trivial either - consider "git rebase"! NixOS today is like early Git.. usable and powerful, but not user-friendly. It needs a good UI, a graphical installer, and high-level porcelain to hide the plumbing unless you need to drop into it. As for the cattle question, I think Nix's real power will come from efficient, declarative "Dockerfiles" and serving as a Bazel-like build system. There was a project for this, Hocker, but it seems inactive.
macintux 8y ago
> TeX, LaTeX (and all the derivatives), Asymptote (better ideas: scribble, skribilo) It’s hard to take screeds like this seriously when their suggested alternatives use LaTeX for output!
- Ambrevar 8y ago
  This is sadly a good point... Scribble and skribilo are not finished, there are some (very unfinished) works to implement a new PDF generator (at least for skribilo). I only said it was a "better idea", not a "better finished product", but I should have been more explicit. Will fix.
- rekado 8y ago
  Skribilo can use lout for output.
sterlind 8y ago
I started using NixOS over Christmas and I have no trouble whatsoever with the language. It seems pretty lazy for the author to shoot Nix down on the grounds that DSLs are "always a bad idea." He even has the nerve to mention Mozilla as failing with XUL, while ignoring the success of Rust! Nix is lightweight, pure and maximally lazy. It's a simple DSL that evaluates targets -> derivations (build specs.) Considering it can build an entire OS with so few features, I'm not sure adding a numeric tower and Turing-completeness is really desirable. Also, I'm surprised this article doesn't mention Hydra. Reproducible binary caches and automatic testing are one of the key advantages of these systems -- does Guix use it?
- Ericson2314 8y ago
  I agree but in fairness Nix is also turing complete. I prefer to think that Nix "out-schemes" scheme.
  - paulddraper 8y ago
    Is Guix not?
    - Ericson2314 8y ago
      Guile Scheme and Nix both are.
- yjftsjthsd-h 8y ago
  > He even has the nerve to mention Mozilla as failing with XUL, while ignoring the success of Rust! Um. Rust is not a DSL; if XUL failed and Rust succeeded, then that's (weak) evidence in favor of "DSLs suck".
- jchw 8y ago
  I also started using NixOS around Christmas time. I really love NixOS, but I'm at best lukewarm on Nix as a language. Honestly, though, the language is not my current concern. My current concern is actually more about compartmentalization. Being able to run `nix-shell -p` and get a shell with a program installed is super cool. Also, being able to add a package to the system declaratively is super cool. However, one thing I wonder about is workflows. For example, I have a lot of Jetbrains IDEs installed for various languages, but I don't want to pollute my global environment with tools, especially command line tools that pollute the PATH. Let's say I want to use Jetbrains Rider. I can easily start a shell with the dotnet SDK with `nix-shell -p dotnet`, then start Rider under that shell. This is OK, but it feels wrong to me. It feels weird that launching Rider outside of nix-shell won't ever work, yet it's installed globally. And yet, I also kind of want it to be globally installed... Another solution would be to have Nix expressions for every project I work on. This actually seems better and I've adopted it for a couple projects, but it also irks me because it feels half-baked. I don't know where to put these expressions other than next to the project, but I don't think it belongs in version control. Also, I'm very mixed for what belongs in these environments. Should it be personally suited, with my IDE and developer tools? If I do that, I can't share the same code I'd use for my tooling as I would for my Nixpkg (assuming there is a nixpkg) which leads to a divergence I don't like. (Though maybe that can be solved?) I almost want a robust system of working environments that encapsulates this. So, I could think about my Nix workflows as separate environments. Declarative or imperative, and ideally with more encapsulation than a typical nix-shell. Maybe instead of orienting my workflow around opening an IDE and opening a project, I can orient it around opening a project environment and then opening an IDE inside of it. At this point I'm just rambling. I still prefer NixOS for practical reasons, since it makes my complex IOMMU setup a cinch and keeps all of the configuration for it surfaced and documented. But dang, the potential here to shift workflow paradigms is enormous, it feels.
fwip 8y ago
> GuixSD strimes at being the “fully-programmable OS." What does this mean? Google is suggesting it has something to do with weed-whackers, and I'm guessing that's not right.
- syrrim 8y ago
  probably s/strimes/strives
  - Ambrevar 8y ago
    Indeed, thanks for catching the typo!
bscphil 8y ago
>GNU/Linux distributions in general lack the aforementioned perks of Guix. Some of the most critical points include: >Lack of support for multiple package version, or “dependency hell”. Say, when the latest mpv requires a new ffmpeg, but upgrading ffmpeg breaks most other programs relying on it, we are stuck we dilemma: either we break some packages or we stick to older versions of other packages. Worse, a program could end up not being packaged or support by the OS at all. This issue is inherent to most distributions which can simply not provide the guarantee to fulfill their primary objective: package any program. I disagree. Having multiple versions of a package means having old versions of a package, and that's something most users should not be messing with because they are not in a position to track and backport security fixes. It's always undesirable to have to a dependency on an old, probably unsupported version of a library. The distributions that do it have a correspondingly huge maintenance burden. One of the advantages (from my point of view) of a lighter rolling distribution like Arch is that because all the software on the system is expected to be compatible with a library version that is upstream-supported, there is significantly less maintenance work to be done. Note that this is compatible with, say, packaging both GTK2 and GTK3 programs, since both of those are supported upstream. The OS is perfectly compatible with shipping multiple versions of a library, but Arch sensibly (IMO) chooses not to do so by default. One way to quickly experience the pain points of the OP's way of doing things is to try to use or distribute software written in a language with a "modern" build tool like npm or cargo. These systems implicitly encourage hardcoding a single version (or a small set of versions) as dependencies, and the convenience of this means that many developers rarely update the list even if the new library versions are fully compatible with their code. So as the user building the software, or someone who wants to distribute it, you can either run with libraries that have known vulnerabilities, or you can update the libraries yourself and run an unsupported configuration, hoping you don't break anything in the process. A more reasonable position is that it is a bug if your program crashes with the latest version of a library.
- zapzupnz 8y ago
  > A more reasonable position is that it is a bug if your program crashes with the latest version of a library This makes sense for actively maintained code. There are a lot of pieces of software that aren't actively maintained but that don't exhibit any breaking bugs and people continue to rely on them. If the libraries that these pieces of software ever make breaking changes, either (a) someone has to step up and start maintaining the software again, (b) an older version of the library must be installed, or (c) the software dropped, annoying a lot of people who still depend on the tool. What macOS has is .frameworks, which let you version shared dynamic libraries. When building a project against a framework, one can either choose to build against a specific version or (more commonly) leave the version unspecified and use the latest. No fuss, no muss.
SeaDude 8y ago
I really want the things Guix provides, but I'm not a computer scientist. Feels like you need to be to make it work somewhat like the linux desktop I enjoy computing on (text editor, graphical web browser, sky, virtualbox, postman, osb, keepassxc, etc.)
- Ambrevar 8y ago
  If you look at https://guix-hpc.bordeaux.inria.fr/browse https://guix-hpc.bordeaux.inria.fr/browse? you'll find most of your wishes there, and many more to come hopefully. Guix is also working on an installer to help reducing the friction. I'd personally like to work on a fully graphical install + package management. While Guix sounds like some heavy scientific stuff, it really is a powerful base that allows anything to grow on top, including user-friendly interfaces.
- rekado 8y ago
  I'm one of the Guix co-maintainers and a Guix user, but I'm not a computer scientist. The biggest thing that might be annoying for someone who is not comfortable with Lisp is probably the operating system configuration, which is done with Scheme. For installing packages, however, you can use the command line interface, or the convenient Emacs user interface --- neither of those require any programming knowledge.
- AnIdiotOnTheNet 8y ago
  Sadly the innovation in Guix and Nix is to bring even more complication what should be the straight-forward task of getting software on your machine, not less.
orangeshark 8y ago
Guix and GuixSD are definitely interesting. I am currently running Guix on top of Fedora for my desktop and just recently started running GuixSD on my laptop. Probably my favorite feature that I use the most is guix environment which can help me set up all the necessary packages needed to build and work on projects. I think there is a lot of hidden potential in Guix, especially with the choice of Guile as the language. The article demonstrates a bit of what you can do from Guile with some small script examples. A lot of the functionality of Guix is exposed and can be used to create tools and scripts. I sort of wonder what interesting tools and scripts will be made using this.
- vindarel 8y ago
  Nice. What languages do you build environments for ? Are they ready for a typical python & JS (vuejs) project ?
  - rekado 8y ago
    Python: sure. JS: ... it's complicated. See this article for an introduction to the problems of attempting to match npm with principled package management: https://dustycloud.org/blog/javascript-packaging-dystopia/ https://dustycloud.org/blog/javascript-packaging-dystopia/
  - orangeshark 8y ago
    I have used guix environments for python, c++, and guile projects.
ethanpil 8y ago
I don't understand why these config systems can't be less 'programmy' (less technical). All of these (Nix/Guix/NginX Lua, etc) config systems are all so complex with layers of interesting syntax and punctuation. Why can't these use simpler (INI/YAML/TOML/CSON or even JSON) configuration schemes? It would reduce barrier to entry - simplify parsing and automation, and a whole lot of other things. Why do I need to learn yet another language just to configure and manage my system?
- kodablah 8y ago
  > Why can't these use simpler [...] configuration schemes? Because you inevitably need something less simple at some point. It's a hard balance to strike. Want only a config format? Get angry advanced users. Want only a programming language? Get angry beginners. Want both? Get a hodge-podge of half-and-half configs calling out to built extensions and in general a bunch of beginners finding poor code-based solutions on the internet. In general, you need a simple programming language to manage this stuff or it becomes unwieldy once it leaves hobbyist size. And mixing config formats and full-blown languages (or worse, template languages) just adds ambiguity on the best way to do something coupled with loose synchronization between the two formats, "extension hell", and half-developed code solutions with an exponential number of poorly tested combinations of exported features that beginners try to use. To see examples of all these problems, one simply has to look at the historical landscape of orchestration engines and build tools.
  - edwintorok 8y ago
    Some food for thought: https://dhall-lang.org/ https://dhall-lang.org/ looks like an interesting balance between config file format and programmability. Would it be suitable for describing packages?
    - Ambrevar 8y ago
      I don't think that would be enough. At the end of the article I linked the paper "Code staging in GNU Guix" (https://arxiv.org/abs/1709.00833 https://arxiv.org/abs/1709.00833) which explains why 2 stages of code execution are so central in Guix. In practice, this means that a Turing-complete language (Scheme) is used both at the declaration level and the build level. Lots of packages make use of this feature, it brings tremendous flexibility to packaging.
IshKebab 8y ago
> Even if the devs don't need Turing-completeness, not adding it to a project is effectively limitating what the user can do with a program. But limiting what people can do with build systems is generally a good thing.
- Ambrevar 8y ago
  Why? Also one core feature of Guix is that it cannot break: you can always roll back.
  - IshKebab 8y ago
    Because then tools can reason about the build system. Also it limits the crazy things people try to do.
deleted 8y ago
[deleted]
k__ 8y ago
I tried NixOS a few years ago when they talked about better UX for the CLI. Anyone know if this happend?
- akavel 8y ago
  It does slowly happen. There's a new `nix` command (a.k.a. Nix 2.0), which has a better CLI, though it's not yet 100% complete, I believe. But already useful (e.g. `nix search`). https://nixos.org/nix/manual/#ssec-relnotes-2.0 https://nixos.org/nix/manual/#ssec-relnotes-2.0
  - k__ 8y ago
    Nice. Does Guix have a better CLI?
    - Ambrevar 8y ago
      Guix CLI is quite different and I've heard a few times people comparing it favorably to Nix. I haven't used Nix enough to compare myself though.
    - civodul 8y ago
      Compared to Nix 1.x (not sure about 2.x), I think it's simpler to use (Guix co-maintainer here and before that a Nix contributor). This is the reference of 'guix package' (analogous to 'nix-env'): https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-package.html https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-pac... Because it's all Scheme, Guix has well defined APIs for all sorts of things. For instance, there's an API for search paths (environment variables you need to define when you install packages), one to create application bundles, one to create VMs containing GuixSD, etc. That, in turn, leads to clean CLIs in my opinion: 'guix package --search-paths', 'guix pack', 'guix system vm', etc.
mark_l_watson 8y ago
I have a question for GuixSD users here: I have a laptop with NVidia CUDA, TensorFlow, mxnet, Python, Julia, etc. installed. I experimented with NixOS last year, liked it, and being long time Lisp user I would like to also try GuixSD. Would I have problems with CUDA, etc.?
- rekado 8y ago
  CUDA is problematic. There is no package for CUDA in the official Guix channels, because it is non-free software. There is a patch for a Tensorflow package, which is built without GPU support (because that requires CUDA), but it hasn't been merged yet, because it isn't really pretty. (I didn't use Bazel to build Tensorflow, because Bazel depends on dozens of Java archives that cannot easily be built exclusively from source.) You can use Nix as an additional package manager on top of a Guix system, of course, but this might not be as satisfying as using one package manager exclusively.
rekado 8y ago
Guix co-maintainer here. The article says "Guix is a fork of Nix", but this is not correct. Guix uses the same format for derivations (~ a low-level representation of builds), so that it can reuse the Nix daemon, but that doesn't make it a fork. Guix builds upon the very same idea of functional package management that was pioneered with Nix, so they are very close and they do have shared roots. But that's not what "fork" is usually understood to mean. Here's something I wrote a few months ago (with minor changes) to clarify the relationship between these two projects. I hope this helps. ------------------- As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what I consider some important unique features of Guix: - Guix is all written in Guile Scheme (with the exception of parts of the inherited daemon, which hasn't yet been completely implemented in Guile); this extends to development tools like importers, updaters, to user tools like "guix environment", and even bleeds into other projects that are used by GuixSD (the GNU system distribution built around Guix), such as the shepherd init system. There is a lot of code reuse across the stack, which makes hacking on Guix really fun and smooth. - Packages are first class citizens in Guix. In Nix the idea of functional package management is very obvious in the way that packages are defined, namely as functions. These functions take their concrete inputs from an enormous mapping. In Guix you define first-class package values as Scheme variables. These package values reference other package values, which leads to a lazily constructed graph of packages. This emergent graph can be used as a library to trivially build other tools like "guix graph" (for visualising the graph in various ways) or "guix web" (for a web interface to installing and searching packages), "guix refresh" (for updating package definitions), a lovely feature-rich Emacs interface etc. - Embedded DSL. Since Guix is written in Scheme---a language for writing languages---it was an obvious choice to embed the package DSL in the host language Scheme instead of implementing a separate language that needs a custom interpreter. This is great for hacking on Guix, because you can use all the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a debugger, etc. With its support for hygienic macros, Scheme is also a perfect vehicle to implement features like monads (we use a monadic interface for talking to the daemon) and to implement other convenient abstractions. - Graph rewriting. Having everything defined as regular Scheme values means that you can almost trivially go through the package graph and rewrite things, e.g. to replace one variant of a package with a different one. Your software environment is just a Scheme value and can be inspected or precisely modified with a simple Scheme API. - Code staging. Thanks to different ways of quoting code (plain S-expressions and package-aware G-expressions), we use Scheme at all stages: on the "host side" as well as on the "build side". Instead of gluing together shell snippets to be run by the daemon we work with the AST of Scheme code at all stages. If you're interested in code staging I recommend reading this paper: https://hal.inria.fr/hal-01580582/en https://hal.inria.fr/hal-01580582/en - Bootstrapping. Some of us are very active in the "bootstrappable builds" community (see http://bootstrappable.org http://bootstrappable.org) and are working towards full bootstrap paths for self-hosting compilers and build systems. One result is a working bootstrap path of the JDK from C (using jikes, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping problems serious and prefer to take the longer way to build things fully from source instead of just adding more binary blobs. This means that we cannot always package as many things as quickly as others (e.g. Java libraries are hard to build recursively from source). I'm currently working on bootstrapping GHC without GHC and without the generated C code, but via interpreting a variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme. - GuixSD, the GNU system distribution built around Guix. GuixSD has many features that are very different from NixOS. The declarative configuration in Scheme includes system facilities, which also form a graph that can be inspected and extended; this allows for the definition of complex system facilities that abstract over co-dependent services and service configurations. GuixSD provides more Scheme APIs that apply to the whole system, turning your operating system into a Scheme library. - I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many perceived problems with the UI have been addressed, of course, but hey, I still prefer the Guix way. I also really like the Emacs interface, which is absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D buffers over 1D command line strings.) - It's what I want GNU to be. I'm a GNU hacker and to me Guix is a representative of a modern and innovative GNU. It's great to see more GNU projects acting as one within the context of Guix and GuixSD to provide an experience that is greater than the sum of its parts. Work on Guix affected other GNU packages such as the Hurd, Guile, Mes, cool Guile libraries, and led to a bunch of new GNU packages such as a workflow language for scientific computing. On the other hand, although Guix has a lot of regular contributors and is very active, Nix currently has more contributors than Guix. Guix is a younger project. The tendency to take bootstrapping problems very seriously means that sometimes difficult packages require more work. Oddly, Guix seems to attract more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with Scheme after watching the SICP lecture videos); it seems to be the other way around with Nix. Having said all that: Nix and Guix are both implementations of functional package management. Both projects solve similar problems and both are active in the reproducible builds efforts. Solutions that were found by Nix devs sometimes make their way into Guix and vice versa. The projects are not competing with one another (there are orders of magnitudes more people out there who use neither Guix nor Nix than there are users of functional package managers, so there's no point in trying to get people who use Nix to switch to Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who invented functional package management and Nix) gave a talk on the future of Nix surrounded by Guix hackers --- there is no rivalry between these two projects.
tomp 8y ago
I only skimmed, but parts of this article read as just another pro-LISP piece... A rant against other languages (which the author terms "DSLs" simply because they're not Turing complete) like LaTeX, HTML, regex, SQL etc. and lists alternatives, all of which are S-expression-based. Well, the superiority of S-expressions is just, like, your opinion, man. Personally, I consider them inferior to pretty much any other syntax (joke languages like Brainfuck, Whitespace, JavaScript excluded). An in absolute terms, the whole civilisation was built on syntax-full DSLs (law, math, engineering, ...). I mean, how is this (Skribilo): (define (freedom . body) (ref :url "http://www.gnu.org/philosophy/free-sw.html" :text body)) (p [Skribilo is a ,(freedom [free]) document production tool that takes a structured document ...]) better than this (LaTeX): Skribilo is a \href{http://www.gnu.org/philosophy/free-sw.html}{free} document production tool that takes a structured document ...
- equalunique 8y ago
  Instead of a pro-scheme rant one could interpret it also as a NixOS pitch using a scheme API instead of a DSL.
- Ambrevar 8y ago
  The article is for the bigger part about operating systems, only a minor part is about programming languages (which is important for the matter at hand). It's not pro-Lisp in particular, it's pro-"general-purpose, well tested and well designed programming languages". I don't exlude other programming languages from the picture. The alternative I gave as examples are the ones that I know of, but sure thing there are others out there in Python, Lua, Ruby, you name it. I personally like S-expressions because they are very general and have deep semantic implications (eval-apply, a.k.a. code is data) that go beyond mere syntactic considerations. Regarding your examples, if I understand correctly they are not equivalent, so they don't exactly compare. Here LaTeX would require the \begin{document}...\end{document} bits. But regardless, TeX is very painful to program with (lack of proper data structures and control structures). It's very important in my opinion.
  - _emacsomancer_ 8y ago
equalunique 8y ago
Nix and Guix both excite me a lot. Guix as a Guile scheme API is a very exciting, but what I like more is, as a result of that, Guix & it's derivations are all part of the same repo. Because they are one in the same I can be sure I'm not going to build a package that hasn't been tested against the version of guix I am running. It simplifies integration testing if I decide to create a new branch of Guix packages.
wuschel 8y ago
Looks to me like Guix is Nix with a Scheme based language (Guile) instead of the Nix specific DSL.
theusername 8y ago
I don't get it. Yeah guix is good. But AFAIK GuixSD has no support for modern hardwares due to their policy toward firmware blobs. So how's a OS being advanced without good hardware support?
_emacsomancer_ 8y ago
I'd really like to see Shepherd used outside of GuixSD. In theory, since Guix can be installed on top of other distros, this could be leveraged to be make swapping in Shepherd easier. Of course, systemd is much more complex, so replacing the init in systemd-based distro would probably be trickier, but it should be more manageable in places like Void Linux.
- theamk 8y ago
  Shepherd is quite scary outside of GUIX. It basically runs package-supplied code in PID 1, with no protection. A badly written init script will halt startup completely and render system unbootable. GUIX (I believe) has this "choose previous version from GRUB" dialog, so you can recover from bad init script by rolling back the whole thing. Any other OS will require manual fixes, and this is going to be quite a pain.
  - _emacsomancer_ 8y ago
    Ah, thanks for the additional information. That's too bad though, I like the model of a Scheme-based init. I suppose I'll stick with runit for now then.

313 points by Ambrevar 8y ago

vemv 8y ago

Exciting stuff. There's been bit of a Lisp renaissance over the last 5-10 years (thanks to the Emacs packaging system, Clojure) so this could be the next logical step for someone who writes parens for a living.

eadmund 8y ago

I do really wish that Guix used Lisp rather than Scheme.

draven 8y ago
You mean Common Lisp ? Because Scheme is a Lisp. Guix is from GNU, Scheme is their official extension language (with Guile as the implementation.)
- darkpuma 8y ago
  It's a tedious fruitless argument that goes back years. Some people in the "Common Lisp camp" believe that Common Lisp has the "rights" to the 'Lisp' "trademark."
  - delish 8y ago
    As someone who programs in Clojure--and therefore has no justification for weighing in--I _believe_ that it's a cultural or generational difference. That is, for certain programmers (working in the 1980s? 1990s?) "Lisp" (capital-L, lower-case isp) meant Common Lisp, and many agreed. I am sure that people tediously, fruitlessly argue about it. But it's also true that for a wide swath of programmers, Lisp is Common Lisp. I wonder if hn's lisper or lispm could weigh in...
    - darkpuma 8y ago
      Arguments about labels are always tedious and fruitless. They don't advance anybody's understanding of anything important, like the substance of the whatever those labels might apply to. Arguing about whether or not "Lisp" means "Common Lisp" doesn't advance anybody's understanding of Common Lisp.
      - delish 8y ago
        I agree with everything you said. The argument is tedious and fruitless. My point is an empirical one: Programmers of a Certain Age were more likely to use "Lisp" than programmers of other ages.
      - kazinator 8y ago
        The sentence at the root of this subthread, namely "I do really wish that Guix used Lisp rather than Scheme" isn't an argument about labels.
        darkpuma 8y ago
        No, but the terminology of the root was plainly coming from the camp of "Scheme isn't Lisp, Common Lisp is Lisp." The child comment was confused by that peculiar terminology, so I provided context for that terminology in a way that I hoped would head off yet another argument about labels. It was my intent to stop the argument before it began.
        deleted 8y ago
        [deleted]
        kazinator 8y ago
        The terminology is troublesome because "Scheme" more specifically determines the language than "Lisp", so "I'd prefer to use Lisp over Scheme" or vice versa is somewhat "apples versus vegetables".
      - lispm 8y ago
  - paulddraper 8y ago
    What do those campers prefer for what others would have called "Lisp"?
    - darkpuma 8y ago
      In my experience they often prefer that scheme/etc ceased to exist at all. I've had conversations with CL fanatics who accuse Scheme/etc of diluting Lisp by merely existing, and thereby harming CL. Others aren't so extreme and just want people to stop saying "scheme is type of lisp."
      - zeveb 8y ago
        I don't mind that Scheme exists, but I do mind that enthusiasts naively use it to build production systems, because they end up wasting time & energy re-implementing things the Common Lisp standard already specifies rather than spending that time & energy on the problems that they're actually trying to solve. Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things. Meanwhile, the ecosystems of non-Lisp-family languages grow ever-larger, and hence ever-more-appealing, which is a problem because while Scheme-the-language is better than Python-the-language or Go-the-language, Scheme-the-fractured-ecosystem is worse than Python-the-healthy-ecosystem or Go-the-astoundingly-robust-ecosystem, which means more people use Python & Go, which means fewer people use Lisp-family languages … it's a vicious cycle. Which means the world is a worse place, stuck in a local maximum of C-family languages and unable to break out to the Lispy global maximum.
        rekado 8y ago
        > Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things. I find this list a little funny, because we do have generic functions, packages, and the ability to extend the reader. In Guix we use reader extensions for G-expressions, for example. I grant you the separate namespaces thing, because, well, we really don't want to have a separate namespace for variables and procedures :)
- eadmund 8y ago
  I do mean Common Lisp. I think that it'd be preferable for Guix to use it because Lisp is more production-ready than Scheme: it standardises things that Scheme — even R7R2 large — doesn't; it's a pragmatic production language into which a lot of experience went. And of course there's CLOS, which is absolutely awesome. Even better, a well-written Guix-Lisp would be portable between multiple Common Lisp implementations; it's extraordinarily difficult to write a real system in Scheme, precisely because Scheme is so under-specified: really, Guix isn't written in Scheme; it's written in Guile Scheme. Scheme is neat, and pretty, and very elegant, but it's not (even in its largest, most recent version) really meant for serious use on large systems. And I don't agree that it's a Lisp: it has only a single namespace, it breaks (car nil) → nil and (if nil "true" "false") → "false". I'm aware that rms dislikes Lisp and wants Scheme to be GNU's extension language; IMHO he's wrong, and his attitude has really held back GNU, Emacs and the Lisp world at large. Had it not been for that attitude, we might have a Common Lisp Emacs by now, we might have a Common Lisp GNU userland by now, we might have a GNU which really is Not Unix, instead of a mess of C, security bugs & hacks.
  - kazinator 8y ago
    Note that MacCarthy's Lisp didn't have (car nil); it was an error. I'm reluctant to insist that a language in the Lisp family must have (car nil), since that means that Lisp 1 and Lisp 1.5 aren't Lisp! See this text in Steele and Gabriel's The Evolution of Lisp: In the end only a trivial exchange of features resulted from "the great MacLisp/Interlisp summit": MacLisp adopted from Interlisp the behavior (CAR NIL) -> NIL and (CDR NIL) -> NIL, and Interlisp adopted the concept of a read table. However, whether or not (car nil) works, it should express "the first element of the empty list, which is also false", rather than "the first element of a symbol that isn't related to lists and isn't Boolean false".

dman 8y ago

Any pointers to an opinionated install guide that does not require me to configure every aspect of the system? Something that yields a working gnome/kde desktop with less than 10 minutes of effort would be ideal.

Ambrevar 8y ago
A more user-friendly installer is in the works and should hit Guix with 1.0. Currently, Guix comes with pre-filled operating system declarations so that beside filling out the hostname and a few other options, there is little to do but run `guix system init`. While Guix install is completely different from any other system (except Nix), it is suprisingly easy with nothing else but 2-3 steps (if you have Linux-libre compatible hardware, that is to say).
- dman 8y ago
  Thanks - really looking forward to moving my workstations to something like GUIX, the productivity gains will be immense.

hardwaresofton 8y ago

Guix seems interesting but I almost stopped reading when I read "Nix". For all the benefits the Nix ecosystem provides, they haven't crossed the usability gap for me. First was naming their packages so confusingly, Nix the language vs NixOS vs Nix the package manager. Then there's the whole promise of it being usable from multiple platforms ("you don't even have to use NixOS, just use the package manager for awesome builds") -- It was supposedly amazing for building some software packages, but the reality was always so sticky and never quite panned out. To be fair I have seen/heard lots praise it a lot for delivering stability to the servers they manage, but in this day and age, I'm not sure it's even worth trying to learn something to manage servers when the cattle approach is so much better (just shoot it). Even when stateful applications get involved, distributed storage is springing up to make it easier than ever to take down a server but have the data it had still be accessible, granted it was replicated, and sync if/when the machine ever comes back up. If the world evolves in that direction, it seems like people will only care about packages at VM/container/whatever base layer build time. Don't want to be the downer here but I don't think it's likely that Guix is going to cross the usability chasm. I've invested a lot of time/interest/effort in projects that were better, but never crossed the usability/mindshare chasm and while I hope I'm wrong, this feels like some of the other ones. Completely unrelated to that though, this quote rang true to me: > Guix is a fork of Nix and addresses the main issue that Nix didn’t get right: instead of comming up with a homebrewed domain-specific language (DSL) with its own set of limitations and idiosyncrasies, Guix uses a full-fledged programming language. (And a good one at that, since it’s Guile Scheme, a Lisp-based language.) I think Hashicorp has this problem with HCL (see the recent updates[0] announced at the last HashiConf, the `for` keyword is now in HCL) -- though I'm not recommending they fix the problem with lisp, people need to stop making DSLs then bridging the gap between their DSL and a full programming language. I much prefer the Pulumi[1]'s approach -- though it leaves devs lots of rope to hang themselves with ("recursive infrastructure building functions...why not?"). [0]: https://www.hashicorp.com/resources/keynote-terraform-free-saas-tier-hcl-upgrades https://www.hashicorp.com/resources/keynote-terraform-free-s... [1]: https://pulumi.io/reference/how.html https://pulumi.io/reference/how.html

sterlind 8y ago
NixOS fangirl here... you're totally right about usability! Git was self-hosting from day 3, but consisted only of a few pieces of exposed plumbing. As more porcelain was bolted on, it got to the point where flashy UIs could exist. Porcelain isn't all trivial either - consider "git rebase"! NixOS today is like early Git.. usable and powerful, but not user-friendly. It needs a good UI, a graphical installer, and high-level porcelain to hide the plumbing unless you need to drop into it. As for the cattle question, I think Nix's real power will come from efficient, declarative "Dockerfiles" and serving as a Bazel-like build system. There was a project for this, Hocker, but it seems inactive.

macintux 8y ago

> TeX, LaTeX (and all the derivatives), Asymptote (better ideas: scribble, skribilo) It’s hard to take screeds like this seriously when their suggested alternatives use LaTeX for output!

Ambrevar 8y ago
This is sadly a good point... Scribble and skribilo are not finished, there are some (very unfinished) works to implement a new PDF generator (at least for skribilo). I only said it was a "better idea", not a "better finished product", but I should have been more explicit. Will fix.
rekado 8y ago
Skribilo can use lout for output.

sterlind 8y ago

I started using NixOS over Christmas and I have no trouble whatsoever with the language. It seems pretty lazy for the author to shoot Nix down on the grounds that DSLs are "always a bad idea." He even has the nerve to mention Mozilla as failing with XUL, while ignoring the success of Rust! Nix is lightweight, pure and maximally lazy. It's a simple DSL that evaluates targets -> derivations (build specs.) Considering it can build an entire OS with so few features, I'm not sure adding a numeric tower and Turing-completeness is really desirable. Also, I'm surprised this article doesn't mention Hydra. Reproducible binary caches and automatic testing are one of the key advantages of these systems -- does Guix use it?

Ericson2314 8y ago
I agree but in fairness Nix is also turing complete. I prefer to think that Nix "out-schemes" scheme.
- paulddraper 8y ago
  Is Guix not?
  - Ericson2314 8y ago
    Guile Scheme and Nix both are.
yjftsjthsd-h 8y ago
> He even has the nerve to mention Mozilla as failing with XUL, while ignoring the success of Rust! Um. Rust is not a DSL; if XUL failed and Rust succeeded, then that's (weak) evidence in favor of "DSLs suck".
jchw 8y ago
I also started using NixOS around Christmas time. I really love NixOS, but I'm at best lukewarm on Nix as a language. Honestly, though, the language is not my current concern. My current concern is actually more about compartmentalization. Being able to run `nix-shell -p` and get a shell with a program installed is super cool. Also, being able to add a package to the system declaratively is super cool. However, one thing I wonder about is workflows. For example, I have a lot of Jetbrains IDEs installed for various languages, but I don't want to pollute my global environment with tools, especially command line tools that pollute the PATH. Let's say I want to use Jetbrains Rider. I can easily start a shell with the dotnet SDK with `nix-shell -p dotnet`, then start Rider under that shell. This is OK, but it feels wrong to me. It feels weird that launching Rider outside of nix-shell won't ever work, yet it's installed globally. And yet, I also kind of want it to be globally installed... Another solution would be to have Nix expressions for every project I work on. This actually seems better and I've adopted it for a couple projects, but it also irks me because it feels half-baked. I don't know where to put these expressions other than next to the project, but I don't think it belongs in version control. Also, I'm very mixed for what belongs in these environments. Should it be personally suited, with my IDE and developer tools? If I do that, I can't share the same code I'd use for my tooling as I would for my Nixpkg (assuming there is a nixpkg) which leads to a divergence I don't like. (Though maybe that can be solved?) I almost want a robust system of working environments that encapsulates this. So, I could think about my Nix workflows as separate environments. Declarative or imperative, and ideally with more encapsulation than a typical nix-shell. Maybe instead of orienting my workflow around opening an IDE and opening a project, I can orient it around opening a project environment and then opening an IDE inside of it. At this point I'm just rambling. I still prefer NixOS for practical reasons, since it makes my complex IOMMU setup a cinch and keeps all of the configuration for it surfaced and documented. But dang, the potential here to shift workflow paradigms is enormous, it feels.

fwip 8y ago

> GuixSD strimes at being the “fully-programmable OS." What does this mean? Google is suggesting it has something to do with weed-whackers, and I'm guessing that's not right.

syrrim 8y ago
probably s/strimes/strives
- Ambrevar 8y ago
  Indeed, thanks for catching the typo!

bscphil 8y ago

>GNU/Linux distributions in general lack the aforementioned perks of Guix. Some of the most critical points include: >Lack of support for multiple package version, or “dependency hell”. Say, when the latest mpv requires a new ffmpeg, but upgrading ffmpeg breaks most other programs relying on it, we are stuck we dilemma: either we break some packages or we stick to older versions of other packages. Worse, a program could end up not being packaged or support by the OS at all. This issue is inherent to most distributions which can simply not provide the guarantee to fulfill their primary objective: package any program. I disagree. Having multiple versions of a package means having old versions of a package, and that's something most users should not be messing with because they are not in a position to track and backport security fixes. It's always undesirable to have to a dependency on an old, probably unsupported version of a library. The distributions that do it have a correspondingly huge maintenance burden. One of the advantages (from my point of view) of a lighter rolling distribution like Arch is that because all the software on the system is expected to be compatible with a library version that is upstream-supported, there is significantly less maintenance work to be done. Note that this is compatible with, say, packaging both GTK2 and GTK3 programs, since both of those are supported upstream. The OS is perfectly compatible with shipping multiple versions of a library, but Arch sensibly (IMO) chooses not to do so by default. One way to quickly experience the pain points of the OP's way of doing things is to try to use or distribute software written in a language with a "modern" build tool like npm or cargo. These systems implicitly encourage hardcoding a single version (or a small set of versions) as dependencies, and the convenience of this means that many developers rarely update the list even if the new library versions are fully compatible with their code. So as the user building the software, or someone who wants to distribute it, you can either run with libraries that have known vulnerabilities, or you can update the libraries yourself and run an unsupported configuration, hoping you don't break anything in the process. A more reasonable position is that it is a bug if your program crashes with the latest version of a library.

zapzupnz 8y ago
> A more reasonable position is that it is a bug if your program crashes with the latest version of a library This makes sense for actively maintained code. There are a lot of pieces of software that aren't actively maintained but that don't exhibit any breaking bugs and people continue to rely on them. If the libraries that these pieces of software ever make breaking changes, either (a) someone has to step up and start maintaining the software again, (b) an older version of the library must be installed, or (c) the software dropped, annoying a lot of people who still depend on the tool. What macOS has is .frameworks, which let you version shared dynamic libraries. When building a project against a framework, one can either choose to build against a specific version or (more commonly) leave the version unspecified and use the latest. No fuss, no muss.

SeaDude 8y ago

I really want the things Guix provides, but I'm not a computer scientist. Feels like you need to be to make it work somewhat like the linux desktop I enjoy computing on (text editor, graphical web browser, sky, virtualbox, postman, osb, keepassxc, etc.)

Ambrevar 8y ago
If you look at https://guix-hpc.bordeaux.inria.fr/browse https://guix-hpc.bordeaux.inria.fr/browse? you'll find most of your wishes there, and many more to come hopefully. Guix is also working on an installer to help reducing the friction. I'd personally like to work on a fully graphical install + package management. While Guix sounds like some heavy scientific stuff, it really is a powerful base that allows anything to grow on top, including user-friendly interfaces.
rekado 8y ago
I'm one of the Guix co-maintainers and a Guix user, but I'm not a computer scientist. The biggest thing that might be annoying for someone who is not comfortable with Lisp is probably the operating system configuration, which is done with Scheme. For installing packages, however, you can use the command line interface, or the convenient Emacs user interface --- neither of those require any programming knowledge.
AnIdiotOnTheNet 8y ago
Sadly the innovation in Guix and Nix is to bring even more complication what should be the straight-forward task of getting software on your machine, not less.

orangeshark 8y ago

Guix and GuixSD are definitely interesting. I am currently running Guix on top of Fedora for my desktop and just recently started running GuixSD on my laptop. Probably my favorite feature that I use the most is guix environment which can help me set up all the necessary packages needed to build and work on projects. I think there is a lot of hidden potential in Guix, especially with the choice of Guile as the language. The article demonstrates a bit of what you can do from Guile with some small script examples. A lot of the functionality of Guix is exposed and can be used to create tools and scripts. I sort of wonder what interesting tools and scripts will be made using this.

vindarel 8y ago
Nice. What languages do you build environments for ? Are they ready for a typical python & JS (vuejs) project ?
- rekado 8y ago
  Python: sure. JS: ... it's complicated. See this article for an introduction to the problems of attempting to match npm with principled package management: https://dustycloud.org/blog/javascript-packaging-dystopia/ https://dustycloud.org/blog/javascript-packaging-dystopia/
- orangeshark 8y ago
  I have used guix environments for python, c++, and guile projects.

ethanpil 8y ago

I don't understand why these config systems can't be less 'programmy' (less technical). All of these (Nix/Guix/NginX Lua, etc) config systems are all so complex with layers of interesting syntax and punctuation. Why can't these use simpler (INI/YAML/TOML/CSON or even JSON) configuration schemes? It would reduce barrier to entry - simplify parsing and automation, and a whole lot of other things. Why do I need to learn yet another language just to configure and manage my system?

kodablah 8y ago
> Why can't these use simpler [...] configuration schemes? Because you inevitably need something less simple at some point. It's a hard balance to strike. Want only a config format? Get angry advanced users. Want only a programming language? Get angry beginners. Want both? Get a hodge-podge of half-and-half configs calling out to built extensions and in general a bunch of beginners finding poor code-based solutions on the internet. In general, you need a simple programming language to manage this stuff or it becomes unwieldy once it leaves hobbyist size. And mixing config formats and full-blown languages (or worse, template languages) just adds ambiguity on the best way to do something coupled with loose synchronization between the two formats, "extension hell", and half-developed code solutions with an exponential number of poorly tested combinations of exported features that beginners try to use. To see examples of all these problems, one simply has to look at the historical landscape of orchestration engines and build tools.
- edwintorok 8y ago
  Some food for thought: https://dhall-lang.org/ https://dhall-lang.org/ looks like an interesting balance between config file format and programmability. Would it be suitable for describing packages?
  - Ambrevar 8y ago
    I don't think that would be enough. At the end of the article I linked the paper "Code staging in GNU Guix" (https://arxiv.org/abs/1709.00833 https://arxiv.org/abs/1709.00833) which explains why 2 stages of code execution are so central in Guix. In practice, this means that a Turing-complete language (Scheme) is used both at the declaration level and the build level. Lots of packages make use of this feature, it brings tremendous flexibility to packaging.

IshKebab 8y ago

> Even if the devs don't need Turing-completeness, not adding it to a project is effectively limitating what the user can do with a program. But limiting what people can do with build systems is generally a good thing.

Ambrevar 8y ago
Why? Also one core feature of Guix is that it cannot break: you can always roll back.
- IshKebab 8y ago
  Because then tools can reason about the build system. Also it limits the crazy things people try to do.

deleted 8y ago

[deleted]

k__ 8y ago

I tried NixOS a few years ago when they talked about better UX for the CLI. Anyone know if this happend?

akavel 8y ago
It does slowly happen. There's a new `nix` command (a.k.a. Nix 2.0), which has a better CLI, though it's not yet 100% complete, I believe. But already useful (e.g. `nix search`). https://nixos.org/nix/manual/#ssec-relnotes-2.0 https://nixos.org/nix/manual/#ssec-relnotes-2.0
- k__ 8y ago
  Nice. Does Guix have a better CLI?
  - Ambrevar 8y ago
    Guix CLI is quite different and I've heard a few times people comparing it favorably to Nix. I haven't used Nix enough to compare myself though.
  - civodul 8y ago
    Compared to Nix 1.x (not sure about 2.x), I think it's simpler to use (Guix co-maintainer here and before that a Nix contributor). This is the reference of 'guix package' (analogous to 'nix-env'): https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-package.html https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-pac... Because it's all Scheme, Guix has well defined APIs for all sorts of things. For instance, there's an API for search paths (environment variables you need to define when you install packages), one to create application bundles, one to create VMs containing GuixSD, etc. That, in turn, leads to clean CLIs in my opinion: 'guix package --search-paths', 'guix pack', 'guix system vm', etc.

mark_l_watson 8y ago

I have a question for GuixSD users here: I have a laptop with NVidia CUDA, TensorFlow, mxnet, Python, Julia, etc. installed. I experimented with NixOS last year, liked it, and being long time Lisp user I would like to also try GuixSD. Would I have problems with CUDA, etc.?

rekado 8y ago
CUDA is problematic. There is no package for CUDA in the official Guix channels, because it is non-free software. There is a patch for a Tensorflow package, which is built without GPU support (because that requires CUDA), but it hasn't been merged yet, because it isn't really pretty. (I didn't use Bazel to build Tensorflow, because Bazel depends on dozens of Java archives that cannot easily be built exclusively from source.) You can use Nix as an additional package manager on top of a Guix system, of course, but this might not be as satisfying as using one package manager exclusively.

rekado 8y ago

Guix co-maintainer here. The article says "Guix is a fork of Nix", but this is not correct. Guix uses the same format for derivations (~ a low-level representation of builds), so that it can reuse the Nix daemon, but that doesn't make it a fork. Guix builds upon the very same idea of functional package management that was pioneered with Nix, so they are very close and they do have shared roots. But that's not what "fork" is usually understood to mean. Here's something I wrote a few months ago (with minor changes) to clarify the relationship between these two projects. I hope this helps. ------------------- As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what I consider some important unique features of Guix: - Guix is all written in Guile Scheme (with the exception of parts of the inherited daemon, which hasn't yet been completely implemented in Guile); this extends to development tools like importers, updaters, to user tools like "guix environment", and even bleeds into other projects that are used by GuixSD (the GNU system distribution built around Guix), such as the shepherd init system. There is a lot of code reuse across the stack, which makes hacking on Guix really fun and smooth. - Packages are first class citizens in Guix. In Nix the idea of functional package management is very obvious in the way that packages are defined, namely as functions. These functions take their concrete inputs from an enormous mapping. In Guix you define first-class package values as Scheme variables. These package values reference other package values, which leads to a lazily constructed graph of packages. This emergent graph can be used as a library to trivially build other tools like "guix graph" (for visualising the graph in various ways) or "guix web" (for a web interface to installing and searching packages), "guix refresh" (for updating package definitions), a lovely feature-rich Emacs interface etc. - Embedded DSL. Since Guix is written in Scheme---a language for writing languages---it was an obvious choice to embed the package DSL in the host language Scheme instead of implementing a separate language that needs a custom interpreter. This is great for hacking on Guix, because you can use all the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a debugger, etc. With its support for hygienic macros, Scheme is also a perfect vehicle to implement features like monads (we use a monadic interface for talking to the daemon) and to implement other convenient abstractions. - Graph rewriting. Having everything defined as regular Scheme values means that you can almost trivially go through the package graph and rewrite things, e.g. to replace one variant of a package with a different one. Your software environment is just a Scheme value and can be inspected or precisely modified with a simple Scheme API. - Code staging. Thanks to different ways of quoting code (plain S-expressions and package-aware G-expressions), we use Scheme at all stages: on the "host side" as well as on the "build side". Instead of gluing together shell snippets to be run by the daemon we work with the AST of Scheme code at all stages. If you're interested in code staging I recommend reading this paper: https://hal.inria.fr/hal-01580582/en https://hal.inria.fr/hal-01580582/en - Bootstrapping. Some of us are very active in the "bootstrappable builds" community (see http://bootstrappable.org http://bootstrappable.org) and are working towards full bootstrap paths for self-hosting compilers and build systems. One result is a working bootstrap path of the JDK from C (using jikes, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping problems serious and prefer to take the longer way to build things fully from source instead of just adding more binary blobs. This means that we cannot always package as many things as quickly as others (e.g. Java libraries are hard to build recursively from source). I'm currently working on bootstrapping GHC without GHC and without the generated C code, but via interpreting a variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme. - GuixSD, the GNU system distribution built around Guix. GuixSD has many features that are very different from NixOS. The declarative configuration in Scheme includes system facilities, which also form a graph that can be inspected and extended; this allows for the definition of complex system facilities that abstract over co-dependent services and service configurations. GuixSD provides more Scheme APIs that apply to the whole system, turning your operating system into a Scheme library. - I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many perceived problems with the UI have been addressed, of course, but hey, I still prefer the Guix way. I also really like the Emacs interface, which is absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D buffers over 1D command line strings.) - It's what I want GNU to be. I'm a GNU hacker and to me Guix is a representative of a modern and innovative GNU. It's great to see more GNU projects acting as one within the context of Guix and GuixSD to provide an experience that is greater than the sum of its parts. Work on Guix affected other GNU packages such as the Hurd, Guile, Mes, cool Guile libraries, and led to a bunch of new GNU packages such as a workflow language for scientific computing. On the other hand, although Guix has a lot of regular contributors and is very active, Nix currently has more contributors than Guix. Guix is a younger project. The tendency to take bootstrapping problems very seriously means that sometimes difficult packages require more work. Oddly, Guix seems to attract more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with Scheme after watching the SICP lecture videos); it seems to be the other way around with Nix. Having said all that: Nix and Guix are both implementations of functional package management. Both projects solve similar problems and both are active in the reproducible builds efforts. Solutions that were found by Nix devs sometimes make their way into Guix and vice versa. The projects are not competing with one another (there are orders of magnitudes more people out there who use neither Guix nor Nix than there are users of functional package managers, so there's no point in trying to get people who use Nix to switch to Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who invented functional package management and Nix) gave a talk on the future of Nix surrounded by Guix hackers --- there is no rivalry between these two projects.

tomp 8y ago

I only skimmed, but parts of this article read as just another pro-LISP piece... A rant against other languages (which the author terms "DSLs" simply because they're not Turing complete) like LaTeX, HTML, regex, SQL etc. and lists alternatives, all of which are S-expression-based. Well, the superiority of S-expressions is just, like, your opinion, man. Personally, I consider them inferior to pretty much any other syntax (joke languages like Brainfuck, Whitespace, JavaScript excluded). An in absolute terms, the whole civilisation was built on syntax-full DSLs (law, math, engineering, ...). I mean, how is this (Skribilo): (define (freedom . body) (ref :url "http://www.gnu.org/philosophy/free-sw.html" :text body)) (p [Skribilo is a ,(freedom [free]) document production tool that takes a structured document ...]) better than this (LaTeX): Skribilo is a \href{http://www.gnu.org/philosophy/free-sw.html}{free} document production tool that takes a structured document ...

equalunique 8y ago
Instead of a pro-scheme rant one could interpret it also as a NixOS pitch using a scheme API instead of a DSL.
Ambrevar 8y ago
The article is for the bigger part about operating systems, only a minor part is about programming languages (which is important for the matter at hand). It's not pro-Lisp in particular, it's pro-"general-purpose, well tested and well designed programming languages". I don't exlude other programming languages from the picture. The alternative I gave as examples are the ones that I know of, but sure thing there are others out there in Python, Lua, Ruby, you name it. I personally like S-expressions because they are very general and have deep semantic implications (eval-apply, a.k.a. code is data) that go beyond mere syntactic considerations. Regarding your examples, if I understand correctly they are not equivalent, so they don't exactly compare. Here LaTeX would require the \begin{document}...\end{document} bits. But regardless, TeX is very painful to program with (lack of proper data structures and control structures). It's very important in my opinion.
- _emacsomancer_ 8y ago

equalunique 8y ago

Nix and Guix both excite me a lot. Guix as a Guile scheme API is a very exciting, but what I like more is, as a result of that, Guix & it's derivations are all part of the same repo. Because they are one in the same I can be sure I'm not going to build a package that hasn't been tested against the version of guix I am running. It simplifies integration testing if I decide to create a new branch of Guix packages.

wuschel 8y ago

Looks to me like Guix is Nix with a Scheme based language (Guile) instead of the Nix specific DSL.

theusername 8y ago

I don't get it. Yeah guix is good. But AFAIK GuixSD has no support for modern hardwares due to their policy toward firmware blobs. So how's a OS being advanced without good hardware support?

_emacsomancer_ 8y ago

I'd really like to see Shepherd used outside of GuixSD. In theory, since Guix can be installed on top of other distros, this could be leveraged to be make swapping in Shepherd easier. Of course, systemd is much more complex, so replacing the init in systemd-based distro would probably be trickier, but it should be more manageable in places like Void Linux.

theamk 8y ago
Shepherd is quite scary outside of GUIX. It basically runs package-supplied code in PID 1, with no protection. A badly written init script will halt startup completely and render system unbootable. GUIX (I believe) has this "choose previous version from GRUB" dialog, so you can recover from bad init script by rolling back the whole thing. Any other OS will require manual fixes, and this is going to be quite a pain.
- _emacsomancer_ 8y ago
  Ah, thanks for the additional information. That's too bad though, I like the model of a Scheme-based init. I suppose I'll stick with runit for now then.