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

I Love Arch, but GNU Guix Is My New Distro

boilingsteam.com

Post reply on HN
Print view View original

121–130 of 318 posts

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

#121

Post by jrm4 »

dralley wrote: post #118
jrm4 wrote: post #111

Earlier quoted context omitted.

Lobbing a charge like "Arbitrary religious dogma" is pretty much the opposite of a reasoned look at what the goals are here. I find the approach interesting. The goal of the Free Software folk was never primarily to "provide the best information to the end user," it is to "preserve software freedom." Guix looks like a possible technical path to do that. Will it work? Will it cause harm? I don't know yet. Either way,…

Yes, but how does static proprietary firmware blobs burned into ROM "preserve user freedom" vs. dynamic loading, even if the user has complete control? It doesn't, and that's why it's arbitrary.

Those two things are WILDLY DIFFERENT in real life. Broadly, "firmware blobs" are usually put there by companies and other entities that you can much better track (and sue if you have to). Dynamic loading stuff can come from any-darn-where. Apologies, but this should be really obvious.

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

#122

Post by marcodiego »

marcan_42 wrote: post #27

> 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 reasons to someone from inside the FSF, so I my knowledge about it can improve. Nevertheless, I can see some points:

  - AFAIK, the form of accepted code is only for "secondary processors" and can't take over the system or compromise it,
  - having things in ROM forces manufacturers to maximally simplify it,
  - having things in ROM forces manufacturers to implement more features in software that can be checked and
  - having things in ROM forces manufacturers to be extra careful when implementing it.
I don't think FSF would consider IME acceptable if it was ROM.

But indeed, it would be very good if someone from FSF could better explain it.

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

#123

Post by amelius »

Nullabillity wrote: post #107
amelius wrote: post #81

Earlier quoted context omitted.

> If you just use pip & co, nix will be unaware of it and won't care one way or another. It will basically treat your pip-installed stuff like it'd treat your sourcefiles or pdfs. Also if you run pip as root (to install for all users at once)?

It fails, because NixOS mounts /nix/store (the Nix store, where all managed packages are stored) as read-only (with some trickery used by Nix itself to bypass this for its own builds). And if you bypass that , `nix-store --verify --check-contents` can detect the issue.

This is very reassuring, thanks.

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

#124

Post by grumbel »

earthscienceman wrote: post #13

A question that nags me every time Guix comes up, or nix, is about the benefits relative to a normal distro on something like ZFS. Are reproducible builds ever going to be all that important to a user? Rollbacks seem like the key feature here and that seems much better left up to the filesystem, not the package tools. This way your storage is also aware of what you're doing.

Rollbacks are a minor feature, I never found any use for in either Guix or Nix.

The main advantage of both of them is that installation and 'making available' are decoupled. Meaning you can install five different versions of the same app and it'll be totally fine, as they don't sit around in '/usr/bin/foo' and clashing with each other. They sit conflict-free in '/nix/store/${HASH}/bin/'. For making them available for use you have to add them to your profile/environment (i.e. $PATH and symlinks that point '/nix/') or just run them from their '/nix' directory if you prefer. This makes development and testing new versions much easier as nothing ever really breaks to begin with. You can just spawn a new environment, fill it with whatever you need and use it. And it all happens at the packaging level, so it's pretty quick and you never end up with snapshots that capture far more of your filesystem than you planed.

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

#125

Post by jrm4 »

grumbel wrote: post #113
kzhukov wrote: post #74

Earlier quoted context omitted.

Well, for some people loading an arbitrary binary code without possibility to check what's inside it is a critical security issue as well.

The issue is that the FSF fine with that binary blobs as long as it's stored in ROM, but if it's in RAM, that's bad. To me that is completely backwards. If a driver loads firmware into RAM, that means I have easy access to the blob, can reverse engineer it, update it and change it. If it's ROM that's going to be a lot more difficult or impossible. Sure it would be nice to have it all Free Software, but then we should…

Your theory makes sense, but practice strikes me as the reverse: Long-term: Stuff in ROM is significantly easier to track because it happens slower, mostly by large trackable entities and processes. Stuff in RAM? Always changing and "under attack" all the time.

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

#126

Post by WastingMyTime89 »

marcodiego wrote: post #122
marcan_42 wrote: post #27

> 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…

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.

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

#127

Post by ckastner »

jrm4 wrote: post #121
dralley wrote: post #118

Earlier quoted context omitted.

Yes, but how does static proprietary firmware blobs burned into ROM "preserve user freedom" vs. dynamic loading, even if the user has complete control? It doesn't, and that's why it's arbitrary.

Those two things are WILDLY DIFFERENT in real life. Broadly, "firmware blobs" are usually put there by companies and other entities that you can much better track (and sue if you have to). Dynamic loading stuff can come from any-darn-where. Apologies, but this should be really obvious.

The OP referenced CPUs and for at least AMD and Intel CPUs, firmware blobs need to be signed.

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

#128

Post by MichaelBurge »

marcan_42 wrote: post #79
medo-bear wrote: post #75

Earlier quoted context omitted.

i just looked through this website and found a link to their certification process at https://ryf.fsf.org/about/criteria it states: > However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, mic…

The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing users of such secondary processors are all deceptive. Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot…

I'm not the FSF, but one argument could be things like the Intel Management Engine that I know the FSF have strong opinions on.

If that's isolated to a separate CPU, it's easier to track the signals going in and out, and the bad things it can do are limited.

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

#129

Post by stjohnswarts »

marcan_42 wrote: post #27

> 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…

It has a lot of features that could make it useful in certain contexts like VM installs where you don't need to lean heavily on GPU. I'm going to try it at some point this weekend on a qemu VMM

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

#130

Post by dralley »

jrm4 wrote: post #121
dralley wrote: post #118

Earlier quoted context omitted.

Yes, but how does static proprietary firmware blobs burned into ROM "preserve user freedom" vs. dynamic loading, even if the user has complete control? It doesn't, and that's why it's arbitrary.

Those two things are WILDLY DIFFERENT in real life. Broadly, "firmware blobs" are usually put there by companies and other entities that you can much better track (and sue if you have to). Dynamic loading stuff can come from any-darn-where. Apologies, but this should be really obvious.

Yes, that is obvious. It is in fact one of the benefits dynamic loading provides for people who care about free software. The blob can often be reverse engineered and replaced with free software.

And literally everyone signs their firmware.

Post reply on HN