12 ms·

GNU Guix 1.0

478 points by brendyn 7y ago

na85 7y ago
How does one pronounce "guix", anyways? Is it "goo-icks"?
- nerdponx 7y ago
  "Geeks"
- deleted 7y ago
  [deleted]
- chongli 7y ago
  It's supposed to rhyme with Nix, being derived from it, so I would suspect it's monosyllabic. Thus, I would pronounce it "gwix."
  - devonkim 7y ago
    A surprisingly high number of Nix and NixOS users are German speakers and there's an informal name of "NichtsOS" given to it.
  - lfam 7y ago
    It's not supposed to rhyme with Nix. Rather, it's a portmanteau of Guile and Nix. The pronunciation is indeed like the English word 'geeks'.
- mouldysammich 7y ago
  I've heard it pronounced geeks by the developers.
- agumonkey 7y ago
  most probably geex, but feel free to be creative: gyeewix, gwiks, g-[u]-ayks
- Foxboron 7y ago
  It's a french spelling of the word "geeks" some devs told me.
  - oska 7y ago
    Not according to the french wiktionary [1]. There is a Catalan word guix however, where it means chalk. [2] [1] https://fr.wiktionary.org/wiki/geek https://fr.wiktionary.org/wiki/geek [2] https://en.wiktionary.org/wiki/guix https://en.wiktionary.org/wiki/guix
    - pygy_ 7y ago
      Geek is a borrowed word in French, and the original English spelling is used. If you wanted to write a word that respects French pronunciation and sounded like "geeks" in English, you'd write it "guix", or "guiks". It is a bilingual pun.
  - m_t 7y ago
    It's not the spelling, as geeks is spelt geeks in France[0], but I guess it's the English "direct" spelling of the French pronunciation. [0] https://www.lemonde.fr/les-cles-de-demain/article/2016/12/16/un-geek-est-avant-tout-un-passionne_5050248_4758288.html https://www.lemonde.fr/les-cles-de-demain/article/2016/12/16...
- westmeal 7y ago
  gooey x?
- petecox 7y ago
  The user manual says 'geeks': https://www.gnu.org/software/guix/manual/en/html_node/Introduction.html#FOOT1 https://www.gnu.org/software/guix/manual/en/html_node/Introd...
- laputan_machine 7y ago
  They did a talk at FOSDEM this year, one of the contributors pronounced it 'Gix'
- KirinDave 7y ago
  The FAQ says the IPA is: ɡiːks (𐑜𐑰𐑒𐑕, not 𐑜𐑰𐑒𐑟). There is a snakey S at the end not a Z like Americans are used to using.
  - _emacsomancer_ 7y ago
    Americans would also say /ɡiːks/. No dialect of English would be likely to use /ɡiːkz/; that's not how voicing assimilation works.
    - KirinDave 7y ago
      I've heard a bunch of people use the Z in person and on recorded talks.
      - _emacsomancer_ 7y ago
        Hmm. If you remember, could you drop me a link the next time you come across this in a recorded talk? It's pretty weird with a word like geek. Something that ends with a voiced sound as in dog of course will be tend to occur with a final /z/ rather than /s/ (though word-final devoicing is a productive process, so even dogs is often realised as /dɔgs/).
dmos62 7y ago
This seems like a large piece of software. I'm interested in the purely functional, portable package manager aspect. I can see that it has [0] a lot of packages that are a pain to build on my Slackware system (or even to download prebuilt) because of the awesome number of dependencies. Downloading mpv and its dependencies takes quite a bit of time, for example. If anyone has experience with using guix this way, I'd be interested. [0] https://www.gnu.org/software/guix/packages https://www.gnu.org/software/guix/packages
- groovybits 7y ago
  > This seems like a large piece of software. That's because Guix is an operating system :D https://www.gnu.org/software/guix https://www.gnu.org/software/guix
  - gmfawcett 7y ago
    GuixSD is the OS distribution; Guix is just the package manager. The two correspond to NixOS and Nix, respectively.
    - rekado 7y ago
      (Note: we call it "Guix System" instead of "GuixSD" now.) There is little difference between Guix and the Guix system when looking a little more closely. Even when using Guix as a package manager it won't link with any of your OS libraries, so you end up downloading or building variants of libraries that you may already have on your host operating system --- that's by design as it unlocks reproducible builds.
      - gmfawcett 7y ago
        Good to know about the terminology change. Thanks! I understand what you mean by the difference. (I currently overlay Nix on top of a different Linux distribution.) But without the "system" part, Guix on its own is still not strictly an OS, since there's no kernel being deployed. A pedantic point, but an accurate one I think. :)
joemccall86 7y ago
Looks like a neat concept. Would anyone here with experience managing this in production care to comment? Seems like it could be interesting if you need to reproduce the exact same software/OS on several machines as deliverables.
- atemerev 7y ago
  Many people run Nix in production — a similarly structured OS. Nix works fine. GUIX is relatively new; I played with it, but didn’t use in production yet.
- rekado 7y ago
  I've been using Guix in production since 2014 at a research institute to support reproducible bioinformatics workflows. It has come a long way since then. Guix takes reproducibility and "bootstrappability" very seriously. Its design as an extension to Guile Scheme enabled the development of software built around Guix, such as a workflow language, alternative user interfaces (e.g. an Emacs interface or a web interface), etc. The `guix system` family of commands is awesome because it can build reproducible containers, disk images, virtual machines, or bare-metal systems all from the same specifications. What's still missing, in my opinion, is a tool to manage systems that have been generated with Guix, e.g. to check on their state, build new configurations and swap them out for old ones, etc. Some work has been done towards this goal, but there's still some way to go there. Other than that I'm very happy with it and use Guix systems and Guix as a package manager on all my machines.
  - sterlind 7y ago
    How does writing Guix Lisp expressions compare to writing Nix? Is it pretty succinct and intuitive? Do patterns make a little bit better sense? It took me a long time to get the hang of the Nix design patterns like the three different kinds of overrides and the module system. Curious if it plays better in Lisp.
    - rekado 7y ago
      "succinct" is hard to answer. It depends a lot on the upstream package. For most packages the package expression looks like data: (define-public r-valr (package (name "r-valr") (version "0.5.0") (source (origin (method url-fetch) (uri (cran-uri "valr" version)) (sha256 (base32 "14jhrwkiwmha3vlmm7b50n2xxyizj6ddmy89gb20mpzq7qhz1ika")))) (build-system r-build-system) (propagated-inputs `(("r-broom" ,r-broom) ("r-dplyr" ,r-dplyr) ("r-ggplot2" ,r-ggplot2) ("r-rcpp" ,r-rcpp) ("r-readr" ,r-readr) ("r-rlang" ,r-rlang) ("r-stringr" ,r-stringr) ("r-tibble" ,r-tibble))) (home-page "https://github.com/rnabioco/valr") (synopsis "Genome interval arithmetic in R") (description "This package enables you to read and manipulate genome intervals and signals. It provides functionality similar to command-line tool suites within R, enabling interactive analysis and visualization of genome-scale data.") (license license:expat))) This defines the name "r-valr" to be a "package" value with the given fields. The "source" field describes how Guix should obtain the source tarball ("url-fetch" is a procedure that implements a URL downloader, but there are others like "git-fetch", "hg-fetch", etc) and what the hash of that data is supposed to be. The "build-system" field tells Guix how to build the thing. "r-build-system" is a very succinct way to say "do with this package as you do for all other R packages: unpack the tarball, run `R CMD bla`, then run the tests, etc". We've got quite a few such build systems: "gnu-build-system", "cmake-build-system", "python-build-system", "ant-build-system", ... All of these can be further configured via the "arguments" package field, which isn't used here, because this is a boring package. The "propagated-inputs" field is an association list of arbitrary labels to actual package values --- the things on the right hand side are variable names that are bound to package values, which are unquoted here, so this field really contains actual references to these other package values. The result is a lazily constructed graph of package values. Some packages can be really nasty, though, when the developers decided to ignore conventions and implement their very own way to build their very special software. We can usually accommodate those packages by starting out with e.g. the gnu-build-system and then modifying the build phases: deleting the "configure" phase, adding a custom phase before the "build", replacing the "install" phase, etc. The system is flexible enough for all of this, but for really ... special software I would no longer call this "succinct" or "intuitive". That said, most packages are easy. Almost all R packages, for example, look like the one above. But there are some really frustrating ones like Tensorflow (due to the fact that we use CMake instead of Bazel because Bazel hasn't been bootstrapped yet) or the old JDKs (that we use as part of a longer bootstrap chain) that are plain ugly. You just need to know when to give up, I suppose :)
shpx 7y ago
Guix doesn't package proprietary software.
- nyberg 7y ago
  Which is great. Means you have a clean install that's sure to be reproducible. There's always the option to keep your own channel of non-free packages if you really need them.
  - tadfisher 7y ago
    Proprietary packages may still be reproducible. Presumably, you verify a hash of the inputs (e.g. upstream tarball/binary and patches), and the output should still be bit-for-bit the same on any machine given the same inputs. Not to mention that there are many open-source (as in OSI) packages that may not be distributed with Guix System because they use non-FSF-approved software licenses.
    - rekado 7y ago
      > Not to mention that there are many open-source (as in OSI) packages that may not be distributed with Guix System because they use non-FSF-approved software licenses. This is not true; at the very least "many" is wrong in the above statement. Generally, there is virtually no difference between the OSI set of approved licenses and the FSF set. Can you list examples of the many packages that would be considered "open source" (according to the OSI definition) but not also Free Software as per the FSF definition?
- serhart 7y ago
  The official Guix channels do not package proprietary software. However, nothing is stopping someone from doing it.
  - atemerev 7y ago
    Tried to install nvidia drivers (the only piece of proprietary software I needed) — no luck. Hope that with 1.0, somebody will find a way.
davexunit 7y ago
I haven't been active for a couple of years, but I've contributed my fair share of packages and features since 2013 that I'm proud to see have made it all the way to 1.0. Congrats, Guix team!
opan 7y ago
I've been using the Guix system since early 2018. It's a lot of fun. I've put off some of the more complicated stuff (from a user's perspective) like packaging new things, but it's managed to stay my daily driver just fine.
the_duke 7y ago
Could someone provide a good comparison to Nix? As in: - What differentiates the two? - What are respective drawbacks / advantages? - How usable are they? How painful is the manual creation of packages?
- rekado 7y ago
  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 Guix System (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. - Guix System, the GNU system distribution built around Guix. Guix System 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. Guix System 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 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. ---- Now to the last question: How usable are they? I've been using Guix (as a package manager and as an OS) since 2014 on all of my machines and I love it. I have written hundreds of package definitions both manually and with the help of "guix import", which generates them for me (even recursively). If you're okay with Lisp it's not painful at all. I have experience with RPM spec files and Arch PKGBUILDs and I love how declarative Guix package definitions are in comparison. For well-behaved projects that's great. For projects that reinvent build systems or come with custom build instructions or that assume unreasonable things about the target system things can get pretty gnarly, though. Guix differs in that you don't use shell snippets to describe the installation steps. This can be confusing for people coming from other packaging systems, and it can be a little uncomfortable having to express things in Scheme instead. On the plus side you have access to a much more flexible language and don't have to mess with low-level shell. You can write procedures and reuse them across packages, or you can abstract the whole build process so that all that is ever needed is a declaration like `(build-system python-build-system)'. (Things that suck: packaging NPM/nodejs things. Guix folks are really into building things from source, and there's a cultural mismatch with NPM folks. There are workarounds but there's no silver bullet.)
geokon 7y ago
Is there a GUI/TUI for it? Like something akin to aptitude or at the very least muon? And does GUIX/Nix has something similar to Recommended/Suggested packages in Ubuntu/Debian land? Or is each package an all-or-nothing kind of deal?
- rekado 7y ago
  Guix has a very nice Emacs interface --- that's better than a bare TUI in my opinion. Even if you aren't a die-hard Emacs user the Emacs interface has a lot to offer. There also is a web interface, but that's more useful for browsing the package collection than to install things. I don't know what you mean by "all-or-nothing kind of deal". You can easily create package variants (thanks to first-class package record values that support field inheritance), but in my experience you rarely need that as packages are often composable at runtime --- you just install them into the same profile.
  - michaelmrose 7y ago
    - Package A recommends Package B, if the package maintainer judges that most users would not want A without also having the functionality provided by B. - Package A suggests Package B if B contains files that are related to (and usually enhance) the functionality of A. - Package A depends on Package B if B is a A can't work without B Its possible for B to actually be optional but in fact be designated as required if A is built with options that require B.
echohack5 7y ago
The hardest thing to understand here about Guix is exactly what it does, because there's only 3 tools out there that operate like this (that I'm aware of, at least): - GNU Guix - NixOS - Chef Habitat These three tools have some common themes but ultimately accomplish different end goals. Some common things: - They all provide a package manager that exists outside of the regular scope of your operating system. - They all bundle together your compiled application code AND configuration code AND runtime dependencies into one package, making it easy to just run your application. Some differences: Nix. [Edit: It was pointed out that the package manager Nix, is separate from NixOS, and this package manager can be run on any operation system). (https://nixos.org/ https://nixos.org/) (https://github.com/NixOS https://github.com/NixOS) GNU Guix has a larger focus on reproducibility and archival properties of software. In other words, Guix uses it's ability to run software independently of your operating system as a way of ensuring authentic, realistic, and 100% portable applications. Guix wants to build your application FIRST, and ignore whatever problems your OS might present to you. It lets you build a development environment in a "clean-room" with the environment command. It also lets you write those configurations and environments using Guile programming interfaces and the Scheme programming language, which is super powerful. (https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/) (https://github.com/pjotrp/guix https://github.com/pjotrp/guix) Chef Habitat is very similar to GNU Guix, except it also works for Windows packages. It's primary goal is so that you can build and deploy your applications completely independently of the constraints of your operating system or runtime environment. Just like GNU Guix, this makes it super awesome to take old applications that are "stuck" on old operating system environments and quickly port them to whatever modern OS or runtime format you wish. Like GNU Guix, it has a chrooted clean-room environment called the Studio and uses Bash/Powershell to allow you to build packages. Chef Habitat diverges from GNU Guix in that it provides a runtime process supervisor that has auto-update / continuous delivery capabilities, and also provides a gossip protocol so that applications can talk to each other and do things like leader election automatically. (https://habitat.sh https://habitat.sh) (https://github.com/habitat-sh/ https://github.com/habitat-sh/) Overall, I think most people will be confused when they approach these tools because they've never used anything like them before. But once you get your hands in them you'll realize how awesome they really are.
- 7y ago
merricksb 7y ago
Recent Guix discussions: Guix: An advanced operating system (4 months ago, 313 points, 168 comments) https://news.ycombinator.com/item?id=18902823 https://news.ycombinator.com/item?id=18902823 Software Heritage and GNU Guix join forces to enable long term reproducibility (13 days ago, 168 points, 7 comments) https://news.ycombinator.com/item?id=19699031 https://news.ycombinator.com/item?id=19699031
berbec 7y ago
Does the logo look similar to the female reproductive system to anyone?
- mrmuagi 7y ago
  It looks like a V with bullhorns to me, which is weird -- what does the V symbolise in this project?
  - rekado 7y ago
    It's a GNU ;)
- Avshalom 7y ago
  ... well now it does.
Zenst 7y ago
Link to x86 64bit .iso image: https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_6... x86 32bit https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.i686-linux.iso.xz https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.i686-... Gleaned from https://www.gnu.org/software/guix/manual/en/html_node/USB-Stick-and-DVD-Installation.html#USB-Stick-and-DVD-Installation https://www.gnu.org/software/guix/manual/en/html_node/USB-St...
vbrandl 7y ago
I'd love to use Guix (or Nix for that matter) as my day-to-day system but (and correct me, if I'm wrong) the package maintainer story is a bit off putting for me. From what I've understood, packages are maintained in a public git repository (GitHub [0] for Nix and savannah.gnu.org [1] for Guix), which might be great if there are enough people submitting updates, but at least for critical system components there should be clearly defined maintainers to make sure all security patches are applied in time. Also I'm not sure how I feel about a core part of my potential operating system being hosted by a now Microsoft-owned company. On the other hand GitHub might be more reliable and better fit to server a huge amount of users than savannah... [0]: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs [1]: https://git.savannah.gnu.org/cgit/guix.git/ https://git.savannah.gnu.org/cgit/guix.git/
- rekado 7y ago
  No "core part" of Guix is hosted on Github. If you're referring to the daemon: it's being replaced with a Guile implementation (it's an ongoing student project). It's not fetched from Github; our old copy of the daemon is part of the Guix git repository.
  - vbrandl 7y ago
    Sorry for being unclear. The part about being hosted on GitHub actually referred to Nix. That's the point where I'm unclear about what seems to be the better solution. GitHub could take a turn for the worse but at least for now, GitHub might be able to handle more users than savannah.
    - rekado 7y ago
      I don't think it matters much. You can use any git mirror in your ~/.config/guix/channels.scm file (including a local clone); you only need access to the git repo when running "guix pull" to upgrade your copy of Guix. I don't think that Savannah will become a bottleneck even with three times the users we have now. If it ever becomes a problem it's trivial to move to something else or to host dedicated infrastructure.
akavel 7y ago
As a person with ~intermediate knowledge of Nix/NixOS and only knowing Guix from a distance yet: - I don't see a word about GuixSD there - what's the status of this? Is it also 1.0 now? - (How) can I pin my whole config to a particular commit of the package set/channel, and only update gradually? I'm kinda having trouble finding out how to do this in NixOS - Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels? I know GNU proper doesn't want me to do this, and I'm sympathetic, but not ready for the jump. What's the situation for me in practice? - Can I replace kernel with L4Linux? I tried to do that in NixOS but gave up because of complexity. - Does GNU mirror/archive all package sources used by Guix somewhere? If github is sunset by MS, can I still build an OS from a 2018 snapshot? - What's the multi-user story? In Nix it's complicated. - Does Guix have something like Nix's home-manager? TIA!
- rekado 7y ago
  > - I don't see a word about GuixSD there - what's the status of this? Is it also 1.0 now? Yes. GuixSD is now called "Guix System". > can I pin my whole config to a particular commit of the package set/channel Yes, you can. You only need to describe the channels you want to use (and possibly their commits) in ~/.config/guix/channels.scm and then run "guix pull". You now have that particular version of Guix and it won't change until you change the channel specification and run "guix pull" again. That's great for reproducing a system elsewhere or at a different point in time. > Can I replace kernel with L4Linux I don't know if anyone has tried. > Does GNU mirror/archive all package sources used by Guix somewhere We cache sources for as long as possible on the build farm; we also fall back to looking up sources through Nix caches; and finally we fall back to the Software Heritage archive. > Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels? Yes and yes. Adding channels is easy: just add a specification to ~/.config/guix/channels.scm > Does Guix have something like Nix's home-manager Sadly it doesn't. I'd love to see something like this in Guix.
  - colemickens 7y ago
    Just for context to the GP, Nix channels work basically the exact same way. Or, you can do as I do, and not use channels and always specify the exact nixpkgs revision as part of your Nix file. Anyone can `nix-build chimera.nix` and get a (nearly) bit-for-bit identical build of my laptop, which is great - we don't have to have a conversation about which channel I'm on, or which rev of which channel I'm on, etc. I can then independently rev the nixpkgs revision and either commit that, or not.
pjmlp 7y ago
I don't have any use for it, but it gets brownie points for its use of Scheme.
- Koshkin 7y ago
  Me, I'll wait for GNU AI to take over everything.
dman 7y ago
Any pointers/tutorial on how to get a gnome desktop up and running using guix?
- rekado 7y ago
  The manual is really good, so I recommend looking through the installation instructions there. The installation image comes with a text-based installer where you can select GNOME. (Personally, I prefer to install a bare-bones system and then reconfigure it to something fancier. This way I can get to enjoy the features of the Guix system much sooner --- including booting into older generations of the system.)
chrisweekly 7y ago
For those (like me) learning of Guix for the first time: >"About GNU Guix GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language." Sounds pretty amazing!
LargoLasskhyfv 7y ago
But...has it USE Flags like Gentoo's Portage? And variable CFLAGS and CXXFLAGS for explicitely choosing to optimize whichever way i see fit, instead of using something generic? Individually, on a per package base? Like described here for example: https://wiki.gentoo.org/wiki/Complete_Handbook/Building_the_system https://wiki.gentoo.org/wiki/Complete_Handbook/Building_the_... https://wiki.gentoo.org/wiki/Safe_CFLAGS https://wiki.gentoo.org/wiki/Safe_CFLAGS
- Crestwave 7y ago
  As far as I know, it does not have USE flags, but you can customize the compilation however you want, adding build options, patches, etc. They also provide binaries for a good amount of packages if you don't want to build some from source.
  - LargoLasskhyfv 7y ago
    I see. But that is not the point. I can customize any compilation anywhere. But it is a hassle i can do without. I really miss the "automagic" of Gentoo because this feature was intrinsic to their package management. I'm watching Guix(XD/System/Whatever) since years, browsing the docs, reading this and that, and it seems to me like just another rpm, deb with some nice addons. And not too inviting at all, because who likes ghettos which ideologically shun this and that which unfortunately is part of my life? Anyways, interesting work whith reproducable bootstrapping in GNU Mes. (sigh)
    - Crestwave 7y ago
      It's not just like those at all... did you think that I was saying that you can just compile things manually or something? You can define build options and such for a group of packages using Guix; there just isn't an abstraction like USE flags. You can find more info at https://ambrevar.xyz/guix-advance/index.html#orgc3c05c9 https://ambrevar.xyz/guix-advance/index.html#orgc3c05c9. And I don't consider its other features just "some nice addons". It's easy to build things from source; in fact, it automatically does it by default if a binary isn't available. It's contained in a directory, you can roll back to a previous state, it's reproducible, everything can be configured through one file, etc. Guix is one of the package managers most different from apt and such; if there's anything it's similar to, it's Nix, which IIRC it's based on/inspired by. Also, I'm curious as to what it is that you do that they shun? Is it working on proprietary software or something?
NateEag 7y ago
I've been intrigued by nix then guix for several years now, but have yet to give either one a test run. I understand some of the technical differences, but can anyone explain the implications of the license differences to me? I know that NixOS is X11/MIT licensed, and that as a GNU project Guix is AGPL. In practice, if I wanted to use Guix as a base system for hosting a proprietary SaaS website, would there be issues with that? Either way, is there an easier-to-read summary than the license itself anywhere?

GNU Guix 1.0

478 points by brendyn 7y ago

na85 7y ago

How does one pronounce "guix", anyways? Is it "goo-icks"?

nerdponx 7y ago
"Geeks"
deleted 7y ago
[deleted]
chongli 7y ago
It's supposed to rhyme with Nix, being derived from it, so I would suspect it's monosyllabic. Thus, I would pronounce it "gwix."
- devonkim 7y ago
  A surprisingly high number of Nix and NixOS users are German speakers and there's an informal name of "NichtsOS" given to it.
- lfam 7y ago
  It's not supposed to rhyme with Nix. Rather, it's a portmanteau of Guile and Nix. The pronunciation is indeed like the English word 'geeks'.
mouldysammich 7y ago
I've heard it pronounced geeks by the developers.
agumonkey 7y ago
most probably geex, but feel free to be creative: gyeewix, gwiks, g-[u]-ayks
Foxboron 7y ago
It's a french spelling of the word "geeks" some devs told me.
- oska 7y ago
  Not according to the french wiktionary [1]. There is a Catalan word guix however, where it means chalk. [2] [1] https://fr.wiktionary.org/wiki/geek https://fr.wiktionary.org/wiki/geek [2] https://en.wiktionary.org/wiki/guix https://en.wiktionary.org/wiki/guix
  - pygy_ 7y ago
    Geek is a borrowed word in French, and the original English spelling is used. If you wanted to write a word that respects French pronunciation and sounded like "geeks" in English, you'd write it "guix", or "guiks". It is a bilingual pun.
- m_t 7y ago
  It's not the spelling, as geeks is spelt geeks in France[0], but I guess it's the English "direct" spelling of the French pronunciation. [0] https://www.lemonde.fr/les-cles-de-demain/article/2016/12/16/un-geek-est-avant-tout-un-passionne_5050248_4758288.html https://www.lemonde.fr/les-cles-de-demain/article/2016/12/16...
westmeal 7y ago
gooey x?
petecox 7y ago
The user manual says 'geeks': https://www.gnu.org/software/guix/manual/en/html_node/Introduction.html#FOOT1 https://www.gnu.org/software/guix/manual/en/html_node/Introd...
laputan_machine 7y ago
They did a talk at FOSDEM this year, one of the contributors pronounced it 'Gix'
KirinDave 7y ago
The FAQ says the IPA is: ɡiːks (𐑜𐑰𐑒𐑕, not 𐑜𐑰𐑒𐑟). There is a snakey S at the end not a Z like Americans are used to using.
- _emacsomancer_ 7y ago
  Americans would also say /ɡiːks/. No dialect of English would be likely to use /ɡiːkz/; that's not how voicing assimilation works.
  - KirinDave 7y ago
    I've heard a bunch of people use the Z in person and on recorded talks.
    - _emacsomancer_ 7y ago
      Hmm. If you remember, could you drop me a link the next time you come across this in a recorded talk? It's pretty weird with a word like geek. Something that ends with a voiced sound as in dog of course will be tend to occur with a final /z/ rather than /s/ (though word-final devoicing is a productive process, so even dogs is often realised as /dɔgs/).

dmos62 7y ago

This seems like a large piece of software. I'm interested in the purely functional, portable package manager aspect. I can see that it has [0] a lot of packages that are a pain to build on my Slackware system (or even to download prebuilt) because of the awesome number of dependencies. Downloading mpv and its dependencies takes quite a bit of time, for example. If anyone has experience with using guix this way, I'd be interested. [0] https://www.gnu.org/software/guix/packages https://www.gnu.org/software/guix/packages

groovybits 7y ago
> This seems like a large piece of software. That's because Guix is an operating system :D https://www.gnu.org/software/guix https://www.gnu.org/software/guix
- gmfawcett 7y ago
  GuixSD is the OS distribution; Guix is just the package manager. The two correspond to NixOS and Nix, respectively.
  - rekado 7y ago
    (Note: we call it "Guix System" instead of "GuixSD" now.) There is little difference between Guix and the Guix system when looking a little more closely. Even when using Guix as a package manager it won't link with any of your OS libraries, so you end up downloading or building variants of libraries that you may already have on your host operating system --- that's by design as it unlocks reproducible builds.
    - gmfawcett 7y ago
      Good to know about the terminology change. Thanks! I understand what you mean by the difference. (I currently overlay Nix on top of a different Linux distribution.) But without the "system" part, Guix on its own is still not strictly an OS, since there's no kernel being deployed. A pedantic point, but an accurate one I think. :)

joemccall86 7y ago

Looks like a neat concept. Would anyone here with experience managing this in production care to comment? Seems like it could be interesting if you need to reproduce the exact same software/OS on several machines as deliverables.

atemerev 7y ago
Many people run Nix in production — a similarly structured OS. Nix works fine. GUIX is relatively new; I played with it, but didn’t use in production yet.
rekado 7y ago
I've been using Guix in production since 2014 at a research institute to support reproducible bioinformatics workflows. It has come a long way since then. Guix takes reproducibility and "bootstrappability" very seriously. Its design as an extension to Guile Scheme enabled the development of software built around Guix, such as a workflow language, alternative user interfaces (e.g. an Emacs interface or a web interface), etc. The `guix system` family of commands is awesome because it can build reproducible containers, disk images, virtual machines, or bare-metal systems all from the same specifications. What's still missing, in my opinion, is a tool to manage systems that have been generated with Guix, e.g. to check on their state, build new configurations and swap them out for old ones, etc. Some work has been done towards this goal, but there's still some way to go there. Other than that I'm very happy with it and use Guix systems and Guix as a package manager on all my machines.
- sterlind 7y ago
  How does writing Guix Lisp expressions compare to writing Nix? Is it pretty succinct and intuitive? Do patterns make a little bit better sense? It took me a long time to get the hang of the Nix design patterns like the three different kinds of overrides and the module system. Curious if it plays better in Lisp.
  - rekado 7y ago
    "succinct" is hard to answer. It depends a lot on the upstream package. For most packages the package expression looks like data: (define-public r-valr (package (name "r-valr") (version "0.5.0") (source (origin (method url-fetch) (uri (cran-uri "valr" version)) (sha256 (base32 "14jhrwkiwmha3vlmm7b50n2xxyizj6ddmy89gb20mpzq7qhz1ika")))) (build-system r-build-system) (propagated-inputs `(("r-broom" ,r-broom) ("r-dplyr" ,r-dplyr) ("r-ggplot2" ,r-ggplot2) ("r-rcpp" ,r-rcpp) ("r-readr" ,r-readr) ("r-rlang" ,r-rlang) ("r-stringr" ,r-stringr) ("r-tibble" ,r-tibble))) (home-page "https://github.com/rnabioco/valr") (synopsis "Genome interval arithmetic in R") (description "This package enables you to read and manipulate genome intervals and signals. It provides functionality similar to command-line tool suites within R, enabling interactive analysis and visualization of genome-scale data.") (license license:expat))) This defines the name "r-valr" to be a "package" value with the given fields. The "source" field describes how Guix should obtain the source tarball ("url-fetch" is a procedure that implements a URL downloader, but there are others like "git-fetch", "hg-fetch", etc) and what the hash of that data is supposed to be. The "build-system" field tells Guix how to build the thing. "r-build-system" is a very succinct way to say "do with this package as you do for all other R packages: unpack the tarball, run `R CMD bla`, then run the tests, etc". We've got quite a few such build systems: "gnu-build-system", "cmake-build-system", "python-build-system", "ant-build-system", ... All of these can be further configured via the "arguments" package field, which isn't used here, because this is a boring package. The "propagated-inputs" field is an association list of arbitrary labels to actual package values --- the things on the right hand side are variable names that are bound to package values, which are unquoted here, so this field really contains actual references to these other package values. The result is a lazily constructed graph of package values. Some packages can be really nasty, though, when the developers decided to ignore conventions and implement their very own way to build their very special software. We can usually accommodate those packages by starting out with e.g. the gnu-build-system and then modifying the build phases: deleting the "configure" phase, adding a custom phase before the "build", replacing the "install" phase, etc. The system is flexible enough for all of this, but for really ... special software I would no longer call this "succinct" or "intuitive". That said, most packages are easy. Almost all R packages, for example, look like the one above. But there are some really frustrating ones like Tensorflow (due to the fact that we use CMake instead of Bazel because Bazel hasn't been bootstrapped yet) or the old JDKs (that we use as part of a longer bootstrap chain) that are plain ugly. You just need to know when to give up, I suppose :)

shpx 7y ago

Guix doesn't package proprietary software.

nyberg 7y ago
Which is great. Means you have a clean install that's sure to be reproducible. There's always the option to keep your own channel of non-free packages if you really need them.
- tadfisher 7y ago
  Proprietary packages may still be reproducible. Presumably, you verify a hash of the inputs (e.g. upstream tarball/binary and patches), and the output should still be bit-for-bit the same on any machine given the same inputs. Not to mention that there are many open-source (as in OSI) packages that may not be distributed with Guix System because they use non-FSF-approved software licenses.
  - rekado 7y ago
    > Not to mention that there are many open-source (as in OSI) packages that may not be distributed with Guix System because they use non-FSF-approved software licenses. This is not true; at the very least "many" is wrong in the above statement. Generally, there is virtually no difference between the OSI set of approved licenses and the FSF set. Can you list examples of the many packages that would be considered "open source" (according to the OSI definition) but not also Free Software as per the FSF definition?
serhart 7y ago
The official Guix channels do not package proprietary software. However, nothing is stopping someone from doing it.
- atemerev 7y ago
  Tried to install nvidia drivers (the only piece of proprietary software I needed) — no luck. Hope that with 1.0, somebody will find a way.

davexunit 7y ago

I haven't been active for a couple of years, but I've contributed my fair share of packages and features since 2013 that I'm proud to see have made it all the way to 1.0. Congrats, Guix team!

opan 7y ago

I've been using the Guix system since early 2018. It's a lot of fun. I've put off some of the more complicated stuff (from a user's perspective) like packaging new things, but it's managed to stay my daily driver just fine.

the_duke 7y ago

Could someone provide a good comparison to Nix? As in: - What differentiates the two? - What are respective drawbacks / advantages? - How usable are they? How painful is the manual creation of packages?

rekado 7y ago
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 Guix System (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. - Guix System, the GNU system distribution built around Guix. Guix System 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. Guix System 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 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. ---- Now to the last question: How usable are they? I've been using Guix (as a package manager and as an OS) since 2014 on all of my machines and I love it. I have written hundreds of package definitions both manually and with the help of "guix import", which generates them for me (even recursively). If you're okay with Lisp it's not painful at all. I have experience with RPM spec files and Arch PKGBUILDs and I love how declarative Guix package definitions are in comparison. For well-behaved projects that's great. For projects that reinvent build systems or come with custom build instructions or that assume unreasonable things about the target system things can get pretty gnarly, though. Guix differs in that you don't use shell snippets to describe the installation steps. This can be confusing for people coming from other packaging systems, and it can be a little uncomfortable having to express things in Scheme instead. On the plus side you have access to a much more flexible language and don't have to mess with low-level shell. You can write procedures and reuse them across packages, or you can abstract the whole build process so that all that is ever needed is a declaration like `(build-system python-build-system)'. (Things that suck: packaging NPM/nodejs things. Guix folks are really into building things from source, and there's a cultural mismatch with NPM folks. There are workarounds but there's no silver bullet.)

geokon 7y ago

Is there a GUI/TUI for it? Like something akin to aptitude or at the very least muon? And does GUIX/Nix has something similar to Recommended/Suggested packages in Ubuntu/Debian land? Or is each package an all-or-nothing kind of deal?

rekado 7y ago
Guix has a very nice Emacs interface --- that's better than a bare TUI in my opinion. Even if you aren't a die-hard Emacs user the Emacs interface has a lot to offer. There also is a web interface, but that's more useful for browsing the package collection than to install things. I don't know what you mean by "all-or-nothing kind of deal". You can easily create package variants (thanks to first-class package record values that support field inheritance), but in my experience you rarely need that as packages are often composable at runtime --- you just install them into the same profile.
- michaelmrose 7y ago
  - Package A recommends Package B, if the package maintainer judges that most users would not want A without also having the functionality provided by B. - Package A suggests Package B if B contains files that are related to (and usually enhance) the functionality of A. - Package A depends on Package B if B is a A can't work without B Its possible for B to actually be optional but in fact be designated as required if A is built with options that require B.

echohack5 7y ago

The hardest thing to understand here about Guix is exactly what it does, because there's only 3 tools out there that operate like this (that I'm aware of, at least): - GNU Guix - NixOS - Chef Habitat These three tools have some common themes but ultimately accomplish different end goals. Some common things: - They all provide a package manager that exists outside of the regular scope of your operating system. - They all bundle together your compiled application code AND configuration code AND runtime dependencies into one package, making it easy to just run your application. Some differences: Nix. [Edit: It was pointed out that the package manager Nix, is separate from NixOS, and this package manager can be run on any operation system). (https://nixos.org/ https://nixos.org/) (https://github.com/NixOS https://github.com/NixOS) GNU Guix has a larger focus on reproducibility and archival properties of software. In other words, Guix uses it's ability to run software independently of your operating system as a way of ensuring authentic, realistic, and 100% portable applications. Guix wants to build your application FIRST, and ignore whatever problems your OS might present to you. It lets you build a development environment in a "clean-room" with the environment command. It also lets you write those configurations and environments using Guile programming interfaces and the Scheme programming language, which is super powerful. (https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/) (https://github.com/pjotrp/guix https://github.com/pjotrp/guix) Chef Habitat is very similar to GNU Guix, except it also works for Windows packages. It's primary goal is so that you can build and deploy your applications completely independently of the constraints of your operating system or runtime environment. Just like GNU Guix, this makes it super awesome to take old applications that are "stuck" on old operating system environments and quickly port them to whatever modern OS or runtime format you wish. Like GNU Guix, it has a chrooted clean-room environment called the Studio and uses Bash/Powershell to allow you to build packages. Chef Habitat diverges from GNU Guix in that it provides a runtime process supervisor that has auto-update / continuous delivery capabilities, and also provides a gossip protocol so that applications can talk to each other and do things like leader election automatically. (https://habitat.sh https://habitat.sh) (https://github.com/habitat-sh/ https://github.com/habitat-sh/) Overall, I think most people will be confused when they approach these tools because they've never used anything like them before. But once you get your hands in them you'll realize how awesome they really are.

7y ago

merricksb 7y ago

Recent Guix discussions: Guix: An advanced operating system (4 months ago, 313 points, 168 comments) https://news.ycombinator.com/item?id=18902823 https://news.ycombinator.com/item?id=18902823 Software Heritage and GNU Guix join forces to enable long term reproducibility (13 days ago, 168 points, 7 comments) https://news.ycombinator.com/item?id=19699031 https://news.ycombinator.com/item?id=19699031

berbec 7y ago

Does the logo look similar to the female reproductive system to anyone?

mrmuagi 7y ago
It looks like a V with bullhorns to me, which is weird -- what does the V symbolise in this project?
- rekado 7y ago
  It's a GNU ;)
Avshalom 7y ago
... well now it does.

Zenst 7y ago

Link to x86 64bit .iso image: https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_6... x86 32bit https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.i686-linux.iso.xz https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.i686-... Gleaned from https://www.gnu.org/software/guix/manual/en/html_node/USB-Stick-and-DVD-Installation.html#USB-Stick-and-DVD-Installation https://www.gnu.org/software/guix/manual/en/html_node/USB-St...

vbrandl 7y ago

I'd love to use Guix (or Nix for that matter) as my day-to-day system but (and correct me, if I'm wrong) the package maintainer story is a bit off putting for me. From what I've understood, packages are maintained in a public git repository (GitHub [0] for Nix and savannah.gnu.org [1] for Guix), which might be great if there are enough people submitting updates, but at least for critical system components there should be clearly defined maintainers to make sure all security patches are applied in time. Also I'm not sure how I feel about a core part of my potential operating system being hosted by a now Microsoft-owned company. On the other hand GitHub might be more reliable and better fit to server a huge amount of users than savannah... [0]: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs [1]: https://git.savannah.gnu.org/cgit/guix.git/ https://git.savannah.gnu.org/cgit/guix.git/

rekado 7y ago
No "core part" of Guix is hosted on Github. If you're referring to the daemon: it's being replaced with a Guile implementation (it's an ongoing student project). It's not fetched from Github; our old copy of the daemon is part of the Guix git repository.
- vbrandl 7y ago
  Sorry for being unclear. The part about being hosted on GitHub actually referred to Nix. That's the point where I'm unclear about what seems to be the better solution. GitHub could take a turn for the worse but at least for now, GitHub might be able to handle more users than savannah.
  - rekado 7y ago
    I don't think it matters much. You can use any git mirror in your ~/.config/guix/channels.scm file (including a local clone); you only need access to the git repo when running "guix pull" to upgrade your copy of Guix. I don't think that Savannah will become a bottleneck even with three times the users we have now. If it ever becomes a problem it's trivial to move to something else or to host dedicated infrastructure.

akavel 7y ago

As a person with ~intermediate knowledge of Nix/NixOS and only knowing Guix from a distance yet: - I don't see a word about GuixSD there - what's the status of this? Is it also 1.0 now? - (How) can I pin my whole config to a particular commit of the package set/channel, and only update gradually? I'm kinda having trouble finding out how to do this in NixOS - Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels? I know GNU proper doesn't want me to do this, and I'm sympathetic, but not ready for the jump. What's the situation for me in practice? - Can I replace kernel with L4Linux? I tried to do that in NixOS but gave up because of complexity. - Does GNU mirror/archive all package sources used by Guix somewhere? If github is sunset by MS, can I still build an OS from a 2018 snapshot? - What's the multi-user story? In Nix it's complicated. - Does Guix have something like Nix's home-manager? TIA!

rekado 7y ago
> - I don't see a word about GuixSD there - what's the status of this? Is it also 1.0 now? Yes. GuixSD is now called "Guix System". > can I pin my whole config to a particular commit of the package set/channel Yes, you can. You only need to describe the channels you want to use (and possibly their commits) in ~/.config/guix/channels.scm and then run "guix pull". You now have that particular version of Guix and it won't change until you change the channel specification and run "guix pull" again. That's great for reproducing a system elsewhere or at a different point in time. > Can I replace kernel with L4Linux I don't know if anyone has tried. > Does GNU mirror/archive all package sources used by Guix somewhere We cache sources for as long as possible on the build farm; we also fall back to looking up sources through Nix caches; and finally we fall back to the Software Heritage archive. > Can I package non-libre software for Guix? Are there third-party non-libre package sets/channels? Yes and yes. Adding channels is easy: just add a specification to ~/.config/guix/channels.scm > Does Guix have something like Nix's home-manager Sadly it doesn't. I'd love to see something like this in Guix.
- colemickens 7y ago
  Just for context to the GP, Nix channels work basically the exact same way. Or, you can do as I do, and not use channels and always specify the exact nixpkgs revision as part of your Nix file. Anyone can `nix-build chimera.nix` and get a (nearly) bit-for-bit identical build of my laptop, which is great - we don't have to have a conversation about which channel I'm on, or which rev of which channel I'm on, etc. I can then independently rev the nixpkgs revision and either commit that, or not.

pjmlp 7y ago

I don't have any use for it, but it gets brownie points for its use of Scheme.

Koshkin 7y ago
Me, I'll wait for GNU AI to take over everything.

dman 7y ago

Any pointers/tutorial on how to get a gnome desktop up and running using guix?

rekado 7y ago
The manual is really good, so I recommend looking through the installation instructions there. The installation image comes with a text-based installer where you can select GNOME. (Personally, I prefer to install a bare-bones system and then reconfigure it to something fancier. This way I can get to enjoy the features of the Guix system much sooner --- including booting into older generations of the system.)

chrisweekly 7y ago

For those (like me) learning of Guix for the first time: >"About GNU Guix GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language." Sounds pretty amazing!

LargoLasskhyfv 7y ago

But...has it USE Flags like Gentoo's Portage? And variable CFLAGS and CXXFLAGS for explicitely choosing to optimize whichever way i see fit, instead of using something generic? Individually, on a per package base? Like described here for example: https://wiki.gentoo.org/wiki/Complete_Handbook/Building_the_system https://wiki.gentoo.org/wiki/Complete_Handbook/Building_the_... https://wiki.gentoo.org/wiki/Safe_CFLAGS https://wiki.gentoo.org/wiki/Safe_CFLAGS

Crestwave 7y ago
As far as I know, it does not have USE flags, but you can customize the compilation however you want, adding build options, patches, etc. They also provide binaries for a good amount of packages if you don't want to build some from source.
- LargoLasskhyfv 7y ago
  I see. But that is not the point. I can customize any compilation anywhere. But it is a hassle i can do without. I really miss the "automagic" of Gentoo because this feature was intrinsic to their package management. I'm watching Guix(XD/System/Whatever) since years, browsing the docs, reading this and that, and it seems to me like just another rpm, deb with some nice addons. And not too inviting at all, because who likes ghettos which ideologically shun this and that which unfortunately is part of my life? Anyways, interesting work whith reproducable bootstrapping in GNU Mes. (sigh)
  - Crestwave 7y ago
    It's not just like those at all... did you think that I was saying that you can just compile things manually or something? You can define build options and such for a group of packages using Guix; there just isn't an abstraction like USE flags. You can find more info at https://ambrevar.xyz/guix-advance/index.html#orgc3c05c9 https://ambrevar.xyz/guix-advance/index.html#orgc3c05c9. And I don't consider its other features just "some nice addons". It's easy to build things from source; in fact, it automatically does it by default if a binary isn't available. It's contained in a directory, you can roll back to a previous state, it's reproducible, everything can be configured through one file, etc. Guix is one of the package managers most different from apt and such; if there's anything it's similar to, it's Nix, which IIRC it's based on/inspired by. Also, I'm curious as to what it is that you do that they shun? Is it working on proprietary software or something?

NateEag 7y ago

I've been intrigued by nix then guix for several years now, but have yet to give either one a test run. I understand some of the technical differences, but can anyone explain the implications of the license differences to me? I know that NixOS is X11/MIT licensed, and that as a GNU project Guix is AGPL. In practice, if I wanted to use Guix as a base system for hosting a proprietary SaaS website, would there be issues with that? Either way, is there an easier-to-read summary than the license itself anywhere?