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

Attempting to Use GNU Guix

zge.us.to

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Attempting to Use GNU Guix

#31

Post by martinflack »

pmoriarty wrote: post #3

Guix in general just needs a lot more contributors and lot more work to come anywhere close to being a competitor to the mainstream (or even near-mainstream) distros and package managers. I'm coming from Gentoo myself, and I've tried to get Guix working on Gentoo a couple of times over the years, and have always been frustrated by how much work and hacking was involved in doing so. I'm no Linux novice, either. I've b…

> trying to compile everything in Guix from scratch on an old laptop is just way too slow. Doing this on Gentoo is slow and painful enough, but it's way worse on Guix, and simply unworkable

Would you elaborate on why you think compilation on Guix is slower than Gentoo? Thanks.

Re: Attempting to Use GNU Guix

#33

Post by takeda »

aseipp wrote: post #29
T-R wrote: post #24

Earlier quoted context omitted.

I'm hoping that maybe Flakes[1] will help ease the issue/pull request situation by letting some of the namespaces move out of the main repository. [1] https://github.com/NixOS/rfcs/pull/49

There are significant advantages to having the entire Nixpkgs package set in a mono repository. While I think Flakes are quite interesting for a number of reasons, I hope it doesn't result in the primary package set getting split up too much. They conceptually act a lot like Git submodules, and going overboard with that is a very easy way to make your life miserable, and significantly increase development turnaround…

I think at very least (and easy to implement) nix needs a bot that closes old tickets. The number of open issues is ridiculous and basically it makes easier for an issue to be overlooked and further increase the count. The number of open issues also causes some people think nix is very buggy and not suitable in production or even exploring.

Re: Attempting to Use GNU Guix

#34

Post by pmoriarty »

martinflack wrote: post #31
pmoriarty wrote: post #3

Guix in general just needs a lot more contributors and lot more work to come anywhere close to being a competitor to the mainstream (or even near-mainstream) distros and package managers. I'm coming from Gentoo myself, and I've tried to get Guix working on Gentoo a couple of times over the years, and have always been frustrated by how much work and hacking was involved in doing so. I'm no Linux novice, either. I've b…

> trying to compile everything in Guix from scratch on an old laptop is just way too slow. Doing this on Gentoo is slow and painful enough, but it's way worse on Guix, and simply unworkable Would you elaborate on why you think compilation on Guix is slower than Gentoo? Thanks.

It's not that compilation itself was slow with Guix, but (to my memory) it was because all Guix packages are completely separate by design and have dependencies which are not shared, so you might have to compile, say, five different versions of guile to satisfy those five different dependencies in five different packages.

Compiling guile from scratch was, by the way, insanely slow, and because I struggled to get Guix working right on my first try, I had to compile it over and over again, which took about a day each time. A "guix pull" took four hours on my system, and I had to do it twice each time, once for root and once for my own user. My first "guix pull" took two weeks due to all the errors, toubleshooting and restarts the process took as I tried to get Guix working as it should.

In addition, it seems that Guix packages don't have optimizations enabled, which is a deal breaker for me, as optimizing the packages I install is a significant reason I compile them from scratch in the first place, as I'm running on an old, slow machine which could use all the performance boosts it can get.

Finally, I might have a broken environment on my system which makes compilation even slower still than it otherwise would be, but until I get it fixed I have to live with it, and so for all of these reasons compiling everything from scratch on Guix is just not practical for me right now.

Maybe with a newer, much faster machine I'd be ok with it.

Re: Attempting to Use GNU Guix

#35

Post by m463 »

MrBingley wrote: post #8

I understand and perhaps admire the GNU project's insistence on being blob-free, but that also means Guix won't run out of the box on 99% of all people's computers. The options are buy (old) hardware that doesn't need blobs (which sometimes isn't even possible), or compile the default kernel to include the binary firmware yourself (which the Guix documentation won't explain for ideological reasons). Both of these wil…

I guess it depends on what you're optimizing.

Hard for a user, but simple for distribution or legal.

Re: Attempting to Use GNU Guix

#36

Post by takeda »

jwilk wrote: post #23
cwyers wrote: post #21

Earlier quoted context omitted.

My guess is that they're referring to the open letter from people working on many GNU projects calling for Stallman to resign.

I think this is the letter in question: https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-pr...

I still don't know what Stallman did.

Re: Attempting to Use GNU Guix

#37

Post by zaphirplane »

ninjin wrote: post #6

Sad to see GNU Guix struggling, they are young though and I have hopes for the future. About a year ago I made a choice between trying out GNU Guix and NixOS, since this week I now run NixOS on all my servers and desktops after gradually phasing out my old Ubuntu stack. It has generally been smooth sailing, with the occasional hick up that required me to draw upon my general Unix skills. What caught me off guard is h…

Something I couldn’t get about nix by skimming the documentation is how it manages application configuration. Using traditional systems when you upgrade the package responsible for the network configuration my current configuration is carried thru or merged into the new format if the package changes it’s configuration syntax. How does nixos manage /etc ?

Re: Attempting to Use GNU Guix

#38

Post by Iv »

I love the style of packets organization that they describe. I think it has a name, I have seen it promoted as an alaternative to the typical mess that is "install everything in various parts of /usr/ and /opt/, put things in /etc/ or ~, silently overwrite old versions"

Re: Attempting to Use GNU Guix

#39

Post by opan »

Someone wrote: post #32

”Just run guix package --roll-pack to “undo” an installation.” I don’t know guix, but that looks like a typo to me. Shouldn’t that be back , not pack ?

'guix package --rollback' is what's in my shell history, so it should probably say that.

Re: Attempting to Use GNU Guix

#40

Post by evil-olive »

zaphirplane wrote: post #37
ninjin wrote: post #6

Sad to see GNU Guix struggling, they are young though and I have hopes for the future. About a year ago I made a choice between trying out GNU Guix and NixOS, since this week I now run NixOS on all my servers and desktops after gradually phasing out my old Ubuntu stack. It has generally been smooth sailing, with the occasional hick up that required me to draw upon my general Unix skills. What caught me off guard is h…

Something I couldn’t get about nix by skimming the documentation is how it manages application configuration. Using traditional systems when you upgrade the package responsible for the network configuration my current configuration is carried thru or merged into the new format if the package changes it’s configuration syntax. How does nixos manage /etc ?

For the majority of changes, it "just works". For example, here's the part of nixpkgs that configures wireless networking via wpa_supplicant, as well as the actual package build of wpa_supplicant:

https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modu...

https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-sp...

Because they're contained within the same git repo, if a new version of wpa_supplicant changed the syntax of wpa_supplicant.conf, the upgrade could be handled easily (assuming the user-facing options in NixOS didn't need to change).

For more complicated changes, there's `system.stateVersion`:

https://nixos.wiki/wiki/FAQ/When_do_I_update_stateVersion

An example of this would be if NixOS version A ships with Postgres version X by default, while NixOS version B upgrades to Postgres version Y. stateVersion allows a sane upgrade path where you can update to NixOS version B without breaking your database immediately (because stateVersion is still A).

Post reply on HN