Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Guix and GuixSD 0.13.0 released

gnu.org

Post reply on HN
Print view View original

21–30 of 37 posts

Re: GNU Guix and GuixSD 0.13.0 released

#21

Post by thomastjeffery »

davexunit wrote: post #16
darklajid wrote: post #14

Earlier quoted context omitted.

I I may (I hope I'm not coming across as rude, I'm genuinely interested in running GuixSD): How 'recent' are the packages? I care for little things, but say.. libvirt or Firefox would be something I'd like to keep quite up to date. Is it possible to run Firefox (not Iceweasel)? Do you use any 'unfree' packages and how much hassle is it to acquire those?

Packages are kept very up-to-date in general. The contributors try their best to keep up with the latest stable releases, so freshness resembles a distro like Arch more than Debian. I don't use any nonfree packages and Guix provides none because it conforms to the GNU FSDG, so there is no Firefox package available. Someone could provide a nonfree package collection that users could install separately but I don't know…

> Someone could provide a nonfree package collection that users could install separately but I don't know of any.

This is the main think holding me back from switching to GuixSD (from NixOS). While I do like the prospect of running a 100% free OS, I'm not 100% sure I can with my current hardware. If I install GuixSD, and find out that I need a non-free driver or kernel, the responsibility of getting that falls on my completely inexperienced lap. I would be much more inclined to run a partially non-free system to get used to GuixSD, then start cutting out the non-free parts.

Re: GNU Guix and GuixSD 0.13.0 released

#22

Post by equalunique »

mtm wrote: post #20
arximboldi wrote: post #12

Any experiences with using GuixSD as a main distribution for a standard laptop working environment? I have been using Debian Sid for more than a decade but the idea of having a system fully configured via reproducible pure Scheme functions is tempting for sure...

I just installed GuixSD 0.12 last week on a Dell 13 7000. Went mostly smoothly (had to use Grub BIOS instead of UEFI, that's been fixed in 0.13) after I replaced the Intel WiFi card with an Atheros based one. My needs are simple: emacs, Clojure (with Icedtea), Icecat and StumpWM. Plus all the guile goodness! Just realized I'm living in a system with four Lisps front and center (guile, Common Lisp, elisp, and Clojure)

That sounds pretty awesome. :)

I'm just here with two NixOS machines playing with ML languages.

Have you tried NixOS & do you have an opinion regarding it? Or was it just straight to GuixSD?

Re: GNU Guix and GuixSD 0.13.0 released

#23

Post by shakna »

darklajid wrote: post #14
davexunit wrote: post #13

Earlier quoted context omitted.

I have been using GuixSD on my Thinkpad X220 for about 2 years now and it is has been good overall. I have fairly simple needs: GNOME 3, Emacs, Firefox (called IceCat in GuixSD). The full system rollback feature has been very handy at times when I do something terrible to my OS configuration file and just want to move on to other things.

I I may (I hope I'm not coming across as rude, I'm genuinely interested in running GuixSD): How 'recent' are the packages? I care for little things, but say.. libvirt or Firefox would be something I'd like to keep quite up to date. Is it possible to run Firefox (not Iceweasel)? Do you use any 'unfree' packages and how much hassle is it to acquire those?

> How 'recent' are the packages?

It's the only place I know of where you can currently get GCC 7.1. [0]

> Is it possible to run Firefox (not Iceweasel)?

If you spun up your own package, and didn't distribute, probably. The IceCat package is 746 lines of Scheme at the moment, so porting it might not be complete hell. [1]

That being said, the current IceCat is based on Firefox 52, so that's a fairly close version-parity, even if you miss out on the nonfree aspects of FF.

> libvirt

Guix currently has libvirt 3.2.0, whereas the very latest is 3.3.0. A fairly close parity, and I'd expect an update to the Guix package soon-ish.

[0] https://www.gnu.org/software/guix/packages/g.html

[1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...

Re: GNU Guix and GuixSD 0.13.0 released

#24

Post by ymse »

darklajid wrote: post #14
davexunit wrote: post #13

Earlier quoted context omitted.

I have been using GuixSD on my Thinkpad X220 for about 2 years now and it is has been good overall. I have fairly simple needs: GNOME 3, Emacs, Firefox (called IceCat in GuixSD). The full system rollback feature has been very handy at times when I do something terrible to my OS configuration file and just want to move on to other things.

I I may (I hope I'm not coming across as rude, I'm genuinely interested in running GuixSD): How 'recent' are the packages? I care for little things, but say.. libvirt or Firefox would be something I'd like to keep quite up to date. Is it possible to run Firefox (not Iceweasel)? Do you use any 'unfree' packages and how much hassle is it to acquire those?

Most of the "core" packages are very recent. Guix typically has zero-day updates for popular software such as git, kernel, ffmpeg etc, and obviously most of the GNU portfolio.

The only "unfree" package I use is the vanilla Linux kernel (for non-free wifi firmware), which is fairly easy to tie into the system configuration.

Re: GNU Guix and GuixSD 0.13.0 released

#25

Post by redtuesday »

davexunit wrote: post #18
nerdponx wrote: post #15

Earlier quoted context omitted.

How easy/hard is it to manage? Does it conflict with Yum?

It is completely isolated from other package managers. So you can use them in harmony, and if you decide that you don't like Guix there's like 2 directories to delete.

I assume unless you use software which installs it's cache/other stuff into the user home directory, right? Then you would also need to delete these dirs as well?

Re: GNU Guix and GuixSD 0.13.0 released

#26

Post by davexunit »

redtuesday wrote: post #25
davexunit wrote: post #18

Earlier quoted context omitted.

It is completely isolated from other package managers. So you can use them in harmony, and if you decide that you don't like Guix there's like 2 directories to delete.

I assume unless you use software which installs it's cache/other stuff into the user home directory, right? Then you would also need to delete these dirs as well?

The only thing that ends up in the user's home directory is a ~/.guix-profile symlink.

Re: GNU Guix and GuixSD 0.13.0 released

#27

Post by davexunit »

dragandj wrote: post #17
rekado wrote: post #6

Earlier quoted context omitted.

Disclaimer: I have been working on Guix since 2014 and use it in production. Guix and Nix are both implementations of the functional package management idea. Nix has been around for quite a few more years than Guix. In Guix package expressions are first-class and the DSL is embedded in Guile, a general purpose language, so packaging has a very different feel to it. It also allows for fun tools like "guix graph". Guix…

How easy (or even possible) is it to use proprietary libraries such as MKL or CUDA or GPU drivers with Guix/GuixSD?

It's all possible to do, but the Guix developers do not provide assistance. From a purely technical perspective, software provided in binary form only impedes one of the main goals of Guix, 100% reproducible builds, because there is no source code.

Re: GNU Guix and GuixSD 0.13.0 released

#28

Post by curiousreader »

rekado wrote: post #5
curiousreader wrote: post #2

How does Guix relate to Flatpak?

Guix is a functional package manager, Flatpak is not. Flatpak is based on the idea of runtimes (a collection of libraries and toolchains). There is no dependency bundling with Guix and there are no "runtimes" against which binaries are deployed. Guix provides the tools for bit-reproducible builds, which is why it's used in some HPC environments (including the institute where I work).

I read up a little on Guix, but I can't reconcile what I read with what you wrote.

Guix clearly does track and even bundle dependencies.

The part I'm missing is how different packages can rely on different dependencies without stepping on each others' toes. And if a certain package relies on a dependency with known vulnerabilities, do I have to wait for the package to change its dependency, or can I upgrade the dependency as soon as it issues a fix?

Re: GNU Guix and GuixSD 0.13.0 released

#29

Post by rekado »

curiousreader wrote: post #28
rekado wrote: post #5

Earlier quoted context omitted.

Guix is a functional package manager, Flatpak is not. Flatpak is based on the idea of runtimes (a collection of libraries and toolchains). There is no dependency bundling with Guix and there are no "runtimes" against which binaries are deployed. Guix provides the tools for bit-reproducible builds, which is why it's used in some HPC environments (including the institute where I work).

I read up a little on Guix, but I can't reconcile what I read with what you wrote. Guix clearly does track and even bundle dependencies. The part I'm missing is how different packages can rely on different dependencies without stepping on each others' toes. And if a certain package relies on a dependency with known vulnerabilities, do I have to wait for the package to change its dependency, or can I upgrade the depen…

> Guix clearly does track and even bundle dependencies.

No, it really does not. What part of the documentation made you come to this conclusion?

Each package is installed into its very own prefix. The prefix is derived from the hash of all of the package's inputs. Inputs mean: the package description itself (including configure flags and the like), the package sources, and all packages it depends on, recursively. This means that every package closes over the complete directed acyclic graph of its dependencies.

Change any of the inputs and the output prefix will change, i.e. the package will end up in a different, separate directory.

Packages keep references to other packages. Instead of bundling all dependencies under the package's prefix, packages can reference other packages directly. We use the RUNPATH feature to embed absolute file names of e.g. libraries.

A big part of Guix itself is a collection of package definitions. These definitions are just Scheme values. Taken together, these Scheme values describe a lazy graph of dependencies. Guix instantiates parts of this lazy graph when installing packages.

As I wrote above, any change to a node in the graph affects all other nodes upstream of it. If there's a security fix that needs to be applied to, say, the glibc it will cause a rebuild of all packages that depend on it. (There is an optimisation called grafts, which allows us to deliver security fixes without actually rebuilding the world.) Packages that have been installed already, however, will remain untouched. To benefit from a security fix these packages have to be upgraded.

Guix makes it trivial to find the users of any given package in the store, so it's easy for example to figure out if you have software that uses a vulnerable library.

Re: GNU Guix and GuixSD 0.13.0 released

#30

Post by rekado »

zck wrote: post #19
arximboldi wrote: post #12

Any experiences with using GuixSD as a main distribution for a standard laptop working environment? I have been using Debian Sid for more than a decade but the idea of having a system fully configured via reproducible pure Scheme functions is tempting for sure...

I tried to use it on top of my Ubuntu install to manage dependencies, and the very first thing I wanted to do didn't work. I wanted to set up Java so I could run Clojure, and the version of Java they build can't make any https requests. There was also a subtext of "you should just build everything in Guix; don't use leiningen or maven". It was pretty disappointing. I hope they can get things to work better; it would…

> the version of Java they build can't make any https requests

This is no longer true.

Our approach to Java is a bit ... unusual. Nobody in the Java world appears to be building everything from source, so bootstrapping the environment is a pretty tough job.

Now we bootstrap the JDK itself from Jikes and GNU Classpath, and we have quite a few more Java packages than before, but still not enough to get Maven packaged without resorting to using pre-built binaries.

There's still a long way to go, but we're walking it.

Post reply on HN