Hi, I think this could be useful for extending the documentation by explaining the limitations of linux-libre in case we don't already do it in an easy language. Appended Message Exchange with Alexandre Oliva:
On May 3, 2017, ng0 wrote: > do you have a bugtracker where progress on this could be visible, 'fraid not. > Do I have your permission to forward this message in full to our > developer mailinglist, Sure > or do you happen to have an explanation already > somewhere more public? I'd have pointed to Bruce Byfield's interview, but evidently that was not clear enough ;-) ----- Forwarded message from Alexandre Oliva ----- > Date: Wed, 03 May 2017 00:20:56 -0300 > From: Alexandre Oliva > To: ng0 > Subject: Re: question about a bug mention in an interview back in 2013 > > On May 1, 2017, ng0 wrote: > > >> 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 for example linux-libre is installed on a device with an > > intel wifi card, and your bug is solved, would this imply that > > the intel card can be loaded (which currently can't be achieved)? > > I suppose you mean 'the blob that controls the intel card can be > loaded'. If so, the answer is yes. Loading it and running it is a > user's decision, even when the software is non-Free. We don't stop > users from doing so, but unfortunately we make it very difficult > (modifying the module sources and rebuilding the kernel, or at least the > module, is currently required). If the bug was fixed, it would likely > work out of the box. > > Unfortunately, it looks like fixing this bug is not possible. Even with > the internal firmware loader and if we were to enumerate available > firmware files before ever asking for them, hashed or not, a userland or > networked filesystem implementation could make a file listing available > that amounted to *installable* firmware rather than to *installed* > firmware, and then, once the kernel asks for a file, proceed to install > it, or ask the user to agree to have it installed. This sort of > kernel-directed request and installation is precisely what we wish to > avoid, and there doesn't seem to be any way to avoid it, and it's not > like the development of such an automated firmware installer is > far-fetched: AFAIK it has been done through hotplug scripts. > > -- > Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ > You must be the change you wish to see in the world. -- Gandhi > Be Free! -- http://FSFLA.org/ FSF Latin America board member > Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ----- End forwarded message ----- -- https://pragmatique.xyz PGP: https://people.pragmatique.xyz/ng0/
