Live data from Hacker News

I Love Arch, but GNU Guix Is My New Distro

boilingsteam.com

141–150 of 318 posts

Re: I Love Arch, but GNU Guix Is My New Distro

#141
post #19
post #11

Earlier quoted context omitted.

As a NixOS user who has (recently!) played with Guix, I don't think ‘battle testing’ is a great reason to prefer Nix. Guix has an excellent CLI and awesome docs. It's stable and plenty usable. All being in one, high-level language like Scheme makes it seem really easy to hack on, and I think that's part of why its CLI is so good already. Nix is faster, it supports macOS, and its package collection is much bigger beca…

What about number of packages available? Does guix have something comparable to Nix Flakes?

I think Guix has like 1/3 the total number of packages available, probably less. This may not be a huge deal— when I started using NixOS, Nixpkgs was much smaller than it is now, too, but it still felt worth it for me. As another user pointed out, packaging in Nix and Guix is pretty easy for anything that doesn't have a bespoke or ill-behaved (requiring network access, trying to write to the directories of other packages, etc.) build system. But it can make a big difference for usability if packaging work is cumbersome for you, or something very large or complex that you want is missing. (I think KDE is still missing, for example.)

Nix flakes are kind of a lot of things: a version pinning system, the switch to pure evaluation mode by default (which impacts caching in a good way but makes configuration slightly more annoying), a distribution mechanism for code written in Nixlang, and a collection of Nixlang schemas which enable a richer command line experience (that, e.g., power the new `nix run` command). It's not clear how many of those functions Nix flakes will retain in its final form.

There's no singular feature that attempts all that in Guix as far as I know, and I don't know the general technical story for evaluation caching with Guix. But Guix does have an integrated, first-party form of package pinning. Where Nix flakes replaces the old 'channel' system, Guix has a richer notion of channels which support pinning in normal Guix expressions.

(In Nix, channels are an output that have a certain structure and get managed in a certain way via fhe nix-channel command to manage them— they're like another type of Nix profile. In Guix, channels are defined by the user directly in Scheme code, just like the rest of their configuratiom, which is more similar to how Nix flake inputs are defined than to Nix channels.)

I've never used Guix channels in anger, so I can't tell you how nice that notion of version pinning is to use.

Re: I Love Arch, but GNU Guix Is My New Distro

#142

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

> "removes security warnings informing users that they need to update their CPU microcode" If you update your CPU microcode to something that can't be checked, you're already sacrificing security. EDIT: But yes, I understand people complaining that FSF rejects proprietary software but is OK with some forms of ROM which in turn may be very similar to "proprietary software you can't change". Well, I never asked their r…

> If you update your CPU microcode to something that can't be checked, you're already sacrificing security.

You are already running CPU microcode that can't be checked when you are running Guix on x86. That ship sailed when you decided to use x86.

Re: I Love Arch, but GNU Guix Is My New Distro

#143
post #135

Earlier quoted context omitted.

Yeah. Then these geniuses get bitten by Spectre/Meltdown because they were too scared of running the microcode update. For real. I agree, if that's the position of Guix, I don't want it in my machine.

Sorry, but you are wrong. GNU people won't run nonfree JS at all. LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run.

At that point why just not power off their machines? That 3 websites that has “free js” is almost as useless as a brick. Also, free software in itself never protected against security vulnerabilities, many eyes is a fallacy.

Re: I Love Arch, but GNU Guix Is My New Distro

#144
post #20

Is there a reason neither Guix nor Nix have made an LTS-type repo? A rolling release seems at odds with the stability granted by reproducible builds. Maybe I have a miopic view, but what's nice with Ubuntu LTS is you know everyone and their mothers has built and tested their packages/libraries/executable against the lib versions provided by Ubuntu 18.04 or 20.04 or whatever. You also know those libs, at their given v…

There are pros and cons of the LTS approach.

A big CON is that even on Ubuntu LTS, lots of softare is incredibly out of date and full of unpatched security vulnerabilities.

Consider Roundcube, probably the most popular PHP email web client.

On Ubuntu 18.04 LTS the last update is from, well, April 2018: https://packages.ubuntu.com/bionic/roundcube

Now consider the amount of CVEs (remote code execution and XSS) published for Rouncube since then, which are all unpatched in that Ubuntu: https://www.cvedetails.com/vulnerability-list/vendor_id-8905...

If you are running Ubuntu LTS on your server, that's a big problem.

The `roundcube` package is in the `universe` repository, meaning "community maintained". In this case for this LTS that meant "no security updates at all for 3 years". The newer LTS, 20.04, doesn't seem to have those CVEs fixed either.

Re: I Love Arch, but GNU Guix Is My New Distro

#145

Earlier quoted context omitted.

Non sense. I trust my CPU provider or I wouldn’t have bought this CPU. I would much rather use an updated microcode than one known to be insecure. I wouldn’t check the microcode anyway and I don’t really trust the people who might more than the company providing my CPU. Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.

If you have enough trust in proprietary software distributors to not care to use software that can't be checked, then you're probably not part of this discussion. I don't check all the software I use myself. But I use open-source software with the peace of mind of someone who knows that the incentives to abuse me are simply not there and the fact that right now that are hundreds of people/bots checking it. > Sure it…

> the fact that right now that are hundreds of people/bots checking it.

As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. Also, the lack of security in userspace GNU/linux codebases is something really worrying, much much more so than hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?

Re: I Love Arch, but GNU Guix Is My New Distro

#146
post #93

Earlier quoted context omitted.

I guess what I don't get is, wouldn't an LTS be way way easier to maintain than a rolling, constantly breaking, release. Heck, id even prolly go through the effort of maintain my own software as a package if it's something I could do once every few years over a stable base. They could even make life easy and match version numbers with whatever the latest Ubuntu LTS is using. And people that'd need newer libs/bins cou…

No. LTS is much more prone to breakage. LTS means you're porting yesterdays's security patches onto code that has been abandoned five years ago. And usually you have package maintainers doing this, not actual software developers. There's no reason to run LTS unless for corporate insanity purposes.

> And usually you have package maintainers doing this, not actual software developers.

This is a weird thing to say. The package maintainers doing substantive backporting work for any distribution absolutely are actual developers.

> There's no reason to run LTS unless for corporate insanity purposes.

LTS releases also give you stability of behavior, which can be valuable even outside of corporate environments.

Plus six months is really short. There's plenty of space between that and the full lifecycle length of a major RHEL release, or an Ubuntu LTS. NixOS releases that lasted two years would be awesome.

I'd love to try to use a more long-term NixOS release for a downstream project, if it ever got the kind of corporate backing necessary to sustain that kind of release.

Re: I Love Arch, but GNU Guix Is My New Distro

#147
post #32

I moved to NixOS and came back to Arch because setting up development environments for general purpose computing felt tricky. I was on a schedule so had to drop it. Is it the same for Guix? I don't know why it should be any different. But still asking. Also, am guessing people will likely have hardware compatibility issues for Guix which isn't a problem for NixOS since they bundle non-free drivers etc.

For “tmp-like” codes, I had a folder with debian installed. I could systemd-nspawn into it for a basically zero-overhead “standard” unix system.

But for slightly larger projects, creating a package description was always worthy. I especially liked having a shell config where entering a directory automatically put the necessary packages in scope.

Re: I Love Arch, but GNU Guix Is My New Distro

#148
post #145

Earlier quoted context omitted.

If you have enough trust in proprietary software distributors to not care to use software that can't be checked, then you're probably not part of this discussion. I don't check all the software I use myself. But I use open-source software with the peace of mind of someone who knows that the incentives to abuse me are simply not there and the fact that right now that are hundreds of people/bots checking it. > Sure it…

> the fact that right now that are hundreds of people/bots checking it. As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. Also, the lack of security in userspace GNU/linux codebases is something really worrying, much much more so than hypothetical hardware attack when you can just append to the end of .bashrc from…

> As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities.

There are also automated scans of a long list of FLOSS. Google runs OSS-Fuzz, you can check LibreOffice to see lots of commits to fix defects detected by OSS-Fuzz, coverity and other static analyzers. Access to the code, at the least allows determined users to more easily find where or why the bug happens. And yes, people do it.

> hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?

Yes, this is more serious. But would need a compromise on packagers side and an uninformed (or automated) update on my side. Considering an update with such a vulnerability would affect initially a small fraction of users before being discovered, it is very unlikely that this hypothetical would have a big impact.

Re: I Love Arch, but GNU Guix Is My New Distro

#149
post #91

Earlier quoted context omitted.

A couple of things - if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always. Then there’s the question of how exactly you reached this state. Having nixos generations is like having an event stream of all changes. Apply your backup to a new machine, what happens?…

> if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always. Could you elaborate on this? If I have state that works on v1 and after upgrade to v2 the state is now non backward compatible to v1, how nix (or guix) can help? As far as I can tell, in such case a fs roll…

What state do you mean? Let’s say you have a backup of your system partition but your home folder is separate. In that case a rollback with the filesystem is the same as one through nix — the latter will place symlinks to all the previous versions and the finished result is identical.

Of course if you have in the meanwhile used the new system and your home folder contains some backwards incompatible changes, both solutions will fail. Rolling back your home folder may not be a good thing as you may have backwards compatible changes you prefer.

Also, nix can also manage installed application’s configs, so those could also be rolled back, on either a per-app basis or however you prefer.

Re: I Love Arch, but GNU Guix Is My New Distro

#150

Earlier quoted context omitted.

> Not sure what level exactly a beginner is, but I have my problems with Guix docs too. Oh don't get me wrong, I'm not saying guix is better (I have absolutely no idea), just that the experience with nix is extremely rough so nix being a bit more popular is not necessarily that much of an edge (or one at all). > I like Guix as package manager, but their docs can definitely be improved with loads of examples and tutor…

I wrote down all I learned here: https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-pack... (or use org-mode file in same repo) I've not yet had the energy or patience to learn the TexInfo format, which is a standard for GNU projects. But if anyone wants to put what I have in the Guix docs, even as merely an example or tutorial, I wont mind.

Out of curiosity, did you try exporting from org mode? https://orgmode.org/manual/Texinfo-export-commands.html
Post reply on HN