[GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Therese Godefroy via RT]

Le Dim 21 Jan 2018 14:22:11, j...@jxself.org a écrit :
[...]
> I think we should wait for someone from the Licensing and Compliance
> Lab, or the FSF at large, to reply before making any changes to that page.
> 
> [0] https://www.gnu.org/server/standards/

OK Jason, I know all this. Nobody is going to change anything before you big 
guys tell us to.  :) 

Who is going to bring the issue to Licensing by the way? It has to be a 
qualified person, for instance someone from gnu-linux-libre. And since the 
Licensing people certainly don't have enough time to read the whole discussion, 
they will need to see the exact changes you feel are necessary, i.e. more or 
less what I was asking in my last message. Then, let's all cross our fingers, 
hoping they don't take too long to review them. I really feel it doesn't help 
the fully-free distros to advertise misleading information about them for 
months (if not years) in a row.

Best,
Thérèse 

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[bill-auger]

On 01/21/2018 02:22 PM, Jason Self wrote:
> I think we should wait for someone from the Licensing and Compliance
> Lab, or the FSF at large, to reply before making any changes to that page.

indeed - i meant only to show that even the clearly incorrect parts take
a long time to be changed - in contrast to the recent suggestions
somewhere along the lines of warnings about 15 year old web browsers
like "DANGER: here be dragons" - where there is comparatively far less
consensus or urgency

i seriously doubt the FSF would want to endorse a distro while at the
same time warning against its use - if that is the best solution so far
then this current topic probably deserves much more discussion



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Jason Self]

Therese Godefroy via RT  wrote ..

> I would be delighted to comment out Blag until it resurrects.

The free distro page is supposed to be maintained by the FSF's
Licensing and Compliance Lab, not the GNU Webmasters. Given that the
GNU Webmasters aren't supposed to add new distros [0] I would take
that to also include not removing them either. Commenting one out
could be seen as the equivalent of removing it since people would not
see it without examining the page source.

Given that the FSF adds the descriptions when adding the distros
making changes to their descriptions could be equally problematic.

I think we should wait for someone from the Licensing and Compliance
Lab, or the FSF at large, to reply before making any changes to that page.

[0] https://www.gnu.org/server/standards/

Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

Perhaps a more philosophical question is: *Should* a free program,
especially one used in FSF-endorsed distros, be generating requests
for proprietary programs in the first place? Regardless of how they
might be handled.

Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

> i must say though that it did not address what is the actual
> behavior preventing the debian kernel from being acceptable, 

I thought it did.

> why is it not possible to simply change or suppress the error
> message printed to the log or to later or periodically scrub the 
> logs of the naughty bits

Because the kernel is not necessarily responsible for all firmware
loading.

Alexandre mentioned this in:

> It's not just about the error messages, it's also about what the
> kernel actually requests of the userland helper script or the
> filesystem serving /lib/firmware, and how distros might configure
> the loader or the filesystem to respond to such requests.

Once the kernel has identified that a firmware is needed for something
then we've got the problem he mentioned:

> When the kernel starts the helper script, it's active telling a
> third-party program "get me a copy of the program foo.bin".

Being that the userland firmware loading program is a separate program
the kernel has no control over what it might do. Absolutely none. It
might log the request, which would be separate from the kernel
logging, and so even if the kernel's logging functionality were
changed in some way it would not have any impact on what this other
program is doing.

But, of course, it could be even worse than logging. It could, for
some examples:

* Display dialog boxes "Hey, this thing is missing. Do you to install
it?" This would be along the lines of how messages are shown about
missing audio/video codecs when you try to play a video. That is
probably even worse that logging because it's right up there, in your
face.

* Automatically download and install it without even asking anything.

* Who knows what else. Being that the userland firmware loading
program is a program, it could do anything that a program could do.
Even things that we aren't currently thinking of.

One might be tempted to say "well, the solution, then, is that -- in
addition to neutering the kernel's logging functionality -- to this to
get rid of the kernel's support for loading firmware from userland,
since it can access the file system directly anyway."

But that is already reducing the kernel's support for loading
firmware, which was part of the original complaint, and doesn't really
address the potential things that could happen: Another problem is
that /lib/firmware could be treated specially by the distro where any
& all of the kernel's attempts to access files there actually succeed
even if the files are not there (Alexandre mentioned the possibility
that the distro mounts /lib/firmware as a separate file system under
FUSE but that would not be the only possible way of doing this), and
then proceed to do exactly the same things that were mentioned as
being problems with the userland firmware helper. In this case another
program is *still* responsible for handling the request and the worse
part is that the kernel would probably not even know this.

Of course, some might be tempted to say that "OK, the solution, then,
is that -- in addition to neutering the kernel's logging functionality
and getting rid of the kernel's support for loading firmware from
userland, it should only try to load firmware when it's not mounted as
a separate file system. Or something." But at point you're starting to
reduce the kernel's ability to load firmware even further, which is
one of the issues that people have raised, and I don't know that there
is a way for the kernel to be able to know the attempt to access the
file system will be handled.

The fundamental problem is with firmware loading being outsourced to
separate programs, regardless of whether the kernel can detect that
this is happening or not. It might not even be able to detect it. And
the kernel has absolutely no control over what that separate program
does after the kernel has made the request via userland or attempted
to access it directly via the file system.

Of course, FSF-endorsed distros would never do any of these things but
Linux-libre is for use by everyone, even those on what Alexandre
called "hostile" distros, and all such cases need to be considered and
handled.

Given all of these possibilities the firmware loading problem may very
well be unsolvable. It's at least very difficult, which is why it
hasn't happened already.

Re: [GNU-linux-libre] add uruk gnu/linux

[alimiracle]

Having more than one distro Depends in same base A good idea
why?
- Ignite the spirit of competition
- Take advantage of the ideas for each distro
For example
 you the owner of the distro afraid to apply the idea
another Distro 
apply this  idea

If you find the idea good
u will apply this  idea
Anyway
uruk gnu/linux
is Different
you can find the Differents
useing uruk web site
and the blog