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

[bill-auger]

after some more prodding i was able to get the BLAG scripts to build
ISOs based on fedora and free-dora v27 for each of the openbox and LXDE
configurations for both i386 and x86_64 - the build does succeed without
the 'kernel-libre-firmware' package - the configs had, for some reason,
a glob *-firmware* blacklisted which was why it failed to load on v25 -
as far as i can tell, the only other important missing packages that may
have been in the BLAG repo are: 'blag-release', 'blag-release-notes',
and 'blag-logos' - i replaced these with 'fedora-release',
fedora-release-notes', and 'fedora-logos' to get the build to complete -
im not so familiar with fedora to know what these files represent; but
the LiveISO environment and anaconda installer are visibly branded as
fedora - the installer fails, however; but over-all, i would say that
BLAG is viable moving into the future

there is currently a licensing issue however - the only indication of
any license is a post install hook that tries to add a GPL file onto the
LiveISO; however this file is not found

  cp $INSTALL_ROOT/usr/share/doc/*-release/GPL $LIVE_ROOT/GPL

that 'GPL' file was presumably in the missing 'blag-release' package but
none of the "kickstart" files posted on the trisquel forum mention a
license - for this reason i think the blag repos would need to be
restored in order to make this project legit - the trisquel forum post
mentions that these "kickstart" files originally came from the BLAG FTP
site so perhaps there is something there that would properly indicate
the license of the "kickstart" files



signature.asc
Description: OpenPGP digital signature

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

[Alexandre Oliva]

On Jan 27, 2018, bill-auger  wrote:

> the scripts are based on a fedora v20 target system and require packages
> from corresponding versioned repos on fedora, freedora, and also a
> native blag repo - the fedora archives are still available but the
> oldest available freedora repo is v25 so that had to be the minimum
> target

Would you like me to dig up the Freed-ora 20 rpms and the blag-specific
rpms from backups?

> it would apparently not be possible to build blag (v.N+1) from a
> running blag (v.N) - i mention this because arguably this does not
> meet the FSDG self-hosting requirement

I can imagine it would be convenient, but I guess these scripts are
supposed to run within a mock buildroot or somesuch, as a last stage in
building the release's live and install images.  The buildroot is
populated with packages that have already been built or imported, in the
corresponding repositories.  The rpms in there are also built within
mock buildroots or equivalent, so it's all really self-hosted: the
buildroots and the build host running mock can be running different
versions, or even different distros.

> where i last left off, i got it to progress as far as the package
> loading phase when it choked on a package missing from the freedora
> repos named something like: 'linux-kernel-firmware' - perhaps this is
> just a renamed package - i have not looked into it any further

kernel-libre-firmware used to be built as part of kernel-libre, but
since 4.14-gnu (-ENOFIRMWARE) it was removed, since there was nothing
left.  I intend to build jxself's linux-libre-firmware to take its
place, but I haven't done that yet (vacations were too short ;-( :-)
However, kernel-libre-firware *is* available in the Freed-ora 25 repos:
that repo was discontinued before getting any 4.14 builds.  So it's
weird that the package couldn't be found.  Freed-ora 26 repos, OTOH,
only have 4.14 builds left, so you might expect this sort of error
there.  You sure you tried 25, not 26 or 27?  I guess whoever decides to
take up blag will have to sort that out.  Hopefully I'll have a newer
kernel-libre-firmware in place by then...

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

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

[bill-auger]

ok - so to steer us back on topic i can say that i tried to build blag
last week using the scripts posted a few months ago on the trisquel
forum - as to be expected, there were issues


the scripts are based on a fedora v20 target system and require packages
from corresponding versioned repos on fedora, freedora, and also a
native blag repo - the fedora archives are still available but the
oldest available freedora repo is v25 so that had to be the minimum
target - obviously though, the original blag repo
(ftp://blag.fsf.org/20/blag/$basearch/os/) is not available and it
is anyone's guess which packages were in this that will not be available
for a build today - and even if it were they may not be compatible as-is
with the other v25 repos

it has many inline commands to get the current fedora version of the
running system - i found most of them in hopes that i could hard-code a
version number but there must be others somewhere because some of the
repo URLS always correspond to the version of running fedora host - so i
absolutely had to build this on a fedora host of the corresponding
version number as the target blag (in this case fedora v25) - i.e. so it
would apparently not be possible to build blag (v.N+1) from a running
blag (v.N) - i mention this because arguably this does not meet the FSDG
self-hosting requirement

where i last left off, i got it to progress as far as the package
loading phase when it choked on a package missing from the freedora
repos named something like: 'linux-kernel-firmware' - perhaps this is
just a renamed package - i have not looked into it any further



signature.asc
Description: OpenPGP digital signature

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

[Luke Shumaker]

This thread is getting a bit off topic, but...

On Fri, 26 Jan 2018 00:49:33 -0500,
bill-auger wrote:
> i wll mention this next bit for completeness, only because no one else
> has yet; though luke alluded to it (lest this thread go irreversibly off
> topic) - that 'URL' stands for "universal resource locater" and 'URI'
> stands for "universal resource identifier" - that very plainly means
> that they are intended to refer to or identify, unambiguously, the
> single canonical location of a single definitive resource

That is wrong on 2 counts.  A URI is not necessarily canonical, and
it does not identify a location.

A URI identifies a resource... *somehow*.

A URL is a type of URI that identifies the resource by giving a
location for it.  That location is not necessarily unique, and it is
not necessarily canonical.  It's just a location that the resource
can be found at.

For URIs that are not URLs, the client must have a priori knowledge
about where and how to access the identified resource, because the URI
doesn't tell it; for example: "URN:ISBN:0-395-36341-1" uniquely
identifies Webster's II New Riverside Dictionary (1984 edition), but
tells a client nothing about how to retrieve it.  (For all URIs, the
client must have a priori knowledge about how to interpret the URI
scheme used by the URI; the scheme being identified by the bit before
the first colon; a registry of URI schemes is maintained by IANA.)

URIs using the "http" and "https" URI schemes are, of course, URLs.

-- 
Happy hacking,
~ Luke Shumaker

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

[bill-auger]

On 01/25/2018 01:28 PM, Ivan Zaigralin wrote:
> To clarify, I agree with you and Luke down below that www subdomain is nice 
> and useful. It's only the tacit assumption that www.whatever.com = 
> whatever.com that I find annoying :)
> 

you quoted me but i also suggested that it is inappropriate to assume
that every client asking for 'foo.com' should always get a World Wide
Web server - not even when that client is a web browser - imagine some
'FooNet' IRC server accessible via irc.foo.com - there may very well be
no website associated with that IRC network - so what should a web
browser see when they enter foo.com or www.foo.com - the answer is
nothing because there is no server responding to those URLs and there
does not need to be - not only are those 2 URLs not equivalent, but
there is no reason to assume that either of them will (or *should*)
respond to any request from any client

i wll mention this next bit for completeness, only because no one else
has yet; though luke alluded to it (lest this thread go irreversibly off
topic) - that 'URL' stands for "universal resource locater" and 'URI'
stands for "universal resource identifier" - that very plainly means
that they are intended to refer to or identify, unambiguously, the
single canonical location of a single definitive resource (such as a
text file or photo) - it was even imagined that this could avoid
duplicate instances of identical files across the world (i.e.
jquery.min.js would have one and only one canonical URL and any URL
referring to a "copy" could collapse into an alias for or be verified as
a faithful duplicate of the canonical published copy hosted by it's
publisher) - as luke said, a file-system directory was not conceived as
such a definitive resources and the index.html convention was added as a
convenience - but it is just a convention and does not imply that there
should be any resource waiting for retrieval at foo.com/index.html or
any other of the infinitely possible URLs, unless it refers explicitly
to some known published resource

of course the URL and HTTP abstractions are abused almost beyond
recognition today aside from servers that still serve only flat files;
and arguably RESTful resource schemas - many web developers would be
quite happy if javascript were the only programming language and their
website had only a single entry point into a javascript "app" that did
all of it's arbitrarily complex business, perhaps even providing
services that generally run on dedicated servers (such as chat, file
transfer, and email), while conspiring with any number of external
servers (perhaps even refusing to serve you unless some external
3rd-party "partner" approves or unless your browser executes all of
provided scripts without fail, scripts often served by a 3rd-party); all
without ever changing the URL



signature.asc
Description: OpenPGP digital signature

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

[Ivan Zaigralin]

To clarify, I agree with you and Luke down below that www subdomain is nice 
and useful. It's only the tacit assumption that www.whatever.com = 
whatever.com that I find annoying :)

On Wednesday, January 24, 2018 21:38:29 bill-auger wrote:
> 'www.' is indeed just a convention but it is not a "traditional" thing
> of the past that should go away - it's meaning is still as well defined
> and useful today as it ever was - sub-domains are very plainly a way to
> distinguish one machine or service from the various other services that
> may be offered under the base domain anme (which is often not associated
> with any server), and to allow each machine or service to have a it's
> own IP address (perhaps at different physical locations), while
> remaining semantically associated under the umbrella of the main domain name
> 
> in the case of the 'www.' sub-domain in 'http://www.foo.com', that
> clearly identifies the HTTP "World Wide Web" server of foo.com - as
> distinguished from it's FTP server ftp.foo.com, it's mail server
> smtp.foo.com, it's usenet server news.foo.com, and so on - some domains
> have only a web server and so there is no confusion if there is a 'www.'
> sub-domain or not; but to assume that as the default case is to assume
> that every client that asks for 'foo.com' should always get a World Wide
> Web server, which is to ignore the plethora of other services that can
> be offered under the same domain as well the possibility that foo.com
> may have no web server at all

signature.asc
Description: This is a digitally signed message part.

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

[Luke Shumaker]

On Wed, 24 Jan 2018 17:25:43 -0500,
Julie Marchant wrote:
> I get the impression that the whole trend of using the "www" subdomain
> came from Usenet hierarchies. Is that accurate?

It's important to understand that one host might not handle all of the
services associated with a domain.  The "A" record (or "" for
IPv6) is IP address(es) of primary host for that domain, but other
records may specify that some of the services for that domain are on
other hosts or addresses; for example, the MX record specifies a host
for handling email.

When building the World Wide Web, they didn't go through the process
of adding a WWW or WEB or something record type to DNS, and just
assumed that the web server for that domain would always be running on
the primary host for that domain.

Of course, some sysadmins didn't like that (running this weird new Web
thing on their core infrastructure!? egad!).  So, they'd deploy the
webserver on a separate host, and name that "www.DOMAIN".

Of course, the web became a killer-app of the Internet, and it became
weird to think that the "main" host of a domain did something other
than run a web server.

Today, we have generic SRV records so that you don't have to go
through the process of adding a DNS record type for new protocols (for
example, XMPP uses SRV).  There have been a few proposals to have HTTP
use that, and fall back to A/ records, but none have gone
anywhere.

> In any case, many websites these days don't do that anymore, and even
> when they did it was never necessary. So yeah, it's inaccurate to say
> that websites' URLs *should* have that prefix. Just optional fluff some
> people like to use.

Indeed.  It's optional fluff, but fluff that is nice for a couple of
reasons.

The "www." prefix is nice because it means to most people "this is a
thing you type in to your web browser", even if they know nothing
about technology; even more-so than "http://; or "https://; (which
also don't work as well verbally).  But that's probably not so much of
a concern for GNU distros ;-)

The "www." prefix is also nice because it lets you use a CNAME record
to manage which of your real hostnames is responsible for serving that
content, as you can't use a CNAME for the root of a domain.  (This is
why we use www. for Parabola.)  Though, some contend that this
practice is just an ugly hack around DNS servers' config file syntax
not having ways to define aliases that get resolved server-side, and
that this should be solved by pre-processing the config file.

-- 
Happy hacking,
~ Luke Shumaker

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

[Luke Shumaker]

On Thu, 25 Jan 2018 05:58:18 -0500,
Andrew Nesbit wrote:
> 
> On 25/01/2018 02:38, bill-auger wrote:
> 
> > in the case of the 'www.' sub-domain in 'http://www.foo.com', that 
> > clearly identifies the HTTP "World Wide Web" server of foo.com
> As a somewhat relevant side issue, what are the rules or conventions
> regarding URLs with unadorned directory or file components, like
> "http://www.foo.com;?
> 
> After reading up the other day, my understanding is that since a
> trailing slash indicates something like a directory resource depending
> on context, "http://www.foo.com; should canonically be represented as
> "http://www.foo.com/;.  The web server will resolve this "directory" to
> "http://www.foo.com/index.html; or something similar.  Do I understand
> correctly?

The "path" part of an URL starts at the first "/" after the initial
"://". (RFC 3986)

If there is no path in an HTTP URL (unless making an OPTIONS
request[1]) the default path is "/".  That is, without knowing a thing
about the server, the client can know that it can normalize
"http://www.foo.com; to "http://www.foo.com/;. (RFC 7230)

The path part of an URL is hierarchical in a way similar to your
filesystem; without knowing a thing about the server, the client may
normalize the path by removing "/foo/../" segments, "/./" segments,
and repeated slashes right next to eachother.  But in this hierarchy,
"foo" and "foo/" are not necessarily the same resource; it does not
get to add or remove a trailing slash. (RFC 3986, incorporated by RFC
7230).

HTTP has no concept of directories or files, just a hierarchy of
resources.  Of course, because of the similarity, an obvious
implementation strategy for HTTP servers is to have those HTTP
resources stored as files in a traditional *nix filesystem.  That has
a few consequences to consider:
 - "what to send when the path given is a directory?".  As `cat` will
   tell you on most *nixen, there's no obvious flat representation of
   a directory.  So, a *convention* for server implementations is to
   look for an "index.html" file in that directory, and assuming that
   that file is a reasonable HTML representation of the directory.
 - In the underlying *nix filesystem, presence or absence of a
   trailing slash when requesting a directory is equivalent; the
   filesystem will give the server the same thing either way.  But,
   the trailing slash will affect how the client interprets relative
   URLs in the resource's HTML representation.  So, to simplify
   writing relative URLs, when an HTTP server receives a request for a
   directory without a trailing slash, it will typically respond by
   sending back a 301 redirect to the version with a trailing slash
   (but some servers do it the other way around!).  (This also helps
   with SEO; it's generally bad to have 2 different URLs serving the
   same content.)
But these are both server implementation details, and are not general
truths about HTTP.

[1]: OPTIONS requests are a special case; for OPTIONS request having
 no path means "tell me things about the entire server", which is
 different than a "/" path, which means "tell me things about the
 '/' resource". (RFC 7231)

> What are the history and rules regarding this?  Is there an RFC or some
> other authoritative resource that explains it?

Modern HTTP 1.1 is defined in the RFC 723X series; RFC 7230 (Message
Syntax and Routing) includes the URI specification, but the
interpretation of that is deferred to RFC 7231 (Semantics and
Content).  Generic URI syntax is RFC 3986.

-- 
Happy hacking,
~ Luke Shumaker

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

[Andrew Nesbit]

On 25/01/2018 11:38, Jean Louis wrote:

> Good starting point with references is here:
> https://en.wikipedia.org/wiki/Subdomain
> 
> In general, if the owner of the website does not
> give you link with "www" such shall not be used
> and referred, especially if other link is simply
> working.

My message wasn't clear.  I was'nt referring to "www." or subdomains.  I
was referring to trailing slashes in URL's.

Andrew

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

[Jean Louis]

On Thu, Jan 25, 2018 at 10:58:18AM +, Andrew Nesbit wrote:
> On 25/01/2018 02:38, bill-auger wrote:
> 
> > in the case of the 'www.' sub-domain in 'http://www.foo.com', that 
> > clearly identifies the HTTP "World Wide Web" server of foo.com
> As a somewhat relevant side issue, what are the rules or conventions
> regarding URLs with unadorned directory or file components, like
> "http://www.foo.com;?
> 
> After reading up the other day, my understanding is that since a
> trailing slash indicates something like a directory resource depending
> on context, "http://www.foo.com; should canonically be represented as
> "http://www.foo.com/;.  The web server will resolve this "directory" to
> "http://www.foo.com/index.html; or something similar.  Do I understand
> correctly?
> 
> What are the history and rules regarding this?  Is there an RFC or some
> other authoritative resource that explains it?

Good starting point with references is here:
https://en.wikipedia.org/wiki/Subdomain

In general, if the owner of the website does not
give you link with "www" such shall not be used
and referred, especially if other link is simply
working.

Don'y you see the link above for Wikipedia, there
is no www inside there, but "en" as in
"en.wikipedia.org" so each website can have
unlimited number of subdomains be it "www" or
anything else.

It was just matter of habbit in beginning of
websites, to use "www.example.com" as hostname for
those servers serving over HTTP, but there is no
rule to it.

Jean

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

[bill-auger]

'www.' is indeed just a convention but it is not a "traditional" thing
of the past that should go away - it's meaning is still as well defined
and useful today as it ever was - sub-domains are very plainly a way to
distinguish one machine or service from the various other services that
may be offered under the base domain anme (which is often not associated
with any server), and to allow each machine or service to have a it's
own IP address (perhaps at different physical locations), while
remaining semantically associated under the umbrella of the main domain name

in the case of the 'www.' sub-domain in 'http://www.foo.com', that
clearly identifies the HTTP "World Wide Web" server of foo.com - as
distinguished from it's FTP server ftp.foo.com, it's mail server
smtp.foo.com, it's usenet server news.foo.com, and so on - some domains
have only a web server and so there is no confusion if there is a 'www.'
sub-domain or not; but to assume that as the default case is to assume
that every client that asks for 'foo.com' should always get a World Wide
Web server, which is to ignore the plethora of other services that can
be offered under the same domain as well the possibility that foo.com
may have no web server at all



signature.asc
Description: OpenPGP digital signature

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

[Ivan Zaigralin]

This is my understanding as well. In a way, www subdomain is a total nuisance. 
It is entirely traditional, but now every web user expects a redirect, 
consciously or not, so that they can use example.com in lieu of 
www.example.com, and still end up in the same place. But this doesn't "just 
happen" on the DNS level; this is an explicit entry/redirect, and it always 
has to be set up (although many web hosting providers will typically do it for 
their clients). You can google (yes, this puppy is ready for genericide) for 
"www domain redirect" to see countless reports of neophyte webmasters seeing 
the problem for the first time and asking WTF.

For example, these are different:

http://ntp.org/
http://www.ntp.org/

This is the generic behavior: www.ntp.org is a different domain name, and it 
may well be bound to some other IP address in the DNS, or even be undefined.

So in conclusion I would recommend citing URLs provided by the respective 
distribution maintainers. Appending or removing "www." without their explicit 
approval is simply wrong, and coercing maintainers to register and redirect a 
www subdomain would be even more uncalled for.

On Wednesday, January 24, 2018 17:25:43 Julie Marchant wrote:
> I get the impression that the whole trend of using the "www" subdomain
> came from Usenet hierarchies. Is that accurate?
> 
> In any case, many websites these days don't do that anymore, and even
> when they did it was never necessary. So yeah, it's inaccurate to say
> that websites' URLs *should* have that prefix. Just optional fluff some
> people like to use.
> 
> --
> Julie Marchant
> https://onpon4.github.io
> 
> Protect your emails with GnuPG:
> https://emailselfdefense.fsf.org

signature.asc
Description: This is a digitally signed message part.

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

[Adonay Felipe Nogueira]

If I recall correctly the use of "www" is for some load balancing
purposes, where the domain owner could set the page-only content of his
site to "www" subdomain and have the main domain redirect to "www",
while the site contet itself could refer to a separate subdomain like
"images" in the main domain, and in such subdomain have a more
elaborated storage or setup. This avoids the need to aquire a full
domain for reference of the other storage of things.

I don't want to advertise non-free JavaScript, nor centralized and
non-federated services, but I think some calls YouTube pages do actually
refer to somethings under a domain called "ything", but are actually
part of YouTube.

2018-01-24T17:25:43-0500 Julie Marchant wrote:
> I get the impression that the whole trend of using the "www" subdomain
> came from Usenet hierarchies. Is that accurate?
>
> In any case, many websites these days don't do that anymore, and even
> when they did it was never necessary. So yeah, it's inaccurate to say
> that websites' URLs *should* have that prefix. Just optional fluff some
> people like to use.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

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

[Therese Godefroy via RT]

Le Mer 24 Jan 2018 16:40:23, s...@dragora.org a écrit :
[...]
> Please do not do that, linking to the full address.. because the current
> website is running under Fossil[1], and we migrate the project to Git
> (again) under Savannah[2][3], the migration to a new website is pending,
> I have to plans to make a new one soon.

The change has been reverted.

> > There is a problem with http://www.ututo.org/. The request is
> > apparently rewritten to HTTPS, then fails because the certificate is
> > invalid (I am using Abrowser _without_ HTTPS-everywhere). Connection
> > is still possible with a more permissive browser (NetSurf), after
> > accepting the certificate. Judging from the error message, it seems
> > that Ututo is hosted by Trisquel.
> 
> You can try to contact with Diego Saravia:
> diego.saravia[@]gmail dot com

Thanks for the tip.

So it seems we are all set. I will contact Licensing with this draft tomorrow.

Bye everybody,
Thérèse

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

[Julie Marchant]

I get the impression that the whole trend of using the "www" subdomain
came from Usenet hierarchies. Is that accurate?

In any case, many websites these days don't do that anymore, and even
when they did it was never necessary. So yeah, it's inaccurate to say
that websites' URLs *should* have that prefix. Just optional fluff some
people like to use.

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

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




signature.asc
Description: OpenPGP digital signature

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

[Matias Fonzo]

On Wed, 24 Jan 2018 22:47:04 +0100
Jean Louis  wrote:

> On Wed, Jan 24, 2018 at 11:29:52AM -0500, Therese Godefroy via RT
> wrote:
> > > Description", if the intention is to read the full description
> > > from website project.  
> > 
> > Done.
> >
> > > Also, to keep more uniform the links for the project websites, it
> > > would be good if starts with 'www.' for the links that do not
> > > have it.  
> > 
> > I checked all the links. They all correspond to the URL you
> > actually get. Several of them don't have www. The only one I
> > changed is https://dragora.org -->
> > https://dragora.org/repo.fsl/doc/trunk/www/index.md (but the
> > redirection is automatic anyway). I also changed http to https when
> > https did work.  
> 
> Please note that there is absolutely no rule by
> standards that a website shall have "www." as
> subdomain name.
> 
> Website may respond only with its domain name,
> such as example.com or with any subdomain as
> any.example.com and need not have www at all.

For the most cases out there, you don't want to left the prefix
for 'www' ;-)

> So it is incorrest to say "it would be good if
> links start with 'www'" -- for links which do not
> have eventually www, if they have it alright, but
> one shall have the link that distribution author
> designates, and if it has no www, than no www
> shall be used.

I don't know which sites are supporting the prefix, I was trying to
make a simple suggestion to make it look more "formal".

> It is a host name, and that host name may be
> there, may be not, it may be used as plain domain
> name or with any host name.
> 
> So assumption that www exists is incorrect. One
> must ask the website owner which hostname they
> wish to use.
> 
> Jean
> 

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

[Jean Louis]

On Wed, Jan 24, 2018 at 11:29:52AM -0500, Therese Godefroy via RT wrote:
> > Description", if the intention is to read the full description from
> > website project.
> 
> Done.
>  
> > Also, to keep more uniform the links for the project websites, it would
> > be good if starts with 'www.' for the links that do not have it.
> 
> I checked all the links. They all correspond to the URL you actually get. 
> Several of them don't have www. The only one I changed is 
> https://dragora.org
> --> https://dragora.org/repo.fsl/doc/trunk/www/index.md
> (but the redirection is automatic anyway).
> I also changed http to https when https did work.

Please note that there is absolutely no rule by
standards that a website shall have "www." as
subdomain name.

Website may respond only with its domain name,
such as example.com or with any subdomain as
any.example.com and need not have www at all.

So it is incorrest to say "it would be good if
links start with 'www'" -- for links which do not
have eventually www, if they have it alright, but
one shall have the link that distribution author
designates, and if it has no www, than no www
shall be used.

It is a host name, and that host name may be
there, may be not, it may be used as plain domain
name or with any host name.

So assumption that www exists is incorrect. One
must ask the website owner which hostname they
wish to use.

Jean

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

[Matias Fonzo]

On Wed, 24 Jan 2018 11:29:52 -0500
"Therese Godefroy via RT"  wrote:

> Thanks for your input.

No problem.
 
> Le Mer 24 Jan 2018 08:30:54, s...@dragora.org a écrit :
>  
> > I suggest changing the field title "Description" to "Brief
> > Description", if the intention is to read the full description from
> > website project.  
> 
> Done.
>  
> > Also, to keep more uniform the links for the project websites, it
> > would be good if starts with 'www.' for the links that do not have
> > it.  
> 
> I checked all the links. They all correspond to the URL you actually
> get. Several of them don't have www. The only one I changed is
> https://dragora.org -->
> https://dragora.org/repo.fsl/doc/trunk/www/index.md (but the
> redirection is automatic anyway). I also changed http to https when
> https did work.

Please do not do that, linking to the full address.. because the current
website is running under Fossil[1], and we migrate the project to Git
(again) under Savannah[2][3], the migration to a new website is pending,
I have to plans to make a new one soon.

[1] http://fossil-scm.org
[2] http://git.savannah.nongnu.org/cgit/dragora.git/
[3] http://git.savannah.nongnu.org/cgit/dragora/olddragora.git/
 
> There is a problem with http://www.ututo.org/. The request is
> apparently rewritten to HTTPS, then fails because the certificate is
> invalid (I am using Abrowser _without_ HTTPS-everywhere). Connection
> is still possible with a more permissive browser (NetSurf), after
> accepting the certificate. Judging from the error message, it seems
> that Ututo is hosted by Trisquel.

You can try to contact with Diego Saravia:
diego.saravia[@]gmail dot com

> 
> Draft at https://www.gnu.org/server/staging/free-distros.html
> 

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

[Therese Godefroy via RT]

Hello Matias, hello Denis,

Thanks for your input.

Le Mer 24 Jan 2018 08:30:54, s...@dragora.org a écrit :
 
> I suggest changing the field title "Description" to "Brief
> Description", if the intention is to read the full description from
> website project.

Done.
 
> Also, to keep more uniform the links for the project websites, it would
> be good if starts with 'www.' for the links that do not have it.

I checked all the links. They all correspond to the URL you actually get. 
Several of them don't have www. The only one I changed is 
https://dragora.org
--> https://dragora.org/repo.fsl/doc/trunk/www/index.md
(but the redirection is automatic anyway).
I also changed http to https when https did work.

There is a problem with http://www.ututo.org/. The request is apparently 
rewritten to HTTPS, then fails because the certificate is invalid (I am using 
Abrowser _without_ HTTPS-everywhere). Connection is still possible with a more 
permissive browser (NetSurf), after accepting the certificate. Judging from the 
error message, it seems that Ututo is hosted by Trisquel.

Draft at https://www.gnu.org/server/staging/free-distros.html

Thérèse
 

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

[Matias Fonzo]

Hello,

On Wed, 24 Jan 2018 07:34:23 -0500
"Therese Godefroy via RT"  wrote:

> Le Lun 22 Jan 2018 05:15:43, godef...@free.fr a écrit :
> [...]
> > I don't think it's a good idea to dump such a long thread on them.
> > The request would certainly go directly to the bottom of their todo
> > list and stay there. It would be more efficient to give them a few
> > lines of explanation, along with a diff. As I said, the
> > gnu-linux-libre people are the most qualified to do this.  
> 
> Hi all,
> 
> After looking more closely at the free-distros page, I found many
> more things that need fixing: redundant or misplaced sentences, need
> for sections and table of contents, styling, etc. I'd like to have
> your feedback on the draft in staging:
> https://www.gnu.org/server/staging/free-distros.html
> 

I suggest changing the field title "Description" to "Brief
Description", if the intention is to read the full description from
website project.

Also, to keep more uniform the links for the project websites, it would
be good if starts with 'www.' for the links that do not have it.

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

[Jaromil]

dear Therese,

On Wed, 24 Jan 2018, Therese Godefroy via RT wrote:

> After looking more closely at the free-distros page, I found many
> more things that need fixing: redundant or misplaced sentences, need
> for sections and table of contents, styling, etc. I'd like to have
> your feedback on the draft in staging:
> https://www.gnu.org/server/staging/free-distros.html



it looks good to me, many thanks for your attention to details!


ciao

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

[Therese Godefroy via RT]

Le Lun 22 Jan 2018 05:15:43, godef...@free.fr a écrit :
[...]
> I don't think it's a good idea to dump such a long thread on them. The
> request would certainly go directly to the bottom of their todo list
> and stay there. It would be more efficient to give them a few lines of
> explanation, along with a diff. As I said, the gnu-linux-libre people
> are the most qualified to do this.

Hi all,

After looking more closely at the free-distros page, I found many more things 
that need fixing: redundant or misplaced sentences, need for sections and table 
of contents, styling, etc. I'd like to have your feedback on the draft in 
staging:
https://www.gnu.org/server/staging/free-distros.html

Thanks.

Best regards,
Thérèse

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

[Therese Godefroy via RT]

Le Dim 21 Jan 2018 19:12:11, js...@gnu.org a écrit :
> One way is that this ticket can be moved into the licensing queue with
> ideas/feedback/suggestions added.

Hi Jason,

I don't think it's a good idea to dump such a long thread on them. The request 
would certainly go directly to the bottom of their todo list and stay there. It 
would be more efficient to give them a few lines of explanation, along with a 
diff. As I said, the gnu-linux-libre people are the most qualified to do this.

Best,
Thérèse

[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] [gnu.org #1262331] (inactive Linux distributions)

[Alexandre Oliva]

On Jan 17, 2018, bill-auger  wrote:

> blag actually has no software available - the download links on their
> website have not worked in a very long time because (as ive heard) the
> files were lost

The server was broken into and then brought down, IIUC.  There are
backups, so nothing was really lost, but for some reason the server has
never been reinstalled and brought back up to make the files available
for web download again.  I think they might still be available as
torrents, if one can find a seeder.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

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

[Alexandre Oliva]

On Jan 19, 2018, Caleb Herbert  wrote:

> wouldn't dropping them from the list act as a wake-up call
> to hurry up?

Maybe that would be too drastic.  After all, even if old and
unmaintained, it's still Free Software.  Perhaps we'd be better off
breaking up the section of self-hosted distros into multiple sections,
so that there could be one section for Live distros that are supposed to
be used in read-only media and don't get updates, like dyne:bolic and
Musix, and one for distros that are in need of contributors to issue
newer releases and even updates like BLAG.  The latter section would be
the wake-up call, and if a distro remained too long in there, then it
gets removed.  It would also get users better information, and avoid
giving users the idea that distros in the list are outdated just because
they hit the one or two that really are.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

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

[Therese Godefroy via RT]

Hello Jaromil,

Le Ven 19 Jan 2018 09:41:10, jaro...@dyne.org a écrit :
> On Fri, 19 Jan 2018, Therese Godefroy via RT wrote:
> 
> > Besides, it's very easy to do: when a distro becomes "dangerously"
> > unmaintained (meaning no security updates, unless it is never used
> > on the net), just comment out the corresponding entry in
> > /distros/free-distros.html and /help/gnu-bucks.html (+ whatever page
> > I don't know about). When the distro is active again, restore the
> > entry.
> 
> please note that the bounty we all accepted is regarding the fact
> distros are 100% free. But I do agree with the other suggestion of
> listing known bugs, just like should be done in any software.
[...]

Please note that, when I wrote this, I wasn't thinking ot Dyne:bolic. An 
earlier post on gnu-linux-libre [0] made clear that the only distro which 
currently may be said to be "dangerously" unmaintained is BLAG. Being free is a 
plus, but I don't think it's a good idea to recommend a distro that doesn't 
provide up-to-date security patches.

What I most object to is advertising an outdated distro which isn't meant to be 
used offline to people who know nothing about GNU/Linux distros, let alone bug 
lists. One of these persons might push the prominent button on the home page of 
gnu.org, reach free-distros.html, install the first distro on the list (which 
happens to be BLAG), and find out the hard way that the browser still contains 
a bad security flaw which got patched in later versions. Do you think it will 
help the cause of free software? Fortunately, this is just a bad dream. This 
person will be unable to install BLAG because the repo can't be reached 
anymore. But this won't help the cause of FS either.

That said, I am very grateful to people like you who maintain fully free 
distros.

Best regards,
Thérèse

[0] https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-01/msg4.html

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

[Jaromil]

On Fri, 19 Jan 2018, Therese Godefroy via RT wrote:

> Besides, it's very easy to do: when a distro becomes "dangerously"
> unmaintained (meaning no security updates, unless it is never used
> on the net), just comment out the corresponding entry in
> /distros/free-distros.html and /help/gnu-bucks.html (+ whatever page
> I don't know about). When the distro is active again, restore the
> entry.

please note that the bounty we all accepted is regarding the fact
distros are 100% free. But I do agree with the other suggestion of
listing known bugs, just like should be done in any software.

people here before saying that they should solicit us to work more,
faster and better, should also consider we do all this for free as
voluntary work that (IMHO) should to be helped and facilitated by
organisations like the FSF. We are working very hard and with a
specialisation that often not even the FSF is able to provide, all for
free and without claiming any of the amounts of donations that the FSF
already receives to.. do what? tell us we are not working enough for
free? then let the labor issues kick in...

honestly yours, running a non-profit foundation in Europe since more
than 15 years here, maintaining dyne:bolic free of charge for
everyone, planning with colleagues even new 100% free distros, and we
are affiliated to FSFE. So I'd ask here a bit of support please and at
least an attitude that considers we are all on the same ship, not
ought to throw each other overboard when we don't row at the same
rythm (and with very different sustainability plans...)


ciao

-- 
  Denis Roio a.k.a. Jaromil  http://Dyne.org think  tank
  Ph.D, CTO & co-foundersoftware to empower communities
  ⚷ crypto κρυπτο крипто गुप्त् 加密 האנוסים المشفره
  GnuPG: 6113D89C A825C5CE DD02C872 73B35DA5 4ACB7D10
  opmsg:73a8e097a038d82b 8afb4c05804bda0d 281b3880fbc19b88

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

[Jaromil]

Hi everyone,

this conversation keeps coming back constantly, may we have a FAQ
about this? In a previous mail to this list I've stressed some aspects
about the perception of what is "actively maintained" and what not.

For now I confirm that dyne:bolic is active. We are very busy working
on a foundation for version 4 (Devuan) that can be 100% free (like
heads.dyne.org) and has a "cleaned up" repository (thanks to a new
software "amprolla" which does a "server side pin" of deb packages.

These days I'm just testing the desktop environment which will perhaps
be Moksha (big up to Bodhilinux for maintaining this fork of E17!) and
you'll see a new release this year.

I take the occasion to wish you all Happy New Year!


-- 
  Denis Roio a.k.a. Jaromil  http://Dyne.org think  tank
  Ph.D, CTO & co-foundersoftware to empower communities
  ⚷ crypto κρυπτο крипто गुप्त् 加密 האנוסים المشفره
  GnuPG: 6113D89C A825C5CE DD02C872 73B35DA5 4ACB7D10
  opmsg:73a8e097a038d82b 8afb4c05804bda0d 281b3880fbc19b88

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

[Therese Godefroy via RT]

Le Ven 19 Jan 2018 04:25:56, c...@bluehome.net a écrit :
> 
> > For some examples my understanding is that people are working on BLAG, 
> > and Dragora has published a new beta version for 3.0. It seems better to 
> > try to support such efforts instead of dropping them. We need more people 
> > working on 100% free distros, not less. :)
> 
> It is true that we need to encourage people to keep working on free
> systems, but wouldn't dropping them from the list act as a wake-up call
> to hurry up?  "Uh-oh, they took us off the list.  We need to release
> something fast to get back on the list!"
 

Hello,

This sounds like a good idea for The Great and Wise ol' Gnu (TM) to chew on.

Besides, it's very easy to do: when a distro becomes "dangerously" unmaintained 
(meaning no security updates, unless it is never used on the net), just comment 
out the corresponding entry in /distros/free-distros.html and 
/help/gnu-bucks.html (+ whatever page I don't know about). When the distro is 
active again, restore the entry.

This is how the mirror list is maintained, by the way, although for mirrors the 
procedure is more complicated.

Also, I think the short descriptions in /distros/free-distros.html should say 
something about the type of maintenance. When a distro is "static" and 
shouldn't be used on the net, it should say so.

Best,
Thérèse

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

[Caleb Herbert]

> For some examples my understanding is that people are working on BLAG, 
> and Dragora has published a new beta version for 3.0. It seems better to 
> try to support such efforts instead of dropping them. We need more people 
> working on 100% free distros, not less. :)

It is true that we need to encourage people to keep working on free
systems, but wouldn't dropping them from the list act as a wake-up call
to hurry up?  "Uh-oh, they took us off the list.  We need to release
something fast to get back on the list!"

-- 
Caleb Herbert
OpenPGP public key: http://bluehome.net/csh/pubkey


signature.asc
Description: This is a digitally signed message part

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

[Julie Marchant]

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



signature.asc
Description: OpenPGP digital signature

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

[Adonay Felipe Nogueira]

I recall seeing a Trisquel forum post about some BLAG 20 Alpha
Kickstart files ([1]), it seems that forum post has the attachment which
has the files inside.

It's somewhat different/unusual for a distro to rely on the forum of
another to post its own files (:S) ... But let's consider that as OK for
now, perhaps one can still make use of the files.

[1] .

2018-01-17T16:46:30-0500 bill-auger wrote:
> where is this ticket that you reference? gnu.org #1262331 - it is not on
> the CC list - is that a on public tracker?
>
> i asked this question myself when i did a review of the FSDG distros
> list last summer[1] noting that proteanos appears to be inactive as well
> - still today there has been no response on either of the blag or
> proteanos mailing lists[2][3] - six months with no response to a simple
> question like "is this project still active?" should indicate a negative
> answer
>
> my opinion however, is that there is no reason to remove a distro from
> the list only for being unmaintained - if it works: it works - and
> always will - but the case with blag is something different - blag
> actually has no software available - the download links on their website
> have not worked in a very long time because (as ive heard) the files
> were lost - "blag" exists in reality only in the form of it's website -
> so there literally is no blag distribution by nature of the fact that
> there is nothing being distributed - so i still suggest that blag be
> removed (or perhaps moved to a new "honerable mentions" section) - but
> if proteanos is still available and viable software then there is no
> reason to remove it merely because it is un-supported
>
>
> there is an evaluation process for adding new distros - uruk has
> requested consideration about a year ago and it fell short of FSDG
> standards at that time; but they are improving it and the discussion is
> still open[4]
>
>
> it was this comment that prompted me to respond - as mentioned above, i
> looked into the current status of all of the FSDG distro last summer and
> i can not concour with Le Dim's evaluation
>
> dragora has been very active in recent months working on the next
> release - far from being inactive, if all FSDG distros were ranked today
> according to development activity, i would place dragora in second place
> closely behind parabola with trisquel a more distant third - of course,
> to put into persoective, parabola, being a rolling release distro
> requires a far greater amount of routine maintenance just to remain sane
> where the other FSDG distros are LTS and designed to require only
> high-priority stability/security upgrades - that is only to say that
> some distros require more or less maintenance than others
>
> the developer of dynebolic is still as active as ever in the dyne
> project and is planning for the next release of dynebolic to be based on
> devuan once the devuan-sdk is completed
>
> the musix developer is also still in contact with it's community and is
> planning the next release[5]
>
> the important thing to note is that regardless of whatever development
> activity is immediately apparent, the current releases of dragora,
> dynebolic, and musix are still available and viable, functioning
> perfectly as intended; and their developers are still in communication
> with the community - this is an especially important factor to consider
> in regards to "Live" distros such as dynebolic and musix which are
> static by design (i.e. they are intended to be run directly from the
> read-only medium and never installed nor upgraded) - the fact that the
> operating system is guaranteed never to change a bit from one boot to
> the next is among the most desirable features of these distros - they
> are not the typical sort of distro that require any intermediate
> maintenance nor is that even possible; so such a distro can not
> reasonably be said to be "inactive"; because they are designed to be
> fixed in form ("carved in stone" if you will) - the project itself could
> be be deemed dormant or inactive; as in: "we can probably not expect
> version N+1"; but that says nothing of the efficacy of any current
> available versions
>
>
> [1]:
> https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-08/msg0.html
> [2]: https://lists.aktivix.org/pipermail/blag-whereto/2017-July/thread.html
> [3]: http://lists.proteanos.com/proteanos-dev/2017/08/
> [4]:
> https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-12/msg3.html
> [5]: https://musixdistro.wordpress.com/

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, 

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

[bill-auger]

On 01/17/2018 06:42 PM, Jason Self wrote:
> They wouldn't. I imagine that the webmasters will handle the replying of 
> email that's sent to them? Maybe this was sent as food for thought or 
> something?
> 

hm - i would have expected fewer question marks in that response
considering the number of times i have seen printed on the GNU website
that you are the "chief" GNU webmaster - is that a position you have
resigned or more of a honorary title?

in any case, as long as The Great and Wise ol' Gnu chews on my ideas, i
am happy to feed him :)



signature.asc
Description: OpenPGP digital signature

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

[Jason Self]

bill-auger  wrote ..
> then the obvious question would be if the OP will see these replies if
> they are not subscribed to this mailing list

They wouldn't. I imagine that the webmasters will handle the replying of 
email that's sent to them? Maybe this was sent as food for thought or 
something?

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

[bill-auger]

On 01/17/2018 05:30 PM, Jason Self wrote:
> It's a ticketing system used to handle certain email addresses like 
> webmast...@gnu.org (and more), which seems to be where the person 
> originally wrote to.
> 

then the obvious question would be if the OP will see these replies if
they are not subscribed to this mailing list



signature.asc
Description: OpenPGP digital signature

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

[Jason Self]

bill-auger  wrote ..
> where is this ticket that you reference? gnu.org #1262331 - it is not 
> on the CC list - is that a on public tracker?

It's a ticketing system used to handle certain email addresses like 
webmast...@gnu.org (and more), which seems to be where the person 
originally wrote to.

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

[bill-auger]

On 01/17/2018 04:32 PM, 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."
i would strongly suggest that guideline be changed to require the distro
only to be available and functional and to remove it only if it were
found to contain something malicious or non-free - as i pointed out in
my previous post, "Live" distros such as dynebolic are intentionally
designed to be forever static in form and never modified; but only
replaced entirely with a new release (or not) - the FSDG does not
require that a new release be perpetually forth-coming; and this FSDG
guideline jason mentions, if strictly applied, would exclude dynebolic
and musix from endorsement by their very nature of not being amenable to
"maintenance"



signature.asc
Description: OpenPGP digital signature

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

[bill-auger]

where is this ticket that you reference? gnu.org #1262331 - it is not on
the CC list - is that a on public tracker?

On 01/17/2018 11:45 AM, Therese Godefroy via RT wrote:
> Should a distro that hasn't been maintained for several years be
listed in free-distros.html, especially if it is based on a major distro
which itself isn't maintained anymore? I am thinking of Blag, based on
Fedora 10 (2010).

i asked this question myself when i did a review of the FSDG distros
list last summer[1] noting that proteanos appears to be inactive as well
- still today there has been no response on either of the blag or
proteanos mailing lists[2][3] - six months with no response to a simple
question like "is this project still active?" should indicate a negative
answer

my opinion however, is that there is no reason to remove a distro from
the list only for being unmaintained - if it works: it works - and
always will - but the case with blag is something different - blag
actually has no software available - the download links on their website
have not worked in a very long time because (as ive heard) the files
were lost - "blag" exists in reality only in the form of it's website -
so there literally is no blag distribution by nature of the fact that
there is nothing being distributed - so i still suggest that blag be
removed (or perhaps moved to a new "honerable mentions" section) - but
if proteanos is still available and viable software then there is no
reason to remove it merely because it is un-supported


On 01/17/2018 11:45 AM, Therese Godefroy via RT wrote:
> Conversely, if unmaintained distros are listed, is there any good
reason not to list a new one, which clearly is actively maintained (Uruk)?

there is an evaluation process for adding new distros - uruk has
requested consideration about a year ago and it fell short of FSDG
standards at that time; but they are improving it and the discussion is
still open[4]


On 01/17/2018 11:45 AM, Therese Godefroy via RT wrote:
> Le Dim 31 Déc 2017 15:50:11, anonym...@foto.nl1.torservers.net a écrit :
>> BLAG is inactive
>> Dragora GNU Linux-Libre is inactive
>> Dynebolic is inactive
>> Musix is inactive


it was this comment that prompted me to respond - as mentioned above, i
looked into the current status of all of the FSDG distro last summer and
i can not concour with Le Dim's evaluation

dragora has been very active in recent months working on the next
release - far from being inactive, if all FSDG distros were ranked today
according to development activity, i would place dragora in second place
closely behind parabola with trisquel a more distant third - of course,
to put into persoective, parabola, being a rolling release distro
requires a far greater amount of routine maintenance just to remain sane
where the other FSDG distros are LTS and designed to require only
high-priority stability/security upgrades - that is only to say that
some distros require more or less maintenance than others

the developer of dynebolic is still as active as ever in the dyne
project and is planning for the next release of dynebolic to be based on
devuan once the devuan-sdk is completed

the musix developer is also still in contact with it's community and is
planning the next release[5]

the important thing to note is that regardless of whatever development
activity is immediately apparent, the current releases of dragora,
dynebolic, and musix are still available and viable, functioning
perfectly as intended; and their developers are still in communication
with the community - this is an especially important factor to consider
in regards to "Live" distros such as dynebolic and musix which are
static by design (i.e. they are intended to be run directly from the
read-only medium and never installed nor upgraded) - the fact that the
operating system is guaranteed never to change a bit from one boot to
the next is among the most desirable features of these distros - they
are not the typical sort of distro that require any intermediate
maintenance nor is that even possible; so such a distro can not
reasonably be said to be "inactive"; because they are designed to be
fixed in form ("carved in stone" if you will) - the project itself could
be be deemed dormant or inactive; as in: "we can probably not expect
version N+1"; but that says nothing of the efficacy of any current
available versions


[1]:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-08/msg0.html
[2]: https://lists.aktivix.org/pipermail/blag-whereto/2017-July/thread.html
[3]: http://lists.proteanos.com/proteanos-dev/2017/08/
[4]:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-12/msg3.html
[5]: https://musixdistro.wordpress.com/




signature.asc
Description: OpenPGP digital signature

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

[Jason Self]

Therese Godefroy via RT  wrote ..
> Should a distro that hasn't been maintained for several years be listed 
> in free-distros.html, especially if it is based on a major distro which 
> itself isn't maintained anymore? I am thinking of Blag, based on Fedora
> 10 (2010).

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.)

For some examples my understanding is that people are working on BLAG, 
and Dragora has published a new beta version for 3.0. It seems better to 
try to support such efforts instead of dropping them. We need more people 
working on 100% free distros, not less. :)

> Conversely, if unmaintained distros are listed, is there any good 
> reason not to list a new one, which clearly is actively maintained 
> (Uruk)?

Provided that Uruk (or, really, any new one) successfully completes the 
standard review process and is added by FSF staff. (The GNU Webmasters 
should not be adding new ones as per 
https://www.gnu.org/server/standards/#distros)

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

[Therese Godefroy via RT]

Hello,

Although this ticket only makes unsupported statements, the OP may have a point.

Should a distro that hasn't been maintained for several years be listed in 
free-distros.html, especially if it is based on a major distro which itself 
isn't maintained anymore? I am thinking of Blag, based on Fedora 10 (2010).

Conversely, if unmaintained distros are listed, is there any good reason not to 
list a new one, which clearly is actively maintained (Uruk)?  

Best regards,
Thérèse


Le Dim 31 Déc 2017 15:50:11, anonym...@foto.nl1.torservers.net a écrit :
> 
> BLAG is inactive
> 
> Dragora GNU Linux-Libre is inactive
> 
> Dynebolic is inactive
> 
> Musix is inactive
> 
> happy a new year
>