[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: Mon, 19 Jul 2021 19:29:34 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0

I could reply to this email but my reply would have exactly the same content as the previous email, because I don't see you've added anything new or that readers might not have deduced autonomously. In any possible scenario, removing JavaScript worsens the user experience (JavaScript is by no means replaceable), making format conversions and adding a repository and/or additional protocols leads to rapid obsolescence and decay within a few years.

Acceptance of factual reality is the prerequisite of any lasting technical project. It is my way of telling you that everything you are insisting on, despite being of noble principles from the point of view of an extremely small group of potential end users ( 0,23% of all potential visitors and even less end users ), is not only superfluous but also potentially harmful both from a technical and reputational point of view. The long-term risk and drawbacks significantly outweigh the short and long-term benefits and ultimately your project proposal does not seem maintainable without the use of a somewhat experienced organic of (dedicated) paid developers, which you cannot afford and without whom won't be able to keep a minimum stable level of quality and coherence.

My final advice is to accept that the FSD is already using an optimal software solution in regards to the business purposes ( in this case, efficiently index and categorize free software ) and hence commit on improving the contents it already manages, using HTML 5, CSS 3, JavaScript and any technology fit for the purpose, with the majority of potential visitors as explicit target.

Il 17/07/21 19:07, Bone Baboon ha scritto:
Lorenzo L. Ancora via writes:

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.

HTTP can serve web pages that are just HTML and CSS with no JavaScript.

There are other protocols in addition to HTTP that do not use
JavaScript.  Such as Gemini and Gopher.

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;

A read only HTML and CSS version of the FSD could be served without

Changes to the FSD contents could be managed with a Git repository and a
Git workflow using email and patches.

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;

This concept of the FSD as a Git repository replaces the client side
JavaScript and equivalent server side code with the use of a Git
repository, Git workflow and rendering the source code to HTML.

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;

To clarify I am suggesting that the source code would be compiled to
HTML and served with CSS so that people can browse a read only version
of the FSD.  This preserves the semantic meaning for people browsing a
read only copy of the FSD that is being served.

Someone would have the freedom to browse the read only FSD HTML contents
with whatever software they want.

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.

To mitigate this a detailed tutorial on how to use Git to contribute to
the FSD could be provided.

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;

Someone would have the freedom to browse the read only FSD HTML contents
with whatever software they want.

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;

This point should be taking into consideration when planning the
structure of the FSD Git repository and how it is rendered to HTML

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

Git seems to be working well for many free software projects including
large projects like the Linux kernel.

If this problem arose then an archive Git repository could be created
and a new repository (truncated) could be used moving forwards.  This
approach could also be used if in the future it was desirable to migrate
to another version control system.

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;

In this concept I am describing the server would be required to:
* compile the source code to HTML
* serve a static website of the source code repository (stagit or cgit)
* serve a static website for browsing a read only version of the FSD
   * source code compiled to HTML

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

I do not see the need for a triple conversion.

Source code compilation:
Plain text -> HTML

Where the plain text could be markdown or org-mode format for example.

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.

Yes this concept of the FSD as a Git repository would have people who
have commit access the the FSD Git repository reviewing submissions.

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

Banking can still be done by walking into a bank branch.

Not everyone uses social media.

People can choose to avoid websites that do not work without

Actually, MediaWiki is already the best choice and nothing more is
required to offer an excellent user experience to 98% of your end

You should not dismiss people who are using text browsers because they
are outnumbered by people using graphical browsers with JavaScript.

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.

Another option that is mention by Bill Auger in this thread is use the
MediaWiki API.

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

Yes other protocols require different servers.

A benefit of this FSD as a Git repository concept is that it is
flexible.  If in the future it was desirable to serve the FSD over
another protocol it could be done by compiling the source code to a
format that the new adopted protocol serves.

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]