FSFLA

Well the thing with the "Guix System" is that is uses the LinuxLibre kernel. So if the hardware you have requires proprietary bits or driver, it just isn't included. That isn't to defend Guix in anyway, but the problem doesn't seem to be Guix when you read the fine print of the distro, the problem is your hardware. So, do I agree necessarily agree with GNU's official distributions having this philosophy? Not really. Firmware and drivers is probably the one area I think the GNU people should finally throw in the towel. It keeps people out of running it, or doing so with relative ease. And the battle is for the most part lost on that end. But they do essentially tell you that it is likely it won't work across a lot of hardware out of the box. But here is the download page [0] https://guix.gnu.org/en/download/ That mentions the Libre kernel with link to information about the Libre kernel [1] https://www.fsfla.org/ikiwiki/selibre/linux-libre/ With the following information: "Linux, the kernel developed and distributed by Linus Torvalds et al, contains non-Free Software, i.e., software that does not respect your essential freedoms, and it induces you to install additional non-Free Software that it doesn't contain. Even after allegedly moving all firmware to a separate project as of release 4.14, Linux so-called "sources" published by Mr Torvalds still contain non-Free firmware disguised as source code. Stux, a cute penguin. Few realize he's not Free GNU Linux-libre is a…

Not exactly the same goal but in the ballpark, reminded me of the linux-libre patches (removes binary blobs and non-gpl code from the kernel)- https://www.fsfla.org/ikiwiki/selibre/linux-libre/

Unfortunately some of the Linux kernel mainline has questionable licensing too. [1] In short, [2] and [3] are probably linux-firmware territory in the mainline kernel. [1] https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre… [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre…

Reminder that Alexandre Oliva was also forced out by his fellow FSF board members for defending RMS from false accusations. https://www.fsfla.org/ikiwiki/blogs/lxo/2021-01-10-resignation.en.html https://www.fsfla.org/ikiwiki/blogs/lxo/2020-12-19-leadership.en.html

The title, and some of the context of the article, made me think of the 0G Manifesto [1]. I realize that the article suggests that German citizens want reliable bandwidth, and are not necessarily thinking in terms of a 0G solution, despite the opening digression about radio enthusiasts. But wouldn't it be liberating to have a fully decentralized mobi-net, hosted by everyone, for everyone. [1]: https://www.fsfla.org/ikiwiki/blogs/lxo/pub/0G

> I sincerely hope that there will be people in the FSF There are: https://www.fsfla.org/%7Elxoliva/ But apart from being next in line, he's also next in line: https://twitter.com/sarahmei/status/1174371580547223553

> that we deliberately changed the kernel to refuse to load I've heard this myth before too. Here's someone else's succinct answer to it: It's a common misunderstanding to think that the Linux-libre project forbids loading non-free modules/drivers by user's request after the kernel was installed. In fact, it's a bug that is very hard to fix due to the way that the Linux kernel itself is made, as Alexandre Oliva, member of Linux-libre project, states at http://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-intervie… (when answering the question "Is there anything that the project wants to do that it can't do now? In general, what are the future plans for the project?").

Related: https://www.fsfla.org/ikiwiki/selibre/linux-libre

> linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode This is FUD. The reason it's not possible to load microcode or other proprietary blobs from linux-libre is because of a limitation of the deblobbing process. From [0]: Indeed, I became aware that some users have got the idea that blocking the loading 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-libre-intervi…