gnu-linux-libre
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Julie Marchant
Subject: Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
Date: Thu, 18 Jan 2018 01:20:45 -0500

On 2018年01月17日 16:32, Jason Self wrote:
> That's already a thing: One of the criteria in the GNU FSDG is that "to 
> be listed, a distribution should be actively maintained." When this has 
> come up in the past, the determination of being actively maintained was 
> said to rest with the distro maintainers and if *they* consider it to be 
> maintained or not (as opposed to, say, moving slowly.)

I think it would be a good idea for a well-defined standard to be
defined regarding whether a distro is current and maintained or not. I
agree that distros that don't get updated often shouldn't be excluded
from consideration, but something should be in place to ensure that the
distro's developer(s) is (are) still involved in the project. I think
security and compatibility implications should be considered, too; after
all, kernels stop working with new hardware and security vulnerabilities
happen. It wouldn't be very nice for someone to use BLAG based on the
FSF's recommendation, only to have their credit card information stolen
because of some old security vulnerability, or something.

I'd like to suggest the following rules as a rough draft:

1. The distro's maintainers should annually do one of the following: (a)
publish a new release; (b) publish a post summarizing work done on the
distro in the prior year which directly impacts the distros users (for
example, such a post could note important packages which have been
updated in the current release and what these updates mean to the
users); (c) write to the FSF to explain why no updates have been
necessary in the respective year (and, in particular, why the security
and hardware compatibility implications of this are unimportant).

2. The distro should ensure one of the following: (a) that all known
security vulnerabilities are fixed for users of the current release of
the distro in a reasonable timeframe; (b) that new, non-technical users
of the distro can see that it has or may have security vulnerabilities,
e.g. via a warning on the distro's website that security updates are not
always delivered.

3. The distro should either: (a) be reasonably expected to be compatible
with computers that can currently be bought from mainstream retailers;
(b) indicate on its website what hardware it is compatible with.

So, let's go through some of the distros and how they would be affected
by these rules:

* Trisquel, gNewSense, Dragora, GuixSD, PureOS, Parabola, and LibreCMC
would be mostly unaffected. Those that release less often than once a
year (e.g. Trisquel) would simply have to make annual posts summarizing
package updates to the current release. They don't need to talk about
all of it, just what the maintainers feel is significant. They can even
just make a quick, non-exhaustive list of packages that have been
updated if they want.

* BLAG would either have to get moving or fail the test. There haven't
been any updates to the "current" release for users, BLAG 140k, in
years, and the system is do doubt susceptible to multiple known security
vulnerabilities. It would likely end up removed.

* Dynebolic and Musix: the respective distro's maintainer would likely
send an email to the FSF every year noting that the lack of updates is
intentional and add a notice to the download page that it is not a
secure distro and should not be used to send sensitive information over
the Internet. It's meant for media editing and secondarily local jobs
like partitioning, so this would be easily justified. Alternatively, if
the maintainer has lost interest in maintaining the distro, it would end
up removed.

-- 
Julie Marchant
https://onpon4.github.io

Protect your emails with GnuPG:
https://emailselfdefense.fsf.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]