I Love Arch, but GNU Guix Is My New Distro
boilingsteam.com
boilingsteam.com
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...
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.
Do you have a better example?
Typically packages including microcode behave the same way - prompt to update the package, no prompt to implement that update (replace individual files).
Also, these packages allow vendors to keep quiet about security issues, because they can silently fix them in the next update.
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...
It's all a big lie. There's proprietary firmware everywhere. The FSF just doesn't want users to know about it, so they can live happily in their blissful ignorance believing they are freer than everyone else.
Here's the Debian package for the Intel microcode, for example:
https://packages.debian.org/bullseye/intel-microcode
Debian hides it away in their "non-free" repo but it's in the default install in many other distros.
dmesg | grep "microcode updated early to"
Stallman personally refused to certify bunnie's Novena laptop (a fully open hardware and software laptop) as "Respects your Freedom" because there were no free drivers for the GPU, and although it wasn't going to ship with GPU acceleration (that's optional anyway), Stallman said users might be "tempted" to install the proprietary blob. Instead he suggested it might be possible to get the manufacturer to cripple the GPU (permanently fuse it off of existing chips that already have it), and then that could be RYF-certified.
bunnie gave up on that, but had he actually shipped a crippled FSF-approved version... a few years later, open drivers for that GPU were developed, so that would've made the regular version certifiable, and everyone who bought the "respects your freedom" version would've been left with needlessly crippled hardware. But the FSF insists this is the way to go.
Meanwhile, they're endorsing "Respects Your Freedom" Bluetooth dongles that have about half a megabyte of proprietary firmware in ROM.
So ... FSF made the right call? What is the point of the certification of a device if there are no drivers for it.
It would be a kinda good idea to have a "rms would almost use this" sticker they could hand out, though.
Looking at: https://ryf.fsf.org/categories/laptops
There is a sorry collection of refurbished laptops.
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...
> 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)
http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...
Grep for "Do no recommend non-Free microcode update" [sic].
The actual censoring patterns are here:
http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...
Grep for "arch/x86/kernel/apic/apic.c" to find some of them.
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.
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.
I agree, if that's the position of Guix, I don't want it in my machine.
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.
LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run.
Can you buy anything at all on the internet?
If attackers who cannot add a comment to their exploit are in your threat model.
Personally, I've been using a browser extension that blocks JS unless it has a comment reading
> This code is NOT evil or malicious!
at the top. Haven't been hacked yet!
https://9to5mac.com/2021/03/11/browser-based-attack-affects-...
Turns out you don't need Turing completeness to perform microarchitectural side channel attacks. This is yet another way in which the "all my software is free, therefore I am safe from attacks" fallacy breaks down.
Nevermind that, as pointed out by other replies, LibreJS provides zero security. It relies on scripts voluntarily declaring that they're freely licensed, and if they do, they're allowed to run. The extension doesn't care whether the script is malicious or not.
I am still safe.
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.
> where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode
Is not ok
https://news.ycombinator.com/item?id=29290087
...at least, I don't see any such code in the actual deblobbing script: https://linux-libre.fsfla.org/pub/linux-libre/releases/5.15....
edit: since you called linux-libre a "fork", I feel compelled to point out that Linux-Libre is just the vanilla Linux kernel with that script applied. No more, no less.
# Do no recommend non-Free microcode update.
announce X86_LOCAL_APIC - Undocumented
clean_blob arch/x86/kernel/apic/apic.c
clean_kconfig arch/x86/Kconfig X86_LOCAL_APIC
clean_mk CONFIG_X86_LOCAL_APIC arch/x86/kernel/apic/MakefileSure 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.
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.
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.
Free software isn't about each of us individually fixing the problems. Nearly exactly the opposite.
"arbitrary political view"
there's a difference, it matters.
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?
Make a fork of their code with your preferred changes. The world will be improved and people who agree with you will be happy.
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.
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.
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.
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.
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.
to the said point, this is definitely a VALID security concern. FSF needs to make these concerns clear. you seem to be very invested in this matter. have you raised these concerns with them?
EDIT: having thought about it some more. doesnt isolating blobs to ROMs restrict the problems to ROMs? i mean non-RYF certified hardware already has this problem. the strategy might them be to focus efforts on opening up ROMs. note that this is simply a question. i am not an expert in this field but i am trying to form an informed opinion
It gets ignored.
I believe it is for the same reason religions ignore issues.
The FSF totally acts as a religion. The church of his Gnusance St. Ignutiutus. And just like religions it pretends to hold an ethical position while making compromises for practical reasons.
Compare religions claiming:
- Killing is bad, unless it's about opponents in war. - Slavery is bad, unless it's outsiders who are slaves. - Blobs are bad, unless they are stored on chip flash.
The FSF gets criticized precisely for this hypocrisy. And just like religions ignore criticism about their inconsistencies so does the FSF.
so is FSF dogmatic or is it practical? surely they cant be both
A really simple example is GPL violations. Pure dogma would require that they try to fight a whole lot of them, since they occur all the time and they're clearly in the legal right.
But they don't, and that's the MUCH SMARTER way to go.
Why this Guix thing strikes me as smart is that it's about "reinforcing modularity." They can't free up EVERYTHING, but they can make the software work different so that it's harder to pretend that everything is all the same.
to clarify my previous post, i was using the term dogmatic in the context of some people claiming that FSF is a cult
What it can't conceive of is an organization with big picture goals that aren't "making a profit" that require strategy and even "real life experimentation." That's what's happening here; y'all are just confused because the FSF feels like "religion" because it's not going for profits, but somewhat acting like a for-profit, in that it's picking and choosing battles.
And literally everyone signs their firmware.
"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'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?"
To respect these principles the Guix project (and others) asks to not discuss non-free software, hardware support, or related matters on official channels. These questions and non-free packages are best left to any number of other venues. Guix does not actively hamper a user’s ability to load non-free software or firmware (see freedom 0), but will not support this in any official capacity. That said, the community is very nice and will not kick you from IRC if it comes up (more likely you’ll get some private messages directing you or helping you out), but better to remember their rules.
I think that says all.
"Hush, hush, and don't look under the rugs!"
This is diplomacy. This is exactly the correct way to act when you are diametrically opposed to something that is widely used, popular, and prevalent -- when you hate something; but understand that other people don't and you're going to have win them over.
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.
But indeed, it would be very good if someone from FSF could better explain it.
Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.
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.
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 a goddamn npm install and basically do anything you want, including streaming every single keypress?
There are also automated scans of a long list of FLOSS. Google runs OSS-Fuzz, you can check LibreOffice to see lots of commits to fix defects detected by OSS-Fuzz, coverity and other static analyzers. Access to the code, at the least allows determined users to more easily find where or why the bug happens. And yes, people do it.
> hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?
Yes, this is more serious. But would need a compromise on packagers side and an uninformed (or automated) update on my side. Considering an update with such a vulnerability would affect initially a small fraction of users before being discovered, it is very unlikely that this hypothetical would have a big impact.
Also, your automatic checker examples are related to the project’s size and importance, not to FOSS alone. It is very welcome but your average one-person C project that is installed on everyone’s system doesn’t benefit from such tools.
This is debatable: https://en.wikipedia.org/wiki/Comparison_of_open-source_and_.... Any links to your argument?
The fact remains, every type of software is ripe for bugs and security measures must be taken so those bugs won’t become exploitable.
Yeah ok now we are in the religion side of things, since you cannot check the silicon...well i stop here, not worth my time.
BTW: The power microcode is opensource.
READ.
The microcode is opensource..
Open source microcode does not change the fact that you need to trust the CPU manufacturer not to backdoor your CPU. There is literally no way around that that does not involve using FPGAs and restricting yourself to 100MHz CPUs.
By the way, I googled POWER9 microcode and was not able to find any source or reference to it. The source code for the firmware running on various auxiliary cores is open source. However, the CPU cores do contain microcode for executing more complex instructions, and I am not finding any reference to this being open source.
>>>since you cannot check the silicon...
And since you have problems using google too:
https://www.sbir.gov/node/1620879
>>A small business has already shown that a completely open source solution (to include CPU firmware, CPU Microcode, Baseboard Management Controller (BMC), BIOS boot code, power management, etc.) based on a high performance CPU is possible.
Imagine who that "small business" is?
FYI, IBM loves to use the term "microcode" to include side CPU firmware and such. This is different from Intel "microcode" which strictly refers to the instruction dispatch part. Is the instruction dispatch microcode in POWER9 open source or not?
None of these are it: https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware
Maybe it's time for you to have the realization that POWER9 has proprietary microcode just like Intel. At least it seems they probably have less of it, and they do vaguely document it in the CPU manual (they have micro-op classes and counts) but it's there, and I don't see any real source code anywhere. They also have patch registers, so you can't even say it's not updatable. The POWER9 manual mentions six Instruction Mask Registers per core, but these registers are documented nowhere (I just spent a good 30 minutes digging through the giant register documentation PDFs and HCODE source, but I couldn't find anything).
Is this better than Intel? Yes. Is it "fully free"? No. Nothing's fully free. Which is why we need nuanced analysis, not the nonsense arbitrary lines the FSF draws in the sand.
https://www.crowdsupply.com/sutajio-kosagi/precursor
Of course, then you get a RISC-V running at 100MHz. If you want something faster, you need to trust your CPU provider. There's no way around that; silicon is not end-user introspectable.
if i dont have options for alternatives, i think its completely rational to use something without trusting it. i would say that this should be a default attitude
However the distinction between blob on chip flash and blob on system storage is nonsensical to me. I would much rather have a sandboxed untrusted part I can update rather than a sandboxed untrusted part that I can not update.
Unfortunately I have not seen anyone actually give a reason why the line should be drawn there instead of closed source blobs are not ok period. Doesn't matter where they live. None of us are arguing in favour of blobs.
this makes it sound like FSF supports these blobs. how i understood the situation is that they tolerate them until an alternative presents itself. this is a valid position to take and does not make them hypocrites/cult/religion etc
actually since you work with macs, do you think Apple respects your freedom or do you think they are more ethical than FSF?
Whether Apple is ethical or not is a different question. There is plenty of criticism to be fired at them for various issues. That's a personal call for people to make. I'm not saying you should go buy Apple hardware. I'm saying it's significantly more trustworthy from a security and privacy standpoint than x86 machines. Do they respect my software freedom? About as much as the RYF machines. They both let me run my own OS and they both rely on proprietary firmware for various things. The FSF's certification criteria do nothing for my software freedom (which has nothing to do with whether blobs are in ROM or RAM), they just hurt security, which is something else I care about.
We all have to make our own decisions about what to purchase based on the information available to us. That is why having such information is so important. If you value repairability more than anything, you should probably get a Framework. If you value security above all, you should get a Precursor device. If you want a trustable machine that's still high performance, you should get a Mac. If you want to run Windows games, you should get a gaming PC. If you value your freedom... there isn't anything truly free out there. RYF machines certainly aren't it, nor more free than many others by practical measures, nor transparent about their design.
Hence why I criticize the program. It's not achieving anything positive. It's just a feel good thing; the FSF says it respects my freedom so I can feel good about being Free™ while running more proprietary firmware than many other off the shelf machines.
Just to put things into perspective, I believe Google have done more for computing device freedom than the FSF, because the Chromebook team is notoriously pretty much the only large team which actually pushes for open source everything pretty hard, and they're important enough that some vendors listen, and they have the money to develop things themselves. For example, if you look for an open boot/OS stack for the Tegra X1, the closest you're going to get is the Chromebook Pixel's. Only the RAM training blob is closed source (and there is a reverse engineered replacement these days). Everything from the low level bootloader to the GPU drivers are open. This is no thanks to Nvidia - for pretty much all other customers they offer proprietary bootloaders. Also, I'm pretty sure some Chromebooks even have open source EC firmware, which those ThinkPads the FSF loves so much don't.
But they also never claimed to be ethical. They never claimed to guard a moral ideal. They have claimed many things (protect privacy of users, guarantee security of users) which they did not act upon, and they have received flack for that. But they didn't claim to be ethical. Not even in a aspirational way like Googles "Don't be evil" moto.
The FSF, however, claims that ethics is it's prime driver. And by endorsing hardware with proprietary blobs (placed on chip flash instead of system storage) they display hypocrisy. They choose the very pragmatism they criticise others for choosing.
And that is something religions do aswell.
I have asked you why is the line there and you have not answered.
Look, don't take my word for it - take the word (and more importantly, the reasoning) of the guys behind the Novena open laptop: https://www.bunniestudios.com/blog/?p=5706
also i am confused why this issue isnt being taken with the hardware manufacturers? if i purchased their product, and if their user license did not forbid me from using linux-libre, and if this update is absolutely vital for my safety, then it makes much more sense to take issue with the manufactures. they should open source the update in this case
You're not sacrificing security, you're making a tradeoff.
If I update my CPU microcode to something I can't check myself, I'm explicitly choosing to trust my CPU provider, under the assumption that the risk of a microcode-based attack from my CPU provider is smaller than the risk of a cpu bug-based attack by an unknown attacker.
If you don't trust your CPU provider then you have zero security from them already. Even if the entire design of the CPU is open-source. https://www.bunniestudios.com/blog/?p=5706
You are already running CPU microcode that can't be checked when you are running Guix on x86. That ship sailed when you decided to use x86.
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.
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.
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
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-Considerat...
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.
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.
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).
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.
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.
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.
>If I didn’t know better, I’d think you had it out for FSF
given the ammount of bad faith in the threads i think it definitely looks like a campaign
who believes this? why are you constantly being insulting? a lot of linux fanboys think that if you run linux you can't get hacked. does that make linux dishonnest? of course not! there are misinformed people everywhere. having been in this exchange for about two daya i learned that FSF does a very good job to inform users about what using their products entails
No mention of the half megabyte of proprietary Bluetooth stack firmware (with significant security and privacy implications) that's in that dongle which supposedly "Respects Your Freedom".
https://ryf.fsf.org/products/VikingsX200
No mention of:
* Proprietary CPU microcode ROM (full access to CPU/memory, security critical)
* Proprietary embedded controller firmware (H8S, connected LPC bus, full access to all memory, security critical, might be able to cause physical destruction / a fire with the right GPIO abuse)
* Proprietary TPM firmware (connected to LPC bus, full access to all memory, security critical)
* Proprietary USB camera firmware (connected to USB port, very large attack surface for OSes)
* Proprietary Bluetooth module firmware (connected to USB port, etc.)
* Proprietary USB card reader module firmware (connected to USB port, etc.)
* Proprietary SATA HDD firmware (can access/modify all user data, security critical if you don't use FDE + integrity)
And those are just the ones I could quickly pick out from the schematic; pretty sure there's at least a couple more major ones and even more minor ones. All the other laptops they endorse are in a similar situation.
How, exactly, are the FSF informing users about the devices they endorse?
BEGIN
> there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software.
>We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification.
END
this explains their decisions in terms of their software freedom ideals, and its perfectly clear. i keep trying to explain to you that FSF is not about doing their best in terms of security. FSF is about doing what they believe is best for software freedom. althought it would be nice, i just dont see why they MUST inform their users about security entailments
of course, it is perfectly fine to point out security flaws in such an approach, but FSF is not selling security, and since the original topic is GNU Guix distro, GNU Guix does not market itself as a security-centric distro. why is this so hard for you to accept
alot of your argument rests on failure of their logic and bluring of a clear distinction between hardware and software. fine, it is a VALID point, but it is a corner case. FSF has taken an approach they believe deals best with such corner cases and explained their reasoning. they might be right in their approach, they might be wrong. you cannot satisfy everyone and not accepting that is just simply infantile
FSF is a pretty large organisation. for large organisations some form of bureocracy becomes necesary to achieve normal functioning. however, bureocracy will always entail some ilogical elements, esspecially in corner cases. that is just life, i believe
It is quite self-evident that not being open about the existence of proprietary code is not the best for software freedom.
I know about their certification process; my entire argument is that their criteria are terrible and the lack of transparency about specific devices and what firmware they contain deceptive. You bringing up their criteria repeatedly isn't helping you counter that point. This silly loop of "The criteria suck. / These are the criteria." doesn't get us anywhere.
If the FSF believe in software freedom, why are they not informing their users about the nonfree software that exists in the devices they sell as "Respects your Freedom"? I'm not saying "why are they certified here"; fine, they have their rules. Why are they not documenting how these devices interact with those rules? Why are they obscuring all of this? What do they have to gain by keeping people in the dark?
To me it is just very clear that they're doing this because they are trying to build a narrative that is different from reality, and the only way that narrative works is if people don't discover the problems with it. Your opinion may differ, but everything I've seen about the FSF's behavior in recent years points towards that. If they wanted to be honest there would be no reason not to document those firmware blobs.
i think that how you framed your concern in this last point is valid from a security point of view. as someone who values knowing security implications i support the argument that they should improve their work on security matters. in saying that, to me FSF is certainly no worse (i would think alot better) than closed source vendors, including ms, apple, intel, nvidia etc as far as making their users aware of security problems is concerned. i actually think that every device should come with a cigarete packet style label that says "might include backdoor inside", not just FSF products. in fact, maybe if only FSF did this, it might create an impression that only their products have this issue
So yes, the FSF is actually worse than closed source vendors because they are promoting ancient laptops with poor isolation and no security mitigations, while Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device. And you can put Linux on those Macs and run a fully open source kernel and userspace - not very different from those laptops in the end. Think about that.
Of course, I am very happy to talk at length about the design of these machines with everyone, and I want all the users of my software to be aware of these things (yes, there are a ton of blobs here - the amount of damage they can do is less than the blobs in the RYF laptops, but they still exist), as well as the things we don't know (e.g. some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable, but we'd like to find out and if it is, that would be a firmware bug to report to Apple). I believe that in order to make an informed decision, users need to have all the information.
but they are promoting such devices on ethical concerns, not on security concerns. they are not deceiving anyone
>Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device
you mentioned FSF fanboys before. there are way more Apple fanboys who are convinced that their Apple products respect their privacy and that their devices are impenetrable. what is worse, Apple markets itself based on this grotesque misperception!
if security and privacy is a vital concern for people, Apple devices are NOT products that should handle their security concerns! you promoting Apple as secure makes you guilty of the very thing you accuse FSF of actually
i would absolutely love it if there is a public non-profit organisation like FSF that is security/privacy focused - eg Secure Software Foundation - that would employ security experts to analyse and audit security and privacy of all software, free and non-free, and of course always open their findings immediately. moreover, i would definitely hope that such an organisation would be as autistic and unwavering toward open security and privacy as FSF is toward software freedom :)
the fact of the matter is, while you can support both free and secure software seperately, they are seperate matters. it is possible to come to a conflict of interest type scenario. secure-software and free-software, although often sharing the same concerns, are simply not the same thing
You're mixing up software and hardware. I have no strong opinion on the security of Apple's (macOS) software from a user perspective. It's a proprietary OS. It gets some things right and some things wrong. There have been privacy concerns (e.g. the CSAM mess). I use it for browsing the web sometimes, but I wouldn't make it my main OS.
But Apple deeply cares about platform security, and notoriously, iOS devices are some of the most secure consumer devices available. This isn't marketing bullshit - their designs are actually that good, which is something I can say as a security professional. You may or may not agree with their motivation, which ostensibly includes both customer security and keeping an iron grip on their iOS devices. But the end result is they have built excellent silicon designs with advanced security features and a very security-conscious architecture throughout. The same stuff that makes it hard to jailbreak iPhones. And so now that they stuck them in Macs and unlocked the bootloader, would I buy one? Of course. And put Linux on it. And so should you*, if you care about security. There really isn't anything else done nearly as well as these things, at least not at a performance level we'd consider decent in 2021.
Yes, it might surprise you coming from Apple, but it makes sense because they did this for their own benefit. It just so happens that their motives end up with a result that aligns with what I want. And so I'll take it, thanks.
I still won't use an iPhone, though.
* Okay, maybe wait until we're done porting things and it runs well.
i think FSF fights against non-free software because it considers it an evil for a society. i have no problems them fighting this fight, and i dont see any other candidates able to fight that fight on their level. i think that people who care about free software should at least respect them
on the other hand, i think security and privacy is a seperate fight, extremely important. if you form an organisation that defends security and privacy as much as FSF defends free software, i will definitely support it and you
No, no no. This is wrong. You don't need a nested hypervisor to make an undetectable backdoor. If you you audit all network traffic from a separate device, most backdoors are detectable, because a backdoor wants to have some effect that goes outside your system and that is the obvious route. But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.
So the M1 firmware is meant to be updated, right? Proprietary updates are the means by which a company exercises unacceptable control. The next update to the network card firmware could check the signature of the OS and stop working.
> some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable
Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open? Seems more likely that this whole theory of yours has a whole in it, that some firmware does have access to change important data.
Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties. Well, you may argue that that is more important than software freedom. Ok, but, then that vendor can then make whatever terms and conditions it wants on those updates, and that includes breaking your security. So, one day, the vendor says: run our proprietary updating software, is every user going to reject it because they realize the security implications? No. And the vendor says: our firmware updates are only distributable through MacOS, so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux. Sounds like a good way to kill GNU/Linux for 99% of users who don't got time for that. Wait, isn't that the situation for M1 laptop users? Riiight.
Look, I'm not a fan of pulling on credentials, but I've literally spent the past year reverse engineering these devices. If you're going to tell me I'm wrong about my security analysis, I hope you've done your own.
> But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.
Not when you can literally flash these devices from scratch (DFU mode) using a public OS image from Apple. That guarantees any preinstalled backdoors go away, since it's a complete wipe (you can do this from a Linux machine, by the way - I just added support for the latest M1 devices and OS to idevicerestore a few days ago). All the runtime components that remain booted while the OS runs are not encrypted, and thus Apple can't hide a secret backdoor in them.
> The next update to the network card firmware could check the signature of the OS and stop working.
The network card is behind an IOMMU and sees exactly what the OS wants it to see. It has no way to check the signature of the OS.
This whole argument is moot anyway, because of course Apple could release a new OS/firmware version that removes the bootloader unlock tools. I've had this discussion a million times already. Apple spent a significant amount of time developing these tools and the infrastructure to allow these unlocks, and I do not believe they would ever do this, as it would be a massive 180 and incur a huge PR hit, nevermind expose them to legal action. If you believe otherwise, then don't buy these machines, or just never update the firmware once you get one. Also don't buy any Android phones, any x86 PCs with Boot Guard, etc., as they all suffer from the same hypothetical retroactive lockdown threat.
> Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open?
We are still reverse engineering these machines. It's not just the IOMMUs. There are other layers of address filtering. We don't know what those streams do, therefore we can't say whether they're evil or not. Given how carefully Apple has designed these things to prevent this, I have no doubt that if there's a path for one of these coprocessors to access all RAM, that's a bug, and if I can confirm that, that'll be an email to product-security@apple.com with a 90 day disclosure deadline, and they'll fix it. It wouldn't be my first rodeo with Apple product security either. They're good, but they're human. They make mistakes.
But we can't say that right now because we literally don't know what's plugged into that port on the IOMMU. It could be a hardware block with an address filter or otherwise controlled by the main CPU anyway. Or it could be outright unused and a vestige of something they were doing on iOS. I can certainly tell you that the main IOMMU port used by the coprocessor subsystem in question does not have access to all RAM. They've been very careful to design the whole SoC like that. If there's a hole, it's a bug.
> Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties.
You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom. In fact, most devices with the kind of little ROMs the FSF loves to ignore, like keyboards, would not use signed firmware if they had a RAM design instead. That means you absolutely gain freedom with the RAM version - the freedom to reverse engineer the proprietary firmware and write your own, or install an open version someone else has already made.
> Wait, isn't that the situation for M1 laptop users? Riiight.
I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet. You can, however, already use DFU mode with another Linux machine running idevicerestore to apply these updates without wiping the whole system nor requiring a macOS install, if you really want to (though it's not the best method because it wipes some stuff that makes it not completely seamless, but it doesn't wipe your OS).
> so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux.
Or you could just dual boot, which is how I expect 95% of our users to use the system. We recommend keeping a macOS install around at this point for various practical reasons. The machines natively support multi-boot and we take full advantage of that. Please learn more about the system architecture before making up FUD.
You're saying that a backdoor can't be secret if it is in an unencrypted binary. That sounds wrong to me. Are you going to decompile and audit the entire OS to find a backdoor, I don't think so.
> I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet.
Well, that is nice.
> You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom.
You "could". In practice, software vendors relies on the updates to abuse their users. For example intel microcode updates have a license that says: you agree not to reverse engineer it. Security updates for printers come with functionality to stop working with third party ink. Oh, you are a sophisticated user and handle it all. Fine. And of course, FSF certainly encourages reverse engineering: if you want to buy something for the purpose of reverse engineering, FSF does endorse that. For everyone else, think it's a perfectly fine position to simply say, we don't endorse opening yourself up to an abusive relationship.
[0] https://news.ycombinator.com/item?id=28628344
[1] https://github.com/podiki/dot.me/tree/master/guix/.config
Have you tried running Proton on Guix?
For someone who is interested in the Guix/Nix ethos but wants to keep Arch, is there anything aside from sentimental reasons that I would be missing by just running the Nix/Guix package managers on top of Arch .
Proton I've only ran through Flatpak Steam. As I mentioned, Nonguix's Steam is limited to older Proton, but I think we'll get that fixed pretty soon once some bigger updates on Guix settle down (today was actually a "sprint" day to fix up changes coming to the main Guix branch soon). But yes, worked great in Flatpak.
The main thing you'll miss from Guix in just using it as a package manager is the system configuration stuff. That will still be your host OS. You can play around with installing different things with Guix, package transformations, and even now trying out the (still in progress) Guix Home [0] to configure your dot files. Guix as a package manager will still give you a good feel of the advanced features it has for managing packages, without touching your host OS.
[0] https://guix.gnu.org/manual/devel/en/html_node/Home-Configur...
Is your XPS 13 the latest revision (i.e. 9310)? If it is, how does Nix handle sleep since Intel had removed S3 support?
Yes I used the linux-surface project. I used a Surface Pro 2017 with an Intel Core i7-7660U CPU. It doesn't have LTE. But touchscreen and pen worked without issues after some fiddling with configs. Battery life was a little worse then on Windows but not dramatically so.
> Is your XPS 13 the latest revision (i.e. 9310)? If it is, how does Nix handle sleep since Intel had removed S3 support?
Yes it's the 9310 model. I use suspend (systemctl suspend) and it works fine. I'm not sure how I can check whether S3 is actually supported. Battery life is about the same story as the Surface. A little bit worse compared to windows.
[1]: https://wiki.archlinux.org/title/Dell_XPS_13_(9370)#Sleep
A rolling release seems at odds with the stability granted by reproducible builds.
Maybe I have a miopic view, but what's nice with Ubuntu LTS is you know everyone and their mothers has built and tested their packages/libraries/executable against the lib versions provided by Ubuntu 18.04 or 20.04 or whatever. You also know those libs, at their given versions, will get patched as issues come up. If all your libraries are constantly churning then you have no idea of the quality of the libs you're linking to (and that lib's dependencies are also churning in turn). You can pin versions, but there is no guarantee what you're pinning to will be patched and fixed as issues come up
I wonder if one could create a business out of supporting such distributions against a comparatively small fee.
Consider threads like https://discourse.nixos.org/t/what-should-stable-nixos-prior...
There's no reason to run LTS unless for corporate insanity purposes.
This is a weird thing to say. The package maintainers doing substantive backporting work for any distribution absolutely are actual developers.
> There's no reason to run LTS unless for corporate insanity purposes.
LTS releases also give you stability of behavior, which can be valuable even outside of corporate environments.
Plus six months is really short. There's plenty of space between that and the full lifecycle length of a major RHEL release, or an Ubuntu LTS. NixOS releases that lasted two years would be awesome.
I'd love to try to use a more long-term NixOS release for a downstream project, if it ever got the kind of corporate backing necessary to sustain that kind of release.
The maintainers doing the backporting are affiliated with the distro rather than being developers of the software they're doing backports for. That is a big distinction because it determines who has to incur the costs of compensating them/recruiting them to volunteer
> And usually you only have package maintainers doing this, not the actual developers.
It's not super unusual for the maintainers of some program's packages in several distros to also be core developers of the project, but yeah, that's a good point.
This means you have multiple versions of a package installed in your system and that you can use them simultaneously for different applications if I understand it right. You can move back and forth between versions if one breaks without effecting the rest of the system. Also if I remember, nixos-update rebuild switch (or something very similar to this command) which is usually fired after installing new packages or when a major change is made to the nix configuratino file creates a new boot entry and hence a snapshot for you to go back to if something in NixOS breaks. So there is no necessity for an LTS version to be present for stability's sake.
Garbage collection is also left to the end user to deal with. There is a garbage collector command in Nix package manager which will clean up when you push the command so that new packages are not flooding your storage space.
NixOS's stable channel can be very loosely compared to Manjaro in the sense that just like Manjaro, NixOS's Stable repo does opinionated changes/interferences/fixes. And NixOS Unstable is like Arch linux with latest and greatest upstream stable versions of the packages.
You just nees to know which versions introduce major API changes etc. and you are fine.
I know I can get any software to run on Ubuntu 18.04. Everyone supports those packages as their specific versions
Having multiple versions or the same package sounds like a disaster. That's the diamond problem. LibA depends on LibB and LibC. Those both depend on LibD at different versions... What then?
These rolling distros generally target one arch and one kernel bc the whole thing is fragile. Things like OpenSSL have bugs even between minor versions numbers once you start looking bigger
What's more, the issues you have with package pinning are more of a problem with traditional package managers. The situation is better on Nix and Guix because it provides you with more control and flexibility over packages.
With traditional system-level package managers, you can't really pin a subset of installed packages. Since all packages are installed into a shared location and depend on each other both explicitly and inexplicitly, packages in a distro release are tightly coupled together. It's just not possible to swap out or pin a subset of packages without the risk of breakage. As a result, a dedicated distro release consisting of old packages is needed to keep using older versions of packages.
This is not the case for Nix and Guix, which installs different packages in their own isolated locations. Packages are more loosely coupled, and you can mix packages from stable channels, unstable channels, and even specific git commits of those channels. Using pinned versions of critical system package is also less of a risk because different versions of the same package can coexist on a single system. Even if something does break, you can always roll back.
Finally, Nix and Guix provides ways to fix issues for pinned packages. With Nix/Guix packages, you're not stuck with whatever the distro provides you with. They're more flexible and allows you to create your own custom packages out of existing ones. For example, here's how you can backport patches for a pinned package on Nix:
existingPackage.overrideAttrs (old: {
patches = old.patches ++ [
(fetchpatch { url = "..."; sha256 = "..."; })
];
})
Nix and Guix are already esoteric enough to scare people away, I don't imagine how these projects would be able to reliably manage LTS releases unless they get serious financial support or enough manpower willing to deal with backporting security and bug fixes.
You might wanna look at Fedora Silverblue and the OSTree technology making its way into RHEL/CentOS/Rocky/ALMA etc.
A big CON is that even on Ubuntu LTS, lots of softare is incredibly out of date and full of unpatched security vulnerabilities.
Consider Roundcube, probably the most popular PHP email web client.
On Ubuntu 18.04 LTS the last update is from, well, April 2018: https://packages.ubuntu.com/bionic/roundcube
Now consider the amount of CVEs (remote code execution and XSS) published for Rouncube since then, which are all unpatched in that Ubuntu: https://www.cvedetails.com/vulnerability-list/vendor_id-8905...
If you are running Ubuntu LTS on your server, that's a big problem.
The `roundcube` package is in the `universe` repository, meaning "community maintained". In this case for this LTS that meant "no security updates at all for 3 years". The newer LTS, 20.04, doesn't seem to have those CVEs fixed either.
In a more interesting note, I wrote an aside about grafts, which are a way of providing changes to packages without rebuilding (often to graft in a security fix to a library the package uses). So you can keep a configuration of packages you like and graft on security fixes while staying on the same version. There are some caveats about when you can do this of course (ABI compatibility mainly), but is some cool technology, to me.
GuixSD and NixOS aren't subject to some of difficulties of traditional rolling release Linux distributions.
You are exposed to upstream behavior changes and upstream bugs more or less as soon as they arrive, just like on Arch Linux or something like that. But most of the other risks and maintenance burdens of ‘running a rolling release’ aren't borne by GuixSD and NixOS users.
This is not so much due to the reproducibility of Nix builds as to the hermeticity and statelessness of Nix and Guix builds.
The hermeticity means that you don't have to worry about ABI breakages in the same way, since packages that need incompatible versions of the same library will each find their respective version of that dependency sitting safely isolated from one another in the package store. This spares you from a few maintenance burdens:
• installation of new packages causing/requiring upgrades of ‘unrelated’ packages because they share some dependency with the new one (this one affects standalone package managers like Homebrew as well as rolling releases of entire operating systems like Arch)
• having to upgrade before installing new things, every time you update your package sources
• having to rebuild some packages that are not part of your main OS configuration because you upgraded your main OS (e.g., Arch updates breaking AUR packages, or system upgrades breaking software you compiled manually or your Python virtualenvs, etc.). (You do have to inform the package manager that you don't want these externally-depended-on packages garbage collected, though. For Nix, for example, you can do that automagically by running fc-userscan against your project directories: https://github.com/flyingcircusio/userscan )
The statelessness is related to reproducibility in that it's a result of the functional package management approach to reproducibility. Since every version of your whole system is generated without reference to previous versions (indeed, from scratch!), the OS never has to navigate state transitions for its packages. It doesn't have to worry about converting configuration files from one format to another, or replacing defaults, or the implicit dependencies of your system undergoing name changes or being replaced. Nix and Guix don't need Debian-style transitional packages and similar tricks. That means you aren't punished, on a per-package basis, for not updating your system constantly.
For example, I recently took some neglected, non-internet-facing NixOS servers and updated them from an early 2018 release of NixOS to the latest NixOS unstable rolling release. While I did have to first work a forward incompatibility issue in Nix itself, the rest of the upgrade was a single step, and I didn't have to worry about finding a valid ‘upgrade path’.
It's worth noting that in a strict sense, the reproducibility is all still there, even for NixOS releases that no longer receive updates. If you need to use an old version of some piece of software for compatibility reasons, in a safe environment, you can use the latest and greatest Nix to install packages from NixOS releases that are 2 or 4 or 6 or 8 years old— including on top of a bleeding edge system running NixOS Unstable.
But you have a point: it would be awesome if there were long-term releases, you would get a different kind of reproducibility— one which is less strict but more useful in some ways. For example, you could take a Nix expression that someone posted in a Gist on GitHub 4 years ago, for what was back then the latest NixOS stable release. If that release were also an LTS, you could not just reproduce what they actually had, but apply it against the latest version of the same LTS to get a system that should be totally compatible in terms of behavior, but suitable for running in production without modification, thanks to up-to-date security patches.
Why not just use Nix, which is more battle tested?
Guix has an excellent CLI and awesome docs. It's stable and plenty usable. All being in one, high-level language like Scheme makes it seem really easy to hack on, and I think that's part of why its CLI is so good already.
Nix is faster, it supports macOS, and its package collection is much bigger because it's older. But Guix seems great to me, too! If you think you might like it, try it.
There are quite a few popular channels, such as non-guix (with things like vanilla Linux), guix-science, guix-past, etc.
As a maintainer of R packages in Guix I'd also like to point out that many R packages in Nix actually need more work to build them, so the number of packages in Nix is rather inflated. Guix also goes to great lengths to actually build things completely from source, such as Java packages, or to minify JavaScript from source files.
Nix flakes are kind of a lot of things: a version pinning system, the switch to pure evaluation mode by default (which impacts caching in a good way but makes configuration slightly more annoying), a distribution mechanism for code written in Nixlang, and a collection of Nixlang schemas which enable a richer command line experience (that, e.g., power the new `nix run` command). It's not clear how many of those functions Nix flakes will retain in its final form.
There's no singular feature that attempts all that in Guix as far as I know, and I don't know the general technical story for evaluation caching with Guix. But Guix does have an integrated, first-party form of package pinning. Where Nix flakes replaces the old 'channel' system, Guix has a richer notion of channels which support pinning in normal Guix expressions.
(In Nix, channels are an output that have a certain structure and get managed in a certain way via fhe nix-channel command to manage them— they're like another type of Nix profile. In Guix, channels are defined by the user directly in Scheme code, just like the rest of their configuratiom, which is more similar to how Nix flake inputs are defined than to Nix channels.)
I've never used Guix channels in anger, so I can't tell you how nice that notion of version pinning is to use.
https://guix.gnu.org/manual/en/html_node/Replicating-Guix.ht...
And while nix may be battle tested that doesn’t translate to a good experience, the learning curve is high and the documentation while plentiful is not really good or helpful to beginners. Plus the entire thing is in flux right now between flakes, home-manager, and a desire to kill nix-env.
If I read this on any other website I’d assume it’s sarcasm. Only on HN, folks.
If you're a long-time lisper interested in the ideas embodied by nix/guix, that alone is a lot of points for guix.
Oh don't get me wrong, I'm not saying guix is better (I have absolutely no idea), just that the experience with nix is extremely rough so nix being a bit more popular is not necessarily that much of an edge (or one at all).
> I like Guix as package manager, but their docs can definitely be improved with loads of examples and tutorials.
In fairness I'll say that especially if you're a long term user it is very easy to be blind to the early user experience. Sadly most projects don't push new users towards really reporting their experience or even contributing to the docs, but if you have the time and inclination to do so I'm quite convinced your experience would be extremely valuable to those who'll come after you, even if the project doesn't necessarily value them that much (but even then it can be useful as evidence of issues with the early experience / uptake, and possibly efforts to rectify them later on).
It's also useful on a personal level, because memory is a fickle thing and a year from now you may not even remember your struggles.
I've not yet had the energy or patience to learn the TexInfo format, which is a standard for GNU projects. But if anyone wants to put what I have in the Guix docs, even as merely an example or tutorial, I wont mind.
The issue here isn't just that the documentation is lacking, but that Guix wants to have everything done in Scheme, so you often run into the issue of having to translate code you already have running in Bash into whatever Scheme equivalent Guix wants.
This is my big gripe with Nix. There are so many things that are almost ready, or almost integrated, and advanced users are typically already using them. It makes it feel like next year will always be a better time to recommend Nix to newbies.
And a lot of the more ambitious contributions to Nix and Nixpkgs that are really, really exciting as a user tend to sit in pull request limbo for a very long time, sometimes dying on the vine. Guix doesn't seem to have that problem yet, but I don't follow it as closely.
It's painful to feel sort of totally married to it but also like I can't whole-heartedly recommend picking it up to most people I know who might enjoy it once they got going.
I haven’t used NixOS though, which could make things a bit different.
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.
But for slightly larger projects, creating a package description was always worthy. I especially liked having a shell config where entering a directory automatically put the necessary packages in scope.
But it also felt like, apart from learning the new way of using my system which NixOS/Guix works, now I have to work with how to deal with different languages. To me this felt like a big overhead. As a n00b of NixOS (not a n00b on Linux BTW), I have questions like doesn't this mean I will have lesser support on setting up something new development when something new comes along? This honestly have made me take my time on going back to NixOS. Cos I cannot just compile the packages directly like I could in normal Linux distros. Right? Or do correct me I am wrong. Like I said, the time constraints (+ pandemic) have made it hard for me to make time. Maybe you could correct me if I am wrong somewhere and make me understand it better. :)
- 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.
Being able to take your setup with you to a new computer is pretty cool, right?
BTW, I rarely rollback, and if I do it's because I've monumentality fucked something up, which is a great feature.
That gives you Binary Transparency, which is already being attempted in the Arch Linux package ecosystem[0], and it protects the user from compromised build environments and software updates that are targeted at a specific user or that occur without upstream's knowledge.
Once updates can be tied securely to version control tags, it is possible to add something like Crev[1] to allow distributed auditing of source code changes. That still leaves open the questions of who to trust for audits, and how to fund that auditing work, but it greatly mitigates other classes of attack.
Then there’s the question of how exactly you reached this state. Having nixos generations is like having an event stream of all changes. Apply your backup to a new machine, what happens? Who knows.
In nixos/guix it’s not about only ”package tools”, it’s about treating the complete system and its state as a coherent whole.
Once I got the taste of it I see no way back to opaque packages, managed by config tools with no concept of state.
And if you’re a dev - shell.nix and declarative containers ftw.
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.
Also, what happens if you incidentally run pip on a Nix system? Will it mess up your installation?
[0] guix install mpv --with-commit=mpv=cc4ada655aae06218b900bb434e3521566394cde
Alternatively you can create derivations instead in which case the resulting artefacts will be fully understood and manageable by nix (I think there are integrations to do that e.g. tools like carnix which can automatically create derivations from existing language-specific packages, not sure if there's one for pip/pypi).
Also if you run pip as root (to install for all users at once)?
And if you bypass that, `nix-store --verify --check-contents` can detect the issue.
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 rollback is better solution.
Of course if you have in the meanwhile used the new system and your home folder contains some backwards incompatible changes, both solutions will fail. Rolling back your home folder may not be a good thing as you may have backwards compatible changes you prefer.
Also, nix can also manage installed application’s configs, so those could also be rolled back, on either a per-app basis or however you prefer.
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.
If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take.
The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia
It's been around for a long time. Idk who all is using it
Nix (and guix) allow for a declarative description of a package, (or, e.g. a collection of packages). In addition to rollbacks, I think some of the other benefits are neat.
e.g. Usually for running some project I see on GitHub, I have to copy-paste the "apt install <whatever>" command; or maybe even run a "curl https://example.com/install.sh | sh". Some projects provide a Docker image, allowing the program to be run without changing what's installed in the system. -- Nix allows for the advantages of each of these (e.g. being able to run the program without installing it into your system, or allowing for a simple command to install it).
e.g. VSCode has a Remote Containers plugin which allows for quickly getting started with a project by using a Docker container as an execution environment. Or things like GitHub Code Spaces or ReplIt aim to provide quick-start environments for developing code. -- I think nix-shell offers similar benefits. (Nix can even be used to describe a Docker image format, instead of using a Dockerfile).
e.g. something like "install this package, but with this different set of build flags enabled" is relatively straightforward in Nix.
It's not, at least not necessarily.
Let's say you try to change your system configuration and you fuck it up, you revert, with zfs your attempt is gone, or you have to go and hunt it down in the snapshot if you remembered to store that.
With nix/guix it's still there to be updated.
An other component is the intentionality of decisions: in nix/guix you can reach a point where the setup of the entire system is fully described and reproducible, in fact there are people who rebuild the machine "from scratch" (really from the nix store) on every boot, to ensure the system does not accumulate transient cruft.
The main advantage of both of them is that installation and 'making available' are decoupled. Meaning you can install five different versions of the same app and it'll be totally fine, as they don't sit around in '/usr/bin/foo' and clashing with each other. They sit conflict-free in '/nix/store/${HASH}/bin/'. For making them available for use you have to add them to your profile/environment (i.e. $PATH and symlinks that point '/nix/') or just run them from their '/nix' directory if you prefer. This makes development and testing new versions much easier as nothing ever really breaks to begin with. You can just spawn a new environment, fill it with whatever you need and use it. And it all happens at the packaging level, so it's pretty quick and you never end up with snapshots that capture far more of your filesystem than you planed.
everything else Is unlikely to break your system enough to prevent you from switching profiles
Having a whole system, including the package database, build out of raw Scheme really doesn't feel like a good idea. It sure is flexible, but also really brittle and the performance is quite horrible.
I am currently in the process of switching over to Nix, which handles that all a bit more sanely.
However, it should be hard to break a Guix system, since you can always roll back. Of course you can find a way (I changed an ext4 flag that turns out Grub doesn't like, but that has nothing to do with Guix), but as long as you let Guix do its job and try not to manually work around it, you should be able to undo everything. Of course nothing is perfect, but I hope you reported it. In my experience the Guix devs and community is keen to improve.
https://gitlab.inria.fr/guix-hpc/guix-hpc-non-free/-/tree/ma...
How to add a channel https://guix.gnu.org/manual/en/html_node/Using-a-Custom-Guix...
That’s a very unique definition of “fun”.
This is a complete denial of reality, of course, and at the cost of the user. Religious dogma, as you put it, seems like an apt description.
But since reality doesn't care about their refusal to adapt, and they can't just throw their hands up in the air and say nothing is free any more and you should just live off the grid and reject all technology, they instead have built a deliberately obtuse set of rules to declare certain things out of scope, so they can maintain the illusion of freedom for their followers while making concessions behind the scenes (and even actively working with manufacturers to devise silly workarounds that fit into that framework, see e.g. the Librem 5's ridiculous secondary CPU core and external flash dance so they can claim the RAM training blob doesn't make their device non-free).
Then they're very careful to never talk about this unless prompted; the fewer people know about all these secret blobs they're running anyway, the better. It's basically cult-like behavior - this kind of control of the information and narrative that followers get is a defining characteristic.
None of this helps users, of course; what would help users would be being informed about not just exactly what blobs exist, but what the risks are, how they might affect their privacy and security, what update options exist, and whether they can be audited or replaced with free versions in the future. But the FSF doesn't care about any of that. They just want to pretend they live in a blob-free utopia.
Edit: Ah, the downvotes have started. I guess the FSF fans have showed up. I hope you're not using an off the shelf mouse to click on the downvote button; those all run proprietary USB HID firmware.
Then they spin narratives about how this is important for not just freedom, but also security/privacy/etc, while their policies have absolutely nothing to do with improving users' security or privacy, as is made evident by the linux-libre issue, among many others. Actual assessment of the privacy/security impact of proprietary firmware on users is a much more nuanced topic, but the FSF are not interested in nuance, they just say "blobs (that you can see) bad".
i think i have always held the opinion that for FSF and GNU their concept of security was "security through free software". that is free software (according to how its understood by them) comes first
The people criticizing the FSF here act as if Stallman were wrong about these issues because he said it back then already. While in reality again and again he was right about how user freedoms are limited when the principles he outlined are not followed.
To give Intel a way to distribute closed source software updates to your processor is definitely a security risk. And we know for certain the actors in the USA that try to use those security risks for their surveillance programs. Don't act like this world does not exist.
> By withholding that information they are effectively eliminating the choice, and restricting users' freedom.
You are mixing up agency and software freedom, it's clear that you won't see eye to eye with the FSF as long as you do so.
I'm not even vigorously defending not showing the note about existing firmware updates, if Guix really does so. I'd prefer a note. Just what it would mean and how problematic closed firmware would be seemed like it needed a clarification here.
That is not what linux-libre is doing/refusing to do. What linux-libre is doing is censoring a message to their users that their microcode is out of date and their CPU has security vulnerabilities. They could've just left that in and let users make the choice whether to manually install the microcode updates or not.
> You are mixing up agency and software freedom
Agency is more important than software freedom. The FSF's problem is precisely their blind focus on "software freedom" when the definition of "software" can't even be precisely defined any more, to the detriment of everything else that affects users.
your refusal to accept FSFs right to adhere to its principles is bordering on the extreme. yet you constantly lob insults toward them as an organization. it does not help your points at all. they obviously hold different values to you. i think FSF is ok as long as they are clear about what they are doing and they are not trying to trick anyone. you have done absolutely nothing to demonstate otherwise in this whole exchange and instead you keep slinging FUD. i will repeat my question that i have asked so many times: has GNU or FSF anywhere claimed that they take a security-centric approach? as far as i know they have always taken a free-software approach. that they refuse to bend their principles to infantile screams is a big plus in my books
IIRC Stallman criticized Ubuntu for collecting users' search info by default-- something they used to do[1].
It's unfortunate to see a call to nuance paired with an exaggerated claim that is so easily disproven.
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 and look at how much freedom you have, how much protection you have, etc. and then ask yourself : where does it come from ?
Well said. If problems are not openly demonstrated and complained about, things will not improve.
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.
And yet they aren't changing it. The FSF has had exactly zero success in changing the direction the world is moving in with regards to firmware and deep proprietary integration.
In fact, they've done very little for freedom in the past 10-20 years; most of the real breakthroughs have come from much more pragmatic people, such as those developing reverse engineered open source drivers for complex hardware like GPUs.
The FSF shows you how much freedom you lack according to their own bizarre definition of freedom... and then does amazingly little to actually improve your freedom.
Whose efforts get completely circumvented through employment of cryptographic firmware signing, which gate keeps necessary functionality out of said pragmatist's reach.
Also, please omit inflammatory swipes like your "Edit", which also badly broke more than one of the site guidelines. Would you mind reviewing them? We're really trying to avoid this sort of hell to the extent possible.
If they were being honest, they would tell people that this dongle has a good half a megabyte or so of proprietary Bluetooth stack built-in (with runtime patching/update ability; they all do), and they wouldn't deceptively have a "TET-BT4 source code" link that makes it sound like the firmware is open, while it's actually just a tarball of the Linux kernel (which contains a generic Bluetooth controller driver, nothing specific to this device).
it states:
> However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software.
>We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification.
END QUOTE
According to you, what is deceptive about this?
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 stack that there is a blob involved, and they can't certify that as "Respects your Freedom". So instead they worked with the manufacturer, and came up with this contrived interpretation of the "secondary processor" rule where, as long as the firmware in the "secondary processor" is at least two steps removed from the main CPU and never handled "directly" by it, it's okay. Then they had the manufacturer put the blob in a Flash ROM (Flash, so updatable, remember? just not that easily), and then they had them write a little loader code that runs on another secondary CPU. So the main CPU (running free software) boots a secondary CPU (running free software) that loads a blob from Flash and then boots a third CPU, which now runs proprietary software. According to the FSF, all this pointless obfuscation and extra levels of indirection makes the device magically compliant with their criteria. And so it got certified.
It is completely evident that absolutely none of this helps end-users' freedom in any way, shape, or form vs. just having the blob in the normal bootloader where it can be more easily inspected and analyzed (and also lets users ensure that it hasn't been tampered with). It's just adding obfuscation so users won't find the blob, and therefore will feel better believing they aren't running any blobs.
By this interpretation of the rule, I could ship an x86 PC with an Nvidia GPU that runs its proprietary driver on one of the CPU cores (isolated from the main OS), loaded by the UEFI firmware through ME or something, which communicates with the rest of the cores via VirtualGL or some other RPC, and that would make this PC eligible for RYF certification. Tell me that's not a farce.
At the moment this back and forth feels like you’re talking past his actual point(s).
> They are deceiving people into believing they are not running proprietary software
edit: as regards FSF's logic i am not informed enough to comment so i didnt. but the conversation (this thread) was definitely about deceptiveness
Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have principles but is instead a cult. Very odd.
> 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. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates.
"Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases.
Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.
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 libreboot - highly recommended - fast, and works well without microcode updates, including virtualization)
>AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates.
>NOTE: 6300 series CPUs have buggy microcode built-in, and libreboot recommends avoiding the updates. The 6200 series CPUs have more reliable microcode. Look at this errata datasheet: http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Gu... (see Errata 734 - this is what kills the 6300 series)
END
source: https://libreboot.org/docs/hardware/kgpe-d16.html
the Errata 734 is quoted here as reference:
BEGIN
>734 Processor May Incorrectly Store VMCB Data
>Description: Under a highly specific and detailed set of internal timing conditions during a #VMEXIT for a virtual guest that has multiple virtual CPUs, the processor may store incorrect data to the virtual machine control (VMCB) reserved and guest save areas and may also store outside of the VMCB.
END
however i wasnt referring to you specifically as arguing in bad faith but that seems to be the attitude of some very vocal people here. i included the full excerpt in case the point is relevant. i am not an expert in this field
does the issue in Erata 734 apply to 6200?
Well there are two reasons. The first is Errata 734, and the second is that the fix for Errata 734 requires loading different microcode than what was baked into the processor at manufacturing time ("6300 series CPUs have buggy microcode built-in, and libreboot recommends avoiding the updates"). I didn't mention Errata 734, because I'm focused on the second reason.
Working back from their reasoning, Errata 734 seemingly does not apply to the 6200 series.
i take no issue about with critically discussing someones logic. fud and attacks are annoying and dont contribute to a healthy discussion
The FSF even condones non-free software (in a rather dorky way) for people whose machines require it[2]. I understand the FSF's principles and am glad they hold to them so strongly, but I would use non-free graphics drivers if I were to install Guix. I do fundamentally agree with the principles of software freedom and I am honest with myself that I am in fact making a moral compromise. Similarly I'd probably compromise over CPU microcode patches, even though I believe I have the moral right to view, understand, and change those microcode updates if I wish to and am displeased that my rights are being violated.
I believe in this day and age where the right to repair your own equipment is under serious threat, the principle that we should be free to modify the machines we own as we see fit is more important than ever.
[1] https://gitlab.com/nonguix/nonguix
[2] https://www.gnu.org/philosophy/install-fest-devil.en.html
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"
However, for fun, I'm going to do my best to steelman the FSF position: The use of non-free software when no free alternative exists is tolerable. The material difference between firmware that comes with the hardware or microcode that comes with the CPU versus a downloadable update is that the update is voluntary, and thus involves a willful violation of the principle of freedom. By doing so one becomes actively complicit in the erosion of freedom.
I also agree that they shouldn't be jerks on mailing lists and IRC, but have some empathy for persons that aren't so fortunate that they can eschew all non-free software.
Principle of freedom, in the context of the FSF, has always referred to user/recipient freedom.
A user voluntarily (of their on unconstrained freedom) making a (informed) choice for themselves, by definition does not violate their own freedom, they are exercising their freedom. You are contradicting yourself.
Complicit-ness can be debated with regards to purchasing decisions, not with regards to updating firmware.
Whereas having a background in embedded design, I can't ignore that I have many more devices running nonfree software than Free software, despite trying to use Free software wherever I can. In particular, my fully Free desktop relies on non-free { monitor, monitor remote, keyboard, mouse, USB hubs, USB hub PS (power supply), USB switch, UPS, network power switch, circuit breaker, ethernet switch, ethernet switch PS, GPON terminal, GPON PS, nonfree BIOS on router }, in addition to the contentious non-free { video card, network card, CPU }. Any and all of those things could be replaced with a Free equivalent, but at the cost of attention that would be better spent elsewhere. In a world being eaten by software, the best we can do is hope for well-defined interfaces with nonfree systems, for our Free systems to interoperate with.
Perhaps a good way forward would be to split (Nonguix, Debian non-free, etc) into two separate categories depending on whether a package runs in the main security domain (drivers, system software, utilities/applications), or is to be loaded into an auxiliary processor (firmware blobs). Then after this distinction became widely accepted, the Free-first distros would hopefully become more comfortable including the firmware blobs, making a better user experience for their Free environments without impinging upon the freedom within.
(FWIW your steelman isn't it - it would seem to indicate that buying a computer with MS Windows preloaded is good from a software freedom perspective)
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.
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 secure than Open BSD
i think that taking a position that free software supports security and also that free software principles come before security considerations is not contradictory let alone deceptive
[0]EDIT: i just searched the RYF site and did not obtain a signle result for the term 'security'
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.
well my point is that FSF never anywhere claimed otherwise. if they did THAT would be wrong and irresponsible
>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.
sure. well a simple example is that security by obscurity is a valid concept in a right environment
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.
and you are free to do that and i would not say that you are a part of marcan-worshipping-cult or following some dogma
>deceiving myself into believing it has been achieved by ignoring anything below a certain level
if you are stating that this is what FSF believes then you are in fact spreading a falsehood and fud. this is what marcan has been doing regarding FSF the whole time during this engagement
>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.
Unless FSF is claiming that GNU Guix is secure by design, or is free from such attacks, this is just a strawman argument
I really do not understand what is so hard to understand that from a free software POV there is no distinction between a chip loading a blob from system storage and a chip loading a blob from it's own tiny updatable flash. Both load a non-free blob. Neither fully respects your freedom. Drawing the line of Respects Your Freedom TM between those 2 is stupid and deceptive.
The users ability to update firmware is also the ability to revert firmware changes (to a old trusted even if closed source version) made by a malicious party. Users do not gain any freedom by giving up that ability. They loose freedom.
Being able to choose between MS Office and Lotus and Star Office and WPS Office (1) gives the user more freedom compared to being stuck with just MS Office (2), even if none of those respect your freedom. Being able to also choose Libre Office (3) is obviously better. But 1 is still obviously better than 2. The existance or absence of 3 does not change that.
With regards to firmware, the FSF believes that 2 is better than 1. That is stupid. How do you not see that?
It is a valid form of protest but Respects Your Freedom TM certified hardware does not truuuuly respect your freedom.
This is harmful because the goal should be hardware with FLOSS firmware with reproducible builds and with the option for the user to add their own signing keys, NOT unupdatable (by the user) closed source proprietary firmware.
your comparison with MS is ridiculous. FSF software is open. do with their software what you like. FSF believes it should not help you with 1 or 2 due to its principles, and that is OK. why wouldnt it be? the source is there so help yourself if you really want something that they are not willing to help you with (even if they often do apparalently)
anyway this whole exchange is becoming tyring to me. a lot of these comments by people seem to be more about vaging a crusade against FSF than it is about discussing issues in good faith. its somewhat dissapointing, esspecially since i only just realised who marcan is. as far as i am concerned, i am completely unconvinced by marcan and co that FSF is a deceptive organisation and that their work is somehow bad for free software. quite the opposite, i am happy that they exist. i say this simply as a spectator. to me the following comment on their website just clearly shows that they are aware that products they certify run nonfree code:
"If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification"
(source given elsewhere in the exchanges)
i do not feel deceived in the slightest. if deception is happening it seems to be regarding FSF's position. take care
(giggle)
Ya, monitors and hard drives all have very complicated firmware too. It is very simple, it is not denying you a freedom which is unethical to deny. FSF is not saying: it's totally great and fine, I'm sure the FSF will be happy to promote any of those devices if they have free firmware in them, celebrating them as more free. It's the same reason they focus on software and not on hardware designs.
https://news.ycombinator.com/newsguidelines.html
We detached this subthread from https://news.ycombinator.com/item?id=29286715.