6 ms·

This is completely obtuse. Why isn’t your anger at the Guix or Linux-libre maintainers’ supposed withholding of information (‘censorship’) directed instead at p

by kdtsh 5y ago

This is completely obtuse. Why isn’t your anger at the Guix or Linux-libre maintainers’ supposed withholding of information (‘censorship’) directed instead at publishers of closed-source, unauditable binary blobs, which constitute a fundamentally greater security risk than any auditable code repository ever could? How does it even make sense for Linux-libre to publish notifications about available binary blobs of any kind, including microcode? Why doesn’t Intel just release the source so this can be put to bed? There is an ideological battle here, and despite the way you frame it, it is between people who believe that users should be empowered to know what the software they run does, and people who don’t. Linux-libre sits in the camp of the former. I don’t know into which camp you fall, but your argument suggests the latter. I personally use the upstream Linux because it works easier for me and the hardware I have, but I have no bones about the fact that I am running non-free software, that that ideally I would have hardware which supported fully free software. Also, as I said, the Guix maintainers believe that their users are competent. Guix users know what they’re getting into when they run Guix, at least when they get to the point when they would drive it daily or run it on a system they see as critical. We know that microcode isn’t included when we use Linux-libre, because it is non-free - and that’s just the way it is. Saying that the Guix project is withholding information from us is incredibly patronising. It’s not a big conspiracy - the project, along with the rest of GNU, is openly in favour of maintaining repositories of fully and solely free software, to the exclusion of all non-free software. And it goes without saying, it is not the job of people in the GNU Project to educate people about the perks of running non-free software - there already exists a wealth of resources about how people can go about doing this, and it does not align with the clearly stated goals of the GNU Project.

marcan_42 5y ago
You're ignoring the crux if the issue. This isn't about running proprietary microcode or not. All x86 Guix users are running proprietary microcode. Period. This is a fact, whether they know about it or not. It's not optional. Would it be great if they didn't have to? Sure. But that's not the world we live in. This is about withholding information about an update to the proprietary microcode they are already running. There is absolutely no reason not to offer users this choice, given they're stuck running the ROM blob to begin with. The only reason the FSF and Linux-libre do this is because they want users to feel better by not knowing about the blob they're already running. There is no freedom gained, only the illusion of freedom. Users don't know what their ROM microcode does just as much as they don't know what the update does. The only thing we know is it fixes a bug. I believe a world where all software, firmware, and hardware is free would be ideal. I also know that is not the world we live in, and so I believe in empowering users with the information about what options they have, what the security/freedom/privacy/etc tradeoffs are, and letting them make their own choices. The FSF's push for restricting information so people believe they are not running any nonfree code is diametrically opposed to my views for this reason. I believe having the illusion of freedom is harmful to the cause for software freedom, as it obfuscates the reality of the current state of affairs. Every single die-hard FSF fanboy needs to learn about the 27 blobs running in little ROMs inside their computer, so they stop believing they live in a fake freedom utopia and come to terms with the reality we live in. Maybe then we'll have even more people pushing for firmware freedom. I'm not even saying Guix should ship the update. But actively censoring information about the existence of the update? That's just ridiculous. Your users are already running the blob. Stop trying to pretend they aren't and tell them it's broken already. How is it better when users are stuck running broken proprietary software when a fix is available because you refuse to inform them about it? That's completely irrational. Incidentally, this is a falsehood: > closed-source, unauditable binary blobs, which constitute a fundamentally greater security risk than any auditable code repository ever could This kind of absolutist view is another problem with this school of thought. Blobs can be in a position where, by the nature of their access or lack thereof to the rest of the system, they pose minimal security risk even if presumed completely evil. This is evidently a much lower risk than, say, low quality open source code in a position of extreme privilege with a large attack surface. Auditability doesn't mean things get audited or all bugs fixed. I have no problem trusting that a blob in a harmless I/O microcontroller poses little to no security risk to me over, say, certain open source cryptography/key storage implementations I've seen which raise a million red flags. Context matters, and the FSF's refusal to consider any context or nuance is also hurting users by not empowering them to make the decisions that are the best for them.
- kdtsh 5y ago
  Leaving aside the fact that binary blobs already existing in x86 processors doesn’t mean much for users because they can’t help that - I mean, GNU existed before Linux, and only became a completely free operating system when Linux was released, so it’s not like the position of the GNU project was to completely rule out the possibility of running any software or hardware if there was a sniff of non-free software within a 5km radius … No, you’re ignoring the crux of the issue, which is user freedom. Why are you so insistent that Guix wave the flag for Intel and allow its users’ freedoms to be even more flagrantly violated by shipping updated microcode? Why does the FSF not openly publishing certain kinds of information amount to censorship? - do you think that, if they were to remove certain blobs from the kernel but leave in these nebulous notifications that microcode updates are available, it wouldn’t be censorship? Talk about a bad user experience by the way - what you suggest is for the maintainers of Linux-libre to say ‘oh, by the way, there are critical updates to microcode running on your processor, but we’re not going to give them to you.’ That’s antisocial nonsense. Should they tell users about updates to all the other drivers in the kernel which they don’t ship either? Give me a break. I am currently, at this very moment, running updated Intel microcode on my Guix machine. Every Guix user who has used the distro for more then 5 minutes knows that a) you can track any channel you like containing packaged software, and b) there is a popular channel which contains some useful non-free software. They know this because it takes about 5 minutes to use a search engine for, say, ‘How do I get Nvidia drivers on my Guix System’, which will lead you to nonguix. What exactly is your problem? Do you think Guix users need to be babied? > Auditability doesn't mean things get audited or all bugs fixed. Correct! But it means that they can. Why won’t you respond to the fact that Guix users simply don’t feel hurt by this? You have taken it upon yourself to speak on behalf of a community which is perfectly happy with the existing arrangement - that the default kernel is built on Linux-libre, and they are free to use any other compatible kernel they like, including the upstream. If you don’t like Linux-libre, don’t use it. If you don’t like Guix, don’t use it. Your pearl-clutching about these projects’ violation of their users’ rights is unwarranted, unwanted, obtuse, and very annoying. If I didn’t know better, I’d think you had it out for FSF. I’ll leave that as my final word on this because this conversation is fruitless and pointless. You are moralising on the behalf of a community that you are not a member of and that doesn’t care for much of what you have to say for them.

by kdtsh 5y ago

marcan_42 5y ago

You're ignoring the crux if the issue. This isn't about running proprietary microcode or not. All x86 Guix users are running proprietary microcode. Period. This is a fact, whether they know about it or not. It's not optional. Would it be great if they didn't have to? Sure. But that's not the world we live in. This is about withholding information about an update to the proprietary microcode they are already running. There is absolutely no reason not to offer users this choice, given they're stuck running the ROM blob to begin with. The only reason the FSF and Linux-libre do this is because they want users to feel better by not knowing about the blob they're already running. There is no freedom gained, only the illusion of freedom. Users don't know what their ROM microcode does just as much as they don't know what the update does. The only thing we know is it fixes a bug. I believe a world where all software, firmware, and hardware is free would be ideal. I also know that is not the world we live in, and so I believe in empowering users with the information about what options they have, what the security/freedom/privacy/etc tradeoffs are, and letting them make their own choices. The FSF's push for restricting information so people believe they are not running any nonfree code is diametrically opposed to my views for this reason. I believe having the illusion of freedom is harmful to the cause for software freedom, as it obfuscates the reality of the current state of affairs. Every single die-hard FSF fanboy needs to learn about the 27 blobs running in little ROMs inside their computer, so they stop believing they live in a fake freedom utopia and come to terms with the reality we live in. Maybe then we'll have even more people pushing for firmware freedom. I'm not even saying Guix should ship the update. But actively censoring information about the existence of the update? That's just ridiculous. Your users are already running the blob. Stop trying to pretend they aren't and tell them it's broken already. How is it better when users are stuck running broken proprietary software when a fix is available because you refuse to inform them about it? That's completely irrational. Incidentally, this is a falsehood: > closed-source, unauditable binary blobs, which constitute a fundamentally greater security risk than any auditable code repository ever could This kind of absolutist view is another problem with this school of thought. Blobs can be in a position where, by the nature of their access or lack thereof to the rest of the system, they pose minimal security risk even if presumed completely evil. This is evidently a much lower risk than, say, low quality open source code in a position of extreme privilege with a large attack surface. Auditability doesn't mean things get audited or all bugs fixed. I have no problem trusting that a blob in a harmless I/O microcontroller poses little to no security risk to me over, say, certain open source cryptography/key storage implementations I've seen which raise a million red flags. Context matters, and the FSF's refusal to consider any context or nuance is also hurting users by not empowering them to make the decisions that are the best for them.

kdtsh 5y ago
Leaving aside the fact that binary blobs already existing in x86 processors doesn’t mean much for users because they can’t help that - I mean, GNU existed before Linux, and only became a completely free operating system when Linux was released, so it’s not like the position of the GNU project was to completely rule out the possibility of running any software or hardware if there was a sniff of non-free software within a 5km radius … No, you’re ignoring the crux of the issue, which is user freedom. Why are you so insistent that Guix wave the flag for Intel and allow its users’ freedoms to be even more flagrantly violated by shipping updated microcode? Why does the FSF not openly publishing certain kinds of information amount to censorship? - do you think that, if they were to remove certain blobs from the kernel but leave in these nebulous notifications that microcode updates are available, it wouldn’t be censorship? Talk about a bad user experience by the way - what you suggest is for the maintainers of Linux-libre to say ‘oh, by the way, there are critical updates to microcode running on your processor, but we’re not going to give them to you.’ That’s antisocial nonsense. Should they tell users about updates to all the other drivers in the kernel which they don’t ship either? Give me a break. I am currently, at this very moment, running updated Intel microcode on my Guix machine. Every Guix user who has used the distro for more then 5 minutes knows that a) you can track any channel you like containing packaged software, and b) there is a popular channel which contains some useful non-free software. They know this because it takes about 5 minutes to use a search engine for, say, ‘How do I get Nvidia drivers on my Guix System’, which will lead you to nonguix. What exactly is your problem? Do you think Guix users need to be babied? > Auditability doesn't mean things get audited or all bugs fixed. Correct! But it means that they can. Why won’t you respond to the fact that Guix users simply don’t feel hurt by this? You have taken it upon yourself to speak on behalf of a community which is perfectly happy with the existing arrangement - that the default kernel is built on Linux-libre, and they are free to use any other compatible kernel they like, including the upstream. If you don’t like Linux-libre, don’t use it. If you don’t like Guix, don’t use it. Your pearl-clutching about these projects’ violation of their users’ rights is unwarranted, unwanted, obtuse, and very annoying. If I didn’t know better, I’d think you had it out for FSF. I’ll leave that as my final word on this because this conversation is fruitless and pointless. You are moralising on the behalf of a community that you are not a member of and that doesn’t care for much of what you have to say for them.