unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* about this linux-libre 'bug' [Fwd: Re: question about a bug mention in an interview back in 2013]
@ 2017-05-11  7:41 ng0
  2017-05-12  5:46 ` Ricardo Wurmus
  0 siblings, 1 reply; 3+ messages in thread
From: ng0 @ 2017-05-11  7:41 UTC (permalink / raw)
  To: guix-devel

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/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: about this linux-libre 'bug' [Fwd: Re: question about a bug mention in an interview back in 2013]
  2017-05-11  7:41 about this linux-libre 'bug' [Fwd: Re: question about a bug mention in an interview back in 2013] ng0
@ 2017-05-12  5:46 ` Ricardo Wurmus
  2017-05-12 15:42   ` ng0
  0 siblings, 1 reply; 3+ messages in thread
From: Ricardo Wurmus @ 2017-05-12  5:46 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel


ng0 <ng0@pragmatique.xyz> writes:

> 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.

I don’t think the Guix documentation is the right place for this, but if
you want to add it please prepare a patch.  Otherwise this probably
won’t happen.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: about this linux-libre 'bug' [Fwd: Re: question about a bug mention in an interview back in 2013]
  2017-05-12  5:46 ` Ricardo Wurmus
@ 2017-05-12 15:42   ` ng0
  0 siblings, 0 replies; 3+ messages in thread
From: ng0 @ 2017-05-12 15:42 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Fri, 12 May 2017, Ricardo Wurmus wrote:

>
> ng0 <ng0@pragmatique.xyz> writes:
>
>> 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.
>
> I don’t think the Guix documentation is the right place for this, but if
> you want to add it please prepare a patch.  Otherwise this probably
> won’t happen.
>
> -- 
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>

Okay. It's probably better to leave it out then.
It's just that those are questions related to a piece
of software we use.. but maybe I should make improment
suggestions at the linux-libre website.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-05-12 15:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-11  7:41 about this linux-libre 'bug' [Fwd: Re: question about a bug mention in an interview back in 2013] ng0
2017-05-12  5:46 ` Ricardo Wurmus
2017-05-12 15:42   ` ng0

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).