20 ms·

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

> 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, because microcode in ROM is fine but dynamically loaded microcode updates are not, in this school of thought. https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002.html https://lists.gnu.org/archive/html/info-gnu/2018-04/msg00002... I have no interest in software that uses arbitrary religious dogma (that doesn't help users' freedom, as those users' CPUs have proprietary microcode whether they know about it or not) to justify censoring critical security vulnerability notifications for users. I regard this as actively evil anti-user behavior.

kzhukov 5y ago
Well, for some people loading an arbitrary binary code without possibility to check what's inside it is a critical security issue as well.
- medo-bear 5y ago
  exactly. and people promoting closed source security updates should print this risk out in most clear fashion. if we want to hold GNU to account for security then we should definitely do so with closed source vendors too
- marcan_42 5y ago
  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.
  - Santosh83 5y ago
    There is a bit more nuance here though. There may be users who trust their old systems but no longer trust the current state of its manufacturer or their binary only updates. Proprietary blobs go against the core freedom as defined by FSF so I can understand why they block by default but IMO they should allow informed users to override. Simply censoring without allowing a user to bypass is not user (or freedom) respecting. The power to choose should be with the user, whom the FSF claims to represent.
  - ajvs 5y ago
    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.
    - georgyo 5y ago
      This is a double edge sword. If there are issues with what are initially released and you do not patch you do not get those fixes. So they could add stuff but they definitely will fix stuff. Not updating could be more dangerous then updating.
    - marcan_42 5y ago
      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.
      - marcodiego 5y ago
        So why don't CPU vendor open source their microcode? Secrets... ok, let's use the ones which have no secrets.
        marcan_42 5y ago
        Good luck with that...
  - javert 5y ago
    Intel hardware definitely cannot be trusted. Probably "good enough" for most people, but it's honestly garbage, security wise.
    - marcan_42 5y ago
      And yet that terrible security situation has approximately nothing to do with the FSF's "no visible blobs" rule. ME could be just as bad running off of ROM, and then it'd meet the FSF's "Respects your Freedom" requirements.
- raverbashing 5y ago
  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.
  - y4mi 5y ago
    I doubt that. While the attack was possible on large hosting providers, utilizing the same on workstations or hardmetal and actually get important data was basically impossible. It had to be fixed, but your thesis that anyone was actually owned by these security issues because they didn't want to apply the mitigation rounds to at most 0.0% with an infinite amount of zeros before a 1.
  - anthk 5y ago
    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.
    - kaba0 5y ago
      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.
      - anthk 5y ago
        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.
        beermonster 5y ago
        I use NoScript and I find very few sites that are really broken if I don't enable JS.
- kaba0 5y ago
  But that is simply not the logical decision.
- grumbel 5y ago
  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 shouldn't treat hardware as a magic black box we don't care about.
  - jrm4 5y ago
    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.
    - mastax 5y ago
      > 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.
      - jrm4 5y ago
        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.
    - mindslight 5y ago
      Firmware in RAM is loaded from distribution packages, which also goes through a trackable process. There is a continuum here with frequent firmware updates being extremely dodgy (why can't they get it right and release a stable version), and infrequent updates (eg CPU microcode) being similar to shipping one image in "ROM". Furthermore, I haven't seen any device that actually ships significant (ie non-bootloader) firmware in "ROM". It's usually in flash, meaning its contents are mutable but less legible to the Free system than if they were loaded every time by a Free driver.
arein3 5y ago
>FSF doctrine that "binary blobs are bad unless you can't see them" your statement is misleading why did you add "unless you can't see them" did FSF said binary blobs you can't see are not bad? Seems opposite from what FSF would do
- marcan_42 5y ago
  The FSF openly endorses devices with hundreds of kilobytes of nonfree blobs burned into ROM. They do this because they claim they can just "say it's equivalent to hardware". They only care about blobs when they're loaded from software, because at that point their existence becomes apparent, even though naturally a blob loaded into RAM gives the user more freedom (e.g. to inspect it or change it) than a blob loaded from ROM.
amelius 5y ago
Huh? I've never updated my CPU microcode in other distros, nor did I receive warnings about it. Do you have a better example?
- computer 5y ago
  Yes you have, it's done automatically.
  - medo-bear 5y ago
    serious question: why is something that is updated without you knowing about it ok?
    - detaro 5y ago
      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.
      - medo-bear 5y ago
        but i dont do that automatically, as the parent described. as far as i am aware i need to manually issue a comand to perform the update, which is ok as far as i have that control
        detaro 5y ago
        "automatically" as in "automatically when you update the rest of your distro", not an extra step as the poster above clearly seemed to expect. That context also was clearly from the other comments already.
        e12e 5y ago
        Distros prompt you when upgrading packages, not binaries. You get a prompt to update Firefox package, not for replacing the actual binary on disk. Typically packages including microcode behave the same way - prompt to update the package, no prompt to implement that update (replace individual files).
wiz21c 5y ago
> arbitrary religious dogma "arbitrary political view" there's a difference, it matters.
- wheelerof4te 5y ago
  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?
  - h2odragon 5y ago
    Consistent application of principles doesn't make a "cult". Its just so rare you may be unfamiliar with the difference. Make a fork of their code with your preferred changes. The world will be improved and people who agree with you will be happy.
  - mbakke 5y ago
    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-guidelines.html 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.
    - rollcat 5y ago
      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.
  - rlopezcc 5y ago
    > Political views have parties [citation needed] Political views MAY have parties. I agree to some extent with the cult argument though.
jrm4 5y ago
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, the law-slash-tech has always come before "ensuring that it's public-understood and ready" as it should.
- dralley 5y ago
  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.
  - jrm4 5y ago
    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.
    - ckastner 5y ago
      The OP referenced CPUs and for at least AMD and Intel CPUs, firmware blobs need to be signed.
      - KingMachiavelli 5y ago
        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 protest against needing these binary blobs. The hope is certainly that adoption of Linux-libre would result in AMD/Intel not having these non-free software requirements.
marcodiego 5y ago
> "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.
- seoaeu 5y ago
  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.
- WastingMyTime89 5y ago
  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.
  - marcodiego 5y ago
    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 might contain code making me vulnerable to a state actor but that’s not a threat profile I care about. State actors are not the only threat. Think about arbitrarily disabled features, DRM, programmed obsolescence or simply not allowing anybody to improve/fix it after the device is abandoned by the manufacturer.
stjohnswarts 5y ago
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
mindslight 5y ago
It's not productive to call it "arbitrary religious dogma". The FSF chose a criteria for what binary blobs are acceptable. Your and my opinions are that they set this criteria wrong, but if we hope to change their policy, then we have to discuss it rationally. I personally think the correct criteria is that of security boundaries and change control. If I've got a graphics card with proprietary code (regardless of whether its in ROM or loaded into RAM), with a proper IOMMU, the attacks it can perform on me are limited (eg TEMPEST). The video card itself is not Free or secure, but it's unfortunately something I have to use to interface with my Free/secure computer, just like my keyboard with its proprietary firmware. And as long as I can load any version of firmware onto that video card, then I retain administrative control where the manufacturer can't revoke functionality after I've purchased it. Disk drives with proprietary software (which is all of them) are not an attack vector, because a drive should only ever be seeing encrypted data to begin with (eg LUKS). A network card is a bit more worrisome with its direct network access (ie backhaul), but a Free/secure design shouldn't be trusting the network either (unless you have Free/secure switches), so this does not meaningfully change your security properties. Obviously the above assumes Free/secure drivers, because drivers are running inside the security boundary of the OS. CPU masks and microcode run afoul of my strict criteria, but are practically inescapable. Proprietary masks/microcode are required for every amd64 system (correct me if I am wrong), so it makes sense to say you have a Free/secure amd64 modulo those proprietary bits (as say Libreboot already does). And with so few versions of CPU microcode, the question of whether to trust a given microcode update is equivalent to whether to trust a given newly released CPU, and shouldn't be viewed as a software Freedom issue.
- marcan_42 5y ago
  The problem is that they have long given up on rationality; they and their devoted followers are an echo chamber of "blobs bad", "my software freedom", etc. They've stopped listening to rational discussion :(
civodul 5y ago
Guix is dedicated to ensuring user freedom. It doesn't provide non-free software so that users can make informed choices: they might choose to use third-party channels that provide non-free packages, or install non-free software via flatpak or some other tool, but they can trust Guix itself will never provide non-free software. Part of allowing for informed choices is about raising awareness, for instance by explaining why some WiFi devices won't work out of the box (which is really the only practical issue one might stumble upon): https://guix.gnu.org/manual/en/html_node/Hardware-Considerations.html https://guix.gnu.org/manual/en/html_node/Hardware-Considerat...
nine_k 5y ago
Guix the package manager can work on top of a different Linux installation, and can even manage other things than distro packages. This is one of the things I'm planning to do. BTW same thing is with Nix: you may not like the choices of NixOS but still enjoy most of the advantages Nix has to offer.
kdtsh 5y ago
This is an enormous thread now - in case it hasn’t already been mentioned, Guix neither helps nor hinders users from using any kernel they like. There is a repository called nonguix, made available by community members, which includes the upstream, non-free kernel, as well as microcode updates for Intel processors. The Guix project states clearly that it does not support these uses of the software, but that users are free to use it - because the software is released under the GPL. So what exactly is the problem? The Guix maintainers consider their users to be competent and able to make decisions for themselves - the charge of ‘evil anti-user behaviour’ isn’t so inappropriate as it is laughable and immature. Also, as other commenters have mentioned, I have never had a warning that I need to install new microcode from any distribution. As a matter of fact, it would not surprise me if other distributions were not to give me a choice in installing new microcode - if I’m running underpowered hardware (not uncommon for hobby Linux users, especially if the hardware is known to be well supported), and I don’t have much to lose on that hardware, having mitigations against things like Spectre/Meltdown is a calculated decision given the performance impact, so why shouldn’t I at least be able to choose? With Guix, this is a one-liner in your configuration.scm file.
- marcan_42 5y ago
  The problem is the endorsement of linux-libre, which goes beyond deblobbing into actively censoring messages. I'm sure Guix allows users to choose (it has to, thanks to Freedom 0, as you say), but by choosing a kernel by default that chooses to withhold information from its users, it is encouraging decreasing user knowledge. That is something that people should be aware of, and honestly, something that should be considered a bug to fix. We can't allow the proliferation of schools of thought that promote not educating users about their options, justified by ideology. For what it's worth, disabling microcode updates in other distros is just uninstalling a package (or not installing it in the first place; my distro of choice, Gentoo, does not install it by default).
  - 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.

kzhukov 5y ago

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

medo-bear 5y ago
exactly. and people promoting closed source security updates should print this risk out in most clear fashion. if we want to hold GNU to account for security then we should definitely do so with closed source vendors too
marcan_42 5y ago
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.
- Santosh83 5y ago
  There is a bit more nuance here though. There may be users who trust their old systems but no longer trust the current state of its manufacturer or their binary only updates. Proprietary blobs go against the core freedom as defined by FSF so I can understand why they block by default but IMO they should allow informed users to override. Simply censoring without allowing a user to bypass is not user (or freedom) respecting. The power to choose should be with the user, whom the FSF claims to represent.
- ajvs 5y ago
  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.
  - georgyo 5y ago
    This is a double edge sword. If there are issues with what are initially released and you do not patch you do not get those fixes. So they could add stuff but they definitely will fix stuff. Not updating could be more dangerous then updating.
  - marcan_42 5y ago
    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.
    - marcodiego 5y ago
      So why don't CPU vendor open source their microcode? Secrets... ok, let's use the ones which have no secrets.
      - marcan_42 5y ago
        Good luck with that...
- javert 5y ago
  Intel hardware definitely cannot be trusted. Probably "good enough" for most people, but it's honestly garbage, security wise.
  - marcan_42 5y ago
    And yet that terrible security situation has approximately nothing to do with the FSF's "no visible blobs" rule. ME could be just as bad running off of ROM, and then it'd meet the FSF's "Respects your Freedom" requirements.
raverbashing 5y ago
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.
- y4mi 5y ago
  I doubt that. While the attack was possible on large hosting providers, utilizing the same on workstations or hardmetal and actually get important data was basically impossible. It had to be fixed, but your thesis that anyone was actually owned by these security issues because they didn't want to apply the mitigation rounds to at most 0.0% with an infinite amount of zeros before a 1.
- anthk 5y ago
  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.
  - kaba0 5y ago
    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.
    - anthk 5y ago
      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.
      - beermonster 5y ago
        I use NoScript and I find very few sites that are really broken if I don't enable JS.
kaba0 5y ago
But that is simply not the logical decision.
grumbel 5y ago
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 shouldn't treat hardware as a magic black box we don't care about.
- jrm4 5y ago
  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.
  - mastax 5y ago
    > 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.
    - jrm4 5y ago
      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.
  - mindslight 5y ago
    Firmware in RAM is loaded from distribution packages, which also goes through a trackable process. There is a continuum here with frequent firmware updates being extremely dodgy (why can't they get it right and release a stable version), and infrequent updates (eg CPU microcode) being similar to shipping one image in "ROM". Furthermore, I haven't seen any device that actually ships significant (ie non-bootloader) firmware in "ROM". It's usually in flash, meaning its contents are mutable but less legible to the Free system than if they were loaded every time by a Free driver.

arein3 5y ago

>FSF doctrine that "binary blobs are bad unless you can't see them" your statement is misleading why did you add "unless you can't see them" did FSF said binary blobs you can't see are not bad? Seems opposite from what FSF would do

marcan_42 5y ago
The FSF openly endorses devices with hundreds of kilobytes of nonfree blobs burned into ROM. They do this because they claim they can just "say it's equivalent to hardware". They only care about blobs when they're loaded from software, because at that point their existence becomes apparent, even though naturally a blob loaded into RAM gives the user more freedom (e.g. to inspect it or change it) than a blob loaded from ROM.

amelius 5y ago

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

computer 5y ago
Yes you have, it's done automatically.
- medo-bear 5y ago
  serious question: why is something that is updated without you knowing about it ok?
  - detaro 5y ago
    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.
    - medo-bear 5y ago
      but i dont do that automatically, as the parent described. as far as i am aware i need to manually issue a comand to perform the update, which is ok as far as i have that control
      - detaro 5y ago
        "automatically" as in "automatically when you update the rest of your distro", not an extra step as the poster above clearly seemed to expect. That context also was clearly from the other comments already.
      - e12e 5y ago
        Distros prompt you when upgrading packages, not binaries. You get a prompt to update Firefox package, not for replacing the actual binary on disk. Typically packages including microcode behave the same way - prompt to update the package, no prompt to implement that update (replace individual files).

wiz21c 5y ago

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

wheelerof4te 5y ago
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?
- h2odragon 5y ago
  Consistent application of principles doesn't make a "cult". Its just so rare you may be unfamiliar with the difference. Make a fork of their code with your preferred changes. The world will be improved and people who agree with you will be happy.
- mbakke 5y ago
  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-guidelines.html 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.
  - rollcat 5y ago
    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.
- rlopezcc 5y ago
  > Political views have parties [citation needed] Political views MAY have parties. I agree to some extent with the cult argument though.

jrm4 5y ago

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, the law-slash-tech has always come before "ensuring that it's public-understood and ready" as it should.

dralley 5y ago
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.
- jrm4 5y ago
  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.
  - ckastner 5y ago
    The OP referenced CPUs and for at least AMD and Intel CPUs, firmware blobs need to be signed.
    - KingMachiavelli 5y ago
      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 protest against needing these binary blobs. The hope is certainly that adoption of Linux-libre would result in AMD/Intel not having these non-free software requirements.

marcodiego 5y ago

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

seoaeu 5y ago
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.
WastingMyTime89 5y ago
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.
- marcodiego 5y ago
  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 might contain code making me vulnerable to a state actor but that’s not a threat profile I care about. State actors are not the only threat. Think about arbitrarily disabled features, DRM, programmed obsolescence or simply not allowing anybody to improve/fix it after the device is abandoned by the manufacturer.

stjohnswarts 5y ago

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

mindslight 5y ago

It's not productive to call it "arbitrary religious dogma". The FSF chose a criteria for what binary blobs are acceptable. Your and my opinions are that they set this criteria wrong, but if we hope to change their policy, then we have to discuss it rationally. I personally think the correct criteria is that of security boundaries and change control. If I've got a graphics card with proprietary code (regardless of whether its in ROM or loaded into RAM), with a proper IOMMU, the attacks it can perform on me are limited (eg TEMPEST). The video card itself is not Free or secure, but it's unfortunately something I have to use to interface with my Free/secure computer, just like my keyboard with its proprietary firmware. And as long as I can load any version of firmware onto that video card, then I retain administrative control where the manufacturer can't revoke functionality after I've purchased it. Disk drives with proprietary software (which is all of them) are not an attack vector, because a drive should only ever be seeing encrypted data to begin with (eg LUKS). A network card is a bit more worrisome with its direct network access (ie backhaul), but a Free/secure design shouldn't be trusting the network either (unless you have Free/secure switches), so this does not meaningfully change your security properties. Obviously the above assumes Free/secure drivers, because drivers are running inside the security boundary of the OS. CPU masks and microcode run afoul of my strict criteria, but are practically inescapable. Proprietary masks/microcode are required for every amd64 system (correct me if I am wrong), so it makes sense to say you have a Free/secure amd64 modulo those proprietary bits (as say Libreboot already does). And with so few versions of CPU microcode, the question of whether to trust a given microcode update is equivalent to whether to trust a given newly released CPU, and shouldn't be viewed as a software Freedom issue.

marcan_42 5y ago
The problem is that they have long given up on rationality; they and their devoted followers are an echo chamber of "blobs bad", "my software freedom", etc. They've stopped listening to rational discussion :(

civodul 5y ago

Guix is dedicated to ensuring user freedom. It doesn't provide non-free software so that users can make informed choices: they might choose to use third-party channels that provide non-free packages, or install non-free software via flatpak or some other tool, but they can trust Guix itself will never provide non-free software. Part of allowing for informed choices is about raising awareness, for instance by explaining why some WiFi devices won't work out of the box (which is really the only practical issue one might stumble upon): https://guix.gnu.org/manual/en/html_node/Hardware-Considerations.html https://guix.gnu.org/manual/en/html_node/Hardware-Considerat...

nine_k 5y ago

Guix the package manager can work on top of a different Linux installation, and can even manage other things than distro packages. This is one of the things I'm planning to do. BTW same thing is with Nix: you may not like the choices of NixOS but still enjoy most of the advantages Nix has to offer.

kdtsh 5y ago

This is an enormous thread now - in case it hasn’t already been mentioned, Guix neither helps nor hinders users from using any kernel they like. There is a repository called nonguix, made available by community members, which includes the upstream, non-free kernel, as well as microcode updates for Intel processors. The Guix project states clearly that it does not support these uses of the software, but that users are free to use it - because the software is released under the GPL. So what exactly is the problem? The Guix maintainers consider their users to be competent and able to make decisions for themselves - the charge of ‘evil anti-user behaviour’ isn’t so inappropriate as it is laughable and immature. Also, as other commenters have mentioned, I have never had a warning that I need to install new microcode from any distribution. As a matter of fact, it would not surprise me if other distributions were not to give me a choice in installing new microcode - if I’m running underpowered hardware (not uncommon for hobby Linux users, especially if the hardware is known to be well supported), and I don’t have much to lose on that hardware, having mitigations against things like Spectre/Meltdown is a calculated decision given the performance impact, so why shouldn’t I at least be able to choose? With Guix, this is a one-liner in your configuration.scm file.

marcan_42 5y ago
The problem is the endorsement of linux-libre, which goes beyond deblobbing into actively censoring messages. I'm sure Guix allows users to choose (it has to, thanks to Freedom 0, as you say), but by choosing a kernel by default that chooses to withhold information from its users, it is encouraging decreasing user knowledge. That is something that people should be aware of, and honestly, something that should be considered a bug to fix. We can't allow the proliferation of schools of thought that promote not educating users about their options, justified by ideology. For what it's worth, disabling microcode updates in other distros is just uninstalling a package (or not installing it in the first place; my distro of choice, Gentoo, does not install it by default).
- 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.