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 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 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/ 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 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 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 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 that really puts in doubt how much liberation effort the TPPMs deserve - let alone to curate new libre-only repos, which maybe no one would use, because it is likely to be missing _something_ for every application 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 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) 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 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 for that reason alone, i would focus first on those (docker, flatpack, appimange, etc) - those are probably more desirable overall - i doubt if any parabola users would complain; because they can get all those applications from the AUR, so deleting them from parabola may not reveal any new information - a distro like trisquel would need to run that experiment so again, that work would be done primarily for other distros - parabola does not really need third-party application installers for twi reasons - A) parabola's application are the newest they can be - B) the AUR is a much better source for anything else, because the application gets built from source, and parabola has a native tool to build them easily - 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
