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

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

Re: [GNU-linux-libre] review of uruk


From: Denis 'GNUtoo' Carikli
Subject: Re: [GNU-linux-libre] review of uruk
Date: Wed, 29 Mar 2023 02:31:57 +0200

On Mon, 27 Mar 2023 10:56:47 -0400
bill-auger <bill-auger@peers.community> wrote:

> On Mon, 27 Mar 2023 16:31:51 +0200 Denis wrote:
> > As I understand, self-hosting has a completely different meaning
> > here: it's not about hosting your own infrastructure and it has
> > nothing to do with infrastructure at all.
> 
> i really think it implies both - the word "provide" would make
> no sense, if the distro does not provide the software, but
> refers users to a third-party, who has no obligation to provide
> anything to those users

Self-hosting is kind of defined as:
> In particular, a free system distribution should be self-hosting.
> This means that you must be able to develop and build the system with
> tools that the system provides you. As a result, a free system
> distribution cannot include free software that can only be built by
> using nonfree software.

So if you install Replicant on a device, you can't build Replicant (the
system) with tools that the system provides you. This most likely
applies to LibreCMC and ProteanOS too: You probably don't have packages
in LibreCMC that enable you to build LibreCMC on a computer running
LibreCMC, though I'm not aware of somebody that tried to do that[1].

Then we have:
> We make an exception to this requirement for small system
> distributions, which are distros designed for devices with limited
> resources, like a wireless router for example. Free small system
> distributions do not need to be self-hosting or complete, because it
> is impractical to do development on such a system, but it must be
> developable and buildable on top of a free complete system
> distribution from our list of distributions, perhaps with the aid of
> free tools distributed alongside the small system distribution itself.

So here "small" fits well for cases like LibreCMC where some supported
devices have 8MiB of storage space, so that makes it "impractical to
do development on such a system". You could probably add external
storage, mount an NFS share, etc, though that is not very practical as
probably not all devices have usb host.

Here I don't think these two paragraph have something to do with where
the web server of the project homepage is running.

That said, there may or may not be requirements that are not in
the FSDG (for instance if the FSDG is not complete, or because no one
though of new problematic cases or issues, or just because some class
of problems usually never happens for one reason or another).

And I think that not self-hosting your own infrastructure is not
necessarily a binary situation: for instance Guix doesn't control all
its infrastructure (because GNU, not Guix controls part of it), but Guix
is part of the GNU project and GNU probably controls all or at least
most of its infrastructure.

A requirement like that would also forbid using savannah for hosting
your source code, forbid secondary mirrors managed by the project, etc.

Though a possible way to improve that would be to see if/how the FSDG
could rely on the "GNU ethical repository criteria" for instance and
require a better grade than F. Though the downside is that it would
require to review the forges being used as well.

Also having parts about "SASS" would probably be a better fit than
requiring things about self-hosting your own infrastructure.

If we'd want to define infrastructure self-hosting, there is a
collective called CHATONS / KITTENS that has a charter about hosting
that defines the CHATONS obligations toward users, that could probably
be reused somehow to define infrastructure self-hosting requirements[2]
as they have to self-host to provide services to its users (which are
not self-hosted as the CHATON host things for users).

And inside that charter there are clauses like that:
> the CHATON must have root access on the operating system running the
> final online services;

So here if some trusted entity that isn't the distribution (like the
FSF for instance) provides a mirror or some space to host files operated
by the project:
- If we have some not-SASS requirements, here it's not SASS so it should
  be OK.
- If we have some the-distro-needs-to-self-host-its-infrastructure
  requirement it's not OK anymore because this is not self-hosting.

If needed, extra requirements could probably then be added (if they
make sense) to for instance make sure that users are not spied on by the
mirrors for instance, that the mirror content is under the distro
control somehow, etc.

Though a document detailing all that would probably also be useful for
other cases, like hosting releases, websites and so on for projects
(like GNU software or other projects that want to use such criteria).

At least some GNU toolchain components (through Sourceware) have a
separate infrastructure from GNU, so there may already be some
requirements or information somewhere about the infrastructure that
could be reused.

Though for now it's probably easier to just focus on the review of uruk
right now and for things that are not inside the FSDG, to request
changes like that on the basis of making the review faster.

For instance moving away from sourceforge is probably a good idea since
we don't need to discuss a lot about if it's acceptable or not, we also
don't need to review sourceforge, look at its JavaScript, etc. 

In general, doing like the other distributions whenever possible would
also make it easier and faster to review it.

In any case, beside the review, we are also waiting for information on
various topics like on the released ISOs for instance.

References:
-----------
[1]To try you'd need to first build LibreCMC for x86 (all the times that
   I tried it worked), and through trial and errors see if there are
   the packages required in LibreCMC to build LibreCMC. For ProteanOS
   I don't know enough about it but it looks like not-self hosting from
   its website documentation.
[2]https://www.chatons.org/en/charte

Denis.

Attachment: pgpQCGFD0FeZo.pgp
Description: OpenPGP digital signature


reply via email to

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