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

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

#221

Post by detaro » Sat, Nov 20, 2021, 8:43 PM UTC

mbakke wrote: post #172

detaro wrote: post #37

Earlier quoted context omitted.

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

Then why is the reasoning in the linked email given as

> Another significant change in this release is that it was pointed out that there were error messages in Linux suggesting users to update x86 CPU microcode. Since such microcode is non-Free Software, such messages don't belong in GNU Linux-libre.

That reads very much as "we don't want to encourage users to consider updating microcode". Your argument also seems unlikely since distros ship the microcode as an extra package that gets picked up by the kernel, so clearly the ability to not upload microcode if the user doesn't provide it is there. (It makes sense that is that way and a different situation than the drivers your link discusses, since the device runs without a microcode update, whereas peripherals that need blobs often won't run at all without them)

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

#222

Post by rollcat » Sat, Nov 20, 2021, 9:10 PM UTC

mbakke wrote: post #175

wheelerof4te wrote: post #102

Earlier quoted context omitted.

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

And by Debian's definition, some of FSF's own packages are non-free (notably, the documentation), so you have to explicitly opt-in to installing that.

I wish both of them directed their efforts towards more pragmatic problems, like making their software more accessible. In the rest of the world, freedom is usually a function of accessibility.

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

#223

Post by mindslight » Sat, Nov 20, 2021, 9:44 PM UTC

User23 wrote: post #199

mindslight wrote: post #158

Earlier quoted context omitted.

No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page: > AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization) > AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot…

One of the nice things about the FSF's free software principles is that if you disagree with how they think you should use their software, they're not going to stop you. Nonguix[1] provides solid non-free support if that's what you want. In fact it has a helpful section on microcode updates. The FSF even condones non-free software (in a rather dorky way) for people whose machines require it[2]. I understand the FSF's…

I fully believe in software freedom (including favoring the GPL), and am trying to push it forward with this argument. I just see using a "6300 with microcode 2019-12-18" as the exact same compromise as using a "6200 with microcode 2011-11-14", regardless that the first blob was loaded at runtime while the second blob was loaded at the factory. Neither one lets me audit or modify my processor. There aren't many performant processors that do let you do such things, so the FSF is willing to compromise on systems with the second type of processor. I argue that they should extend that same pragmatism to the first type of processor as well.

Ultimately, the goal of a GNU/Linux distribution is to create a fully Free GNU/Linux environment. A fully free system would be a worthy goal, but Guix is not attempting such a thing (say by refusing to run if it detects hardware that has non-free firmware in flash). Rather they preemptively compromise by ignoring blobs stored in flash, but refuse the same compromise when those blobs would be loaded at runtime. This is completely backwards given that blobs loaded into auxiliary processors' RAM by Free software running on the main processor are actually more under the control of Free software.

And sure, nonguix exists. But I've gotten the impression that when you interact with the Guix community (eg irc), they will give you a bit of a cold shoulder for using nonguix because it is "not free software", even though you're making the exact same compromise as anyone else with a non-Free microprocessor or non-free auxiliary processor firmware. So ultimately I'm arguing that community norms, as led by the FSF, need to change here. They're stuck with an outdated model that simply ignores embedded firmware, rather than engaging with the nuance of labeling each part of a system as "free" or "non-free"

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

#224

Post by mindslight » Sat, Nov 20, 2021, 9:50 PM UTC

medo-bear wrote: post #183

mindslight wrote: post #158

Earlier quoted context omitted.

No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page: > AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization) > AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot…

i am not affiliated with FSF in any way. yet it seems to me that there are plenty of people arguing against them in very bad faith. here is the full excerpt in question: BEGIN >CPUs supported: >AMD Opteron 6100 series (Fam10h. No IOMMU support. Not recommended - old. View errata datasheet here: http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf ) >AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboo…

If you are referring to me, I don't see how my excerpt is incomplete or could be seen as bad faith. Libreboot is steering people away from 6300 processors because using them requires explicitly loading a proprietary blob, while encouraging the use of 6200 processors that have an analogous blob baked in at the factory. The real difference is that the former makes you more aware of the compromise.

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

#225

Post by jordanbeiber » Sat, Nov 20, 2021, 9:51 PM UTC

kaba0 wrote: post #149

m1keil wrote: post #91

Earlier quoted context omitted.

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

Sure you could, like Solaris did IIRC, zfs snapshot before updates was applied.

What I mean is that a fs snapshot is ”dumb” in and of it self.

If you couple zfs with the nixos rebuild command, then… sure, I guess - but the previous generations are already more or less directly available, unless GC’d.

This is what the fine manual has to say:

Since Nix is good at being Nix, most users will want their server's data backed up, and don't mind reinstalling NixOS and then restoring data.

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

#226

Post by fsflover » Sat, Nov 20, 2021, 10:23 PM UTC

kaba0 wrote: post #145

marcodiego wrote: post #131

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

This is debatable: https://en.wikipedia.org/wiki/Comparison_of_open-source_and_.... Any links to your argument?

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

#227

Post by alexvoda » Sat, Nov 20, 2021, 10:25 PM UTC

medo-bear wrote: post #188

marcan_42 wrote: post #177

Earlier quoted context omitted.

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

>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. For a company that values software freedom above all else this is completely fine. If they are called Secure Software Foundation then your arguments would hold more weight. For example, I really doubt that FSF would claim that GNU Guix is more secur…

Security is part of protecting your freedom from being compromised. I read this entire thread and wholeheartedly agree with marcan_42. FSF's position to draw a line where none exists is foolish wishful thinking and potentially dangerous.

I prefer knowing that I live in a world where COMPLETE software freedom is close to unachievable and it (COMPLETE software freedom) is a worthy goal to strive for compared to deceiving myself into believing it has been achieved by ignoring anything below a certain level.

Just because I choose to amputate my ability to update firmware does not mean a malicious party might not be able to do so. Anyone with physical access to hardware will still have that ability by using extra hardware. Handwaving the firmware away does not work against an evil maid attack.

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

#228

Post by jrm4 » Sat, Nov 20, 2021, 10:32 PM UTC

mastax wrote: post #210

jrm4 wrote: post #125

Earlier quoted context omitted.

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.

> Stuff in ROM is significantly easier to track because it happens slower, mostly by large trackable entities and processes. Assuming you're able to track it at all. If the hardware does not provide any way to read the blobs, then how do you track anything? Decap your CPU and stick it under an electron microscope? Much easier to inspect a file on my filesystem.

You're completely missing the fundamental point that all of this takes a proverbial village.

Free software isn't about each of us individually fixing the problems. Nearly exactly the opposite.

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

#229

Post by jrm4 » Sat, Nov 20, 2021, 10:34 PM UTC

marcan_42 wrote: post #200

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

There is no freedom without information. Freedom requires being informed so you can take decisions that you believe are best for you. Lack of knowledge restricts your ability to make the right choices, and thus your freedom. "Freedom" through lack of information is the kind of tactic that repressive regimes use to control their populace. It has no place in an organization claiming to further and support true freedom.

And exactly when did Guix or the FSF censor anything?

I'm not speaking for them, but I'm pretty sure they would say something in the realm of "the information provided by your updates is a false sense of security, so why WOULD we pass that on?"

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

#230

Post by alexvoda » Sat, Nov 20, 2021, 10:43 PM UTC

medo-bear wrote: post #214

marcan_42 wrote: post #208

Earlier quoted context omitted.

The FSF have repeatedly associated software freedom (by their definition) with security and privacy. This is just one example, there are many others: https://www.fsf.org/bulletin/2020/spring/privacy-encryption

but security is associated with free and open source software. i think this is a common position of a vast majority of security experts. to make your claim that FSF deceives or misleads people you need to do a LOT more. for example, can you provide an example where someone claims that GNU Guix is secure by design[0] i think that taking a position that free software supports security and also that free software princi…

The factors that actually impact the upper boundary of achivable security are availability of source code (open or not) and reproducible builds. The 4 freedoms do not actually affect any aspect of security, they are orthogonal.

Also, just because the 2 factors above impact the upper boundary of achievable security does not mean an open source software is automatically more secure.

It is conceivable for 2 comparable pieces of software to exist one open source and the other closed source and for the closed source one to be more secure.

There are many reasons why open source software is in practice considered more secure, among others being faster availability of updates and the aforementioned higher upper ceiling of security.