Re: FSD as a Git repository

[Lorenzo L. Ancora]

Hi all,
I was waiting for a document from Donald before leaving the newsletter 
for good. I guess I may as well leave you a last message to prevent the 
FSD from self-destroying. :-P

As I've have always done - paying the consequences with my banishment 
from the GNU Project Webmasters after years of patient support, because 
apparently I am an heretic - I suggest that it is useless and 
unmaintainable in the long term to support text-only web browsers and/or 
those that do not implement JavaScript. Not your fault, it is how the 
World Wide Web was designed and will be developed.

Now I will rapidly go though an informal list of why this is likely to 
be a bad time investment:

1. JavaScript is required ( -- technically unavoidable -- ) to implement 
accessibility and interactivity in complex, modern websites. Literally, 
at some point you will always be forced to use it, because scripting is 
very often necessary;

2. Server-side alternatives to some functionalities typically offered 
via JavaScript do exist but, since HTTP/S is a stateless protocol, they 
almost always cause high server load and extend the attack surface. 
Furthermore, the security requirements of the FSF would impede the FSD 
administrators from managing server-side code;

3. Nowadays, text-only does not mean more accessible, quite the 
opposite: HTML 5 conveys semantic information via semantic tags; CSS 
conveys semantic information through visibility and appearance rules; 
the combination of JavaScript and CSS 3 offers the ability to detect the 
features of the web browser and adapt the web page dynamically.
That info is required by physically and/or mentally impaired users.
Text files does not offer any kind of aid in navigation, visualization 
(no branching logic = no ability to adapt), SEO (nowadays search engines 
interpret the meaning of the tags) and maintainability (no Content 
Management System = more hard work). Using Markdown won't make them more 
accessible, it will only make them awkward for TTS/Braille software, 
which is very bad;

4. Not all users are command-line savvy and can use Git, Bazaar, Breezy, 
CVS, ... without risking cause damage to their system or personal data 
by overwriting files or accidentally storing hidden directories 
alongside their backups. Speaking of privacy, for a user it is more 
difficult to delete the history of a terminal than to clear the browser 
history or use the private browsing mode;

5. The number one rule of SEO is to never duplicate your content, 
because search engines are not made by idiots and will penalize all 
domains and subdomains which host non-original/cloned contents, 
especially text. This means that you will inevitably lose users each 
time you decide to duplicate your content;

6. Git (and really any other VCS) can be used to aid in hosting entire 
websites, but only if those websites are not managed by many people. The 
reason is that those systems are designed to allow per-file downgrade 
and will store a lot of ever-growing data. This works like a charm for 
small websites (guess what, I use them too!) but what happens when you 
need to store the continuous contributions of hundreds of users? You 
have hundreds of commits and changes, which will cause the size of the 
repository to grow rapidly, reducing the performance, making it almost 
impossible to efficiently diagnose problems and finally you will be 
forced to truncate the entire repository;

7. ...you will then need to implement server-side checks for the 
consistency of the repository, nullifying any performance gain and, even 
worse, creating increasingly heavy loading spikes on the server;

8. Because of the loss/approximation of positional (layout) information 
caused by the triple format conversion (HTML [manual] -> text [manual] 
-> folded CLI text [automatic) ) you may inadvertently convey bogus 
information to end users, so you will need someone competent to check 
every single file in the repository continuously... and you cannot 
afford that, because this is not a work for volunteers. This happens 
because all web pages are written with a combination of the WYSIWYM and 
WYSIWYG approaches, not good for downgrades;

9. Only trusted users should even ever have write access to a repository 
because in general a VCS lacks the ability to manage user rights, making 
user management, security audit and information verification very complex.

The list is superficial and I could go on and on, but you get the idea.

Also, it should be noted that some users for the sole purpose of 
"showing their support for free software" declare that they usually use 
text-only browsers or disable JavaScript. However, this is unrealistic, 
because all banking sites, most social networks and in general most 
websites require the use of graphical browsers and JavaScript. So these 
statements are solely due to social pressure and such users certainly 
have the ability to use a modern graphical browser.

Actually, MediaWiki is already the best choice and nothing more is 
required to offer an excellent user experience to 98% of your end users.
The only correct way to allow access to the FSD for the narrow minority 
of users using text-only web browsers is to create an ad-hoc web service 
with the help of a good full-stack web developer.

Regarding the development of a customized and dedicated web service, if 
supporting users with text-only browsers (and even those with JS 
disabled) is one of your long-term business goals, I could do it for you 
at a significant discount, offering an equally discounted management and 
FLOSS development model. If there is interest, as always, contact me 
privately and make an offer.

Best regards,
Lorenzo

PS: Gopher and other exotic/ancient protocols require dedicated server 
software and proper isolation to be used in production.

Il 13/07/21 08:46, Ian Kelling ha scritto:
> Bone Baboon <bone.baboon@disroot.org> writes:
>
> > I wanted to ask what people think about the idea of the FSD being a git
> > repository.  This idea is motivated by this email thread.
> > <https://mail.gnu.org/archive/html/directory-discuss/2021-06/msg00017.html>
> >
> > Here is an example of how the FSD could work as a Git repository:
> >
> > * The Git repository would have the normal readme, contributing, license
> >    files.
> > * The FSD contents could be organized with a clear and deliberate
> >    directory hierarchy.
> > * The directories and files would have clear and deliberate names.
> > * The files could be written in a simple plain text format (Markdown,
> >    org-mode, etc).
> > * A static website of the Git repository and it's source code could be
> >    generated using free software tools like stagit and cgit.
> > * The FSD's plain text files could be compiled to HTML and served as a
> >    static web site without JavaScript using free software (discount,
> >    org-mode, etc).
> >
> > There would be trade off between using the current MediaWiki setup and
> > using a Git setup.
> >
> > Both Git and MediaWiki provide:
> > * Metadata on contributions
> > * History of changes
> >
> > Git advantages:
> > * No graphical web browser required.
> > * No JavaScript required.
> > * A text web browser would be optional.
> > * A contributor does not need a computer with a graphical environment.
> >    Not all GPU's have free firmware.
> > * A contributor would not have to sign up to be able to make
> >    contributions.  (signing up currently does not work without JavaScript
> >    and cookies)
> > * The Git repository could be cloned and worked on offline.
> > * Free software tools could be used to work on the Git repository.
> > * Contributors can make edits with their free software text editor of
> >    choice.
> > * Static websites without JavaScript for browsing the Git repository and
> >    source code would be accessible with text web browsers.
> > * Static websites without JavaScript rendered from the FSD's Git
> >    repository would be accessible to browse with a text web browsers.
> > * Once the content is in a plain text format it would be easier to move
> >    to another plain text format using free software (Pandoc for example)
> >    if that was desirable in the future.
> > * Simpler server administration without a database.
> > * Uses less system resources on the server.
> >
> > Git disadvantages:
> > * Requires learning how to use Git.
> > * Requires learning a simple markdown format.
> > * Requires a data migration initiative to move the FSD's data from it's
> >    current MediaWiki format into plain text files.
> > * Requires individuals with commit access to the Git repository to
> >    accept patches submitted by contributors.
> >
> > MediaWiki advantages:
> > * The FSD already uses MediaWiki.
> > * Currently works for contributors who have graphical browsers.
> > * Has forms that provide validation checks on entered data.
> > * Has reusable templates for common content.
> >
> > MediaWiki disadvantages:
> > * Requires learning the how to use MediaWiki.
> > * Does not work well with text web browsers.  Can not sign in with EWW
> >    Emacs's built in web browser for example.  Not all GPU's have free
> >    firmware and are able to run a graphical web browser.
>
> It is an interesting idea, it could work but it would be a lot of work,
> and probably not worth it. Maybe you want to create a prototype?
>
> - Ian

--
All messages from/to this account should be considered private.
Messages from/to newsletters should not be reshared.
TZ: Europe/Rome (Italy - CEST).

OpenPGP_signature
Description: OpenPGP digital signature