On Tue, 1 Aug 2023 01:58:10 -0400 bill-auger <bill-auger@peers.community> wrote:
> On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > > PureOS probably doesn't need to ship CPU microcode updates. > > that was why i mentioned it - that package is not part of pureos - it > is kept on a puri.sm server; so it never conflicted with the FSDG Even if it's software I don't think that it has been packaged, and if it is, it would probably be packaged for other distributions than PureOS (like Pureboot or other distributions that allow nonfree software). And this problem is not directly related to the FSDG. To put things into perspective, with computers that have 100% nonfree boot software (BIOS, UEFI), and/or that have ATI/AMD and Nvidia GPUs, users of FSDG distributions also run nonfree software. That software isn't provided by the distribution but it is bundled in the hardware. Here are two very common examples: - The boot software exports ACPI bytecode that the kernel runs. When the boot software is 100% nonfree, that bytecode is also nonfree. - Removable GPUs contain code that is run by the boot software (even if the boot software is free it still runs this code). Then the radeon/amdgpu/nouveau kernel drivers run some nonfree bytecode (called AtomBIOS for ATI/AMD) that is exported by these GPUs to initialize them. This also why there is a RYF certification: FSDG and RYF are complementary. So maybe you were trying to describe the fact that users are not informed about all that. And I think this is a real issue but the way to fix that is precisely to find ways to inform users as PureOS seems to do things correctly here. In fact you can even use PureOS on some RYF compliant computers. > puri.sm does have a desire to liberate the remaining blobs; but they > are a special case as a hardware vendor _and_ a distro - other > distros are not likely to ever liberate hardware Replicant liberates hardware. But it's also very different since it's an Android distribution. I applied for funding through NLnet again and part of the work will be to close more the gap between Android and GNU/Linux by improving collaboration with various upstream projects. > On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > > For Puri.sm hardware, Puri.sm can easily ship them in their Coreboot > > images instead, which are not part of PureOS. > > > > Though I wonder if/they update their Coreboot image. Maybe they have > > some way to do it that is outside PureOS. > > yes it looks like they have an coreboot/firmware update script, also > not part of pureos - i found some information: > > https://puri.sm/faq/what-is-the-difference-between-libreboot-and-my-librems-coreboot-firmware/ > https://puri.sm/projects/coreboot/ Thanks. > On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > > I think the key disagreement we have is if programming language > > repositories are useful or not. > > > > If we assume that they are useless, then they could indeed be > > removed and the problem would also go away. > > of course it is useful; but it is only a convenience for the distro to > distribute the package manager - they are very easy to acquire from > the same third-party - so regardless of utility, removing them from > distros is not a huge problem for anyone I think it depends: - After I removed rubygems in Parabola, most Ruby programs don't work anymore as import fail. There is probably a better way to do that though but I don't know how and I didn't have the time to look into it. - Guix probably uses these package managers for guix import, so simply removing them will affect that functionality, though there is probably a way to hide the package to users but still enable Guix import to use it. But here my point is that a rule to remove them all blindly won't work here. - Dragora and Guix are not FHS compliant, so users can't easily download these package manager from the programming language website and run them. - Not all programming language package manager easily be installed by users. With rust (rustup), python (pip), the tool is widely publicized and on the tool website there are instructions and a script to install it on top of a GNU/Linux distributions. But that might not be the case for all languages. I didn't find how to install rubygems for instance. All of these situations are not an issue anymore if these package managers point to FSDG compliant repositories. > On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > > I assume that they are badly needed, and that many users can't live > > without them and so they need fixing. > > i think what youre really getting at, is that people will use them > anyways, whether the distro provides it or not; so it is better to > use a more freedom-respecting version from the distro Here if we assume that they are not useful, then removing them does make sense as it fixes the distribution really fast and the problem goes away. But if we assume that they are useful, we get the opposite conclusion as freedom-respecting versions of these package managers is worth having I think. But alone, that reasoning by itself cannot tell what is more important between having the distributions fixed now and having the distributions fixed later and having freedom-respecting versions of these package managers. For that we need more context, users input, etc. > my counter-argument there, is that we do not know yet, if anyone > would use a libre-only version of pip or whatever - i looked at ruby > one time - roughly half of all packages were not licensed - that > means a libre-only version would be only half as useful I've had the use cases for the go package manager. I sometimes want to try some software like docker-registry that isn't packaged in any FSDG distribution, to see if it fit my use case. So without a programming language package manager I end up wasting lot of time packaging software just to test it, and I do that because it's faster to make a package than to build that software by hand. But making a package is order of magnitude slower than just typing one command like 'go get registry' to install and test it. And here at the end I found out that docker-registry wasn't as useful as I assumed it was. > a typical webby application setup will install about 100 dependencies > - if any one of them is unavailable, that is a total deal-breaker for > that person's use-case - most likely, the user will try to install > some webby thing, but some dependencies will not be available - so > that user, rather than decide not to install that webby thing, will > instead stop using the libre-only version, and install the upstream > version anyways What is a webby application? Is it something like mediawiki? Or is it some electron application? Or both? In any case if the application cannot be installed in the 100% free version of the programming language repository, it will signal the user that there is potentially a problem. If the user looks into it and finds nonfree dependencies, it would give the user power to fight back: - Even if the user is pushed to use that application as part of work, or collaboration in other structures, the user can more easily refuse to use it or refuse to make the organization depend on it on the basis that it doesn't work without nonfree software, similar to the Java Trap. The user could also raise legal issues and show that there is a problem, etc, pushing the organization to refuse to use it or depend on it. - The issue could be publicized in the hope that either the issue is fixed, or to give more leverage to people to resist against depending on that application. Instead without any information that proves that the application is nonfree people not wanting to depend on nonfree software would have a harder time convincing other people that there is indeed a very serious problem and that they are not paranoid or too strict. Here I would also have used that to understand if some web applications were really free software to warn people I know that were deploying them. > On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > > A way to find out here would be to understand if FSDG compliant > > distributions users really use third party software, and what kind > > of software they use. > > IMHO that was the most interesting goal of our experiment to remove > pip and rubygems - only a few people complained about pip - in > reality, more people objected before it was done, than who complained > afterward - people complained about rubygems, but only because it > prints a warning message to the shell, not because they wanted it back About rubygems I got only 1 complaint in person at the FOSDEM 2023. I also found after that it broke ruby packages so I now officially complain too (even if I did that change). Now these changes for programming languages were done in Parabola only, and there are distributions with more users (at least Trisquel) and more diverse user groups (Guix, Trisquel, PureOS) where such changes could have very different effects. > users of FSDG distros definitely use third-party software - typically > applications (AUR packages, appimages, flatpacks); so that concern > (who would miss them and why) could be considered as two broad > categories: (language library TPPMS, and application TPPMS) There are also games, in-applications plugins, etc. This issue touches a wide variety of software. > the language TPPMS are normally used for installing an enormous > number of packages; so they are notably worse - also the language > TPPMS are normally used by the more tech savvy people, who would have > no trouble installing the upstream's package manager if the distro > does not provide it I'm unsure if people wanting that are that tech savvy. If they aren't then pointing them to upstream documentation on how to install these upstream package managers (that have repositories with nonfree software) is not allowed by the FSDG for good reasons. Instead if we have FSDG compliant programming language package managers, and that they also release versions that can be installed on top of any distributions, then distributions like Parabola could simply point to installation instructions of these package managers. In addition it would make it easier for people to adopt them, including on top of non-FSDG compliant distributions. So they would be able to know if what they depend has nonfree dependencies or not etc. > the application TPPMS are normally used by non-technical users, for > installing a relatively small number of packages (though instide you > will probably find much more than a single application) - i see that > more often with LTS distro users, to get a newer version of an > application which is in the distro repos as an older version Fedora has an interesting approach where some of the packages of the newer versions of Fedora are also available as flatpak so they can be installed on top of LTS distributions. I personally would like the FSDG distributions to also do that so people can also get more recent FSDG compliant packages without upgrading everything. We already have Guix that can do that but it requires at least to know well the command line and to know of how GNU/Linux works to use it on top of another distribution as you'll need to handle the integration inside the distribution (like change the PATH, source files, etc). > i would much rather tell parabola users never to > use a flatpak or similar, but to grab a PKGBUILD from the AUR > instead, or make a packaging request For Parabola I advise users to: (1) Manually download from Aur the package definition and their package definition for the dependencies. That can be long though but (2) is longer anyway. (2) Review the freedom of all that (check licenses, check source code for suspicious things, check if the license is properly declared in the source code, etc). (3) Ideally send patches to Parabola to add all that in the PCR repository, so that everybody can install that software and know that it has got some sort of review. (4) Ideally from time to time send patches to update the packages to the latest versions. Without (3) and (4), it would not be that great as (1) and (2) can take quite some time for software with a lot of dependencies. Denis.
pgpSnEBt78SXz.pgp
Description: OpenPGP digital signature
