If it wasn't for AMD GPU closed firmware I could use GNU Guix with linux-libre kernel.
I Love Arch, but GNU Guix Is My New Distro
201–210 of 318 posts
Re: I Love Arch, but GNU Guix Is My New Distro
#202As much as I love lisp and hate the Nix expression language, I'm interested in actually getting things done more than I am in preserving software freedom, so I'm on NixOS.
Re: I Love Arch, but GNU Guix Is My New Distro
#203Earlier quoted context omitted.
God doesn't exist, that doesn't prevent him of being. The quest for freedom is, of course, an idealistic one. The important thing is that, in their fight to promote freedom, they meet obstacles. Those friction points reveal the lack of freedom. And so, although they don't reach freedom, they actually show that freedom is limited. IOW, refusing the statu quo is one of the way to change it. You should look at history a…
> how much freedom you have, how much protection you have, etc. and then ask yourself : where does it come from Game theoretic behaviour in society that has advanced beyond zero sum. Same goes for reasonable approach to FOSS, like Marcan is doing himself vs the cult and the arbitrary zero tolerance rules.
i strongly disagree. i think cult, dogma, and religion accusations as well as misrepresentation of FSFs stance (i have zero association with FSF yet i could see thatbtheir position is being crudely misrepresented) do much to discredit any valid points marcan holds
Re: I Love Arch, but GNU Guix Is My New Distro
#204Earlier quoted context omitted.
The OP referenced CPUs and for at least AMD and Intel CPUs, firmware blobs need to be signed.
In theory a government could force AMD or Intel to sign a malicious firmware. That could be distributed as the normal firmware or used to target a specific person. Firmware that ships with the actual CPU is a bit 'safer' because it has a lot more users and eyes looking at it (sort of). Depends on what your attack vector is. Another aspect is that while this policy is worse for Linux-libre users, it is sort of a prote…
Nobody is looking at Intel's microcode mask ROM. It's in ROM. You can't even look at it.
Microcode is a bad example because the updates are encrypted too, but for the vast majority of the blobs that the FSF hates so much, at least you can look at them and audit them with a disassembler. Meanwhile, the devices with giant firmware ROMs that they openly endorse are not auditable, as you can't see the blob. This policy is making it easier for manufacturers to ship backdoors that will never be detected.
Re: I Love Arch, but GNU Guix Is My New Distro
#205Earlier 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.
I don't fully agree with some of these decisions, but in the defense of Guix I must say as a user replacing linux-libre by the linux kernel is trivial if you are using guix tooling.
Re: I Love Arch, but GNU Guix Is My New Distro
#206I 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.
It's tricky because both There is more than one way to do it, and many of those ways aren't well documented. Here's what I use:
- steam-run lets most binaries targeted at Ubuntu "just work" with no setup.
- buildFHSUserEnv lets you work with things that expect a typical /usr /bin /etc tree
- For cases where I just need an LD_LIBRARY_PATH and PATH setup, see[1]. This runs an emacs with my development environment. Since it uses buildenv, if I find I'm missing a library, I can add it, and rebuild the environment without starting emacs and it works fine.
Re: I Love Arch, but GNU Guix Is My New Distro
#207Earlier 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.
Reading this from the guy who's trying to put Linux on a black-box has a certain flavor of irony, to me.
Re: I Love Arch, but GNU Guix Is My New Distro
#208Earlier 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…
The FSF have repeatedly associated software freedom (by their definition) with security and privacy. This is just one example, there are many others:
Re: I Love Arch, but GNU Guix Is My New Distro
#209Earlier quoted context omitted.
Same way that it's ok that if you update your distro it fetches newer drivers, a new kernel and patched versions of all the software you installed? Microcode is loaded at runtime, it's not permanently modifying your system.
The question is still: are "magic incantations" in packages ok, considering that they allow the issuer to control your hardware more than if the code was baked into firmware just once? Also, these packages allow vendors to keep quiet about security issues, because they can silently fix them in the next update.
Is it any more of a "magic incantation" than the linux-image-XYZ package which controls which OS kernel is installed? Or the linux-firmware package which controls what firmware gets loaded on various devices?
If you want to see when Intel issues new microcode updates, it is all available on their GitHub: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
Re: I Love Arch, but GNU Guix Is My New Distro
#210Earlier quoted context omitted.
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.
> 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.