--- a/src/about.html.luan	Sun Sep 15 08:09:27 2024 -0600
+++ b/src/about.html.luan	Sun Sep 15 10:52:25 2024 -0600
@@ -43,7 +43,7 @@
 
 			<p>Today's West is currently at the level of the decaying Greeks, heading toward complete idiocracy.  The programmers in Silicon Valley are like Ptolemy, able to construct and maintain horrible overcomplicated monstrosities, but totally unable to innovate at a fundamental level.  All good programming ideas are rejected because they don't fit into current programming ideologies.  Any programmer like Aristarchus who comes up with a good programming idea will be rejected and ridiculed for violating orthodoxy.  Modern programmers are in love with their own ideas and love complexity.  They hate simplicity and anything that violates their ideologies.</p>
 
-			<p>For a concrete example, consider <a href="http://www.luan.software/goodjava.html#parser">my parser</a>.  It is a basic innovation that massively simplifies parsing.  So what reception did it get?  Of course <a href="https://old.reddit.com/r/Compilers/comments/cv78b3/parsing_for_programmers_who_hate_modern_software/">it was ridiculed</a> by modern programmers.  This is the same story as Aristarchus.  Modern programmers naturally hate everything that is good and only love what is horrible.</p>
+			<p>For a concrete example, consider <a href="https://www.luan.software/goodjava.html#parser">my parser</a>.  It is a basic innovation that massively simplifies parsing.  So what reception did it get?  Of course <a href="https://old.reddit.com/r/Compilers/comments/cv78b3/parsing_for_programmers_who_hate_modern_software/">it was ridiculed</a> by modern programmers.  This is the same story as Aristarchus.  Modern programmers naturally hate everything that is good and only love what is horrible.</p>
 
 			<p>Given this situation, what should a good reactionary programmer do?  In Matthew 7:6, Jesus said "Do not give what is holy to dogs, and do not throw your pearls before swine, or they will trample them under their feet, and turn and tear you to pieces."  Good software is pearls and modern programmers are swine.  So do not repeat my mistake of showing good software to modern programmers.</p>
 
@@ -67,11 +67,11 @@
 
 			<p><b>The decline of Java</b> - An example of modern programmers destroying good software as I explained in <a href="/java.html">the Java post</a>.</p>
 
-			<p><b>Java mail library</b> - The original <a href="https://docs.oracle.com/javaee/7/api/javax/mail/package-summary.html">javax.mail</a> was a huge overcomplicated mess.  This JavaMail package has since <a href="https://javaee.github.io/javamail/">moved to GitHub</a> where it belongs along with other horrible modern software.  Googling for alternatives gives you other libraries that are built on top of JavaMail.  Naturally I rejected all the garbage and wrote my own <a href="http://www.luan.software/goodjava.html#mail">goodjava.mail</a> from scratch.  This whole library is a little over 200 lines of code and is a thin layer on top of SMTP and MIME.  Modern programmers hate thin layers because they always think that they can do better than the underlying layer.  But a thick layer actually adds complexity and makes debugging more difficult for the user of the library.  My thin layer lets the user set the headers directly.  Does this mean that the user has to fully understand MIME headers?  No, not at all.  The user can just send himself an email of the type he wants using his favorite mail client, say gmail, and then when he receives the email, he can look at its source (with gmail "Show original").  Then he can just copy the headers into his code.  If the user is doing something complicated, then my thin layer gives him complete control to generate exactly whatever complex email he wants.  With modern libraries with their disgusting thick layers, it is always a struggle to do anything complex.</p>
+			<p><b>Java mail library</b> - The original <a href="https://docs.oracle.com/javaee/7/api/javax/mail/package-summary.html">javax.mail</a> was a huge overcomplicated mess.  This JavaMail package has since <a href="https://javaee.github.io/javamail/">moved to GitHub</a> where it belongs along with other horrible modern software.  Googling for alternatives gives you other libraries that are built on top of JavaMail.  Naturally I rejected all the garbage and wrote my own <a href="https://www.luan.software/goodjava.html#mail">goodjava.mail</a> from scratch.  This whole library is a little over 200 lines of code and is a thin layer on top of SMTP and MIME.  Modern programmers hate thin layers because they always think that they can do better than the underlying layer.  But a thick layer actually adds complexity and makes debugging more difficult for the user of the library.  My thin layer lets the user set the headers directly.  Does this mean that the user has to fully understand MIME headers?  No, not at all.  The user can just send himself an email of the type he wants using his favorite mail client, say gmail, and then when he receives the email, he can look at its source (with gmail "Show original").  Then he can just copy the headers into his code.  If the user is doing something complicated, then my thin layer gives him complete control to generate exactly whatever complex email he wants.  With modern libraries with their disgusting thick layers, it is always a struggle to do anything complex.</p>
 
-			<p><b>Other Java libraries</b> - All of the libraries in <a href="http://www.luan.software/goodjava.html">my goodjava library collection</a> were written because all other alternatives that I could find were horrible, so I wrote my own.  Besides <a href="http://www.luan.software/goodjava.html#mail">goodjava.mail</a>, I have <a href="http://www.luan.software/goodjava.html#webserver">goodjava.webserver</a>, <a href="http://www.luan.software/goodjava.html#logger">goodjava.logger</a>, <a href="http://www.luan.software/goodjava.html#json">goodjava.json</a>, <a href="http://www.luan.software/goodjava.html#xml">goodjava.xml</a>, and of course <a href="http://www.luan.software/goodjava.html#parser">goodjava.parser</a> as good examples.  In every one of these cases, I challenge you to find an alternative to my library that is as easy to use.</p>
+			<p><b>Other Java libraries</b> - All of the libraries in <a href="https://www.luan.software/goodjava.html">my goodjava library collection</a> were written because all other alternatives that I could find were horrible, so I wrote my own.  Besides <a href="https://www.luan.software/goodjava.html#mail">goodjava.mail</a>, I have <a href="https://www.luan.software/goodjava.html#webserver">goodjava.webserver</a>, <a href="https://www.luan.software/goodjava.html#logger">goodjava.logger</a>, <a href="https://www.luan.software/goodjava.html#json">goodjava.json</a>, <a href="https://www.luan.software/goodjava.html#xml">goodjava.xml</a>, and of course <a href="https://www.luan.software/goodjava.html#parser">goodjava.parser</a> as good examples.  In every one of these cases, I challenge you to find an alternative to my library that is as easy to use.</p>
 
-			<p><b>Scripting languages</b> - <a href="https://en.wikipedia.org/wiki/Scripting_language">Scripting languages</a> should be extremely simple.  There is no reason to make them complicated.  Yet all existing usable scripting languages are complicated.  So I wrote my own simple scripting language - <a href="http://www.luan.software/">Luan</a>.</p>
+			<p><b>Scripting languages</b> - <a href="https://en.wikipedia.org/wiki/Scripting_language">Scripting languages</a> should be extremely simple.  There is no reason to make them complicated.  Yet all existing usable scripting languages are complicated.  So I wrote my own simple scripting language - <a href="https://www.luan.software/">Luan</a>.</p>
 
 			<h2>What you can do</h2>