[Top][All Lists]

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

Re: FSD as a Git repository

From: Lorenzo L. Ancora
Subject: Re: FSD as a Git repository
Date: Tue, 13 Jul 2021 13:59:07 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0

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

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

Here is an example of how the FSD could work as a Git repository:

* The Git repository would have the normal readme, contributing, license
* 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
* 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).

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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