I Love Arch, but GNU Guix Is My New Distro • Hacker News Board

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

#171

Post by opan » Sat, Nov 20, 2021, 5:34 PM UTC

amelius wrote: post #70

opan wrote: post #44

Earlier quoted context omitted.

Guix, and I think Nix also, package the things from these other package managers so you can manage them all with the same package manager. This also means features like rollbacks can apply to your emacs packages. You can run pip on Guix System, but I don't think you'd have to, ideally. Same for rust's cargo and so on.

Ok, makes sense. Does that mean that you don't get the latest updates that are available in pip? Also, what happens if you incidentally run pip on a Nix system? Will it mess up your installation?

You can update packages to newer commits ahead of guix itself updating the package with a simple command[0] as long as dependencies and such haven't changed. So, if guix were behind, you should be able to easily remedy it.

[0] guix install mpv --with-commit=mpv=cc4ada655aae06218b900bb434e3521566394cde

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

#172

Post by mbakke » Sat, Nov 20, 2021, 5:35 PM UTC

detaro wrote: post #37

amelius wrote: post #34

Earlier quoted context omitted.

Huh? I've never updated my CPU microcode in other distros, nor did I receive warnings about it. Do you have a better example?

... yes, because your distro did the right thing and does provide updated packages and loads them for you (it's not persistent, but rather done on each boot), and thus you don't need to do anything and also don't see warnings about your distro failing to do so. Whereas linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-u…

> linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode

This is FUD. The reason it's not possible to load microcode or other proprietary blobs from linux-libre is because of a limitation of the deblobbing process. From [0]:

Indeed, I became aware that some users have got the idea that blocking the loading of blobs is a feature. It's not; it's just a bug that's quite difficult to fix. The decision on whether or not to use a piece of software, be it Free or not, should belong to the users, and it's not our intent to make that difficult.

If you can make the deblobbing script leave an escape hatch for users to load their own blobs, at their option, I'm sure the pull request would be well-received.

[0] https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-lib...

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

#173

Post by anthk » Sat, Nov 20, 2021, 5:42 PM UTC

kaba0 wrote: post #143

anthk wrote: post #135

Earlier quoted context omitted.

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.

You are really wrong, a lot of services (specially news) work either without JS or have a libre alternative, such as Twitter/Nitter, or Reddit/Teddit.

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

#174

Post by raverbashing » Sat, Nov 20, 2021, 5:51 PM UTC

mbakke wrote: post #164

raverbashing wrote: post #103

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.

Guix will never prevent you from doing what you want with your hardware. Nor will it give you software that is not properly free (as in freedom). The "nonguix" channel mentioned in the article does have Intel and AMD microcode for users who want it. This is similar to Debian, where you have to opt-in by enabling the "nonfree" repository and "apt install" the microcode package corresponding to your CPU.

Good to know, but still

> where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode

Is not ok

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

#175

Post by mbakke » Sat, Nov 20, 2021, 5:55 PM UTC

wheelerof4te wrote: post #102

wiz21c wrote: post #95

Earlier quoted context omitted.

> arbitrary religious dogma "arbitrary political view" there's a difference, it matters.

It is a religion at this point. Political views have parties and parties have supporters. FSF is more like a cult that has followers. How else do you explain their rejection to include Debian as a fully free distro?

Debian is rejected because it has an official, endorsed "non-free" repository. That does not fulfill the GNU FSDG:

https://www.gnu.org/distros/free-system-distribution-guideli...

Specifically, "A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so."

This is a political stance based on rational arguments and has nothing to do with religion.

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

#176

Post by rlopezcc » Sat, Nov 20, 2021, 6:03 PM UTC

wheelerof4te wrote: post #102

wiz21c wrote: post #95

Earlier quoted context omitted.

> arbitrary religious dogma "arbitrary political view" there's a difference, it matters.

It is a religion at this point. Political views have parties and parties have supporters. FSF is more like a cult that has followers. How else do you explain their rejection to include Debian as a fully free distro?

> Political views have parties [citation needed] Political views MAY have parties. I agree to some extent with the cult argument though.

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

#177

Post by marcan_42 » Sat, Nov 20, 2021, 6:11 PM UTC

MichaelBurge wrote: post #128

marcan_42 wrote: post #79

Earlier quoted context omitted.

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.

The FSF don't actually care about such details - sure, they'll deride ME, but they make no attempt to inform users about how it compares with alternatives and which options are better for users. That's because their criteria are not based on technical analysis, like determining what the access surface of the blobs is, but instead on the mere existence of the blobs. To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust.

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

#178

Post by civodul » Sat, Nov 20, 2021, 6:12 PM UTC

pxc wrote: post #141

kohlerm wrote: post #19

Earlier quoted context omitted.

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

"guix describe" and "guix time-machine" make it rather easy to pin a Guix revision (and thus the whole package set) and to restore it anytime:

https://guix.gnu.org/manual/en/html_node/Replicating-Guix.ht...

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

#179

Post by seoaeu » Sat, Nov 20, 2021, 6:13 PM UTC

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…

The question is why proprietary microcode that ships with your CPU is fine, but microcode patches released later are non-free? According to the FSF, you should never apply a vendor's microcode patch and instead you should buy a newer processor from them which will ship with the microcode patch already burned in.

You can't even argue that it is a difference of being stored in ROM vs. RAM because the existence of patches means that microcode is upgradeable.

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

#180

Post by marcan_42 » Sat, Nov 20, 2021, 6:14 PM UTC

ajvs wrote: post #86

marcan_42 wrote: post #82

Earlier quoted context omitted.

Those people are already running arbitrary binary code without the possibility to check what's inside, it's just that it was loaded before purchase. If you don't trust Intel's updates, then you also can't trust their CPUs in the first place.

Just because some proprietary code exists doesn't mean you should leave the door open for them to add as much extra proprietary code as they wish. You can regard it as two separate features: one that's needed for the CPU to function, and another that's the door for more code being added. In that perspective it's better to go with preventing additions.

You can't add much to a CPU via microcode. The space of what updates can do is extremely limited, with a limited amount of patch RAM and patch registers. It's designed to fix bugs. You're arguing against fixing bugs in proprietary software you're already running.