Re: [H-source-users] Introduction

[Bone Baboon]

bill-auger writes:

> On Sat, 17 Jul 2021 23:04:01 -0400 Bone wrote:
>> I would suggest converting the h-node web application into a Git
>> repository.  This could be easier to accomplish as it can be done
>> with stable existing free software.
>
> PHP and python are also stable existing free software

Yes you are correct that PHP and Python are stable existing free
software.  However they are programming languages that someone would use
to create other free software program.  What I was referring to where
ready to use free software programs that can be used right now without
requiring software development effort.

> On Sat, 17 Jul 2021 23:04:01 -0400 Bone wrote:
>> I recently requested feedback on what people thought of the Free
>> Software Directory (FSD) being a Git repository.
>
> i admire your persistence and intentions; but my response would
> be much the same as the FSD proposal; which is considerably
> less enthusiastic than damien's
>
> what this amounts to, is taking something which is very easy for
> anyone to contribute to, with no technical skills required, and
> converting it into something which requires proficiency with
> software development tools, in order to do even the simplest
> operations
>
> to expect non-technical people to learn software development
> tools, could only discourage participation more than encourage it

The use of Git could be a barrier to people that want to contribute to
h-node and are not familiar with Git.  To help mitigate this a detailed
tutorial explaining how to make h-node contributions using Git could be
provided.

h-node already has the significant (necessary) barrier to contributing
of requiring that either a FSDG operating system
<https://www.gnu.org/distros/free-distros.html> or Debian is
installed. <https://h-node.org/> Currently few computers come with
either of these preinstalled at purchase.  So a contributor to h-node
has probably installed a FSDG operating system or Debian on their
computer themselves.  Being able to install an operating system is
probably a good indicator that they are able to follow documentation and
would hopefully be okay following along with a Git tutorial for h-node.

> your arguments are more fitting WRT to mediawiki (access via
> text-only, no-js, etc); but h-node is a much simpler website -
> the "web application" buzzword is ridiculous when applied to
> such a modest website - it needs to be nothing more than a
> front-end to a database

The current implementation of h-node could be called a website and
database instead of a web application.  Regardless of what you call
h-node's current implementation, the Git repository approach has these
benefits in regards to its maintenance:

* Simpler
* Less maintain burden
* More resilient to change

This is highlighted by h-node's current implementation faced with these
other two proposals:
* Update h-node to work with a newer version of PHP.
* Rewrite h-node in Python 3.

Thank you for highlighting some of the the accessibility benefits of
h-node being a Git repository.  Some of the accessibility advantages of
h-node being a Git repository include:

* Text only
* No JavaScript
* No web browser required
* Readers and contributors can use free software programs of their
  choice that meet their accessibility needs.
* People who are using a FSDG operating system and have a GPU that does
  not work without nonfree software (no graphical environment like Xorg
  or Wayland) can still read and contribute.

> all that is also ignoring the h-client program, which is the
> preferred way to contribute data, and is much, much, easier then
> using the web interface for that purpose - no web browser nor
> terminal is required to collect all of the relevant hardware
> data and upload it to the database - h-client does everything -
> the user does not even need to understand what is happening, in
> order to contribute complete and perfectly formatted information
> - a few mouse clicks, and the entire process is done

Thank you for pointing out h-client.

It does not look like h-client has received a commit since 2011.
<http://git.savannah.nongnu.org/cgit/h-source.git/log/h-client>

If h-node is upgraded to a newer version of PHP or is rewritten in
Python 3 then h-client may need to be update as well.

h-client is written in Python.

<http://git.savannah.nongnu.org/cgit/h-source.git/tree/h-client>

Is h-client written in Python 2?

Python 2 has reached it's end of life and is no longer being maintained
or receiving security fixes.
<https://www.python.org/doc/sunset-python-2/>

It looks like h-client has been packaged for only two FSDG operating
systems.
<https://h-node.org/wiki/page/en/client-for-h-node-org>
<https://repology.org/project/h-client/versions>

Rewriting h-client as a POSIX shell script would make it more portable
and more contributors could use it.  They could download the h-client
shell script and run it.

A program like h-client could be created for preparing submissions to
h-node if it was a Git repository.

> there is another issue, which i dont believe that anyone
> addressed in the FSD discussion, which is as relevant for
> h-node, that is: login credentials - you are proposing all
> "static web" pages - that makes it impossible for anyone to
> register or login via the web; because there is no database
> andno authentication service running

Yes you are correct login credentials would not be required for the
concept of h-node as a Git repository.

> then what should be done with all of the existing registrations
> and password hashes? - shall those go in the public git repo? -
> surely, thats not a good idea

Current user information should definitely not be part of the h-node Git
repository.  That would be equivalent to a data breach of user
information.

If h-node is converted to a Git repository then once that is completed
the database tables with user information could be dropped as they would
no longer be required.

> but without login credentials, everything MUST be done with git; and
> all new contributions would be anonymous - but that is a very loud
> invitation for spam; so where do you put the captcha?

Guix <https://guix.gnu.org/> is a FSDG operating system that does it's
development using Git patches submitted to a mailing list.  Contributors
are allowed to use pseudonyms.

<https://guix.gnu.org/en/manual/en/html_node/Contributing.html#Contributing>

Guix does not use captchas.

The issue of spam appears to be manageable for Guix.  If spam where a
problem for h-node then a good question would be:
How does Guix manage their contribution process to deal with spam?