Talk:Kernel/Deblobbing

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 15:32, 5 November 2024 (UTC)
:: Your reply ~~~~

Setting Python version

Talk status

This discussion is done.

I don't really like changing my favorite Python version with eselect globally. What about running the deblob script in the following way?

root #PYTHON="python2.7" ./deblob-4.11

--Fturco (talk) 13:12, 26 June 2017 (UTC)

Of course, feel free to change the page content if you tested this solution (I'll try it at my next deblob run). Making two eselect python set if needed, before and after deblobing, isn't such a big work…

Francoisd (talk) 16:22, 26 June 2017 (UTC)

Done.

Fturco (talk) 19:18, 27 June 2017 (UTC)

Fturco, I don't agree with your deletion of the eselect solution, it would be better to add the second (and very good) one: Gentoo's philosophy is to provide choices to users, then they choose the solution they prefer. The 1^st solution indicates if Python 2.7 is installed, the 2^nd one needs an emerge even if Python 2.7 is installed and is the favorite version.

Francoisd (talk) 11:01, 28 June 2017 (UTC)

My solution doesn't require the user to re-emerge python:2.7 if it already installed because of the --noreplace option. Changing the default Python interpreter with eselect may break other applications if you forget to restore the initial settings. My solution instead is limited to the deblob script only, and it is easier because it requires just one command instead of two. Fturco (talk) 09:58, 29 June 2017 (UTC)

Linux-libre is more than remove blobs

Talk status

This discussion is done.

In the Wiki, we should indicate about Linux-libre patches and, instead of the message "Starting with kernel version 4.14, the whole firmware tree has been dropped. So, for new kernel versions, deblobbing is no longer necessary.", we should to write about as Linux-libre patching is for deblobbing and for to remove options based on FSF Philosophy as CPU Microcode Support, it isn't only for deblob the kernel.

-- John82 (talk) 14:55, 18 March 2024 (UTC)

Can you word that note in a more neutral way please? I'm sure that Linux upstream would strongly disagree that there was "malicious code within the kernel". See also wikipedia:wp:NPOV. --ulm (talk) 15:17, 18 March 2024 (UTC)

Verify it now; I've written it in a neutral manner regarding what constitutes a distribution not compliant with the GNU FSDG as Gentoo. --John82 (talk) 16:00, 18 March 2024 (UTC)

Calling them "proprietary components" is slightly better but still not neutral wording. IIUC these scripts also remove some (free!) code for firmware loading that is needed on many systems, e.g. for mitigation of Spectre/Meltdown/Retbleed CPU vulnerabilities. (I've always wondered why the Linux-libre folks find it o.k. to run a CPU with the firmware that was installed by its manufacturer, but patching that firmware is considered a bad thing.) --ulm (talk) 16:30, 18 March 2024 (UTC)

While it is true that the term "proprietary components" may carry certain connotations, it accurately reflects the perspective of the Free Software Foundation regarding non-free software elements within the system kernel. Regarding the removal of certain firmware loading code, it is important to understand that the Linux-libre project aims to prioritize software freedom over other considerations, such as security updates for CPU vulnerabilities. The decision to remove certain firmware loading code stems from the principle of ensuring that all software running on a system complies with the GNU Free System Distribution Guidelines (FSDG), which advocate exclusively for free software. Additionally, ideally, both the firmware installed and the installable firmware should be free. Another possibility would be for such firmware to be non-updatable and be stored in ROM rather than in RWM. Additionally, the goal of not executing external firmware is to treat the firmware installed by the manufacturer as part of the hardware itself, thus avoiding the inclusion of proprietary software in the kernel. This is important because external firmware can alter the CPU logic, which could compromise the system's integrity and users' ability to control their own hardware. --John82 (talk) 21:04, 18 March 2024 (UTC)

As I said before, we aim for a neutral point of view. The FSF's point of view is sometimes non-neutral and carries a political message. As such, using a wording like "proprietary components" for firmware loaders is not appropriate for this wiki. --ulm (talk) 15:29, 19 March 2024 (UTC)

The changes you have made seem appropriate from your perspective. As for me, I conclude the discussion here. Thank you for the discussion. --John82 (talk) 18:42, 19 March 2024 (UTC)