Quoting intrigeri (2022-04-19 13:20:19) > Jonas Smedegaard (2022-04-19): > > In other words: Please let's take this is multiple steps, first > > being to distinguish non-free firmware from other non-free code, > > without deciding yet exactly how strongly we then allow that new > > section to be integrated with our "pure" parts. > > I tend to favor incremental approaches. In the case at hand though, > I'm worried it'll be difficult to find people motivated to accomplish > that first step (which I guess is the biggest part of the work, but > arguably yields little benefit), without some commitment from the > project to actually use that work in order to solve the problems this > thread is about. > > So I'd like to understand: why do you prefer to postpone the decision?
Good point! When I install systems, I consider non-free blobs more risky than other code. Yes, that includes blobs executed non on the system but is uploaded to other isolated systems: Even though I myself am not clever enough to detect security flaws in most Free code, others are, and some even take on as educational tasks to examine source code. So I have a higher trust on the "more eyeballs, fewer bugs" logic for Free software than for non-free blobs. When I (sometimes, but not always¹) choose to "infect" my systems with non-free packages, I therefore consider each non-free package to try minimize the amount of risky blobs on my systems. As an example, I may choose to not apply realtek firmware updates when I can verify that my ethernet device works adequately without it. Now, some may argue that I am describing a case for package pinning here, and that *might* be true but I don't know that yet - because the proposed change to the system does not exist yet so I cannot really know that yet. Possibly the implementation will be so that I continuously need to check if some new non-free blobs was introduced and block those, instead of the current situation of not needing to do anything actively to keeping most possible risky "stuff" away from my systems. Hope that makes sense. A counter-question: What is the large work required to do the separation stage, without the integration stage? I recognize that there is an ongoing burden of status quo, and therefore of prolonging that. Sorry that my option 6 cannot really address that. I do not, however, understand how the task of separating a non-free-firmware section is "all work and no joy". Kind regards, - Jonas ¹ Really! I do recognize that certain types of systems, e.g. rack servers, more often than not require non-free blobs for crucial components like ethernet drivers, but not all do, and commonly the kind of systems I manage do not. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
