Talk:Kernel/Deblobbing
From Gentoo Wiki
< Talk:Kernel(Redirected from Talk:Kernel Deblobing)
Jump to:navigation
Jump to:search
Note
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.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)
- 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 1st solution indicates if Python 2.7 is installed, the 2nd 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)
- 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)