[GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
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)
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)
On 01/21/2018 02:08 PM, Therese Godefroy via RT wrote: > Now that the issue has been thoroughly discussed, could anyone on the > gnu-linux-libre write blurbs for the problematic distros im not convinced that there are any problematic distros other than blag - and even that one has been disputed are you actually able to modify the FSDG free distros page Therese? if so, may i note that there is one incontrovertible correction to that page to the "Ututo" entry that has been needed for a very long time - the specific text to change it to was requested by the Ututo maintainer about 6 months ago and no one yet has made that correction - see "=== Ututo ===" here --> https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-08/msg0.html signature.asc Description: OpenPGP digital signature
Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
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/
[GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
Le Sam 20 Jan 2018 14:10:25, luke...@lukeshu.com a écrit : [...] > I do agree that it would be good for distros intended for read-only > media to have that indicated on the page, but that could just be in > the distro description, I don't think they need to be moved to a > separate section. Now that the issue has been thoroughly discussed, could anyone on the gnu-linux-libre write blurbs for the problematic distros, to replace what's on /distros/free-distros.html? I certainly don't feel qualified to do this, but as a basic user I would be delighted to comment out Blag until it resurrects. Thanks in advance. Best, Thérèse
Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?
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?
> 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
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