commit b573bb8ffd1ec74cff3809ecce85c005d3e159c1
parent 9ea0d4b19893a3592c37d6b26d60c7465a8fe7e0
Author: Oscar Benedito <oscar@oscarbenedito.com>
Date: Sat, 2 Apr 2022 21:06:12 +0200
Move markdown files to HTML
Diffstat:
94 files changed, 3535 insertions(+), 3185 deletions(-)
diff --git a/content/_index.html b/content/_index.html
@@ -0,0 +1,25 @@
+<!-- priority: 1.0 -->
+<!-- extraheader: <link rel="me" href="https://github.com/oscarbenedito"/><link rel="me" href="https://gitlab.com/oscarbenedito"/><link rel="me" href="mailto:oscar@oscarbenedito.com"/><link rel="pgpkey" href="/pgp/pubkey.asc"/> -->
+<!-- description: Hello and welcome to my website! I'm Oscar Benedito and this is my corner of the Internet. -->
+
+<p>
+ Hello and welcome to my website! My name is Oscar Benedito and I am a 24-year-old from Barcelona.
+ I enjoy tinkering with and customizing computers and I often undertake small software projects for
+ personal use. When away from a computer, I like to do sport (the particular sport varies depending
+ on the season and year) and I occasionally juggle. Last year I graduated in Mathematics and
+ Computer Engineering from <a href="https://www.upc.edu/en">UPC</a> and I am currently working as
+ an Associate Software Engineer at Oracle.</p>
+<!-- /p -->
+
+<p>
+ I encourage you to check out some of my content: <a href="/blog/">my blog</a>, where I talk about
+ privacy, software and other related topics, or <a href="https://git.oscarbenedito.com">my Git
+ repositories</a> (which are mirrored on <a href="https://git.sr.ht/~ob">SourceHut</a> and <a
+ href="https://github.com/oscarbenedito">GitHub</a>). If you want to read more about my
+ academic/professional life, check out <a href="https://www.linkedin.com/in/oscarbenedito">my
+ LinkedIn profile</a>.</p>
+<!-- /p -->
+
+<h2>Contact me</h2>
+
+<p>Feel free to contact me! Details can be found on my <a href="/contact/">contact page</a>.</p>
diff --git a/content/_index.md b/content/_index.md
@@ -1,29 +0,0 @@
-<!-- priority: 1.0 -->
-<!-- extraheader: <link rel="me" href="https://github.com/oscarbenedito"/><link rel="me" href="https://gitlab.com/oscarbenedito"/><link rel="me" href="mailto:oscar@oscarbenedito.com"/><link rel="pgpkey" href="/pgp/pubkey.asc"/> -->
-<!-- description: Hello and welcome to my website! I'm Oscar Benedito and this is my corner of the Internet. -->
-
-Hello and welcome to my website! My name is Oscar Benedito and I am a
-24-year-old from Barcelona. I enjoy tinkering with and customizing computers and
-I often undertake small software projects for personal use. When away from a
-computer, I like to do sport (the particular sport varies depending on the
-season and year) and I occasionally juggle. Last year I graduated in Mathematics
-and Computer Engineering from [UPC][upc] and I am currently working as an
-Associate Software Engineer at Oracle.
-
-I encourage you to check out some of my content: [my blog][blog], where I talk
-about privacy, software and other related topics, or [my Git repositories][git]
-(which are mirrored on [SourceHut][sh] and [GitHub][gh]). If you want to read
-more about my academic/professional life, check out [my LinkedIn profile][li].
-
-## Contact me
-
-Feel free to contact me! Details can be found on my [contact page][c].
-
-
-[upc]: <https://www.upc.edu/en> "Universitat Politècnica de Catalunya (UPC)"
-[blog]: </blog/> "Personal blog"
-[git]: <https://git.oscarbenedito.com> "Personal Git server"
-[sh]: <https://git.sr.ht/~ob> "Sourcehut Git repositories"
-[gh]: <https://github.com/oscarbenedito> "GitHub profile"
-[li]: <https://www.linkedin.com/in/oscarbenedito> "LinkedIn profile"
-[c]: </contact/> "Contact page"
diff --git a/content/about.html b/content/about.html
@@ -0,0 +1,39 @@
+<!-- title: About this site -->
+<!-- description: Information about the site: privacy, license and source code. -->
+
+<h2>Privacy</h2>
+
+<p>
+ The site contains no ads or cross-site references. I am currently hosted by <a
+ href="https://www.hetzner.com">Hetzner</a> and can't guarantee that they don't keep any logs of
+ the website's visitors. I do keep logs for 14 days and use GoAccess to keep track of how many
+ visitors I get. This information is not shared with anyone else.</p>
+<!-- /p -->
+
+<h2>Licenses</h2>
+
+<p>
+ This site is powered by free software. The software is published under the <a
+ href="https://www.gnu.org/licenses/gpl-3.0.html">GNU General Public License version 3</a>.</p>
+<!-- /p -->
+
+<p>
+ The content of the site is published under a <a
+ href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International
+ License</a> unless otherwise stated.</p>
+<!-- /p -->
+
+<p>I am hosting local copies of the licenses: <a href="/licenses/gpl-3.0.txt">GPLv3</a>, <a href="/licenses/cc-by-4.0.txt">CC-BY-4.0</a>.</p>
+
+<h2>Source code</h2>
+
+<p>
+ This site is genarated using <a href="https://git.oscarbenedito.com/oscarbenedito.com/file/gensite.py.html">gensite.py</a>,
+ a small Python script based on <a href="https://github.com/sunainapai/makesite">makesite.py</a>.
+ You can find the site's source code on <a href="https://git.oscarbenedito.com/oscarbenedito.com/">this repository</a>.</p>
+<!-- /p -->
+
+<p>
+ You can find all the JavaScript run on the site along with the licenses and source code in the <a
+ href="/jsweblabels/">JavaScript Web Labels page</a>.</p>
+<!-- /p -->
diff --git a/content/about.md b/content/about.md
@@ -1,39 +0,0 @@
-<!-- title: About this site -->
-<!-- description: Information about the site: privacy, license and source code. -->
-
-## Privacy
-
-The site contains no ads or cross-site references. I am currently hosted by
-[Hetzner][hetzner] and can't guarantee that they don't keep any logs of the
-website's visitors. I do keep logs for 14 days and use GoAccess to keep track of
-how many visitors I get. This information is not shared with anyone else.
-
-## Licenses
-
-This site is powered by free software. The software is published under the [GNU
-General Public License version 3][gpl].
-
-The content of the site is published under a [Creative Commons Attribution 4.0
-International License][cc-by] unless otherwise stated.
-
-I am hosting local copies of the licenses: [GPLv3][gpl-local],
-[CC-BY-4.0][cc-by-local].
-
-## Source code
-
-This site is genarated using [gensite.py][], a small Python script based on
-[makesite.py][]. You can find the site's source code on [this repository][repo].
-
-You can find all the JavaScript run on the site along with the licenses and
-source code in the [JavaScript Web Labels page][jswl].
-
-
-[hetzner]: <https://www.hetzner.com> "Hetzner"
-[gpl]: <https://www.gnu.org/licenses/gpl-3.0.html> "GNU General Public License version 3"
-[cc-by]: <https://creativecommons.org/licenses/by/4.0/> "Creative Commons Attribution 4.0 International License"
-[gpl-local]: </licenses/gpl-3.0.txt> "GNU General Public License version 3"
-[cc-by-local]: </licenses/cc-by-4.0.txt> "Creative Commons Attribution 4.0 International License"
-[gensite.py]: <https://git.oscarbenedito.com/oscarbenedito.com/file/gensite.py.html> "gensite.py — git.oscarbenedito.com"
-[makesite.py]: <https://github.com/sunainapai/makesite> "makesite.py — GitHub"
-[repo]: <https://git.oscarbenedito.com/oscarbenedito.com/> "Source code"
-[jswl]: </jsweblabels/> "JavaScript Web Labels"
diff --git a/content/blog/2019-09-09-getting-a-domain.html b/content/blog/2019-09-09-getting-a-domain.html
@@ -0,0 +1,45 @@
+<!-- title: Getting my own domain name -->
+<!-- slug: getting-a-domain -->
+<!-- categories: Decentralization, Personal domain -->
+<!-- date: 2019-09-09T00:00:00Z -->
+<!-- lastmod: 2020-03-01T00:00:00Z -->
+
+<p>
+ After thinking about getting my own domain name for a while and letting the thought rest for a
+ couple of months, I finally bought one. It is a very easy and inexpensive process, and I am happy
+ I did it. The original idea was to set up my email with it, so I could change my email provider
+ without changing the address (I am in the process of changing my provider, and it takes a lot of
+ effort), but having a domain name opens a world of opportunities.</p>
+<!-- /p -->
+
+<hr />
+
+<p>
+ Although I had known about how to get a domain for a while, I didn't have much experience on which
+ companies were "better" or "worse" (since I only needed a domain but no hosting, I am not sure why
+ a company could give me a more appealing offer, since prices are the same in all websites). I
+ finally decided to go with <a href="https://www.gandi.net">Gandi.net</a> because a known site uses
+ it, I had heard about it on the <a href="https://en.wikipedia.org/wiki/Fediverse">Fediverse</a>,
+ and it looked like a good and reliable company. The hardest part was figuring out which domain I
+ wanted, once that was decided, buying it took around 5 minutes.</p>
+<!-- /p -->
+
+<p>
+ Since I had never seen a DNS record before, configuring my email provider was a little trickier.
+ My provider gave me some lines to copy and paste into the record, but they needed some
+ modification in order to work, so it took me a little while to figure it out. The next part was
+ setting a landing page for my domain: if someone saw my email address and wanted to check what <a
+ href="https://obenedito.org">obenedito.org</a> was all about, I didn't want them to get a 404. So
+ I designed a very simple page with my name and a link to my email address and one to my GitLab
+ account. Since I don't have a home server or a VPS, I decided to host my page on GitLab (basically
+ because it's free and I don't need a dynamic website). I once again had some trouble setting up
+ the GitLab custom domain—the lines I was given to add to the record weren't the ones I actually
+ needed to add, so that took a bit to figure out as well.</p>
+<!-- /p -->
+
+<p>
+ I still have a lot to learn about how DNS records work (for instance the difference between a type
+ A or CNAME entry), but, for now, it works just fine.</p>
+<!-- /p -->
+
+<p><em>Edit</em>: My personal domain has been moved to <a href="https://oscarbenedito.com">oscarbenedito.com</a>.</p>
diff --git a/content/blog/2019-09-09-getting-a-domain.md b/content/blog/2019-09-09-getting-a-domain.md
@@ -1,47 +0,0 @@
-<!-- title: Getting my own domain name -->
-<!-- slug: getting-a-domain -->
-<!-- categories: Decentralization, Personal domain -->
-<!-- date: 2019-09-09T00:00:00Z -->
-<!-- lastmod: 2020-03-01T00:00:00Z -->
-
-After thinking about getting my own domain name for a while and letting the
-thought rest for a couple of months, I finally bought one. It is a very easy and
-inexpensive process, and I am happy I did it. The original idea was to set up my
-email with it, so I could change my email provider without changing the address
-(I am in the process of changing my provider, and it takes a lot of effort), but
-having a domain name opens a world of opportunities.
-
-***
-
-Although I had known about how to get a domain for a while, I didn't have much
-experience on which companies were "better" or "worse" (since I only needed a
-domain but no hosting, I am not sure why a company could give me a more
-appealing offer, since prices are the same in all websites). I finally decided
-to go with [Gandi.net][g] because a known site uses it, I had heard about it on
-the [Fediverse][f], and it looked like a good and reliable company. The hardest
-part was figuring out which domain I wanted, once that was decided, buying it
-took around 5 minutes.
-
-Since I had never seen a DNS record before, configuring my email provider was a
-little trickier. My provider gave me some lines to copy and paste into the
-record, but they needed some modification in order to work, so it took me a
-little while to figure it out. The next part was setting a landing page for my
-domain: if someone saw my email address and wanted to check what
-[obenedito.org][org] was all about, I didn't want them to get a 404. So I
-designed a very simple page with my name and a link to my email address and one
-to my GitLab account. Since I don't have a home server or a VPS, I decided to
-host my page on GitLab (basically because it's free and I don't need a dynamic
-website). I once again had some trouble setting up the GitLab custom domain—the
-lines I was given to add to the record weren't the ones I actually needed to
-add, so that took a bit to figure out as well.
-
-I still have a lot to learn about how DNS records work (for instance the
-difference between a type A or CNAME entry), but, for now, it works just fine.
-
-*Edit*: My personal domain has been moved to [oscarbenedito.com][com].
-
-
-[g]: <https://www.gandi.net> "Gandi"
-[f]: <https://en.wikipedia.org/wiki/Fediverse> "Fediverse — Wikipedia"
-[org]: <https://obenedito.org>
-[com]: <https://oscarbenedito.com>
diff --git a/content/blog/2019-09-11-joplin.html b/content/blog/2019-09-11-joplin.html
@@ -0,0 +1,40 @@
+<!-- title: My note taking app: Joplin -->
+<!-- slug: joplin -->
+<!-- categories: Decentralization, FOSS, Privacy -->
+<!-- date: 2019-09-11T00:00:00Z -->
+<!-- lastmod: 2019-09-24T00:00:00Z -->
+
+<p>
+ Two years ago I had an iPhone and, back then, the native "Notes" app worked pretty well for me.
+ However, when I changed to Android I had some trouble finding a similar app or a different one
+ that would fit my needs. For some time I used Google Keep, but I didn't like how the main view
+ would show you the whole note (instead of having only one line per note, which allows more notes
+ to fit in the screen). I changed to Evernote for some time—which was definitely more suited for
+ me—but there were too many ads about getting premium features and, since I didn't need them, I
+ eventually got tired of it.</p>
+<!-- /p -->
+
+<p>
+ Back then I already knew what Markdown was, since I had used it to build a website, and I realized
+ that an app with Markdown support could be a very good alternative. I looked around and finally
+ found <a href="https://joplinapp.org">Joplin</a>, a free/libre and open source app that supported
+ Markdown as well as synchronization—perfect for my needs, since I like having notes backed up in
+ case I lose access to my phone. I have been using it for half a year and so far it has been a
+ great app. I type my notes with Markdown and once I'm done it renders them beautifully. It also
+ lets me backup a copy with Nextcloud which is good since it doesn't force me to do it through
+ Google Drive/Dropbox and on top of that I can set up end-to-end encryption for my backed-up notes!
+ I haven't paid a lot of attention to what algorithm is used to encrypt since I trust my Nextcloud
+ provider, however, I know metadata is not encrypted (I'm guessing to make synchronization faster),
+ but that's fine with me. This also allows me to synchronize my notes with my computer, something
+ that I had never thought would be useful before, but as I use my computer more and more (and my
+ phone less and less), it is becoming very convenient.</p>
+<!-- /p -->
+
+<p>
+ Moreover, since I use it on my computer and I can arrange notes with the use of notebooks, it is
+ becoming more of a personal wiki than a note-taking app. I have a notebook named "Notes", but the
+ remaining notebooks hold information in a less "casual" way. I suppose everyone uses notes that
+ way, but being able to use Markdown allows me to store lots of information in a more convenient
+ way, especially when dealing with links and fragments of code.</p>
+<!-- /p -->
+
diff --git a/content/blog/2019-09-11-joplin.md b/content/blog/2019-09-11-joplin.md
@@ -1,41 +0,0 @@
-<!-- title: My note taking app: Joplin -->
-<!-- slug: joplin -->
-<!-- categories: Decentralization, FOSS, Privacy -->
-<!-- date: 2019-09-11T00:00:00Z -->
-<!-- lastmod: 2019-09-24T00:00:00Z -->
-
-Two years ago I had an iPhone and, back then, the native "Notes" app worked
-pretty well for me. However, when I changed to Android I had some trouble
-finding a similar app or a different one that would fit my needs. For some time
-I used Google Keep, but I didn't like how the main view would show you the whole
-note (instead of having only one line per note, which allows more notes to fit
-in the screen). I changed to Evernote for some time—which was definitely more
-suited for me—but there were too many ads about getting premium features and,
-since I didn't need them, I eventually got tired of it.
-
-Back then I already knew what Markdown was, since I had used it to build a
-website, and I realized that an app with Markdown support could be a very good
-alternative. I looked around and finally found [Joplin][j], a free/libre and
-open source app that supported Markdown as well as synchronization—perfect for
-my needs, since I like having notes backed up in case I lose access to my phone.
-I have been using it for half a year and so far it has been a great app. I type
-my notes with Markdown and once I'm done it renders them beautifully. It also
-lets me backup a copy with Nextcloud which is good since it doesn't force me to
-do it through Google Drive/Dropbox and on top of that I can set up end-to-end
-encryption for my backed-up notes! I haven't paid a lot of attention to what
-algorithm is used to encrypt since I trust my Nextcloud provider, however, I
-know metadata is not encrypted (I'm guessing to make synchronization faster),
-but that's fine with me. This also allows me to synchronize my notes with my
-computer, something that I had never thought would be useful before, but as I
-use my computer more and more (and my phone less and less), it is becoming very
-convenient.
-
-Moreover, since I use it on my computer and I can arrange notes with the use of
-notebooks, it is becoming more of a personal wiki than a note-taking app. I have
-a notebook named "Notes", but the remaining notebooks hold information in a less
-"casual" way. I suppose everyone uses notes that way, but being able to use
-Markdown allows me to store lots of information in a more convenient way,
-especially when dealing with links and fragments of code.
-
-
-[j]: <https://joplinapp.org> "Joplin"
diff --git a/content/blog/2019-09-23-upgrading-providers.html b/content/blog/2019-09-23-upgrading-providers.html
@@ -0,0 +1,152 @@
+<!-- title: Upgrading to privacy-conscious providers -->
+<!-- slug: upgrading-providers -->
+<!-- categories: Cryptography, Decentralization, Privacy -->
+<!-- date: 2019-09-23T00:00:00Z -->
+<!-- lastmod: 2019-09-24T00:00:00Z -->
+
+<p>
+ I have been reading a lot about decentralization and not depending too much in one company in the
+ past six months and I realized how much I relied on Google: my email, all my files, contacts,
+ calendars, pictures... Most of my data was stored on their servers. This was inconvenient for
+ three reasons: (1) if something was to happen to Google or my account, I would lose a lot of data,
+ (2) Google doesn't use end-to-end encryption, which means that they (and anyone with access to
+ their servers) can see all my files, emails, etc. and (3) Google already uses all this data (and
+ other it collects) to better know my personality.</p>
+<!-- /p -->
+
+<p>
+ Some people might think that the main three problems I have with Google aren't that important. In
+ fact, I have used Google for many years because that was my opinion for a long time. However, the
+ more I read about the issue, the more I realize they aren't minor problems. I realized that for me
+ it is worth it to pay $12 or $24 a year in exchange for privacy. If you are still doubting, <a
+ href="https://www.gnu.org/proprietary/malware-google.html">this post</a> might change your
+ mind.</p>
+<!-- /p -->
+
+<hr />
+
+<p>Let's see what I needed out of my new providers/configuration:</p>
+
+<ol>
+ <li>Control over my data: if something were to happen to my account, it shouldn't affect me too much.</li>
+ <li>Encrypting my data: end-to-end encryption for my services, so there wasn't a need to "trust"
+ the provider, as well as to avoid any problems in case the servers were compromised—which is not
+ that uncommon.</li>
+ <!-- /li -->
+ <li>Privacy: the provider shouldn't be using my data in any way (which is mostly solved with end-to-end encryption).</li>
+</ol>
+
+<h3>1. Control over my data</h3>
+
+<p>
+ My first problem was easily solvable, I simply needed to back up everything that was on the cloud.
+ That process was pretty easy using <a href="https://takeout.google.com/">Google's export tool</a>.
+ With a few clicks, everything was ready, and I only had to wait for Google to collect all the data
+ and create the file. I'm not sure how much that took, I would say less than an hour, but
+ definitely less than a day (it was a long ago, so I don't remember).</p>
+<!-- /p -->
+
+<p>
+ Selecting all the different services I wanted to export from one page instead of having to go to
+ each service's URL and then select export made the process so much smoother. I was surprised by
+ how easy the export was, and all the data was in convenient files to import to other services:
+ contacts in a VCF file, calendar in an iCal file... which makes a lot of sense, but not all
+ services allow such an easy process to export everything and ready to use in a different service.
+ Fortunately, that was the case, so my next problem was a lot easier to solve.</p>
+<!-- /p -->
+
+<h3>2. Encrypting my data</h3>
+
+<p>
+ In order to encrypt my content, I needed to find an alternative to a lot of services that Google
+ was offering me (or use tools such as <a href="https://cryptomator.org">Cryptomator</a>, which was
+ discarded because of problem number 3). And so the search began.</p>
+<!-- /p -->
+
+<h4>Email</h4>
+
+<p>
+ There are a lot of encrypted mailboxes and there is also the option of self-hosting email. I
+ wasn't interested in managing my own server just for my email, so I had to choose a provider. Many
+ of the sources I checked recommended <a href="https://protonmail.com">Protonmail</a> and <a
+ href="https://tutanota.com">Tutanota</a>, among others. They both looked nice and offered a free
+ tier, so I tried them. After some time, I finally decided to go with Tutanota because of how they
+ approached their user community as well as other details (for instance, their app not using any of
+ the Google Play Services), although it was a hard choice.</p>
+<!-- /p -->
+
+<h4>File storage</h4>
+
+<p>
+ Most of my files in the cloud were old and not usually needed, they were just online because I
+ used Google Drive as my home folder. The solution was easy: I backed them up on an offline
+ external storage as well as on my computer and deleted them from the cloud.</p>
+<!-- /p -->
+
+<p>
+ As for the few files I actually needed online (the ones I use both at home and at college), I now
+ use a USB stick to have them wherever I go, as well as backing them up every once in a while. No
+ need to have them online, and it is faster to plug in a USB stick than log in to Google Drive and
+ download the files (which was what I was doing on all computers running GNU/Linux).</p>
+<!-- /p -->
+
+<p>
+ There is one type of file I haven't replaced yet: anything that was shared is still on my Drive
+ (even if other services offer it, for now, I am fine with using Google).</p>
+<!-- /p -->
+
+<h4>Calendar and contacts</h4>
+
+<p>
+ I created an account in a Nextcloud instance for my calendar and contacts. Nextcloud is very
+ intuitive and I like the user interface. There's the <a href="https://www.davx5.com">DAVx⁵</a> app
+ that synchronizes them to my phone, so that was an easy choice. Having an account at a Nextcloud
+ instance is also useful in case I want to upload files and it also allows me to sync my <a
+ href="https://joplinapp.org">Joplin</a> notes.</p>
+<!-- /p -->
+
+<h4>Search</h4>
+
+<p>
+ I thought the search engine would be the hardest service to substitute, however, there are a lot
+ of good alternatives. The one I went for is <a href="https://duckduckgo.com">DuckDuckGo</a> which
+ works pretty well and also works if you are connected to the internet through the <a
+ href="https://www.torproject.org">Tor network</a>.</p>
+<!-- /p -->
+
+<h4>Others</h4>
+
+<p>
+ I never had to substitute the web browser since I already used <a
+ href="https://www.mozilla.org/firefox/">Firefox</a>, and as for the photo hosting service, I just
+ don't upload them online anymore and I use the <a
+ href="https://www.simplemobiletools.com/gallery/">Simple Gallery</a> app (you can install it for
+ free from <a
+ href="https://f-droid.org/en/packages/com.simplemobiletools.gallery.pro/">F-Droid</a>). I also
+ substituted Android's custom ROM, but I will talk about that some other time.</p>
+<!-- /p -->
+
+<h4>Temporarily not replaced</h4>
+
+<p>
+ I temporarily haven't replaced one service: Google Maps. Its accuracy is so good that it is hard
+ to match. I have downloaded <a href="https://osmand.net/">OsmAnd</a>, but when searching for
+ public transport routes, I still check Google Maps.</p>
+<!-- /p -->
+
+<h3>3. Privacy</h3>
+
+<p>
+ When looking for all the new services in order to get end-to-end encryption, I already looked at
+ their policies in relation to privacy, so this problem was solved as well.</p>
+<!-- /p -->
+
+<h2>Conclusion</h2>
+
+<p>
+ It took me some time to make all these changes, especially my phone's operative system and my
+ email address—I still use the old one with a lot of people, I am progressively updating it. Some
+ of the services are hard to replace and it takes time to get used to the new providers. However,
+ if you are interested in getting privacy when sending personal emails or saving files online, it
+ is worth the change.</p>
+<!-- /p -->
diff --git a/content/blog/2019-09-23-upgrading-providers.md b/content/blog/2019-09-23-upgrading-providers.md
@@ -1,146 +0,0 @@
-<!-- title: Upgrading to privacy-conscious providers -->
-<!-- slug: upgrading-providers -->
-<!-- categories: Cryptography, Decentralization, Privacy -->
-<!-- date: 2019-09-23T00:00:00Z -->
-<!-- lastmod: 2019-09-24T00:00:00Z -->
-
-I have been reading a lot about decentralization and not depending too much in
-one company in the past six months and I realized how much I relied on Google:
-my email, all my files, contacts, calendars, pictures... Most of my data was
-stored on their servers. This was inconvenient for three reasons: (1) if
-something was to happen to Google or my account, I would lose a lot of data, (2)
-Google doesn't use end-to-end encryption, which means that they (and anyone with
-access to their servers) can see all my files, emails, etc. and (3) Google
-already uses all this data (and other it collects) to better know my
-personality.
-
-Some people might think that the main three problems I have with Google aren't
-that important. In fact, I have used Google for many years because that was my
-opinion for a long time. However, the more I read about the issue, the more I
-realize they aren't minor problems. I realized that for me it is worth it to pay
-$12 or $24 a year in exchange for privacy. If you are still doubting, [this
-post][mw] might change your mind.
-
-***
-
-Let's see what I needed out of my new providers/configuration:
-
-1. Control over my data: if something were to happen to my account, it shouldn't
- affect me too much.
-2. Encrypting my data: end-to-end encryption for my services, so there wasn't a
- need to "trust" the provider, as well as to avoid any problems in case the
- servers were compromised—which is not that uncommon.
-3. Privacy: the provider shouldn't be using my data in any way (which is mostly
- solved with end-to-end encryption).
-
-### 1. Control over my data
-
-My first problem was easily solvable, I simply needed to back up everything that
-was on the cloud. That process was pretty easy using [Google's export tool][to].
-With a few clicks, everything was ready, and I only had to wait for Google to
-collect all the data and create the file. I'm not sure how much that took, I
-would say less than an hour, but definitely less than a day (it was a long ago,
-so I don't remember).
-
-Selecting all the different services I wanted to export from one page instead of
-having to go to each service's URL and then select export made the process so
-much smoother. I was surprised by how easy the export was, and all the data was
-in convenient files to import to other services: contacts in a VCF file,
-calendar in an iCal file... which makes a lot of sense, but not all services
-allow such an easy process to export everything and ready to use in a different
-service. Fortunately, that was the case, so my next problem was a lot easier to
-solve.
-
-### 2. Encrypting my data
-
-In order to encrypt my content, I needed to find an alternative to a lot of
-services that Google was offering me (or use tools such as [Cryptomator][c],
-which was discarded because of problem number 3). And so the search
-began.
-
-#### Email
-
-There are a lot of encrypted mailboxes and there is also the option of
-self-hosting email. I wasn't interested in managing my own server just for my
-email, so I had to choose a provider. Many of the sources I checked recommended
-[Protonmail][pm] and [Tutanota][tn], among others. They both looked nice and
-offered a free tier, so I tried them. After some time, I finally decided to go
-with Tutanota because of how they approached their user community as well as
-other details (for instance, their app not using any of the Google Play
-Services), although it was a hard choice.
-
-#### File storage
-
-Most of my files in the cloud were old and not usually needed, they were just
-online because I used Google Drive as my home folder. The solution was easy: I
-backed them up on an offline external storage as well as on my computer and
-deleted them from the cloud.
-
-As for the few files I actually needed online (the ones I use both at home and
-at college), I now use a USB stick to have them wherever I go, as well as
-backing them up every once in a while. No need to have them online, and it is
-faster to plug in a USB stick than log in to Google Drive and download the files
-(which was what I was doing on all computers running GNU/Linux).
-
-There is one type of file I haven't replaced yet: anything that was shared is
-still on my Drive (even if other services offer it, for now, I am fine with
-using Google).
-
-#### Calendar and contacts
-
-I created an account in a Nextcloud instance for my calendar and contacts.
-Nextcloud is very intuitive and I like the user interface. There's the
-[DAVx⁵][dx] app that synchronizes them to my phone, so that was an easy choice.
-Having an account at a Nextcloud instance is also useful in case I want to
-upload files and it also allows me to sync my [Joplin][j] notes.
-
-#### Search
-
-I thought the search engine would be the hardest service to substitute, however,
-there are a lot of good alternatives. The one I went for is [DuckDuckGo][ddg]
-which works pretty well and also works if you are connected to the internet
-through the [Tor network][tor].
-
-#### Others
-
-I never had to substitute the web browser since I already used [Firefox][ff],
-and as for the photo hosting service, I just don't upload them online anymore
-and I use the [Simple Gallery][sg] app (you can install it for free from
-[F-Droid][fd]). I also substituted Android's custom ROM, but I will talk about
-that some other time.
-
-#### Temporarily not replaced
-
-I temporarily haven't replaced one service: Google Maps. Its accuracy is so good
-that it is hard to match. I have downloaded [OsmAnd][oa], but when searching for
-public transport routes, I still check Google Maps.
-
-### 3. Privacy
-
-When looking for all the new services in order to get end-to-end encryption, I
-already looked at their policies in relation to privacy, so this problem was
-solved as well.
-
-## Conclusion
-
-It took me some time to make all these changes, especially my phone's operative
-system and my email address—I still use the old one with a lot of people, I am
-progressively updating it. Some of the services are hard to replace and it takes
-time to get used to the new providers. However, if you are interested in getting
-privacy when sending personal emails or saving files online, it is worth the
-change.
-
-
-[mw]: <https://www.gnu.org/proprietary/malware-google.html> "Google's Software is Malware — GNU Project"
-[to]: <https://takeout.google.com/> "Takeout — Google"
-[c]: <https://cryptomator.org> "Cryptomator"
-[pm]: <https://protonmail.com> "Protonmail"
-[tn]: <https://tutanota.com> "Tutanota"
-[dx]: <https://www.davx5.com> "DAVx5"
-[j]: <https://joplinapp.org> "Joplin"
-[ddg]: <https://duckduckgo.com> "DuckDuckGo"
-[tor]: <https://www.torproject.org> "Tor project"
-[ff]: <https://www.mozilla.org/firefox/> "Firefox"
-[sg]: <https://www.simplemobiletools.com/gallery/> "Simple Gallery"
-[fd]: <https://f-droid.org/en/packages/com.simplemobiletools.gallery.pro/> "Simple Gallery — F-Droid"
-[oa]: <https://osmand.net/> "OsmAnd"
diff --git a/content/blog/2019-10-06-dark-theme.html b/content/blog/2019-10-06-dark-theme.html
@@ -0,0 +1,59 @@
+<!-- title: Creating a dark theme -->
+<!-- slug: dark-theme -->
+<!-- categories: Personal domain, Projects -->
+<!-- date: 2019-10-06T00:00:00Z -->
+
+<p>
+ The first contact I had with HTML and CSS was about two years ago, when I created my first website
+ along with a friend who already had some experience with them, as well as with JavaScript. We used
+ a premade theme (based on <a href="https://getbootstrap.com/">Bootstrap</a>), so I didn't really
+ learn much CSS, but I started understanding what was HTML and how it worked. One year later, I
+ wanted to design my own website and I decided to build my own theme. I looked up many CSS
+ frameworks and ended up using <a href="https://bulma.io/">Bulma</a> because of how simple it is (I
+ didn't need many features for a personal website). It worked pretty well and I had a first contact
+ with CSS and SASS, but when I finally finished my page and released it under my domain, I soon
+ wanted another feature: the possibility to change to a dark theme.</p>
+<!-- /p -->
+
+<p>
+ I started looking for dark colors that I liked and I came up with a nice design, now I needed to
+ combine the two designs with a simple toggle JavaScript function. The way I implemented it, the
+ function switched the default CSS file for the one defining the dark theme. However, if you try to
+ change your theme by changing the stylesheet, you will realize that it takes a split of a second
+ for the page to re-render, especially the first time you toggle the theme since it has to download
+ the whole file before rendering the page. It can sound like a minor problem, but it was notable,
+ so I tried to shorten the time needed to toggle the theme. I used a tool (unCSS) that removes
+ unused CSS from a stylesheet, which made the file so much smaller but, although the download time
+ was reduced, the page still took too long to re-render. Looking around online I concluded that my
+ best option was to make only one file using CSS variables, and just change the value by changing
+ HTML elements' classes with the JavaScript function.</p>
+<!-- /p -->
+
+<p>
+ The problem with using variables with Bulma is that it uses SASS functions that given a color,
+ output a different one (and it can't do that if the input color is a variable) so it doesn't
+ <em>compile</em>. I tried to change the affected functions with similar ones supported in CSS, but
+ the result wasn't what I wanted, and it changed a lot of things related to Bulma. After some
+ thought, I decided to refrain from using a framework and just create a tailored stylesheet for my
+ website. That would allow me to abandon the unCSS tool—which was pretty inconvenient to use—as
+ well as having a better understanding of my CSS file.</p>
+<!-- /p -->
+
+<p>
+ Looking around for simple themes to base my new stylesheet in, I found a couple that, combined,
+ could result in a similar website than the one I had. I based my theme on the <a
+ href="https://github.com/nanxiaobei/hugo-paper/">Hugo Paper</a> theme (you can see that the cards
+ look very similar) and I added a header (inspired by the <a
+ href="https://github.com/shankar/hugo-grapes/">Hugo Grapes</a> theme) and a footer. I changed how
+ some elements appeared (such as the tables), I added some more features that I found interesting
+ and I themed it with the colors I wanted. I also used my old site to inspire the new features
+ (especially the header and footer), so it might resemble a site using Bulma, although it is
+ not.</p>
+<!-- /p -->
+
+<p>
+ The process took a lot of time, since learning how everything worked and completely redoing the
+ stylesheet was very time-consuming, however, the result was worth the time. Finally, you can enjoy
+ a dark theme that toggles instantly, and it is now so much easier for me to redesign certain parts
+ of the website, as I know more CSS and have a better understanding of my stylesheet.</p>
+<!-- /p -->
diff --git a/content/blog/2019-10-06-dark-theme.md b/content/blog/2019-10-06-dark-theme.md
@@ -1,61 +0,0 @@
-<!-- title: Creating a dark theme -->
-<!-- slug: dark-theme -->
-<!-- categories: Personal domain, Projects -->
-<!-- date: 2019-10-06T00:00:00Z -->
-
-The first contact I had with HTML and CSS was about two years ago, when I
-created my first website along with a friend who already had some experience
-with them, as well as with JavaScript. We used a premade theme (based on
-[Bootstrap][bs]), so I didn't really learn much CSS, but I started understanding
-what was HTML and how it worked. One year later, I wanted to design my own
-website and I decided to build my own theme. I looked up many CSS frameworks and
-ended up using [Bulma][b] because of how simple it is (I didn't need many
-features for a personal website). It worked pretty well and I had a first
-contact with CSS and SASS, but when I finally finished my page and released it
-under my domain, I soon wanted another feature: the possibility to change to a
-dark theme.
-
-I started looking for dark colors that I liked and I came up with a nice design,
-now I needed to combine the two designs with a simple toggle JavaScript
-function. The way I implemented it, the function switched the default CSS file
-for the one defining the dark theme. However, if you try to change your theme by
-changing the stylesheet, you will realize that it takes a split of a second for
-the page to re-render, especially the first time you toggle the theme since it
-has to download the whole file before rendering the page. It can sound like a
-minor problem, but it was notable, so I tried to shorten the time needed to
-toggle the theme. I used a tool (unCSS) that removes unused CSS from a
-stylesheet, which made the file so much smaller but, although the download time
-was reduced, the page still took too long to re-render. Looking around online I
-concluded that my best option was to make only one file using CSS variables, and
-just change the value by changing HTML elements' classes with the JavaScript
-function.
-
-The problem with using variables with Bulma is that it uses SASS functions that
-given a color, output a different one (and it can't do that if the input color
-is a variable) so it doesn't *compile*. I tried to change the affected functions
-with similar ones supported in CSS, but the result wasn't what I wanted, and it
-changed a lot of things related to Bulma. After some thought, I decided to
-refrain from using a framework and just create a tailored stylesheet for my
-website. That would allow me to abandon the unCSS tool—which was pretty
-inconvenient to use—as well as having a better understanding of my CSS file.
-
-Looking around for simple themes to base my new stylesheet in, I found a couple
-that, combined, could result in a similar website than the one I had. I based my
-theme on the [Hugo Paper][hp] theme (you can see that the cards look very
-similar) and I added a header (inspired by the [Hugo Grapes][hg] theme) and a
-footer. I changed how some elements appeared (such as the tables), I added some
-more features that I found interesting and I themed it with the colors I wanted.
-I also used my old site to inspire the new features (especially the header and
-footer), so it might resemble a site using Bulma, although it is not.
-
-The process took a lot of time, since learning how everything worked and
-completely redoing the stylesheet was very time-consuming, however, the result
-was worth the time. Finally, you can enjoy a dark theme that toggles instantly,
-and it is now so much easier for me to redesign certain parts of the website, as
-I know more CSS and have a better understanding of my stylesheet.
-
-
-[bs]: <https://getbootstrap.com/> "Bootstrap"
-[b]: <https://bulma.io/> "Bulma"
-[hp]: <https://github.com/nanxiaobei/hugo-paper/> "Hugo Paper — GitHub"
-[hg]: <https://github.com/shankar/hugo-grapes/> "Hugo Grapes — GitHub"
diff --git a/content/blog/2019-10-19-password-manager.html b/content/blog/2019-10-19-password-manager.html
@@ -0,0 +1,102 @@
+<!-- title: Switching to a password manager -->
+<!-- slug: password-manager -->
+<!-- categories: Cryptography -->
+<!-- date: 2019-10-19T00:00:00Z -->
+
+<p>
+ Before I learned about password managers, less than a year ago, having all my passwords on the
+ same place sounded like a really bad idea—if someone managed to get access to "that place", they
+ could log in to all my accounts, to my <em>online identity</em>.</p>
+<!-- /p -->
+
+<p>
+ As I learned about security (particularly when using the internet), it became a better idea, to
+ the point that I now have used one for over half a year. I use <a
+ href="https://keepassxc.org/">KeePassXC</a>, an offline password manager. I have also been
+ recommended an online alternative (<a href="https://bitwarden.com/">Bitwarden</a>), although I
+ haven't used it because I would much rather not have my passwords online.</p>
+<!-- /p -->
+
+<h2>Password requirements</h2>
+
+<p>
+ Before considering whether having a password manager is worth it or not, it is necessary to expose
+ what I require of my passwords.</p>
+<!-- /p -->
+
+<ul>
+ <li>
+ <strong>Unique passwords for each account</strong>: if one of the sites I use was to be hacked
+ and my password compromised, that should not be a problem for any of my other accounts. I think
+ it is a pretty reasonable requirement if I want to lower the chances of my accounts being
+ accessed by unauthorised parties, however, it makes remembering all my passwords a lot
+ harder.</li>
+ <!-- /li -->
+ <li>
+ <strong>Complex passwords</strong>: my passwords should be hard to guess for a computer. You can
+ imagine what type of password is easy to guess—or you can find examples on <a
+ href="https://en.wikipedia.org/wiki/Password_strength#Examples_of_weak_passwords">Wikipedia</a>—,
+ however, even if we complicate passwords a little more they are still pretty easy to guess. In
+ the end, what I mean by "complex" is that they should be long [pseudo]randomly-generated
+ passwords that contain letters, numbers and special characters (long being about 16 characters,
+ although normally I use more since adding characters is nearly free of cost when using a
+ password manager).</li>
+ <!-- /li -->
+</ul>
+
+<h2>Dealing with complex passwords</h2>
+
+<p>
+ Trying to remember passwords that fulfill my requirements gets incredibly hard very quickly (at
+ least in my case). So I eventually realized I needed to rely on something different than my own
+ memory if I wanted unique complex passwords. I had two options: have a physical notebook where I
+ would write my passwords (avoiding the risk of my passwords gotten stolen if my computer was
+ compromised) or use a password manager.</p>
+<!-- /p -->
+
+<p>
+ The notebook option was quickly discarded since typing the passwords in would take too much time
+ (as well as writing them down when originally generated). In my case, someone accessing the
+ passwords in my notebook—which is a lot of people's concern—wouldn't be an issue, since the
+ notebook could be kept safe somewhere at home, but this solution just isn't efficient enough for
+ me.</p>
+<!-- /p -->
+
+<p>
+ So using a password manager was a natural solution to manage my passwords. Although there are
+ options to self-host an online password vault, I don't feel confident doing so, that's why I use
+ an offline password manager. All my passwords are organized in folders on an encrypted database,
+ but KeePassXC can do a lot more than that. It can create randomly generated passwords and has an
+ auto-type feature that makes typing 30 character long passwords a breeze. It can also store extra
+ information like <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm">TOTP</a>
+ keys, but also miscellaneous information, both as an attribute-value pair or as plain-text notes.
+ It has other features you might find useful, these are just the ones I use the most.</p>
+<!-- /p -->
+
+<p>
+ On top of that, having a password manager enables me to track all my online accounts, making it
+ easier to spot and remove old unused accounts.</p>
+<!-- /p -->
+
+<h2>Final comments</h2>
+
+<p>
+ There is an option I haven't discussed yet:
+ <a href="https://en.wikipedia.org/wiki/Multi-factor_authentication">Multi-Factor Authentification</a>
+ (or Two-Factor Authentification). Although it is very useful, a lot of online services still don't
+ offer an option for it and it is easier for me to just use a password manager, however, 2FA might
+ be better suited for you (because it allows you to be less strict on the password requirements
+ while still keeping your accounts safe).</p>
+<!-- /p -->
+
+<p>
+ On a different note, some might say that it would be unusual for someone to try and hack my
+ accounts by brute-forcing them (after all, they don't contain anything useful to a random stranger
+ or entity), and it is probably true, but that isn't a good enough argument to give up on my
+ security.</p>
+<!-- /p -->
+
+<p>
+ On the whole, I find that using a password manager grants me a lot of useful tools, while the
+ drawbacks are nearly imperceptible.</p>
+<!-- /p -->
diff --git a/content/blog/2019-10-19-password-manager.md b/content/blog/2019-10-19-password-manager.md
@@ -1,86 +0,0 @@
-<!-- title: Switching to a password manager -->
-<!-- slug: password-manager -->
-<!-- categories: Cryptography -->
-<!-- date: 2019-10-19T00:00:00Z -->
-
-Before I learned about password managers, less than a year ago, having all my
-passwords on the same place sounded like a really bad idea—if someone managed to
-get access to "that place", they could log in to all my accounts, to my *online
-identity*.
-
-As I learned about security (particularly when using the internet), it became a
-better idea, to the point that I now have used one for over half a year. I use
-[KeePassXC][kp], an offline password manager. I have also been recommended an
-online alternative ([Bitwarden][bw]), although I haven't used it because I would
-much rather not have my passwords online.
-
-## Password requirements
-
-Before considering whether having a password manager is worth it or not, it is
-necessary to expose what I require of my passwords.
-
-- **Unique passwords for each account**: if one of the sites I use was to be
- hacked and my password compromised, that should not be a problem for any of
- my other accounts. I think it is a pretty reasonable requirement if I want to
- lower the chances of my accounts being accessed by unauthorised parties,
- however, it makes remembering all my passwords a lot harder.
-- **Complex passwords**: my passwords should be hard to guess for a computer.
- You can imagine what type of password is easy to guess—or you can find
- examples on [Wikipedia][wp]—, however, even if we complicate passwords a
- little more they are still pretty easy to guess. In the end, what I mean by
- "complex" is that they should be long [pseudo]randomly-generated passwords
- that contain letters, numbers and special characters (long being about 16
- characters, although normally I use more since adding characters is nearly
- free of cost when using a password manager).
-
-## Dealing with complex passwords
-
-Trying to remember passwords that fulfill my requirements gets incredibly hard
-very quickly (at least in my case). So I eventually realized I needed to rely on
-something different than my own memory if I wanted unique complex passwords. I
-had two options: have a physical notebook where I would write my passwords
-(avoiding the risk of my passwords gotten stolen if my computer was compromised)
-or use a password manager.
-
-The notebook option was quickly discarded since typing the passwords in would
-take too much time (as well as writing them down when originally generated). In
-my case, someone accessing the passwords in my notebook—which is a lot of
-people's concern—wouldn't be an issue, since the notebook could be kept safe
-somewhere at home, but this solution just isn't efficient enough for me.
-
-So using a password manager was a natural solution to manage my passwords.
-Although there are options to self-host an online password vault, I don't feel
-confident doing so, that's why I use an offline password manager. All my
-passwords are organized in folders on an encrypted database, but KeePassXC can
-do a lot more than that. It can create randomly generated passwords and has an
-auto-type feature that makes typing 30 character long passwords a breeze. It can
-also store extra information like [TOTP][totp] keys, but also miscellaneous
-information, both as an attribute-value pair or as plain-text notes. It has
-other features you might find useful, these are just the ones I use the most.
-
-On top of that, having a password manager enables me to track all my online
-accounts, making it easier to spot and remove old unused accounts.
-
-## Final comments
-
-There is an option I haven't discussed yet: [Multi-Factor Authentification][mfa]
-(or Two-Factor Authentification). Although it is very useful, a lot of online
-services still don't offer an option for it and it is easier for me to just use
-a password manager, however, 2FA might be better suited for you (because it
-allows you to be less strict on the password requirements while still keeping
-your accounts safe).
-
-On a different note, some might say that it would be unusual for someone to try
-and hack my accounts by brute-forcing them (after all, they don't contain
-anything useful to a random stranger or entity), and it is probably true, but
-that isn't a good enough argument to give up on my security.
-
-On the whole, I find that using a password manager grants me a lot of useful
-tools, while the drawbacks are nearly imperceptible.
-
-
-[kp]: <https://keepassxc.org/> "KeePassXC"
-[bw]: <https://bitwarden.com/> "Bitwarden"
-[wp]: <https://en.wikipedia.org/wiki/Password_strength#Examples_of_weak_passwords> "Examples of weak passwords — Wikipedia"
-[totp]: <https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm> "TOTP — Wikipedia"
-[mfa]: <https://en.wikipedia.org/wiki/Multi-factor_authentication> "Multi-Factor Authentification — Wikipedia"
diff --git a/content/blog/2019-10-27-ship-scrappy.html b/content/blog/2019-10-27-ship-scrappy.html
@@ -0,0 +1,42 @@
+<!-- title: Ship scrappy -->
+<!-- slug: ship-scrappy -->
+<!-- categories: Miscellany -->
+<!-- date: 2019-10-27T00:00:00Z -->
+
+<blockquote>
+ <p>
+ The only choice is to launch before you’re ready.<br/>
+ Before it’s perfect.<br/>
+ Before it’s 100% proven to be no risk to you.<br/>
+ At that moment, your resistance says, “don’t ship it, it’s crappy stuff. We don’t ship crap.”<br/>
+ And it’s true that you shouldn’t ship work that’s hurried, sloppy or ungenerous.<br/>
+ But what’s actually on offer is something scrappy.<br/>
+ Scrappy means that while it’s unpolished, it’s better than good enough.<br/>
+ Scrappy doesn’t care about cosmetics as much as it cares about impact.<br/>
+ Scrappy is flexible and resilient and ready to learn.<br/>
+ Ship scrappy.</p>
+ <!-- /p -->
+ <p>— <em><a href="https://seths.blog/2019/07/scrappy-is-not-the-same-as-crappy/">Seth's Blog</a></em></p>
+</blockquote>
+
+<p>
+ I just wanted to post this interesting reflexion, as I tend to make sure everything is 100%
+ perfect before "shipping it". In some scenarios, this can be good, since you don't want what you
+ are releasing to have any bugs or errors, but sometimes it is better to publish something yet to
+ be perfected (for instance, my personal website).</p>
+<!-- /p -->
+
+<p>
+ The publication of my personal website/blog had been postponed for a long time, waiting for my own
+ approval on every detail. Finally, this summer I read a couple of articles about just starting a
+ blog, without much preparation, and then just "seeing how it goes", so I did it (at this point, a
+ big part of the site was already developed). Not only did I start writing posts and doing other
+ things I would have probably delayed until other unrelated parts were finished (like having a dark
+ theme or deciding on the favicon), but I also realized some of the features that I wanted to
+ implement were not that important.</p>
+<!-- /p -->
+
+<p>
+ If you are waiting to release something, reluctant to publish it because it might have a bug,
+ maybe you should try to do it—you can always tag it as a work in progress.</p>
+<!-- /p -->
diff --git a/content/blog/2019-10-27-ship-scrappy.md b/content/blog/2019-10-27-ship-scrappy.md
@@ -1,39 +0,0 @@
-<!-- title: Ship scrappy -->
-<!-- slug: ship-scrappy -->
-<!-- categories: Miscellany -->
-<!-- date: 2019-10-27T00:00:00Z -->
-
-> The only choice is to launch before you’re ready.<br/>
-> Before it’s perfect.<br/>
-> Before it’s 100% proven to be no risk to you.<br/>
-> At that moment, your resistance says, “don’t ship it, it’s crappy stuff. We don’t ship crap.”<br/>
-> And it’s true that you shouldn’t ship work that’s hurried, sloppy or ungenerous.<br/>
-> But what’s actually on offer is something scrappy.<br/>
-> Scrappy means that while it’s unpolished, it’s better than good enough.<br/>
-> Scrappy doesn’t care about cosmetics as much as it cares about impact.<br/>
-> Scrappy is flexible and resilient and ready to learn.<br/>
-> Ship scrappy.
->
-> — *[Seth's Blog][ss]*
-
-I just wanted to post this interesting reflexion, as I tend to make sure
-everything is 100% perfect before "shipping it". In some scenarios, this can be
-good, since you don't want what you are releasing to have any bugs or errors,
-but sometimes it is better to publish something yet to be perfected (for
-instance, my personal website).
-
-The publication of my personal website/blog had been postponed for a long time,
-waiting for my own approval on every detail. Finally, this summer I read a
-couple of articles about just starting a blog, without much preparation, and
-then just "seeing how it goes", so I did it (at this point, a big part of the
-site was already developed). Not only did I start writing posts and doing other
-things I would have probably delayed until other unrelated parts were finished
-(like having a dark theme or deciding on the favicon), but I also realized some
-of the features that I wanted to implement were not that important.
-
-If you are waiting to release something, reluctant to publish it because it
-might have a bug, maybe you should try to do it—you can always tag it as a work
-in progress.
-
-
-[ss]: <https://seths.blog/2019/07/scrappy-is-not-the-same-as-crappy/> "'Scrappy' is not the same as 'crappy' — Seth's Blog"
diff --git a/content/blog/2019-11-04-new-host.html b/content/blog/2019-11-04-new-host.html
@@ -0,0 +1,45 @@
+<!-- title: New website hosting servers -->
+<!-- slug: new-host -->
+<!-- categories: Decentralization, Personal domain -->
+<!-- date: 2019-11-04T00:00:00Z -->
+
+<p>
+ Until yesterday, this website had been hosted by <a href="https://gitlab.com">GitLab</a> (using
+ GitLab Pages). For some time now the fact that they used servers owned by Google bothered me, so I
+ have been looking for a new host for a while.</p>
+<!-- /p -->
+
+<p>
+ One possibility I looked at was paying for a virtual private server. They aren't particularly
+ expensive, but since the complete website's size is under 1MiB, a whole virtual server is a bit
+ too much. Of course, I could use it to host other services (maybe a private Gitea instance, or a
+ database to backup my files), but those are services that I don't need right now. Besides, I still
+ wouldn't have any power to ensure no IPs of my visitors are logged somewhere, so it wouldn't solve
+ my problems.</p>
+<!-- /p -->
+
+<p>
+ Another option I considered was getting a home server. I would love to learn how to build a server
+ out of nothing, set it up and get it up and running, but I don't want to have a computer running
+ 24/7 at home and, if it was to stop working, my website would be down for some time (until I
+ had spare time to fix it). Indubitably, any server can have downtime, but I trust that volunteers
+ partly dedicated to maintaining servers will be able to fix issues before I can do it myself.</p>
+<!-- /p -->
+
+<p>
+ So I had to find a privacy respecting host that would serve a small static site like mine at a
+ reasonable price. I found a couple of sites that interested me, but <a
+ href="https://www.autistici.org">Autistici/Inventati</a> was the one that got most of my
+ attention. First of all, they respect users' privacy—or so they claim—and it is one of the
+ projects that has given me the best impression in this matter so far. They also have a
+ decentralized network thanks to the <a href="https://www.autistici.org/who/rplan/">R* plan</a>
+ and, on top of that, the project has ethical values that I share (something that I wasn't looking
+ for in a host, but is much appreciated). Finally, my hosting is free of charge, although I will
+ donate to the project to help it keep running.</p>
+<!-- /p -->
+
+<p>
+ In conclusion, I am very happy with my new host. It is better than what I was looking for and I
+ get to choose how much I want to pay for it. What is more, I know that anything I donate to
+ support it will go to a project trying to make a better internet.</p>
+<!-- /p -->
diff --git a/content/blog/2019-11-04-new-host.md b/content/blog/2019-11-04-new-host.md
@@ -1,44 +0,0 @@
-<!-- title: New website hosting servers -->
-<!-- slug: new-host -->
-<!-- categories: Decentralization, Personal domain -->
-<!-- date: 2019-11-04T00:00:00Z -->
-
-Until yesterday, this website had been hosted by [GitLab][gl] (using GitLab
-Pages). For some time now the fact that they used servers owned by Google
-bothered me, so I have been looking for a new host for a while.
-
-One possibility I looked at was paying for a virtual private server. They aren't
-particularly expensive, but since the complete website's size is under 1MiB, a
-whole virtual server is a bit too much. Of course, I could use it to host other
-services (maybe a private Gitea instance, or a database to backup my files), but
-those are services that I don't need right now. Besides, I still wouldn't have
-any power to ensure no IPs of my visitors are logged somewhere, so it wouldn't
-solve my problems.
-
-Another option I considered was getting a home server. I would love to learn how
-to build a server out of nothing, set it up and get it up and running, but I
-don't want to have a computer running 24/7 at home and, if it was to stop
-working, my website would be down for some time (until I had spare time to fix
-it). Indubitably, any server can have downtime, but I trust that volunteers
-partly dedicated to maintaining servers will be able to fix issues before I can
-do it myself.
-
-So I had to find a privacy respecting host that would serve a small static site
-like mine at a reasonable price. I found a couple of sites that interested me,
-but [Autistici/Inventati][ai] was the one that got most of my attention. First
-of all, they respect users' privacy—or so they claim—and it is one of the
-projects that has given me the best impression in this matter so far. They also
-have a decentralized network thanks to the [R* plan][r] and, on top of that, the
-project has ethical values that I share (something that I wasn't looking for in
-a host, but is much appreciated). Finally, my hosting is free of charge,
-although I will donate to the project to help it keep running.
-
-In conclusion, I am very happy with my new host. It is better than what I was
-looking for and I get to choose how much I want to pay for it. What is more, I
-know that anything I donate to support it will go to a project trying to make a
-better internet.
-
-
-[gl]: <https://gitlab.com> "GitLab"
-[ai]: <https://www.autistici.org> "Autistici/Inventati"
-[r]: <https://www.autistici.org/who/rplan/> "R* plan — Autistici/Inventati"
diff --git a/content/blog/2019-11-10-deploying-website.html b/content/blog/2019-11-10-deploying-website.html
@@ -0,0 +1,93 @@
+<!-- title: Deploying a website using the WebDAV protocol -->
+<!-- slug: deploying-website -->
+<!-- categories: FOSS, Personal domain -->
+<!-- date: 2019-11-10T00:00:00Z -->
+
+<p>
+ Now that my website is <a href="/blog/2019/11/new-host/">hosted by Autistici/Inventati</a>, I can
+ no longer deploy it by just pushing my git repository's changes to GitLab, as I used to. In order
+ to deploy my website, I need to access the server using the WebDAV protocol. To do so, I use <a
+ href="https://savannah.nongnu.org/projects/davfs2">davfs2</a>—which mounts the WebDAV resource—so
+ I can access it like any other folder in the filesystem.</p>
+<!-- /p -->
+
+<p>
+ I had never used the WebDAV protocol before, so I used A/I's tutorial. It was was a very simple
+ tutorial, but it goes straight to the point, without giving unneeded explanations. I set it all up
+ and edited the <code>~/.davfs2/secrets</code> file to make the mounting process smother. I know
+ that having a password in plain text is a potential security risk, but the password only gives
+ access to the WebDAV service (not my whole A/I account) and is easily resettable. If someone got
+ hold of the password, all they could do is change my website, until I realized it and change
+ it.</p>
+<!-- /p -->
+
+<p>
+ Deploying the website would mean copying all the output files from <a
+ href="https://gohugo.io">Hugo</a>—the static site generator used to build my site—to the specified
+ folder on the mounted filesystem. The problem was that copying files (as well as removing them)
+ takes a long time, I am guessing due to A/I's resources' configuration. To give some context, it
+ took around 1 minute to copy 1MiB worth of files, plus 10 seconds to delete them. So deleting and
+ copying the whole folder again every time I changed something wasn't a good deploying method
+ (besides, it wastes resources server-side).</p>
+<!-- /p -->
+
+<p>
+ The solution I chose was <a href="https://rsync.samba.org">rsync</a>. It is a great piece of
+ software that efficiently transfers files from one folder to another. It checks the last
+ modification time and the file size to avoid transferring files that are up to date. I already
+ knew this program as I use it to back up my computers to hard drives (it reduces the backup time
+ considerably after the first time), so implementing it should have been a breeze. I encountered
+ two problems:</p>
+<!-- /p -->
+
+<ol>
+ <li>
+ By default, <code>rsync</code> makes use of modification times to check whether a file should be
+ transferred, but every time I build my site, all files are created again, so the modification
+ times are always newer than the ones in the server.<br/>
+
+ There is a quick fix for this: the program has an option (<code>-c</code> or
+ <code>--checksum</code>) that makes the program use the checksum of a file (instead of
+ the modification time) along with the file size to determine whether it has
+ changed.</li>
+ <!-- /li -->
+ <li>
+ <code>rsync</code> makes use of auxiliary files while synchronizing them. For some reason (that
+ I still don't know, my guess is something to do with permissions), when those auxiliary files
+ are finally renamed to the definitive filename, it fails, giving out an error and exiting
+ without any file transferred.<br/>
+
+ To fix this issue, I used the <code>--temp-dir</code> option to specify a local directory as the
+ one that should be used for the temporary files. With that set up, it doesn't give any more
+ errors.</li>
+ <!-- /li -->
+</ol>
+
+<p>
+ So finally the <code>rsync</code> command worked, and the time used to update the website is now
+ around 10 seconds, which is a lot better than a minute (considering my website might get larger,
+ the impact can be even bigger). To automate the process I build a little script that will mount
+ the filesystem, build the site, synchronize it with the server and unmount it again:</p>
+<!-- /p -->
+
+<pre><code class="language-bash"><!--
+ -->#!/bin/bash
+
+<!-- -->HUGO_PATH="{path_to_hugo_directory}"
+<!-- -->TEMP_DIR="{path_to_temp_directory_to_use_with_rsync}"
+<!-- -->MOUNT_PATH="{path_to_the_mounted_directory}"
+<!-- -->WEBDAV_FOLDER="{website_directory_in_webdav_filesystem}"
+
+<!-- -->rm -rf $HUGO_PATH/public
+<!-- -->hugo -s $HUGO_PATH --minify
+<!-- -->mount $MOUNT_PATH
+<!-- -->mkdir $TEMP_DIR
+<!-- -->rsync -ruvc --progress --delete --temp-dir=$TEMP_DIR $HUGO_PATH/public/ $MOUNT_PATH/$WEBDAV_FOLDER
+<!-- -->rmdir $TEMP_DIR
+<!-- -->umount $MOUNT_PATH</code></pre>
+
+<p>
+ As you can see, it is a very simple script. It removes the last built of the site from the local
+ filesystem and builds it again (using the <code>--minify</code> option to reduce file sizes), it
+ mounts the WebDAV resource, transfers the files and then unmounts the resource again.</p>
+<!-- /p -->
diff --git a/content/blog/2019-11-10-deploying-website.md b/content/blog/2019-11-10-deploying-website.md
@@ -1,87 +0,0 @@
-<!-- title: Deploying a website using the WebDAV protocol -->
-<!-- slug: deploying-website -->
-<!-- categories: FOSS, Personal domain -->
-<!-- date: 2019-11-10T00:00:00Z -->
-
-Now that my website is [hosted by Autistici/Inventati][hb], I can no longer
-deploy it by just pushing my git repository's changes to GitLab, as I used to.
-In order to deploy my website, I need to access the server using the WebDAV
-protocol. To do so, I use [davfs2][d]—which mounts the WebDAV resource—so I can
-access it like any other folder in the filesystem.
-
-I had never used the WebDAV protocol before, so I used A/I's tutorial. It was
-was a very simple tutorial, but it goes straight to the point, without giving
-unneeded explanations. I set it all up and edited the `~/.davfs2/secrets` file
-to make the mounting process smother. I know that having a password in plain
-text is a potential security risk, but the password only gives access to the
-WebDAV service (not my whole A/I account) and is easily resettable. If someone
-got hold of the password, all they could do is change my website, until I
-realized it and change it.
-
-Deploying the website would mean copying all the output files from
-[Hugo][hugo]—the static site generator used to build my site—to the specified
-folder on the mounted filesystem. The problem was that copying files (as well as
-removing them) takes a long time, I am guessing due to A/I's resources'
-configuration. To give some context, it took around 1 minute to copy 1MiB worth
-of files, plus 10 seconds to delete them. So deleting and copying the whole
-folder again every time I changed something wasn't a good deploying method
-(besides, it wastes resources server-side).
-
-The solution I chose was [rsync][r]. It is a great piece of software that
-efficiently transfers files from one folder to another. It checks the last
-modification time and the file size to avoid transferring files that are up to
-date. I already knew this program as I use it to back up my computers to hard
-drives (it reduces the backup time considerably after the first time), so
-implementing it should have been a breeze. I encountered two problems:
-
-1. By default, `rsync` makes use of modification times to check whether a file
- should be transferred, but every time I build my site, all files are created
- again, so the modification times are always newer than the ones in the
- server.<br/>
- There is a quick fix for this: the program has an option (`-c` or
- `--checksum`) that makes the program use the checksum of a file (instead of
- the modification time) along with the file size to determine whether it has
- changed.
-
-2. `rsync` makes use of auxiliary files while synchronizing them. For some
- reason (that I still don't know, my guess is something to do with
- permissions), when those auxiliary files are finally renamed to the definitive
- filename, it fails, giving out an error and exiting without any file
- transferred.<br/>
- To fix this issue, I used the `--temp-dir` option to specify a
- local directory as the one that should be used for the temporary files. With
- that set up, it doesn't give any more errors.
-
-So finally the `rsync` command worked, and the time used to update the website
-is now around 10 seconds, which is a lot better than a minute (considering my
-website might get larger, the impact can be even bigger). To automate the
-process I build a little script that will mount the filesystem, build the site,
-synchronize it with the server and unmount it again:
-
-```bash
-#!/bin/bash
-
-HUGO_PATH="{path_to_hugo_directory}"
-TEMP_DIR="{path_to_temp_directory_to_use_with_rsync}"
-MOUNT_PATH="{path_to_the_mounted_directory}"
-WEBDAV_FOLDER="{website_directory_in_webdav_filesystem}"
-
-rm -rf $HUGO_PATH/public
-hugo -s $HUGO_PATH --minify
-mount $MOUNT_PATH
-mkdir $TEMP_DIR
-rsync -ruvc --progress --delete --temp-dir=$TEMP_DIR $HUGO_PATH/public/ $MOUNT_PATH/$WEBDAV_FOLDER
-rmdir $TEMP_DIR
-umount $MOUNT_PATH
-```
-
-As you can see, it is a very simple script. It removes the last built of the
-site from the local filesystem and builds it again (using the `--minify` option
-to reduce file sizes), it mounts the WebDAV resource, transfers the files and
-then unmounts the resource again.
-
-
-[hb]: </blog/2019/11/new-host/> "New website hosting servers — Oscar Benedito"
-[d]: <https://savannah.nongnu.org/projects/davfs2> "davfs2 — NonGNU Savannah"
-[hugo]: <https://gohugo.io> "Hugo"
-[r]: <https://rsync.samba.org> "rsync"
diff --git a/content/blog/2019-11-17-lineageos-with-microg.html b/content/blog/2019-11-17-lineageos-with-microg.html
@@ -0,0 +1,106 @@
+<!-- title: Switching to LineageOS with microG -->
+<!-- slug: lineageos-with-microg -->
+<!-- categories: FOSS, Privacy -->
+<!-- date: 2019-11-17T00:00:00Z -->
+<!-- lastmod: 2019-11-22T00:00:00Z -->
+
+<p>
+ One of the things I wanted to do when switching to more privacy-respecting providers was getting
+ rid of Google Services on my phone. According to multiple articles, your Android phone gathers a
+ lot of data and sends it to Google. It is true that my daily routine isn't a big secret, and any
+ friend who asked me could probably get my location, but giving it away without my (explicit)
+ consent is a completely different thing.</p>
+<!-- /p -->
+
+<h2>First attempt</h2>
+
+<p>
+ I first installed LineageOS on my phone in January 2019. I tried installing it with Google Apps,
+ but I then realized I was back with Google, so I decided to go with <a
+ href="https://microg.org">microG</a> (a free/libre re-implementation of Google’s proprietary
+ Android user space apps and libraries). But for some reason—unknown to me back then—, microG
+ didn't work. As a result, the apps that required those libraries didn't work either. Apps that I
+ wasn't willing to stop using, so I switched back to Android's stock ROM<sup id="fnref1"><a
+ href="#fn1">1</a></sup>.</p>
+<!-- /p -->
+
+<h2>Finding the problem</h2>
+
+<p>For some time I used Android's stock ROM, when, by chance, I read the following:</p>
+
+<blockquote>
+ <p>
+ MicroG requires a patch called "signature spoofing", which allows the microG's apps to spoof
+ themselves as Google Apps. LineageOS' developers refused (multiple times) to include the patch,
+ forcing us to fork their project.</p>
+ <!-- /p -->
+</blockquote>
+
+<p>
+ LineageOS' developers had their reasons to refuse to do it. Luckily, the microG project has found
+ a solution: they forked the project to add the signature spoofing patch. This way, you can get
+ LineageOS with microG without having to worry about the patching part. They also added the
+ "F-Droid Privileged Extension":</p>
+<!-- /p -->
+
+<blockquote>
+ <p>
+ [F-Droid Privileged Extension] allows F-Droid to install and update apps without the need of user
+ interaction or the unsafe "Unknown sources" option.</p>
+ <!-- /p -->
+</blockquote>
+
+<p>You can find more information about the fork at <a href="https://lineage.microg.org/">https://lineage.microg.org/</a>.</p>
+
+<h2>Second attempt</h2>
+
+<p>
+ So I tried installing microG's fork. The installation process is the same, so it was very easy, as
+ I already had all the required software installed on my computer and had already done all the
+ steps multiple times before.</p>
+<!-- /p -->
+
+<p>
+ This time everything turned out fine and microG libraries worked fine. I installed the apps I
+ needed from <a href="https://f-droid.org">F-Droid</a> and those that weren't there, I got from the
+ <a href="https://auroraoss.com">Aurora Store</a>, an app that allows the user to download apps
+ from the Google Play Store without actually having it installed.</p>
+<!-- /p -->
+
+<h2>Performance</h2>
+
+<p>
+ I had my doubts on whether the apps that require Google's libraries would function, but most of
+ them did (and perfectly fine!), even the ones using Google Maps—which are now using MapBox—or the
+ ones using location services. There was one app that didn't work, a game. I am not sure which was
+ the problem, but I wasn't playing the game much anyway, so I just deleted the app.</p>
+<!-- /p -->
+
+<p>
+ Most of the time I don't even notice that my OS doesn't have any Google proprietary code, as it
+ behaves (nearly) the same as if it did. If you are thinking of moving to LineageOS, check out the
+ fork, microG works very well!</p>
+<!-- /p -->
+
+<h2>Final comments</h2>
+
+<p>
+ There is one alternative to microG's fork (besides LineageOS itself) that is also an "unGoogled"
+ version of Android, <a href="https://e.foundation/">/e/</a>. Their product looks interesting,
+ however, I didn't need the extra features they add on top of LineageOS so I went with the simpler
+ option. If you are thinking about installing /e/, you might be interested in what the <a
+ href="https://ewwlo.xyz/">ewwlo</a> website claims about the project.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ It wasn't actually that quick. I tried to reinstall LineageOS with Gapps once again, but, for
+ some reason, it wouldn't work and the phone stopped working (it was stuck on the boot screen, I
+ left it for hours). I finally got help from an acquaintance (we had to go into Emergency
+ Download Mode using the test point) and I was finally able to go back to Android's stock
+ ROM. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2019-11-17-lineageos-with-microg.md b/content/blog/2019-11-17-lineageos-with-microg.md
@@ -1,86 +0,0 @@
-<!-- title: Switching to LineageOS with microG -->
-<!-- slug: lineageos-with-microg -->
-<!-- categories: FOSS, Privacy -->
-<!-- date: 2019-11-17T00:00:00Z -->
-<!-- lastmod: 2019-11-22T00:00:00Z -->
-
-One of the things I wanted to do when switching to more privacy-respecting
-providers was getting rid of Google Services on my phone. According to multiple
-articles, your Android phone gathers a lot of data and sends it to Google. It is
-true that my daily routine isn't a big secret, and any friend who asked me could
-probably get my location, but giving it away without my (explicit) consent is a
-completely different thing.
-
-## First attempt
-
-I first installed LineageOS on my phone in January 2019. I tried installing it
-with Google Apps, but I then realized I was back with Google, so I decided to go
-with [microG][mg] (a free/libre re-implementation of Google’s proprietary
-Android user space apps and libraries). But for some reason—unknown to me back
-then—, microG didn't work. As a result, the apps that required those libraries
-didn't work either. Apps that I wasn't willing to stop using, so I switched back
-to Android's stock ROM[^note].
-
-[^note]: It wasn't actually that quick. I tried to reinstall LineageOS with
- Gapps once again, but, for some reason, it wouldn't work and the phone stopped
- working (it was stuck on the boot screen, I left it for hours). I finally got
- help from an acquaintance (we had to go into Emergency Download Mode using the
- test point) and I was finally able to go back to Android's stock ROM.
-
-## Finding the problem
-
-For some time I used Android's stock ROM, when, by chance, I read the following:
-
-> MicroG requires a patch called "signature spoofing", which allows the microG's
-> apps to spoof themselves as Google Apps. LineageOS' developers refused
-> (multiple times) to include the patch, forcing us to fork their project.
-
-LineageOS' developers had their reasons to refuse to do it. Luckily, the microG
-project has found a solution: they forked the project to add the signature
-spoofing patch. This way, you can get LineageOS with microG without having to
-worry about the patching part. They also added the "F-Droid Privileged
-Extension":
-
-> [F-Droid Privileged Extension] allows F-Droid to install and update apps
-> without the need of user interaction or the unsafe "Unknown sources" option.
-
-You can find more information about the fork at <https://lineage.microg.org/>.
-
-## Second attempt
-
-So I tried installing microG's fork. The installation process is the same, so it
-was very easy, as I already had all the required software installed on my
-computer and had already done all the steps multiple times before.
-
-This time everything turned out fine and microG libraries worked fine. I
-installed the apps I needed from [F-Droid][fd] and those that weren't there, I
-got from the [Aurora Store][as], an app that allows the user to download apps
-from the Google Play Store without actually having it installed.
-
-## Performance
-
-I had my doubts on whether the apps that require Google's libraries would
-function, but most of them did (and perfectly fine!), even the ones using Google
-Maps—which are now using MapBox—or the ones using location services. There was
-one app that didn't work, a game. I am not sure which was the problem, but I
-wasn't playing the game much anyway, so I just deleted the app.
-
-Most of the time I don't even notice that my OS doesn't have any Google
-proprietary code, as it behaves (nearly) the same as if it did. If you are
-thinking of moving to LineageOS, check out the fork, microG works very well!
-
-## Final comments
-
-There is one alternative to microG's fork (besides LineageOS itself) that is
-also an "unGoogled" version of Android, [/e/][e]. Their product looks
-interesting, however, I didn't need the extra features they add on top of
-LineageOS so I went with the simpler option. If you are thinking about
-installing /e/, you might be interested in what the [ewwlo][ew] website claims
-about the project.
-
-
-[mg]: <https://microg.org> "microG"
-[gd]: <https://f-droid.org> "F-Droid"
-[as]: <https://auroraoss.com> "Aurora Store"
-[e]: <https://e.foundation/> "/e/ Foundation"
-[ew]: <https://ewwlo.xyz/> "ewwlo"
diff --git a/content/blog/2019-11-24-backups.html b/content/blog/2019-11-24-backups.html
@@ -0,0 +1,57 @@
+<!-- title: Backing up my computer -->
+<!-- slug: backups -->
+<!-- categories: FOSS, Privacy -->
+<!-- date: 2019-11-24T00:00:00Z -->
+
+<p>
+ If you have important information on your computer, you probably back it up somehow. I used to
+ save all my important files on Google Drive, which was convenient not only because it would make
+ backups automatically, but because I could access my files from any computer, or even my phone
+ without much effort.</p>
+<!-- /p -->
+
+<p>
+ Since reducing my dependency on Google, that isn't an option anymore, so I had to find an
+ alternative. I have an account in a server running Nextcloud, so I could use it the way I used
+ Google Drive—and I could access it as easily from other computers or my phone—, but I am also
+ trying to reduce the amount of private information I put online (whether it is behind a password
+ or not), so I decided that I should have offline backups for my computer<sup id="fnref1"><a
+ href="#fn1">1</a></sup>.</p>
+<!-- /p -->
+
+<p>
+ The main problem with backups is the effort/time spent doing them, so the process had to be as
+ automated as possible, as well as fast and efficient. I decided to use the <code>rsync</code>
+ tool, as it efficiently copies files from one directory to another, skipping the ones that are
+ already up to date (it is also preinstalled and easy to run from the terminal). I use a bunch of
+ options that make the transfer behave as I want to, and I created an alias for the command, so I
+ only need to type <code>backup_all</code> to back up my computer.</p>
+<!-- /p -->
+
+<p>
+ On top of my ordinary backup, I do a secondary backup (just in case!), which is made on my
+ everyday USB drive. Having a backup of my <code>home</code> folder there is a little risky, as I
+ have private information on my computer, so that is why I encrypt the backups. The software I use
+ is <a href="https://www.veracrypt.fr/en/Home.html">VeraCrypt</a>, and this obviously makes the
+ backup process a little more complicated. However, I created another alias that mounts the
+ VeraCrypt volumes (there are two because I need more than 4GiB and the USB drive uses the FAT
+ format), synchronizes the files and unmounts the volumes. So the only remaining thing for me to do
+ is type in the passwords—although actually, KeePassXC does that for me. I might even automate that
+ part in the future, so I only have to type in my master password.</p>
+<!-- /p -->
+
+<p>
+ So backing up my files is a pretty smooth process again, plus I now know exactly what I am doing
+ when running the command and the backups are made to hardware that I have access to.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ Regardless of the existence of an online backup, making an offline one is an interesting option,
+ as you have full control over it. <a class="footnote-backref" href="#fnref1" title="Jump
+ back to footnote 1 in the text">↩</a>
+ </li>
+</ol>
diff --git a/content/blog/2019-11-24-backups.md b/content/blog/2019-11-24-backups.md
@@ -1,45 +0,0 @@
-<!-- title: Backing up my computer -->
-<!-- slug: backups -->
-<!-- categories: FOSS, Privacy -->
-<!-- date: 2019-11-24T00:00:00Z -->
-
-If you have important information on your computer, you probably back it up
-somehow. I used to save all my important files on Google Drive, which was
-convenient not only because it would make backups automatically, but because I
-could access my files from any computer, or even my phone without much effort.
-
-Since reducing my dependency on Google, that isn't an option anymore, so I had
-to find an alternative. I have an account in a server running Nextcloud, so I
-could use it the way I used Google Drive—and I could access it as easily from
-other computers or my phone—, but I am also trying to reduce the amount of
-private information I put online (whether it is behind a password or not), so I
-decided that I should have offline backups for my computer[^note].
-
-[^note]: Regardless of the existence of an online backup, making an offline one
- is an interesting option, as you have full control over it.
-
-The main problem with backups is the effort/time spent doing them, so the
-process had to be as automated as possible, as well as fast and efficient. I
-decided to use the `rsync` tool, as it efficiently copies files from one
-directory to another, skipping the ones that are already up to date (it is also
-preinstalled and easy to run from the terminal). I use a bunch of options that
-make the transfer behave as I want to, and I created an alias for the command,
-so I only need to type `backup_all` to back up my computer.
-
-On top of my ordinary backup, I do a secondary backup (just in case!), which is
-made on my everyday USB drive. Having a backup of my `home` folder there is a
-little risky, as I have private information on my computer, so that is why I
-encrypt the backups. The software I use is [VeraCrypt][vc], and this obviously
-makes the backup process a little more complicated. However, I created another
-alias that mounts the VeraCrypt volumes (there are two because I need more than
-4GiB and the USB drive uses the FAT format), synchronizes the files and unmounts
-the volumes. So the only remaining thing for me to do is type in the
-passwords—although actually, KeePassXC does that for me. I might even automate
-that part in the future, so I only have to type in my master password.
-
-So backing up my files is a pretty smooth process again, plus I now know exactly
-what I am doing when running the command and the backups are made to hardware
-that I have access to.
-
-
-[vc]: <https://www.veracrypt.fr/en/Home.html> "VeraCrypt"
diff --git a/content/blog/2019-12-06-composer.html b/content/blog/2019-12-06-composer.html
@@ -0,0 +1,96 @@
+<!-- title: Designing a composing interface -->
+<!-- slug: composer -->
+<!-- categories: FOSS, Projects -->
+<!-- date: 2019-12-06T00:00:00Z -->
+<!-- lastmod: 2019-12-06T01:00:00Z -->
+
+<p>
+ To write my blog posts, I use Markdown, a useful language to write simple fragments of text. The
+ text is then "compiled" into HTML, which is then served as a webpage. Since Markdown files are
+ plain text files, I mostly have used plain text editors in the past to write my posts, and I have
+ had a decent experience with them. A week ago I was trying <a
+ href="https://writefreely.org/">WriteFreely</a> and the difference between their composing user
+ interface and a text editor is very noticeable. I have read people say they love writing in Vim or
+ Emacs, but for me, something more aesthetic is more suited.</p>
+<!-- /p -->
+
+<p>
+ I looked around to see if I could find any text editor similar to <a
+ href="https://write.as/new">WriteFreely's composer</a> and found <a
+ href="https://github.com/wereturtle/ghostwriter">Ghostwriter</a> which looked exactly like what I
+ was looking for. However, the installation process wasn't particularly smooth in Debian, and I
+ also use computers where I don't have root privileges, so I decided that it wouldn't suit my
+ needs. Inspired by WriteFreely's composer, I decided to make an HTML file that would do exactly
+ what I wanted.</p>
+<!-- /p -->
+
+<h2>Creating my own writing interface</h2>
+
+<p>
+ To create my composing interface, I started with WriteFreely's and edited it heavily. The original
+ had a lot of features (including a publishing button), so I deleted most of the code and added
+ some of my own. As of the time of writing, my composer doesn't have many features, because it is
+ supposed to be a simple and distraction-free tool to write content, but I will talk about the
+ couple I have added so far.</p>
+<!-- /p -->
+
+<h3>Saving the content between sessions</h3>
+
+<p>
+ The content you write doesn't disappear when you close your browser—unless you clean the browser's
+ data. I use local storage<sup id="fnref1"><a href="#fn1">1</a></sup> to store the text written, so
+ when the composer is opened again, you can continue writing where you left off. I have whitelisted
+ my domain from <a href="https://github.com/Cookie-AutoDelete/Cookie-AutoDelete">Cookie
+ AutoDelete</a>, so I can start writing and get back to it and any point, just opening my browser.
+ I also added a way to edit multiple "entries" at once using query strings to differentiate which
+ one you want to retrieve/save the changes on.</p>
+<!-- /p -->
+
+<h3>Exporting the text</h3>
+
+<p>
+ I found myself pressing <code>Ctrl+s</code> pretty frequently when writing, a habit I have from
+ coding (always save your changes!). If you do so on Firefox, a pop-up will appear offering you to
+ save the page—the actual HTML page. I found it quite annoying and decided to assign the shortcut a
+ different action. If you press <code>Ctrl+s</code>, it will seem like nothing happened, however,
+ the composer will update the word count and save the text using the system mentioned previously
+ (it also does all this after 0.2 seconds without typing, so the feature isn't super-useful, except
+ for getting rid of the saving the HTML dialog).</p>
+<!-- /p -->
+
+<p>
+ However, this gave me the idea to add an exporting feature. So, if you press
+ <code>Ctrl+Shift+s</code>, you will download a Markdown file with the text written. I decided to
+ make it specifically a Markdown file because it is what the composer is for, however, it can be
+ used for any other language.</p>
+<!-- /p -->
+
+<h2>Conclusion</h2>
+
+<p>
+ I can now write my posts on a very simple and minimalist interface, without distractions, but with
+ a nice design. All this without the need of installing any software. Finally, I can also edit it
+ to my needs, as I know exactly how it works and have learned basic notions of JavaScript.</p>
+<!-- /p -->
+
+<p>
+ Some people have disagreed with making a webpage act like a piece of software, however, it is the
+ most convenient method for me. You can also simply save the HTML file with the dependencies (the
+ CSS and JavaScript files) and use it offline, so it shouldn't be that much of a problem.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ Wait! Local storage sounds like cookies, the ones that track you, right?! Well, in the first
+ place, it is not the same. Local storage doesn't leave your computer (except through JavaScript,
+ you <a href="/jsweblabels/">can check</a> it doesn't in the composer). On the other hand,
+ cookies are just pieces of information stored on your computer which are sent to the server.
+ Someone can store a unique ID, so when you visit a website, they know it's you, tracking you
+ around the internet. But cookies are also useful when you log in to a website, so you don't have
+ to do it every time you move around a webpage. Cookies are not inherently bad. <a href="#fnref1"
+ title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2019-12-06-composer.md b/content/blog/2019-12-06-composer.md
@@ -1,85 +0,0 @@
-<!-- title: Designing a composing interface -->
-<!-- slug: composer -->
-<!-- categories: FOSS, Projects -->
-<!-- date: 2019-12-06T00:00:00Z -->
-<!-- lastmod: 2019-12-06T01:00:00Z -->
-
-To write my blog posts, I use Markdown, a useful language to write simple
-fragments of text. The text is then "compiled" into HTML, which is then served
-as a webpage. Since Markdown files are plain text files, I mostly have used
-plain text editors in the past to write my posts, and I have had a decent
-experience with them. A week ago I was trying [WriteFreely][wf] and the
-difference between their composing user interface and a text editor is very
-noticeable. I have read people say they love writing in Vim or Emacs, but for
-me, something more aesthetic is more suited.
-
-I looked around to see if I could find any text editor similar to [WriteFreely's
-composer][wfc] and found [Ghostwriter][gr] which looked exactly like what I was
-looking for. However, the installation process wasn't particularly smooth in
-Debian, and I also use computers where I don't have root privileges, so I
-decided that it wouldn't suit my needs. Inspired by WriteFreely's composer, I
-decided to make an HTML file that would do exactly what I wanted.
-
-## Creating my own writing interface
-
-To create my composing interface, I started with WriteFreely's and edited it
-heavily. The original had a lot of features (including a publishing button), so
-I deleted most of the code and added some of my own. As of the time of writing,
-my composer doesn't have many features, because it is supposed to be a simple
-and distraction-free tool to write content, but I will talk about the couple I
-have added so far.
-
-### Saving the content between sessions
-
-The content you write doesn't disappear when you close your browser—unless you
-clean the browser's data. I use local storage[^ls] to store the text written, so
-when the composer is opened again, you can continue writing where you left off.
-I have whitelisted my domain from [Cookie AutoDelete][cad], so I can start
-writing and get back to it and any point, just opening my browser. I also added
-a way to edit multiple "entries" at once using query strings to differentiate
-which one you want to retrieve/save the changes on.
-
-[^ls]: Wait! Local storage sounds like cookies, the ones that track you, right?!
- Well, in the first place, it is not the same. Local storage doesn't leave your
- computer (except through JavaScript, you [can check][jswl] it doesn't in the
- composer). On the other hand, cookies are just pieces of information stored on
- your computer which are sent to the server. Someone can store a unique ID, so
- when you visit a website, they know it's you, tracking you around the
- internet. But cookies are also useful when you log in to a website, so you
- don't have to do it every time you move around a webpage. Cookies are not
- inherently bad.
-
-### Exporting the text
-
-I found myself pressing `Ctrl+s` pretty frequently when writing, a habit I have
-from coding (always save your changes!). If you do so on Firefox, a pop-up will
-appear offering you to save the page—the actual HTML page. I found it quite
-annoying and decided to assign the shortcut a different action. If you press
-`Ctrl+s`, it will seem like nothing happened, however, the composer will update
-the word count and save the text using the system mentioned previously (it also
-does all this after 0.2 seconds without typing, so the feature isn't
-super-useful, except for getting rid of the saving the HTML dialog).
-
-However, this gave me the idea to add an exporting feature. So, if you press
-`Ctrl+Shift+s`, you will download a Markdown file with the text written. I
-decided to make it specifically a Markdown file because it is what the composer
-is for, however, it can be used for any other language.
-
-## Conclusion
-
-I can now write my posts on a very simple and minimalist interface, without
-distractions, but with a nice design. All this without the need of installing
-any software. Finally, I can also edit it to my needs, as I know exactly how it
-works and have learned basic notions of JavaScript.
-
-Some people have disagreed with making a webpage act like a piece of software,
-however, it is the most convenient method for me. You can also simply save the
-HTML file with the dependencies (the CSS and JavaScript files) and use it
-offline, so it shouldn't be that much of a problem.
-
-
-[wf]: <https://writefreely.org/> "WriteFreely"
-[wfc]: <https://write.as/new> "New Post — Write.as"
-[gr]: <https://github.com/wereturtle/ghostwriter> "Ghostwriter — GitHub"
-[cad]: <https://github.com/Cookie-AutoDelete/Cookie-AutoDelete> "Cookie AutoDelete"
-[jswl]: </jsweblabels/> "JavaScript Web Labels — Oscar Benedito"
diff --git a/content/blog/2019-12-15-your-corner-of-the-internet.html b/content/blog/2019-12-15-your-corner-of-the-internet.html
@@ -0,0 +1,150 @@
+<!-- title: Your corner of the Internet -->
+<!-- slug: your-corner-of-the-internet -->
+<!-- categories: Decentralization, Personal domain -->
+<!-- lastmod: 2019-12-06T00:00:00Z -->
+<!-- date: 2019-12-15T00:00:00Z -->
+
+<p>
+ We tend to have online accounts across different social networks and services. We upload our
+ projects in some sites, we post on different ones and we follow different people on all of them.
+ Our online identities—along with everything we share—are all over the place, but there is a way to
+ solve this (and many other problems): personal websites.</p>
+<!-- /p -->
+
+<p>
+ Creating a personal website is a great way to share our projects, experiences, thoughts, etc.
+ under our own terms, without being limited to a given theme or a couple of available options in a
+ certain service. A personal website allows you to customize it as you want, whether that is
+ quickly setting up a simple website with a portfolio, spending time creating the perfect CSS file
+ or even setting up a service to share files with your friends using a password.</p>
+<!-- /p -->
+
+<p>
+ You can buy a personal domain at a considerably cheap price (less than $12 a year for a
+ <code>.me</code>, <code>.org</code> or <code>.com</code> domain), but it will provide you with
+ something much more valuable: your corner of the Internet. Nobody can shut down your domain
+ because it is no longer profitable and if your host can't continue to provide you with what you
+ need, or they change their terms, you can simply switch companies, and still show your website
+ under the same URL. You can change anything on the "backstage", and others will always find you at
+ the same place.</p>
+<!-- /p -->
+
+<h2>Building the website</h2>
+
+<p>
+ If you don't have any experience with programming or using plain text and you don't want to spend
+ time getting familiar with it, you can use WordPress<sup id="fnref1"><a href="#fn1">1</a></sup> to
+ create your site. It is a free (as in freedom) <a
+ href="https://en.wikipedia.org/wiki/Content_management_system">content management system</a> that
+ will allow you to build a site without much HTML/CSS knowledge. If you are more comfortable with
+ plain text and the terminal or want to get in touch with them, building a static site that
+ supports Markdown will probably be a much better option.</p>
+<!-- /p -->
+
+<h3>What is a static site?</h3>
+
+<p>
+ Most of the websites we visit are dynamic. That means that the server we are retrieving the pages
+ from is executing a program, and the pages we see are the results of that web application. Dynamic
+ sites can be useful when we want users to be able to edit data. For instance, if users can log in
+ and publish posts, that would require a dynamic site.</p>
+<!-- /p -->
+
+<p>
+ On the other hand, there are static websites. In this case, the server simply serves files that
+ are already stored on the server. So, for a given URL, everybody sees the same HTML (and
+ JavaScript and CSS). You probably won't require a dynamic personal website, since you'll probably
+ be publishing information about you, your projects, etc., without the need of a server that does
+ real-time calculations to serve a page<sup id="fnref2"><a href="#fn2">2</a></sup>.</p>
+<!-- /p -->
+
+<p>Why am I talking about static sites? Well, they offer some advantages over dynamic ones.</p>
+
+<ul>
+ <li>
+ <strong>More efficient</strong>: since serving a page doesn't need any extra server-side
+ operation, static sites use way fewer resources, which can benefit you when considering
+ self-hosting the site. It will also make your site more environmentally friendly.</li>
+ <!-- /li -->
+ <li>
+ <strong>More secure</strong>: since there isn't an app server, potential vulnerabilities are
+ reduced drastically.</li>
+ <!-- /li -->
+ <li>
+ <strong>Faster</strong>: because the server doesn't need to do operations, it can respond to
+ requests faster, hence accelerating the loading time.<br/> <em>That is a general claim, by using
+ proper caching and using content delivery networks, speeds can change considerably. It also
+ depends on the number of plugins installed (or other operations made by the server).</em></li>
+ <!-- /li -->
+</ul>
+
+<p>
+ Because of these advantages, you can find free hosting for static sites and lower prices when
+ self-hosting or using shared-hosting because of the lower amount of resources needed. Furthermore,
+ since everything is stored in plain text and not in a database, you can easily use a version
+ control system (such as Git) to keep a history of all your changes and easily share the source
+ code of your site.</p>
+<!-- /p -->
+
+<h2>Generating a multi-page site</h2>
+
+<p>
+ To create a static website with multiple pages, you can use a static site generator. There are a
+ lot of static site generators, and I use Hugo (for a couple of reasons that I might write about
+ some other time). With the use of Hugo—most other generators also offer this functionality—, you
+ can code your navigation bar in a file, your footer in a different one and include both of them in
+ multiple templates. These templates will then gather the content from your Markdown (or HTML)
+ files, put it all together and output all the HTML files of your site. Now that I have an
+ operative site, when I want to publish a new post, I create a file with some metadata and the post
+ content, and Hugo does the rest. Post files look like the following:</p>
+<!-- /p -->
+
+<pre><code><!--
+ -->---
+<!-- -->title: "Post title"
+<!-- -->categories: category
+<!-- -->tags: [ "tag1", "tag2" ]
+<!-- -->---
+
+<!-- -->Post content.</code></pre>
+
+<p>
+ Thanks to Hugo, it is very easy to add content to a website, and the source code is neatly
+ organized. Hugo also lets you minify the content to reduce file sizes—although some people might
+ argue against it, I find it useful and some files get reduced by up to 30% (CSS files)<sup
+ id="fnref3"><a href="#fn3">3</a></sup>.</p>
+<!-- /p -->
+
+<h2>Conclusion</h2>
+
+<p>
+ Since my recent exit from multiple services because of privacy terms concerns, I realized having a
+ personal website can substitute social networks. I get to share anything I want on my own terms
+ (and with my own theme!), ensuring privacy to anybody who wants to read, and I get to keep the
+ copyright over my content. I now have my corner of the Internet, where everyone can find me,
+ contact me and read what I have to share.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ I use WordPress as the dynamic alternative because it has a free license, it is
+ beginner-friendly, it can easily be configured to run a personal website with a blog and a
+ portfolio and because it is very popular. However, if you are thinking about creating a dynamic
+ personal site, you should consider other options that are also interesting. <a href="#fnref1"
+ title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ You can still change the contents in a static site, however, you will have to edit the text
+ files manually and then upload them to the server (this can be automated). It is less
+ complicated than it sounds once you learn Markdown (which is very simple). <a href="#fnref2"
+ title="Jump back to footnote 2 in the text">↩</a></p></li>
+ <!-- /li -->
+ <li id="fn3">
+ On top of that, you can always find the source code well indented in the repository, by clicking
+ on <em>Inspect element</em> or by using a prettifier. <a href="#fnref3" title="Jump back to
+ footnote 3 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2019-12-15-your-corner-of-the-internet.md b/content/blog/2019-12-15-your-corner-of-the-internet.md
@@ -1,127 +0,0 @@
-<!-- title: Your corner of the Internet -->
-<!-- slug: your-corner-of-the-internet -->
-<!-- categories: Decentralization, Personal domain -->
-<!-- lastmod: 2019-12-06T00:00:00Z -->
-<!-- date: 2019-12-15T00:00:00Z -->
-
-We tend to have online accounts across different social networks and services.
-We upload our projects in some sites, we post on different ones and we follow
-different people on all of them. Our online identities—along with everything we
-share—are all over the place, but there is a way to solve this (and many other
-problems): personal websites.
-
-Creating a personal website is a great way to share our projects, experiences,
-thoughts, etc. under our own terms, without being limited to a given theme or a
-couple of available options in a certain service. A personal website allows you
-to customize it as you want, whether that is quickly setting up a simple website
-with a portfolio, spending time creating the perfect CSS file or even setting up
-a service to share files with your friends using a password.
-
-You can buy a personal domain at a considerably cheap price (less than $12 a
-year for a `.me`, `.org` or `.com` domain), but it will provide you with
-something much more valuable: your corner of the Internet. Nobody can shut down
-your domain because it is no longer profitable and if your host can't continue
-to provide you with what you need, or they change their terms, you can simply
-switch companies, and still show your website under the same URL. You can change
-anything on the "backstage", and others will always find you at the same place.
-
-## Building the website
-
-If you don't have any experience with programming or using plain text and you
-don't want to spend time getting familiar with it, you can use WordPress[^wp] to
-create your site. It is a free (as in freedom) [content management system][cms]
-that will allow you to build a site without much HTML/CSS knowledge. If you are
-more comfortable with plain text and the terminal or want to get in touch with
-them, building a static site that supports Markdown will probably be a much
-better option.
-
-[^wp]: I use WordPress as the dynamic alternative because it has a free license,
- it is beginner-friendly, it can easily be configured to run a personal website
- with a blog and a portfolio and because it is very popular. However, if you
- are thinking about creating a dynamic personal site, you should consider other
- options that are also interesting.
-
-### What is a static site?
-
-Most of the websites we visit are dynamic. That means that the server we are
-retrieving the pages from is executing a program, and the pages we see are the
-results of that web application. Dynamic sites can be useful when we want users
-to be able to edit data. For instance, if users can log in and publish posts,
-that would require a dynamic site.
-
-On the other hand, there are static websites. In this case, the server simply
-serves files that are already stored on the server. So, for a given URL,
-everybody sees the same HTML (and JavaScript and CSS). You probably won't
-require a dynamic personal website, since you'll probably be publishing
-information about you, your projects, etc., without the need of a server that
-does real-time calculations to serve a page[^static].
-
-[^static]: You can still change the contents in a static site, however, you will
- have to edit the text files manually and then upload them to the server (this
- can be automated). It is less complicated than it sounds once you learn
- Markdown (which is very simple).
-
-Why am I talking about static sites? Well, they offer some advantages over
-dynamic ones.
-
-- **More efficient**: since serving a page doesn't need any extra server-side
- operation, static sites use way fewer resources, which can benefit you when
- considering self-hosting the site. It will also make your site more
- environmentally friendly.
-- **More secure**: since there isn't an app server, potential vulnerabilities
- are reduced drastically.
-- **Faster**: because the server doesn't need to do operations, it can respond
- to requests faster, hence accelerating the loading time.<br/>
- *That is a general claim, by using proper caching and using content delivery
- networks, speeds can change considerably. It also depends on the number of
- plugins installed (or other operations made by the server).*
-
-Because of these advantages, you can find free hosting for static sites and
-lower prices when self-hosting or using shared-hosting because of the lower
-amount of resources needed. Furthermore, since everything is stored in plain
-text and not in a database, you can easily use a version control system (such as
-Git) to keep a history of all your changes and easily share the source code of
-your site.
-
-## Generating a multi-page site
-
-To create a static website with multiple pages, you can use a static site
-generator. There are a lot of static site generators, and I use Hugo (for a
-couple of reasons that I might write about some other time). With the use of
-Hugo—most other generators also offer this functionality—, you can code your
-navigation bar in a file, your footer in a different one and include both of
-them in multiple templates. These templates will then gather the content from
-your Markdown (or HTML) files, put it all together and output all the HTML files
-of your site. Now that I have an operative site, when I want to publish a new
-post, I create a file with some metadata and the post content, and Hugo does the
-rest. Post files look like the following:
-
-```markdown
----
-title: "Post title"
-categories: category
-tags: [ "tag1", "tag2" ]
----
-
-Post content.
-```
-
-Thanks to Hugo, it is very easy to add content to a website, and the source code
-is neatly organized. Hugo also lets you minify the content to reduce file
-sizes—although some people might argue against it, I find it useful and some
-files get reduced by up to 30% (CSS files)[^minify].
-
-[^minify]: On top of that, you can always find the source code well indented in
- the repository, by clicking on *Inspect element* or by using a prettifier.
-
-## Conclusion
-
-Since my recent exit from multiple services because of privacy terms concerns, I
-realized having a personal website can substitute social networks. I get to
-share anything I want on my own terms (and with my own theme!), ensuring privacy
-to anybody who wants to read, and I get to keep the copyright over my content. I
-now have my corner of the Internet, where everyone can find me, contact me and
-read what I have to share.
-
-
-[cms]: <https://en.wikipedia.org/wiki/Content_management_system> "Content management system — Wikipedia"
diff --git a/content/blog/2019-12-24-new-world-of-software.html b/content/blog/2019-12-24-new-world-of-software.html
@@ -0,0 +1,81 @@
+<!-- title: A new world of software -->
+<!-- slug: new-world-of-software -->
+<!-- categories: FOSS, Miscellany -->
+<!-- date: 2019-12-24T00:00:00Z -->
+
+<p>
+ As I have said before, I was a big user of big tech companies' services. I also used macOS (and
+ Windows before that) and proprietary software for mostly everything. I didn't really know what
+ free<sup id="fnref1"><a href="#fn1">1</a></sup> software was and, if I was running any, it was by
+ coincidence.</p>
+<!-- /p -->
+
+<p>
+ At college, I discovered the world of GNU/Linux. I had an old computer that was very slow and
+ someone promised that GNU/Linux would make it significantly faster, so I installed Debian next to
+ macOS. This way, every time I turned on my computer I would be able to choose which operating
+ system I wanted to use, and if something happened to my GNU partition, I could still use the
+ computer as before. Even with Debian installed, the computer eventually started to become too slow
+ for my needs and I bought a new computer where I also installed Debian next to the default OS. As
+ for the old computer, I eventually erased both partitions and installed Manjaro with XFCE instead,
+ I don't use it much anymore because of its limitations.</p>
+<!-- /p -->
+
+<p>
+ Progressively, I learned more and more about free software and I decided to use the Debian
+ partition nearly-exclusively. Ultimately, I got used to the new desktop environment, the new tools
+ (the terminal!) and all the new different things you find in GNU/Linux. There has been an
+ interesting side effect of using Debian as my daily operative system: most of the software I now
+ run is free/libre as a result of it.</p>
+<!-- /p -->
+
+<p>
+ I always thought free software was either worse than the proprietary alternative or non-existent
+ for a given task. What I have realized is that there are free options for most of the use cases
+ and that once you are used to the terminal, they can even be easier to work with, work faster and
+ be more reliable. Moreover, they normally<sup id="fnref2"><a href="#fn2">2</a></sup> are also
+ lighter programs, use fewer resources and generally follow standards (whereas proprietary software
+ creates its own protocols/file types more frequently).</p>
+<!-- /p -->
+
+<p>
+ Don't get me wrong, there are advantages to proprietary software. It can sometimes work better, be
+ nicer or more intuitive. Maybe it just suits your needs better because it's what you are used to.
+ There may be commodities we are familiar with in proprietary software that are hard to let go of.
+ However, in my case, it has gotten to the point that it is the other way around. It is hard to let
+ go the easy installation process of free software, without license complications, the fact that it
+ is available for GNU/Linux operative systems, the community around the software, the minimalism of
+ the tools that get the job done, without the need of thousands of extra features.</p>
+<!-- /p -->
+
+<p>
+ There is a whole world of efficient and useful software that I had never <em>really</em> explored
+ and I now see why so many people use it. I no longer look for free/libre <em>alternatives</em> to
+ a proprietary program, but it is the only kind of software that I look for. Dealing with closed
+ source and proprietary software is now my plan B, when everything else fails.</p>
+<!-- /p -->
+
+<h2>Final note</h2>
+
+<p>
+ Firstly, in this post I claim certain qualities of both free and proprietary software. It is
+ always spoken from my experience and perspective, your experience may be different. They are also
+ qualities that I commonly find, instead of a claim that all software on a given category has them.
+ Secondly, I deliberately left aside the ethical component of free software, as it wasn't what I
+ wanted to talk about, however, you might be interested in reading more about it.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ Here (and throughout the post) I am talking about <a
+ href="https://www.gnu.org/philosophy/free-sw.html">free as in freedom</a> software. <a
+ href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ That is generally in my experience. <a href="#fnref2" title="Jump back to footnote 2 in the
+ text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2019-12-24-new-world-of-software.md b/content/blog/2019-12-24-new-world-of-software.md
@@ -1,69 +0,0 @@
-<!-- title: A new world of software -->
-<!-- slug: new-world-of-software -->
-<!-- categories: FOSS, Miscellany -->
-<!-- date: 2019-12-24T00:00:00Z -->
-
-As I have said before, I was a big user of big tech companies' services. I also
-used macOS (and Windows before that) and proprietary software for mostly
-everything. I didn't really know what free[^fsw] software was and, if I was
-running any, it was by coincidence.
-
-[^fsw]: Here (and throughout the post) I am talking about [free as in
- freedom][fs] software.
-
-At college, I discovered the world of GNU/Linux. I had an old computer that was
-very slow and someone promised that GNU/Linux would make it significantly
-faster, so I installed Debian next to macOS. This way, every time I turned on my
-computer I would be able to choose which operating system I wanted to use, and
-if something happened to my GNU partition, I could still use the computer as
-before. Even with Debian installed, the computer eventually started to become
-too slow for my needs and I bought a new computer where I also installed Debian
-next to the default OS. As for the old computer, I eventually erased both
-partitions and installed Manjaro with XFCE instead, I don't use it much anymore
-because of its limitations.
-
-Progressively, I learned more and more about free software and I decided to use
-the Debian partition nearly-exclusively. Ultimately, I got used to the new
-desktop environment, the new tools (the terminal!) and all the new different
-things you find in GNU/Linux. There has been an interesting side effect of using
-Debian as my daily operative system: most of the software I now run is
-free/libre as a result of it.
-
-I always thought free software was either worse than the proprietary alternative
-or non-existent for a given task. What I have realized is that there are free
-options for most of the use cases and that once you are used to the terminal,
-they can even be easier to work with, work faster and be more reliable.
-Moreover, they normally[^ime] are also lighter programs, use fewer resources and
-generally follow standards (whereas proprietary software creates its own
-protocols/file types more frequently).
-
-[^ime]: That is generally in my experience.
-
-Don't get me wrong, there are advantages to proprietary software. It can
-sometimes work better, be nicer or more intuitive. Maybe it just suits your
-needs better because it's what you are used to. There may be commodities we are
-familiar with in proprietary software that are hard to let go of. However, in my
-case, it has gotten to the point that it is the other way around. It is hard to
-let go the easy installation process of free software, without license
-complications, the fact that it is available for GNU/Linux operative systems,
-the community around the software, the minimalism of the tools that get the job
-done, without the need of thousands of extra features.
-
-There is a whole world of efficient and useful software that I had never
-*really* explored and I now see why so many people use it. I no longer look for
-free/libre *alternatives* to a proprietary program, but it is the only kind of
-software that I look for. Dealing with closed source and proprietary software is
-now my plan B, when everything else fails.
-
-## Final note
-
-Firstly, in this post I claim certain qualities of both free and proprietary
-software. It is always spoken from my experience and perspective, your
-experience may be different. They are also qualities that I commonly find,
-instead of a claim that all software on a given category has them. Secondly, I
-deliberately left aside the ethical component of free software, as it wasn't
-what I wanted to talk about, however, you might be interested in reading more
-about it.
-
-
-[fs]: <https://www.gnu.org/philosophy/free-sw.html> "What is free software? — GNU Project"
diff --git a/content/blog/2020-01-12-securing-communications.html b/content/blog/2020-01-12-securing-communications.html
@@ -0,0 +1,139 @@
+<!-- title: Securing communications -->
+<!-- slug: securing-communications -->
+<!-- categories: Cryptography -->
+<!-- date: 2020-01-12T00:00:00Z -->
+<!-- lastmod: 2020-08-10T00:00:00Z -->
+
+<p>
+ We use cryptographic techniques daily without really knowing how they work, so I'm going to try
+ and explain some basic concepts. Let's start with Wikipedia's current definition:</p>
+<!-- /p -->
+
+<blockquote>
+ <p>
+ Cryptography or cryptology is the practice and study of techniques for secure communication in
+ the presence of third parties called adversaries.</p>
+ <!-- /p -->
+
+ <p>— <em><a href="https://en.wikipedia.org/wiki/Cryptography">Wikipedia's cryptography entry</a></em></p>
+</blockquote>
+
+<p>
+ One cryptographic process we are all familiar with is encryption, that allows us to change the
+ contents of a message so only certain people with a "key" can decipher and read it. A simple—and
+ well known—example of encryption is the <a href="https://en.wikipedia.org/wiki/Caesar_cipher">Caesar cipher</a>
+ (if you haven't heard of it, check out how it works!).</p>
+<!-- /p -->
+
+<p>
+ Let's consider the following scenario with three people (or parties): Alice, Bob and Craig. Alice
+ wants to contact Bob privately, while Craig is trying to eavesdrop. This is all happening through
+ a network, in this particular scenario, they are communicating through the mail. Craig works at
+ the postal office, so he could get Alice's letter, open it, read it, put it back in a new envelope
+ that looks exactly the same as Alice's and then send it to Bob.</p>
+<!-- /p -->
+
+<p>
+ Craig's attack is known as a man-in-the-middle attack, happening when the attacker is able to
+ secretly relay information between two parties (and with the ability to change the contents of the
+ communication). This attack isn't particularly hard to carry out on the Internet, but we are
+ normally protected by cryptographic methods (that ensure the privacy and authenticity of our
+ communications).</p>
+<!-- /p -->
+
+<h2>Encrypting a message</h2>
+
+<p>
+ Alice knows about the flaws of the mail system, so she decides to encrypt her message. She could
+ use the Caesar cipher. If Bob knows how much Alice "shifted" the alphabet, he will be able to read
+ her message, while Craig won't. Or will he? Couldn't Craig just try all the numbers from 1 to 25
+ and just see which one gives a message that makes sense? And how did Alice tell Bob how much she
+ "shifted" the alphabet without Craig reading it?</p>
+<!-- /p -->
+
+<p>
+ Those are good points. We currently use better encryption methods than the Caesar cipher that
+ tackle these issues. The first concern is talking about a brute-force attack (when the attacker
+ tries many keys in order to—eventually—find the correct one). We can protect our messages against
+ brute-force attacks by using an encryption method that admits a huge number of different possible
+ keys. How big? If you create a key with GPG, the minimum key size is 1024 bits (which gives us
+ 2<sup>1024</sup> different possible keys). How hard would it be to crack it? <a
+ href="https://www.youtube.com/watch?v=S9JGmA5_unY">This video</a> explains it pretty well for a
+ key that is 256 bits long (2<sup>256</sup> possible keys). First problem solved! Bob isn't
+ deciphering our letter anytime soon!</p>
+<!-- /p -->
+
+<p>
+ About the second issue... How can Alice tell Bob her secret password before they can encrypt
+ anything? It turns out she doesn't need to do that at all! She can use asymmetric cryptography to
+ solve this problem. In asymmetric encryption, everyone has two keys<sup id="fnref1"><a
+ href="#fn1">1</a></sup>: a public key and a private key. Our public key will be <em>public</em>!
+ Everyone can know it (and that won't put our encrypted messages in danger), while our private key
+ will only be known to us. When using asymmetric encryption, we encrypt messages using someone
+ else's <strong>public</strong> key, but only someone with the <strong>private</strong> key will be
+ able to decipher it.</p>
+<!-- /p -->
+
+<p>
+ So now Bob can simply send Alice his public key, which she will use to encrypt the message. Only
+ Bob with his private key will be able to decipher the message. A system of communication that is
+ resistant to Craig's attacks, so far...</p>
+<!-- /p -->
+
+<h2>Signing a message</h2>
+
+<p>
+ Craig can't decipher the message, so he might try another strategy: change it! He will get Alice's
+ letter, destroy it, and send a different one to Bob (making it look like it came from Alice). The
+ communication is private, but not secure yet!</p>
+<!-- /p -->
+
+<p>
+ Once again, cryptographic techniques come to the rescue with the ability to digitally sign
+ messages (also using asymmetric cryptography). What signing a message does is kind of the opposite
+ of encryption: Alice can use her <strong>private</strong> key to sign her message, which will
+ output a new file (the signature). Now, anybody with the message, the signature made by Alice, and
+ her <strong>public</strong> key can check that the message was signed using Alice's private key,
+ therefore ensuring nobody changed it (signatures are different for different messages).</p>
+<!-- /p -->
+
+<p>
+ Now, Craig can still destroy the message and send a different one. However, Bob will realize there
+ isn't a signature (or the one given doesn't match the message). This will alert Bob that the
+ contents of the message might indeed not come from Alice. Bob might not be able to get Alice's
+ message, but Craig will never be able to impersonate her.</p>
+<!-- /p -->
+
+<h2>Final notes</h2>
+
+<p>
+ The problem with the digital signature is that there has to be an initial contact that both
+ parties know has not been compromised<sup id="fnref2"><a href="#fn2">2</a></sup>. This could be
+ achieved by meeting in person and exchanging keys, although that could be hard for two parties
+ that live in different parts of the world trying to talk over the Internet. There are methods to
+ work around this problem, although none is perfect.</p>
+<!-- /p -->
+
+<p>
+ Hopefully, this post gave you a basic overview of some things that can be done using cryptographic
+ techniques and how they are necessary when securing our online communications.</p>
+<!-- /p -->
+
+<p><em>Edit</em>: Invidious link has been changed to YouTube as Invidious instance is shutting down.</p>
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ These pair of keys are created in a particular way (that "links" them). I won't get into detail
+ on how it works (it is beyond the scope of this post), but there is a lot of information on the
+ Internet if you are interested. <a href="#fnref1" title="Jump back to footnote 1 in the
+ text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ If not, the first time Alice sends her public key, Craig could change it a different one and
+ therefore being able to successfully sign messages with what Bob trusts is Alice's private key.
+ <a href="#fnref2" title="Jump back to footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-01-12-securing-communications.md b/content/blog/2020-01-12-securing-communications.md
@@ -1,118 +0,0 @@
-<!-- title: Securing communications -->
-<!-- slug: securing-communications -->
-<!-- categories: Cryptography -->
-<!-- date: 2020-01-12T00:00:00Z -->
-<!-- lastmod: 2020-08-10T00:00:00Z -->
-
-We use cryptographic techniques daily without really knowing how they work, so
-I'm going to try and explain some basic concepts. Let's start with Wikipedia's
-current definition:
-
-> Cryptography or cryptology is the practice and study of techniques for secure
-> communication in the presence of third parties called adversaries.
->
-> — *[Wikipedia's cryptography entry][cry]*
-
-One cryptographic process we are all familiar with is encryption, that allows us
-to change the contents of a message so only certain people with a "key" can
-decipher and read it. A simple—and well known—example of encryption is the
-[Caesar cipher][cc] (if you haven't heard of it, check out how it works!).
-
-Let's consider the following scenario with three people (or parties): Alice, Bob
-and Craig. Alice wants to contact Bob privately, while Craig is trying to
-eavesdrop. This is all happening through a network, in this particular scenario,
-they are communicating through the mail. Craig works at the postal office, so he
-could get Alice's letter, open it, read it, put it back in a new envelope that
-looks exactly the same as Alice's and then send it to Bob.
-
-Craig's attack is known as a man-in-the-middle attack, happening when the
-attacker is able to secretly relay information between two parties (and with the
-ability to change the contents of the communication). This attack isn't
-particularly hard to carry out on the Internet, but we are normally protected by
-cryptographic methods (that ensure the privacy and authenticity of our
-communications).
-
-## Encrypting a message
-
-Alice knows about the flaws of the mail system, so she decides to encrypt her
-message. She could use the Caesar cipher. If Bob knows how much Alice "shifted"
-the alphabet, he will be able to read her message, while Craig won't. Or will
-he? Couldn't Craig just try all the numbers from 1 to 25 and just see which one
-gives a message that makes sense? And how did Alice tell Bob how much she
-"shifted" the alphabet without Craig reading it?
-
-Those are good points. We currently use better encryption methods than the
-Caesar cipher that tackle these issues. The first concern is talking about a
-brute-force attack (when the attacker tries many keys in order
-to—eventually—find the correct one). We can protect our messages against
-brute-force attacks by using an encryption method that admits a huge number of
-different possible keys. How big? If you create a key with GPG, the minimum key
-size is 1024 bits (which gives us 2<sup>1024</sup> different possible keys). How
-hard would it be to crack it? [This video][yt] explains it pretty well for a key
-that is 256 bits long (2<sup>256</sup> possible keys). First problem solved! Bob
-isn't deciphering our letter anytime soon!
-
-About the second issue... How can Alice tell Bob her secret password before they
-can encrypt anything? It turns out she doesn't need to do that at all! She can
-use asymmetric cryptography to solve this problem. In asymmetric encryption,
-everyone has two keys[^nodetail]: a public key and a private key. Our public key
-will be *public*! Everyone can know it (and that won't put our encrypted
-messages in danger), while our private key will only be known to us. When using
-asymmetric encryption, we encrypt messages using someone else's **public** key,
-but only someone with the **private** key will be able to decipher it.
-
-[^nodetail]: These pair of keys are created in a particular way (that "links"
- them). I won't get into detail on how it works (it is beyond the scope of this
- post), but there is a lot of information on the Internet if you are
- interested.
-
-So now Bob can simply send Alice his public key, which she will use to encrypt
-the message. Only Bob with his private key will be able to decipher the message.
-A system of communication that is resistant to Craig's attacks, so far...
-
-## Signing a message
-
-Craig can't decipher the message, so he might try another strategy: change it!
-He will get Alice's letter, destroy it, and send a different one to Bob (making
-it look like it came from Alice). The communication is private, but not secure
-yet!
-
-Once again, cryptographic techniques come to the rescue with the ability to
-digitally sign messages (also using asymmetric cryptography). What signing a
-message does is kind of the opposite of encryption: Alice can use her
-**private** key to sign her message, which will output a new file (the
-signature). Now, anybody with the message, the signature made by Alice, and her
-**public** key can check that the message was signed using Alice's private key,
-therefore ensuring nobody changed it (signatures are different for different
-messages).
-
-Now, Craig can still destroy the message and send a different one. However, Bob
-will realize there isn't a signature (or the one given doesn't match the
-message). This will alert Bob that the contents of the message might indeed not
-come from Alice. Bob might not be able to get Alice's message, but Craig will
-never be able to impersonate her.
-
-## Final notes
-
-The problem with the digital signature is that there has to be an initial
-contact that both parties know has not been compromised[^sharingpk]. This could
-be achieved by meeting in person and exchanging keys, although that could be
-hard for two parties that live in different parts of the world trying to talk
-over the Internet. There are methods to work around this problem, although none
-is perfect.
-
-[^sharingpk]: If not, the first time Alice sends her public key, Craig could
- change it a different one and therefore being able to successfully sign
- messages with what Bob trusts is Alice's private key.
-
-Hopefully, this post gave you a basic overview of some things that can be done
-using cryptographic techniques and how they are necessary when securing our
-online communications.
-
-*Edit*: Invidious link has been changed to YouTube as Invidious instance is
-shutting down.
-
-
-[cry]: <https://en.wikipedia.org/wiki/Cryptography> "Cryptography — Wikipedia"
-[cc]: <https://en.wikipedia.org/wiki/Caesar_cipher> "Caesar cipher — Wikipedia"
-[yt]: <https://www.youtube.com/watch?v=S9JGmA5_unY> "How secure is 256 bit security? — YouTube"
diff --git a/content/blog/2020-01-17-documenting-server.html b/content/blog/2020-01-17-documenting-server.html
@@ -0,0 +1,52 @@
+<!-- title: Documenting my server -->
+<!-- slug: documenting-server -->
+<!-- categories: Self-hosting -->
+<!-- date: 2020-01-17T00:00:00Z -->
+<!-- lastmod: 2020-03-01T01:00:00Z -->
+
+<p>
+ Not long ago I realized that I could get $50 of credit on Digital Ocean with my GitHub Student
+ account, so I decided to try it. I transferred my website there, and with time I started adding
+ services. It is currently running the following services:</p>
+<!-- /p -->
+
+<ul>
+ <li>My webpage (<a href="https://oscarbenedito.com">oscarbenedito.com</a>).</li>
+ <li>
+ Redirections from <a href="https://www.oscarbenedito.com">www.oscarbenedito.com</a>,
+ <a href="https://obenedito.org">obenedito.org</a> and
+ <a href="https://www.obenedito.org">www.obenedito.org</a> to
+ <a href="https://oscarbenedito.com">oscarbenedito.com</a>.</li>
+ <!-- /li -->
+ <li>A <a href="https://gotify.net/">Gotify</a> server through which I am able to send notifications to my phone.</li>
+ <li> A static page showing traffic on my website thanks to <a href="https://goaccess.io/">GoAccess</a> (which analyzes Apache's log files).</li>
+ <li>It runs <a href="https://git.oscarbenedito.com/git-backup/">this script</a> daily to back up all my git repositories and others I find interesting.</li>
+ <li>It notifies me if any new documents are uploaded to my college Moodle using <a href="https://git.oscarbenedito.com/osf/file/moodle-updates-notifications.py.html">this script</a> and a cronjob.</li>
+ <li>It notifies me every time someone logs in to the server using SSH.</li>
+</ul>
+
+<p>
+ As time passes I am adding more and more features to my server. In the first place because it is
+ fun to learn about different things and installing them, but also because they are useful features
+ (indeed I have tried to run other programs which ended up not being as useful as I initially
+ thought). I realized it is getting to the point where if something was to happen to my server (and
+ it got erased), I would probably not remember how I set up everything, so I decided to do some
+ documentation work<sup id="fnref1"><a href="#fn1">1</a></sup>.</p>
+<!-- /p -->
+
+<p>
+ After some time, I am nearly done documenting everything that is set up and I am pretty confident
+ if I had to do it all again now, the documentation would be very useful. Besides, it is also a
+ good way of keeping a record of everything running in the server and its configuration.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ I know that taking snapshots of the server or making a backup every once in a while would solve
+ that issue. However, that wasn't the only goal. I wanted to be able to rebuild my server from
+ scratch again. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-01-17-documenting-server.md b/content/blog/2020-01-17-documenting-server.md
@@ -1,50 +0,0 @@
-<!-- title: Documenting my server -->
-<!-- slug: documenting-server -->
-<!-- categories: Self-hosting -->
-<!-- date: 2020-01-17T00:00:00Z -->
-<!-- lastmod: 2020-03-01T01:00:00Z -->
-
-Not long ago I realized that I could get $50 of credit on Digital Ocean with my
-GitHub Student account, so I decided to try it. I transferred my website there,
-and with time I started adding services. It is currently running the following
-services:
-
-- My webpage ([oscarbenedito.com][com]).
-- Redirections from [www.oscarbenedito.com][wcom], [obenedito.org][org] and
- [www.obenedito.org][worg] to [oscarbenedito.com][com].
-- A [Gotify][g] server through which I am able to send notifications to my
- phone.
-- A static page showing traffic on my website thanks to [GoAccess][ga] (which
- analyzes Apache's log files).
-- It runs [this script][gb] daily to back up all my git repositories and others
- I find interesting.
-- It notifies me if any new documents are uploaded to my college Moodle using
- [this script][mun] and a cronjob.
-- It notifies me every time someone logs in to the server using SSH.
-
-As time passes I am adding more and more features to my server. In the first
-place because it is fun to learn about different things and installing them, but
-also because they are useful features (indeed I have tried to run other programs
-which ended up not being as useful as I initially thought). I realized it is
-getting to the point where if something was to happen to my server (and it got
-erased), I would probably not remember how I set up everything, so I decided to
-do some documentation work[^backup].
-
-[^backup]: I know that taking snapshots of the server or making a backup every
- once in a while would solve that issue. However, that wasn't the only goal. I
- wanted to be able to rebuild my server from scratch again.
-
-After some time, I am nearly done documenting everything that is set up and I am
-pretty confident if I had to do it all again now, the documentation would be
-very useful. Besides, it is also a good way of keeping a record of everything
-running in the server and its configuration.
-
-
-[com]: <https://oscarbenedito.com>
-[wcom]: <https://www.oscarbenedito.com>
-[org]: <https://obenedito.org>
-[worg]: <https://www.obenedito.org>
-[g]: <https://gotify.net/> "Gotify"
-[ga]: <https://goaccess.io/> "GoAccess"
-[gb]: <https://git.oscarbenedito.com/git-backup/> "Git Backup — git.oscarbenedito.com"
-[mun]: <https://git.oscarbenedito.com/osf/file/moodle-updates-notifications.py.html> "Moodle Updates Notifications — git.oscarbenedito.com"
diff --git a/content/blog/2020-01-25-syncthing.html b/content/blog/2020-01-25-syncthing.html
@@ -0,0 +1,21 @@
+<!-- title: File synchronization software: Syncthing -->
+<!-- slug: syncthing -->
+<!-- categories: Decentralization, FOSS, Privacy -->
+<!-- date: 2020-01-25T00:00:00Z -->
+
+<p>
+ <a href="https://syncthing.net/">Syncthing</a> is a file synchronization program. It allows you to
+ sync files between computers over LAN or the Internet. It is a very simple program that just gets
+ the job done.</p>
+<!-- /p -->
+
+<p>
+ I use it to synchronize files between two computers and my phone. When synchronizing two
+ computers, I find it to be a much faster—and smoother—approach than doing it with a USB, while
+ mantaining my privacy and avoiding the exposure of private document to companies on the Internet.
+ I also use it to back up a couple of folders from my phone, including my pictures. Every once in a
+ while I will activate syncthing on my phone, it will sync everything with my computer and then I
+ just exit it. It is fast and simple.</p>
+<!-- /p -->
+
+<p>If you want to synchronize/back up your computer or phone privately, check it out!</p>
diff --git a/content/blog/2020-01-25-syncthing.md b/content/blog/2020-01-25-syncthing.md
@@ -1,22 +0,0 @@
-<!-- title: File synchronization software: Syncthing -->
-<!-- slug: syncthing -->
-<!-- categories: Decentralization, FOSS, Privacy -->
-<!-- date: 2020-01-25T00:00:00Z -->
-
-[Syncthing][s] is a file synchronization program. It allows you to sync files
-between computers over LAN or the Internet. It is a very simple program that
-just gets the job done.
-
-I use it to synchronize files between two computers and my phone. When
-synchronizing two computers, I find it to be a much faster—and smoother—approach
-than doing it with a USB, while mantaining my privacy and avoiding the exposure
-of private document to companies on the Internet. I also use it to back up a
-couple of folders from my phone, including my pictures. Every once in a while I
-will activate syncthing on my phone, it will sync everything with my computer
-and then I just exit it. It is fast and simple.
-
-If you want to synchronize/back up your computer or phone privately, check it
-out!
-
-
-[s]: <https://syncthing.net/> "Syncthing"
diff --git a/content/blog/2020-02-12-deploying-hugo-site.html b/content/blog/2020-02-12-deploying-hugo-site.html
@@ -0,0 +1,145 @@
+<!-- title: Deploying a website built with Hugo -->
+<!-- slug: deploying-hugo-site -->
+<!-- categories: Personal domain, Self-hosting -->
+<!-- date: 2020-02-12T00:00:00Z -->
+
+<p>
+ I have <a href="/blog/2019/12/your-corner-of-the-internet/">previously talked</a> about creating a
+ personal website, in this post I will talk about hosting it. More specifically, I'm going to
+ explain how to host a website built with Hugo.</p>
+<!-- /p -->
+
+<h2>Hosting without a server</h2>
+
+<p>
+ If you don't have a server or don't want to be in charge of one, you can let GitLab host your
+ website. You can either do it with your own domain or use the one GitLab will assign you based on
+ your username. If you want to do it this way, take a look at <a
+ href="https://gitlab.com/pages/hugo">their example</a>, you only need to add that
+ <code>.gitlab-ci.yml</code> file to your repository and GitLab will do the rest.</p>
+<!-- /p -->
+
+<p>
+ There are other services that will host a static site for free like Netlify (which supports Hugo)
+ or services that host a site given the HTML files such as Neocities—in this case, you would need
+ to run Hugo locally and upload the output files.</p>
+<!-- /p -->
+
+<h2>Hosting with a server</h2>
+
+<p>
+ If you have a server or would like to run one, you can host your website there. Let's see how to
+ do it using Apache. First of all, we will install Apache and Hugo on our server and clone our
+ site's repository somewhere. In my case, my Hugo directory is found in the <code>/srv</code>
+ directory and the actual files that should be served are in the <code>public</code> folder inside
+ the directory<sup id="fnref1"><a href="#fn1">1</a></sup>. Therefore, the directory I want to serve
+ is <code>/srv/<hugo_directory>/public</code> (created by Hugo).</p>
+<!-- /p -->
+
+<p>
+ Before we begin, let's edit Apache's configuration to deny access to the default folders. I am not
+ sure if this is actually necessary as you will be setting up site root directories, but I like to
+ restrict any access and then grant it on a per-site basis. Go to the Apache configuration file
+ found at <code>/etc/apache2/apache2.conf</code> and comment the lines with the following content
+ (put a <code>#</code> at the start of the line):</p>
+<!-- /p -->
+
+<pre><code><!--
+ --><Directory /var/www/>
+<!-- --> Options Indexes FollowSymLinks
+<!-- --> AllowOverride None
+<!-- --> Require all granted
+<!-- --></Directory>
+
+<!-- --><Directory /srv/>
+<!-- --> Options Indexes FollowSymLinks
+<!-- --> AllowOverride All
+<!-- --> Require all granted
+<!-- --></Directory></code></pre>
+
+<p>
+ That will restrict access to the specified directories (which will not be public from now on). In
+ order to grant access to the desired folder, we'll create a file under
+ <code>/etc/apache2/sites-available</code> with the site's configuration. I like to name the files
+ after the (sub)domain, so I would put my apache configuration in the file
+ <code>/etc/apache2/sites-available/<domain_name>.conf</code>, with the following
+ configuration:</p>
+<!-- /p -->
+
+<pre><code><!--
+ --><VirtualHost *:80>
+<!-- --> ServerName <domain_name>
+<!-- --> DocumentRoot /srv/<hugo_directory>/public
+<!-- --> ErrorLog ${APACHE_LOG_DIR}/error-<domain_name>.log
+<!-- --> CustomLog ${APACHE_LOG_DIR}/access-<domain_name>.log combined
+
+<!-- --> <Directory "/srv/<hugo_directory>/public">
+<!-- --> Options FollowSymLinks
+<!-- --> AllowOverride None
+<!-- --> Require all granted
+
+<!-- --> ErrorDocument 403 /404.html
+<!-- --> ErrorDocument 404 /404.html
+<!-- --> </Directory>
+<!-- --></VirtualHost></code></pre>
+
+<p>
+ What is happening here? We are creating a virtual host for incoming connections on port 80
+ (default HTTP port) that will respond to requests to the <code><domain_name></code> domain
+ (specified on the <code>ServerName</code>). The root folder for the domain will be
+ <code>/srv/<hugo_directory>/public</code> (so if you access
+ <code>http://<domain_name>/blog/index.html</code>, it will serve with the file found at
+ <code>/srv/<hugo_directory>/public/blog/index.html</code>). After that, we set up the error
+ and access log files (the domain part of the name is not necessary, especially if you are only
+ hosting one service).</p>
+<!-- /p -->
+
+<p>
+ The second part of the file looks similar to the commented lines above, and they actually do the
+ same job, we just have them in this file which makes it easier to keep track of which directories
+ is each site depending on and their permissions. In this case, we allow Apache to follow symbolic
+ links and we give access to our files to any user on the web (we won't ask for a password). On top
+ of that, I specified a custom 404 file (which will also be served when the visitor is trying to
+ access a restricted file or directory, which gives error 403).</p>
+<!-- /p -->
+
+<p>Configuration ready! We'll need to activate it using the following command as the root user:</p>
+
+<pre><code>a2ensite <domain_name>.conf</code></pre>
+
+<p>
+ And just make sure your DNS is pointing to the server. Everything should work now! However, we are
+ serving our page through HTTP, we <a href="https://doesmysiteneedhttps.com/">definitely</a> want
+ HTTPS. It might sound unnecessary since we don't have any forms on our website (no data to be
+ encrypted), but HTTPS also guarantees site authenticity (protects you against man-in-the-middle
+ attacks) and normalizes the use of encryption on the web.</p>
+<!-- /p -->
+
+<p>
+ In order to set up HTTPS, we need a certificate. I use one issued by <a
+ href="https://letsencrypt.org">Let's Encrypt</a>, which are free and very easy to use (and they
+ are renewed automatically). To do so, I use <a href="https://certbot.eff.org/">Certbot</a>,
+ developed by the <a href="https://www.eff.org/">EFF</a>. To use it, go to the Certbot's page,
+ install it on your server and follow the instructions on the website. Make sure you enable
+ redirection to HTTPS!</p>
+<!-- /p -->
+
+<p>
+ It takes about 2 minutes to set up and now people will connect to your site using HTTPS. You can
+ see that a new file has been created at
+ <code>/etc/apache2/sites-available/<domain_name>-le-ssl.conf</code> by Certbot to configure
+ the HTTPS site, plus a couple of lines will be added to the configuration file on port 80 to
+ redirect to the encrypted site.</p>
+<!-- /p -->
+
+<p>Your site is ready!</p>
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ It is also a common practice to put it under <code>/var/www</code>. <a href="#fnref1"
+ title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-02-12-deploying-hugo-site.md b/content/blog/2020-02-12-deploying-hugo-site.md
@@ -1,132 +0,0 @@
-<!-- title: Deploying a website built with Hugo -->
-<!-- slug: deploying-hugo-site -->
-<!-- categories: Personal domain, Self-hosting -->
-<!-- date: 2020-02-12T00:00:00Z -->
-
-I have [previously talked][post] about creating a personal website, in this post
-I will talk about hosting it. More specifically, I'm going to explain how to
-host a website built with Hugo.
-
-## Hosting without a server
-
-If you don't have a server or don't want to be in charge of one, you can let
-GitLab host your website. You can either do it with your own domain or use the
-one GitLab will assign you based on your username. If you want to do it this
-way, take a look at [their example][ex], you only need to add that
-`.gitlab-ci.yml` file to your repository and GitLab will do the rest.
-
-There are other services that will host a static site for free like Netlify
-(which supports Hugo) or services that host a site given the HTML files such as
-Neocities—in this case, you would need to run Hugo locally and upload the output
-files.
-
-## Hosting with a server
-
-If you have a server or would like to run one, you can host your website there.
-Let's see how to do it using Apache. First of all, we will install Apache and
-Hugo on our server and clone our site's repository somewhere. In my case, my
-Hugo directory is found in the `/srv` directory and the actual files that should
-be served are in the `public` folder inside the directory[^var]. Therefore, the
-directory I want to serve is `/srv/<hugo_directory>/public` (created by Hugo).
-
-[^var]: It is also a common practice to put it under `/var/www`.
-
-Before we begin, let's edit Apache's configuration to deny access to the default
-folders. I am not sure if this is actually necessary as you will be setting up
-site root directories, but I like to restrict any access and then grant it on a
-per-site basis. Go to the Apache configuration file found at
-`/etc/apache2/apache2.conf` and comment the lines with the following content
-(put a `#` at the start of the line):
-
-```apache
-<Directory /var/www/>
- Options Indexes FollowSymLinks
- AllowOverride None
- Require all granted
-</Directory>
-
-<Directory /srv/>
- Options Indexes FollowSymLinks
- AllowOverride All
- Require all granted
-</Directory>
-```
-
-That will restrict access to the specified directories (which will not be public
-from now on). In order to grant access to the desired folder, we'll create a
-file under `/etc/apache2/sites-available` with the site's configuration. I like
-to name the files after the (sub)domain, so I would put my apache configuration
-in the file `/etc/apache2/sites-available/<domain_name>.conf`, with the
-following configuration:
-
-```apache
-<VirtualHost *:80>
- ServerName <domain_name>
- DocumentRoot /srv/<hugo_directory>/public
- ErrorLog ${APACHE_LOG_DIR}/error-<domain_name>.log
- CustomLog ${APACHE_LOG_DIR}/access-<domain_name>.log combined
-
- <Directory "/srv/<hugo_directory>/public">
- Options FollowSymLinks
- AllowOverride None
- Require all granted
-
- ErrorDocument 403 /404.html
- ErrorDocument 404 /404.html
- </Directory>
-</VirtualHost>
-```
-
-What is happening here? We are creating a virtual host for incoming connections
-on port 80 (default HTTP port) that will respond to requests to the
-`<domain_name>` domain (specified on the `ServerName`). The root folder for the
-domain will be `/srv/<hugo_directory>/public` (so if you access
-`http://<domain_name>/blog/index.html`, it will serve with the file found at
-`/srv/<hugo_directory>/public/blog/index.html`). After that, we set up the error
-and access log files (the domain part of the name is not necessary, especially
-if you are only hosting one service).
-
-The second part of the file looks similar to the commented lines above, and they
-actually do the same job, we just have them in this file which makes it easier
-to keep track of which directories is each site depending on and their
-permissions. In this case, we allow Apache to follow symbolic links and we give
-access to our files to any user on the web (we won't ask for a password). On top
-of that, I specified a custom 404 file (which will also be served when the
-visitor is trying to access a restricted file or directory, which gives error
-403).
-
-Configuration ready! We'll need to activate it using the following command as
-the root user:
-
-```bash
-a2ensite <domain_name>.conf
-```
-
-And just make sure your DNS is pointing to the server. Everything should work
-now! However, we are serving our page through HTTP, we [definitely][dmsnh] want
-HTTPS. It might sound unnecessary since we don't have any forms on our website
-(no data to be encrypted), but HTTPS also guarantees site authenticity (protects
-you against man-in-the-middle attacks) and normalizes the use of encryption on
-the web.
-
-In order to set up HTTPS, we need a certificate. I use one issued by [Let's
-Encrypt][le], which are free and very easy to use (and they are renewed
-automatically). To do so, I use [Certbot][cb], developed by the [EFF][eff]. To
-use it, go to the Certbot's page, install it on your server and follow the
-instructions on the website. Make sure you enable redirection to HTTPS!
-
-It takes about 2 minutes to set up and now people will connect to your site
-using HTTPS. You can see that a new file has been created at
-`/etc/apache2/sites-available/<domain_name>-le-ssl.conf` by Certbot to configure
-the HTTPS site, plus a couple of lines will be added to the configuration file
-on port 80 to redirect to the encrypted site.
-
-Your site is ready!
-
-
-[post]: </blog/2019/12/your-corner-of-the-internet/> "Your corner of the Internet — Oscar Benedito"
-[ex]: <https://gitlab.com/pages/hugo> "GitLab Pages Examples: Hugo — GitLab"
-[dmsnh]: <https://doesmysiteneedhttps.com/> "Does my site need HTTPS?"
-[le]: <https://letsencrypt.org> "Let's Encrypt"
-[cb]: <https://certbot.eff.org/> "Certbot"
-[eff]: <https://www.eff.org/> "Electronic Frontier Foundation"
diff --git a/content/blog/2020-02-23-sharing-a-secret.html b/content/blog/2020-02-23-sharing-a-secret.html
@@ -0,0 +1,113 @@
+<!-- title: Sharing a secret -->
+<!-- slug: sharing-a-secret -->
+<!-- categories: Cryptography -->
+<!-- date: 2020-02-23T00:00:00Z -->
+<!-- extrafooter: <a href="/jsweblabels/" rel="jslicense" style="display: none;"></a><script id="MathJax-script" async src="/js/mathjax-3.1.0/tex-chtml.js"></script> -->
+
+<p>
+ Making a backup of a secret can be tricky. For instance: I have a lot of passwords stored in an
+ encrypted file, which I can edit through my password manager. The data in that file is both very
+ sensitive and crucial. I currently have some offline backups (which are updated every once in a
+ while) in different locations and one online backup in case I lose access to my passwords and I am
+ not able to go to one of the locations where other backups are kept.</p>
+<!-- /p -->
+
+<p>
+ The problem with having an online backup is that such sensitive data must be kept away from
+ untrusted third parties and, so far, there's no third party I would trust with all those
+ passwords. My solution is to distribute the trust. The encrypted file is encrypted again multiple
+ times with very long random passwords. Those passwords are distributed across different services,
+ and the file in another one, so no one service has access to the encrypted file.</p>
+<!-- /p -->
+
+<p>
+ This seems like a reasonably secure system (considering the diversity of parties that should agree
+ to attack me/get hacked). However, a couple of days ago, I was introduced to a much simpler and
+ convenient method to "distribute" a secret: <a
+ href="https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing">Shamir's Secret Sharing</a>.</p>
+<!-- /p -->
+
+<h2>Shamir's Secret Sharing</h2>
+
+<p>
+ Shamir's Secret Sharing was created by <a href="https://en.wikipedia.org/wiki/Adi_Shamir">Adi
+ Shamir</a>, a cryptographer who is also the co-inventor of the—probably more widely known—<a
+ href="https://en.wikipedia.org/wiki/RSA_(cryptosystem)">RSA algorithm</a> (yes, that S stands for
+ Shamir!). Here, I'll try to briefly explain how it works.</p>
+<!-- /p -->
+
+<p>
+ Given a secret \(S\) (coded as a number), we want to distribute it among \(n\) parties (giving
+ each party a "share" of the secret) in such a way that only \(k \leq n\) shares are needed to
+ retrieve the secret, but that \(k-1\) shares don't grant any kind of knowledge on \(S\).</p>
+<!-- /p -->
+
+<p>
+ Shamir's method is based on the fact that given \(n + 1\) pairs \((x_i, y_i)\) such that \(i \neq
+ j \implies x_i \neq x_j\), then there exists a unique polynomial \(p\) of degree \(n\) or less
+ that satisfies that \(p(x_i) = y_i\), \(\forall i \in \{1, \dots, n\}\) (and we have an efficient
+ method to find \(p\) given \(n\) points).</p>
+<!-- /p -->
+
+<p>
+ Let's put it into practice. Given a secret \(S\), to be shared with \(n\) parties in a way that
+ any \(k\) parties can retrieve it, we'll build the following polynomial:</p>
+<!-- /p -->
+
+<p>\[p(x) = S + a_1 x + a_2 x^2 + ... + a_{k-1} x^{k-1},\]</p>
+
+<p>
+ where \(a_i\) are random numbers, \(\forall i \in \{1, \dots, k-1\}\). Now we'll evaluate our
+ polynomial on \(n\) different points (and different from 0) to obtain \(n\) pairs of the form
+ \((x_i, p(x_i))\). This will be the shares of the secret. Each party will get one share. We know
+ that \(k\) shares define a unique polynomial \(p\) of degree \(k-1\), (if we find it, we'll find
+ \(S\)). On the other hand, there are an infinite amount of polynomials of degree \(k-1\) that
+ interpolate \(k-1\) points, so the secret cannot be easily obtained by gaining access to \(k-1\)
+ shares<sup id="fnref1"><a href="#fn1">1</a></sup>.</p>
+<!-- /p -->
+
+<p>
+ If we want to recover the secret from \(k\) shares, we can interpolate the \(k\) points \((x_i,
+ p(x_i))\) using <a href="https://en.wikipedia.org/wiki/Lagrange_polynomial">Lagrange's form for
+ the interpolation polynomial</a><sup id="fnref2"><a href="#fn2">2</a></sup>:</p>
+<!-- /p -->
+
+<p>\[p(x) = \sum_{i=1}^{k} p(x_i) l_i(x),\]</p>
+
+<p>where</p>
+
+<p>
+ \[l_i(x) = \prod_{\begin{smallmatrix}1\leq m\leq k\ m\neq i\end{smallmatrix}}
+ \frac{x-x_m}{x_i-x_m}.\]</p>
+<!-- /p -->
+
+<p>Now, evaluating on \(x = 0\) we'll find the secret (because \(p(0) = S\)).</p>
+
+<h2>Final notes</h2>
+
+<p>
+ Now we have a method to share our secret between multiple parties and being able to retrieve it
+ with only some of them. This method is not too hard to code yourself, however, there are
+ implementations online if you would rather not do that (make sure you are running trusted
+ code!).</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ This is not completely true when working with positive integers, but it can be solved by working
+ with finite fields. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ Let's quickly prove that the \(p\) defined in Lagrange's form (\(\bar{p}\) from now on) is the
+ same as the previously defined \(p\). \(\bar{p}\) is clearly a polynomial of degree (at most)
+ \(k-1\), since it is the sum of polynomials of degree \(k-1\), so we only need to prove that it
+ interpolates the points given (we'll asume that the fact that there is only one polynomial of
+ degree at most \(k-1\) that interpolates \(k\) points is true). That is easy to prove since \(i
+ \neq j \implies l_i(x_j) = 0\) and \(l_i(x_i) = 1\), therefore having \(\bar{p}(x_i) = p(x_i)
+ l_i(x_i) = p(x_i)\). <a href="#fnref2" title="Jump back to footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
+</div>
diff --git a/content/blog/2020-02-23-sharing-a-secret.md b/content/blog/2020-02-23-sharing-a-secret.md
@@ -1,96 +0,0 @@
-<!-- title: Sharing a secret -->
-<!-- slug: sharing-a-secret -->
-<!-- categories: Cryptography -->
-<!-- date: 2020-02-23T00:00:00Z -->
-<!-- extrafooter: <a href="/jsweblabels/" rel="jslicense" style="display: none;"></a><script id="MathJax-script" async src="/js/mathjax-3.1.0/tex-chtml.js"></script> -->
-
-Making a backup of a secret can be tricky. For instance: I have a lot of
-passwords stored in an encrypted file, which I can edit through my password
-manager. The data in that file is both very sensitive and crucial. I currently
-have some offline backups (which are updated every once in a while) in different
-locations and one online backup in case I lose access to my passwords and I am
-not able to go to one of the locations where other backups are kept.
-
-The problem with having an online backup is that such sensitive data must be
-kept away from untrusted third parties and, so far, there's no third party I
-would trust with all those passwords. My solution is to distribute the trust.
-The encrypted file is encrypted again multiple times with very long random
-passwords. Those passwords are distributed across different services, and the
-file in another one, so no one service has access to the encrypted file.
-
-This seems like a reasonably secure system (considering the diversity of parties
-that should agree to attack me/get hacked). However, a couple of days ago, I was
-introduced to a much simpler and convenient method to "distribute" a secret:
-[Shamir's Secret Sharing][sss].
-
-## Shamir's Secret Sharing
-
-Shamir's Secret Sharing was created by [Adi Shamir][as], a cryptographer who is
-also the co-inventor of the—probably more widely known—[RSA algorithm][rsa]
-(yes, that S stands for Shamir!). Here, I'll try to briefly explain how it
-works.
-
-Given a secret \\(S\\) (coded as a number), we want to distribute it among
-\\(n\\) parties (giving each party a "share" of the secret) in such a way that
-only \\(k \\leq n\\) shares are needed to retrieve the secret, but that
-\\(k-1\\) shares don't grant any kind of knowledge on \\(S\\).
-
-Shamir's method is based on the fact that given \\(n + 1\\) pairs \\((x_i,
-y_i)\\) such that \\(i \\neq j \\implies x_i \\neq x_j\\), then there exists a
-unique polynomial \\(p\\) of degree \\(n\\) or less that satisfies that
-\\(p(x_i) = y_i\\), \\(\\forall i \\in \\{1, \\dots, n\\}\\) (and we have an
-efficient method to find \\(p\\) given \\(n\\) points).
-
-Let's put it into practice. Given a secret \\(S\\), to be shared with \\(n\\)
-parties in a way that any \\(k\\) parties can retrieve it, we'll build the
-following polynomial:
-
-\\[p(x) = S + a_1 x + a_2 x^2 + ... + a_{k-1} x^{k-1},\\]
-
-where \\(a_i\\) are random numbers, \\(\\forall i \\in \\{1, \\dots, k-1\\}\\).
-Now we'll evaluate our polynomial on \\(n\\) different points (and different
-from 0) to obtain \\(n\\) pairs of the form \\((x_i, p(x_i))\\). This will be
-the shares of the secret. Each party will get one share. We know that \\(k\\)
-shares define a unique polynomial \\(p\\) of degree \\(k-1\\), (if we find it,
-we'll find \\(S\\)). On the other hand, there are an infinite amount of
-polynomials of degree \\(k-1\\) that interpolate \\(k-1\\) points, so the secret
-cannot be easily obtained by gaining access to \\(k-1\\) shares[^integers].
-
-[^integers]: This is not completely true when working with positive integers,
- but it can be solved by working with finite fields.
-
-If we want to recover the secret from \\(k\\) shares, we can interpolate the
-\\(k\\) points \\((x_i, p(x_i))\\) using [Lagrange's form for the interpolation
-polynomial][int][^proof]:
-
-[^proof]: Let's quickly prove that the \\(p\\) defined in Lagrange's form
- (\\(\\bar{p}\\) from now on) is the same as the previously defined \\(p\\).
- \\(\\bar{p}\\) is clearly a polynomial of degree (at most) \\(k-1\\), since it
- is the sum of polynomials of degree \\(k-1\\), so we only need to prove that
- it interpolates the points given (we'll asume that the fact that there is only
- one polynomial of degree at most \\(k-1\\) that interpolates \\(k\\) points is
- true). That is easy to prove since \\(i \\neq j \\implies l_i(x_j) = 0\\) and
- \\(l_i(x_i) = 1\\), therefore having \\(\\bar{p}(x_i) = p(x_i) l_i(x_i) =
- p(x_i)\\).
-
-\\[p(x) = \\sum_{i=1}^{k} p(x_i) l_i(x),\\]
-
-where
-
-\\[l_i(x) = \\prod_{\\begin{smallmatrix}1\\leq m\\leq k\\ m\\neq
-i\\end{smallmatrix}} \\frac{x-x_m}{x_i-x_m}.\\]
-
-Now, evaluating on \\(x = 0\\) we'll find the secret (because \\(p(0) = S\\)).
-
-## Final notes
-
-Now we have a method to share our secret between multiple parties and being able
-to retrieve it with only some of them. This method is not too hard to code
-yourself, however, there are implementations online if you would rather not do
-that (make sure you are running trusted code!).
-
-
-[sss]: <https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing> "Shamir's Secret Sharing — Wikipedia"
-[as]: <https://en.wikipedia.org/wiki/Adi_Shamir> "Adi Shamir — Wikipedia"
-[rsa]: <https://en.wikipedia.org/wiki/RSA_(cryptosystem)> "RSA — Wikipedia"
-[int]: <https://en.wikipedia.org/wiki/Lagrange_polynomial> "Lagrange polynomial — Wikipedia"
diff --git a/content/blog/2020-03-01-new-domain-name.html b/content/blog/2020-03-01-new-domain-name.html
@@ -0,0 +1,11 @@
+<!-- title: New domain name: oscarbenedito.com -->
+<!-- slug: new-domain-name -->
+<!-- categories: Miscellany, Personal domain -->
+<!-- date: 2020-03-01T00:00:00Z -->
+
+<p>
+ After a lot of thought, I have decided to change my domain to <a
+ href="https://oscarbenedito.com">oscarbenedito.com</a>. My website should be completely moved,
+ however other services (including my email) are still under the obenedito.org domain, I will move
+ them progressively when I have time to do so.</p>
+<!-- /p -->
diff --git a/content/blog/2020-03-01-new-domain-name.md b/content/blog/2020-03-01-new-domain-name.md
@@ -1,9 +0,0 @@
-<!-- title: New domain name: oscarbenedito.com -->
-<!-- slug: new-domain-name -->
-<!-- categories: Miscellany, Personal domain -->
-<!-- date: 2020-03-01T00:00:00Z -->
-
-After a lot of thought, I have decided to change my domain to
-[oscarbenedito.com](https://oscarbenedito.com). My website should be completely
-moved, however other services (including my email) are still under the
-obenedito.org domain, I will move them progressively when I have time to do so.
diff --git a/content/blog/2020-03-02-types-of-networks.html b/content/blog/2020-03-02-types-of-networks.html
@@ -0,0 +1,98 @@
+<!-- title: Centralized, decentralized and distributed networks -->
+<!-- slug: types-of-networks -->
+<!-- categories: Miscellany -->
+<!-- date: 2020-03-02T00:00:00Z -->
+
+<p>
+ When we are trying to understand a communications network, having an approximate image of how the
+ network operates can be very valuable. Do all communications go through the same node? Is there a
+ central authority? Can nodes communicate directly with each other? Depending on how the network
+ operates, we can classify it as centralized, decentralized or distributed.</p>
+<!-- /p -->
+
+<h3>Centralized networks</h3>
+
+<p>
+ When all the nodes on a network are connected to one unique node, we call it a centralized
+ network. All communications happen through that one "master" node. An example of a centralized
+ network is the one created by most instant messengers, for example <a href="https://signal.org/">Signal</a>.
+ Every time we send a message, it goes to Signal's servers and it is then sent to its destination.
+ This creates a network similar to the following, where everyone is connected to one server (or
+ cluster of servers).</p>
+<!-- /p -->
+
+<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/centralized-network.svg#l"></use></svg></p>
+
+<p>
+ Having everything go through the same computer has its pros and cons. On the one hand, it makes
+ deployment easier and faster, data consistency is easy to maintain and it is an efficient network
+ (if, for instance, you need to gather data, it is all in one server). On the other hand, it
+ creates a single point of failure for the whole network (which also facilitates censorship) and it
+ makes it easier to abuse users (as the central server has a monopoly over the network)<sup
+ id="fnref1"><a href="#fn1">1</a></sup>. This type of network also makes escalation much harder, as
+ the resources are provided by one sole party.</p>
+<!-- /p -->
+
+<h3>Decentralized networks</h3>
+
+<p>
+ Decentralized networks don't have one central node, but multiple of them, which are connected
+ between themselves. When clients connect to the network, their communications go through their
+ "master" node, to the destination's "master" node, and finally to the destination. An example of a
+ decentralized network is <a href="https://en.wikipedia.org/wiki/Email">e-mail</a>. When Alice
+ (<code>alice@example.com</code>) wants to send an e-mail to Bob (<code>bob@example.org</code>),
+ Alice's computer sends the message to <code>example.com</code>'s server. From there, it is sent to
+ <code>example.org</code>, and finally <code>example.org</code> sends it to Bob's computer. A
+ decentralized network looks similar to the following network.</p>
+<!-- /p -->
+
+<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/decentralized-network.svg#l"></use></svg></p>
+
+<p>
+ Decentralized networks solve some of the centralization problems: no entity has control over the
+ whole network anymore, allowing users to choose between different providers and switch servers (or
+ self-host) if one starts abusing its power. If a server is down, others can still communicate
+ ordinarily, which also makes censorship more difficult. Decentralized networks are also easier to
+ escalate. Nonetheless, this type of network requires more infrastructure and can become less
+ efficient for certain operations (like global tasks). It is also harder to deploy updates, as
+ servers might update at different times, when each administrator decides to do so.</p>
+<!-- /p -->
+
+<h3>Distributed networks</h3>
+
+<p>
+ Distributed networks only have one type of node, and they are connected with each other (although
+ not necessarily all with all). This creates a very robust network where all nodes are client and
+ server at the same time. The <a href="https://en.wikipedia.org/wiki/BitTorrent">BitTorrent
+ protocol</a> is an example of a protocol that works with a distributed network. The following
+ image shows what a distributed network looks like.</p>
+<!-- /p -->
+
+<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/distributed-network.svg#l"></use></svg></p>
+
+<p>
+ Because there are no central servers, distributed networks easily circumvent censorship and are
+ practically immune to denial-of-service attacks. Since every user is client and server at the same
+ time, these networks are highly scalable without the need for additional central resources.
+ However, distributed networks make deployment a lot harder.</p>
+<!-- /p -->
+
+<h2>Final comments</h2>
+
+<p>
+ I hope this post has clarified the main differences between centralized, decentralized and
+ distributed networks as well as showed some applications for each of them. In the future, I might
+ refer to this post when talking about services and the type of network they rely on.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ This is pretty usual. Whether it is services selling user's data, censoring content, a sudden
+ rise of prices, etc., when dealing with centralized services, users don't have much choice but
+ to leave the network completely (which might not be affordable). <a href="#fnref1" title="Jump
+ back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-03-02-types-of-networks.md b/content/blog/2020-03-02-types-of-networks.md
@@ -1,88 +0,0 @@
-<!-- title: Centralized, decentralized and distributed networks -->
-<!-- slug: types-of-networks -->
-<!-- categories: Miscellany -->
-<!-- date: 2020-03-02T00:00:00Z -->
-
-When we are trying to understand a communications network, having an approximate
-image of how the network operates can be very valuable. Do all communications go
-through the same node? Is there a central authority? Can nodes communicate
-directly with each other? Depending on how the network operates, we can classify
-it as centralized, decentralized or distributed.
-
-### Centralized networks
-
-When all the nodes on a network are connected to one unique node, we call it a
-centralized network. All communications happen through that one "master" node.
-An example of a centralized network is the one created by most instant
-messengers, for example [Signal][s]. Every time we send a message, it goes to
-Signal's servers and it is then sent to its destination. This creates a network
-similar to the following, where everyone is connected to one server (or cluster
-of servers).
-
-<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/centralized-network.svg#l"></use></svg></p>
-
-Having everything go through the same computer has its pros and cons. On the one
-hand, it makes deployment easier and faster, data consistency is easy to
-maintain and it is an efficient network (if, for instance, you need to gather
-data, it is all in one server). On the other hand, it creates a single point of
-failure for the whole network (which also facilitates censorship) and it makes
-it easier to abuse users (as the central server has a monopoly over the
-network)[^common]. This type of network also makes escalation much harder, as
-the resources are provided by one sole party.
-
-[^common]: This is pretty usual. Whether it is services selling user's data,
- censoring content, a sudden rise of prices, etc., when dealing with
- centralized services, users don't have much choice but to leave the network
- completely (which might not be affordable).
-
-### Decentralized networks
-
-Decentralized networks don't have one central node, but multiple of them, which
-are connected between themselves. When clients connect to the network, their
-communications go through their "master" node, to the destination's "master"
-node, and finally to the destination. An example of a decentralized network is
-[e-mail][em]. When Alice (`alice@example.com`) wants to send an e-mail to Bob
-(`bob@example.org`), Alice's computer sends the message to `example.com`'s
-server. From there, it is sent to `example.org`, and finally `example.org` sends
-it to Bob's computer. A decentralized network looks similar to the following
-network.
-
-<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/decentralized-network.svg#l"></use></svg></p>
-
-Decentralized networks solve some of the centralization problems: no entity has
-control over the whole network anymore, allowing users to choose between
-different providers and switch servers (or self-host) if one starts abusing its
-power. If a server is down, others can still communicate ordinarily, which also
-makes censorship more difficult. Decentralized networks are also easier to
-escalate. Nonetheless, this type of network requires more infrastructure and can
-become less efficient for certain operations (like global tasks). It is also
-harder to deploy updates, as servers might update at different times, when each
-administrator decides to do so.
-
-### Distributed networks
-
-Distributed networks only have one type of node, and they are connected with
-each other (although not necessarily all with all). This creates a very robust
-network where all nodes are client and server at the same time. The [BitTorrent
-protocol][bt] is an example of a protocol that works with a distributed network.
-The following image shows what a distributed network looks like.
-
-<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/distributed-network.svg#l"></use></svg></p>
-
-Because there are no central servers, distributed networks easily circumvent
-censorship and are practically immune to denial-of-service attacks. Since every
-user is client and server at the same time, these networks are highly scalable
-without the need for additional central resources. However, distributed networks
-make deployment a lot harder.
-
-## Final comments
-
-I hope this post has clarified the main differences between centralized,
-decentralized and distributed networks as well as showed some applications for
-each of them. In the future, I might refer to this post when talking about
-services and the type of network they rely on.
-
-
-[s]: <https://signal.org/> "Signal"
-[em]: <https://en.wikipedia.org/wiki/Email> "Email — Wikipedia"
-[bt]: <https://en.wikipedia.org/wiki/BitTorrent> "BitTorrent — Wikipedia"
diff --git a/content/blog/2020-03-12-lightweight-website.html b/content/blog/2020-03-12-lightweight-website.html
@@ -0,0 +1,58 @@
+<!-- title: A lightweight website -->
+<!-- slug: lightweight-website -->
+<!-- categories: Personal domain -->
+<!-- date: 2020-03-12T00:00:00Z -->
+
+<p>
+ Since the start of this site, having a lightweight website has been one of my priorities. Every
+ file served has been minimized, you won't see any pictures that aren't vector graphics (except for
+ the <code>favicon.ico</code> file) and users don't need to download fonts or JavaScript libraries.
+ On top of that, the amount of JavaScript required is minimum. Indeed, as of right now, the only JS
+ that runs is a very simple function to toggle the theme and another one to open the navigation
+ menu on small screens. That results in super lightweight pages, which keeps the loading time to a
+ minimum and reduces the bandwidth usage of the server.</p>
+<!-- /p -->
+
+<p>
+ The one thing I've had doubts about is minimizing HTML. Some friends argued that minimizing the
+ code obscures it, while I argued that it is easy to <em>prettify</em> HTML with one of the many
+ tools online. However, lately, I have been a bit frustrated with Hugo's minimizing tool as it had
+ some unexpected behavior with SVG's, so I decided to investigate the pros and cons of file
+ minimization a bit further.</p>
+<!-- /p -->
+
+<p>
+ When you access a webpage it is normally compressed (if the server supports it), and this compression
+ makes the previous minimization of files almost useless. Let me explain: my main blog page's size
+ is about 18.3KB, but it can be reduced down to 17.2KB with Hugo's minimizing tool<sup
+ id="fnref1"><a href="#fn1">1</a></sup>. Once compressed with <a href="https://en.wikipedia.org/wiki/Gzip">gzip</a>,
+ the sizes are 5845 and 5747 bytes respectively, so the bandwidth save is only 100 bytes! Similar
+ results have been obtained for all the pages of the site that I have tested, so it looks like
+ minimizing isn't helping that much.</p>
+<!-- /p -->
+
+<p>
+ On the other hand, I see the point made by the friends who argue that having the code available
+ when pressing <code>view source</code> can be useful, even if code could potentially be
+ prettified. Given this, I have decided not to minimize the HTML files. A similar argument could be
+ made to not minimize CSS and JS (indeed, in the future I might change my mind), but they will stay
+ minimized for now<sup id="fnref2"><a href="#fn2">2</a></sup>.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ It is actually 15.5KB, but that includes errors on the SVG's minified, once fixed, it becomes
+ the 17.2KB mentioned. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ These files can be found more easily on the source code since they are not build up from
+ templates, and it is uncommon to view the source code of those files, as they are normally
+ viewed from the browser's inspection tools. On top of that, CSS is "compiled" from SCSS files,
+ and once again, these files are easily reachable at the public repository of the website.
+ Finally, the change in size is higher (1.5KB for the CSS file). <a href="#fnref2" title="Jump
+ back to footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-03-12-lightweight-website.md b/content/blog/2020-03-12-lightweight-website.md
@@ -1,50 +0,0 @@
-<!-- title: A lightweight website -->
-<!-- slug: lightweight-website -->
-<!-- categories: Personal domain -->
-<!-- date: 2020-03-12T00:00:00Z -->
-
-Since the start of this site, having a lightweight website has been one of my
-priorities. Every file served has been minimized, you won't see any pictures
-that aren't vector graphics (except for the `favicon.ico` file) and users don't
-need to download fonts or JavaScript libraries. On top of that, the amount of
-JavaScript required is minimum. Indeed, as of right now, the only JS that runs
-is a very simple function to toggle the theme and another one to open the
-navigation menu on small screens. That results in super lightweight pages, which
-keeps the loading time to a minimum and reduces the bandwidth usage of the
-server.
-
-The one thing I've had doubts about is minimizing HTML. Some friends argued that
-minimizing the code obscures it, while I argued that it is easy to *prettify*
-HTML with one of the many tools online. However, lately, I have been a bit
-frustrated with Hugo's minimizing tool as it had some unexpected behavior with
-SVG's, so I decided to investigate the pros and cons of file minimization a bit
-further.
-
-When you access a webpage it is normally compressed (if the server supports it),
-and this compression makes the previous minimization of files almost useless.
-Let me explain: my main blog page's size is about 18.3KB, but it can be reduced
-down to 17.2KB with Hugo's minimizing tool[^errors]. Once compressed with
-[gzip][gz], the sizes are 5845 and 5747 bytes respectively, so the bandwidth
-save is only 100 bytes! Similar results have been obtained for all the pages of
-the site that I have tested, so it looks like minimizing isn't helping that
-much.
-
-[^errors]: It is actually 15.5KB, but that includes errors on the SVG's
- minified, once fixed, it becomes the 17.2KB mentioned.
-
-On the other hand, I see the point made by the friends who argue that having the
-code available when pressing `view source` can be useful, even if code could
-potentially be prettified. Given this, I have decided not to minimize the HTML
-files. A similar argument could be made to not minimize CSS and JS (indeed, in
-the future I might change my mind), but they will stay minimized for
-now[^css-js].
-
-[^css-js]: These files can be found more easily on the source code since they
- are not build up from templates, and it is uncommon to view the source code of
- those files, as they are normally viewed from the browser's inspection tools.
- On top of that, CSS is "compiled" from SCSS files, and once again, these files
- are easily reachable at the public repository of the website. Finally, the
- change in size is higher (1.5KB for the CSS file).
-
-
-[gz]: <https://en.wikipedia.org/wiki/Gzip> "gzip — Wikipedia"
diff --git a/content/blog/2020-03-21-lighter-website.html b/content/blog/2020-03-21-lighter-website.html
@@ -0,0 +1,77 @@
+<!-- title: A lighter website -->
+<!-- slug: lighter-website -->
+<!-- categories: Personal domain -->
+<!-- date: 2020-03-21T00:00:00Z -->
+
+<p>
+ Following up with the <a href="/blog/2020/03/lightweight-website/">last post</a>, I decided to
+ make my website even faster (which probably doesn't make a difference anymore).</p>
+<!-- /p -->
+
+<h2>The logo</h2>
+
+<p>
+ My pages (HTML only) were about 21KB (without compression), but 11KB of those consisted of an SVG
+ that appeared in all of them: the logo. The logo wasn't requested from a different static file
+ because I needed to modify it using CSS (so that colors would change when switching to the dark
+ theme) and, at the time, I thought inlining was the only option to allow that. However,
+ investigating a little I found out there are alternatives to inlining: we can take advantage of
+ the <code>use</code> tag of SVGs to "inline" an SVG from a different URL. By using that, my pages
+ are now around 10KB of size (plus the statics files, which have a total size of 37KB for the pages
+ without MathJax).</p>
+<!-- /p -->
+
+<h2>The static files</h2>
+
+<p>
+ Considering that the <code>favicon.ico</code> is already 15KB, 47KB for a page is very good!
+ Nevertheless, I wanted to reduce it even more<sup id="fnref1"><a href="#fn1">1</a></sup>. I looked
+ into browser caching and liked the idea. I'll explain the basics. When our browser sends a request
+ for a certain resource (URL/file), the server that responds can add information that tells the
+ browser how long it should keep the file for. If the next time you browse that site and need the
+ file again the file hasn't "expired", your browser will not request it, but instead make use of
+ the copy previously downloaded. This reduces the number of requests made and the bandwidth
+ used.</p>
+<!-- /p -->
+
+<p>
+ The only problem with browser caching is that if the contents of a certain file change, your users
+ will not see those until their copies expire. We want to maximize the time a file is used for
+ before requesting it again while minimizing the time between update checks (unless our static
+ files never change). To solve that, I used <a href="https://gohugo.io/hugo-pipes">Hugo's
+ Pipes</a>, which allows you to add the SHA256 sum of a static file to its name automatically (and
+ all the places where the file is referenced). Now when downloading the CSS file, your browser is
+ requesting <code>https://oscarbenedito.com/css/style.min.<SHA256>.css</code>, which will
+ (highly probably) change when the contents change. Since the URL will be different, the browser
+ will request the new file.</p>
+<!-- /p -->
+
+<h2>The uncompressed SVGs</h2>
+
+<p>
+ I found out that SVG files where not being compressed by default<sup id="fnref2"><a
+ href="#fn2">2</a></sup>. So I also enabled that!</p>
+<!-- /p -->
+
+<h2>Final comment</h2>
+
+<p>
+ My webpage is ridiculously small and all these optimizations aren't that important. However, it is
+ fun to learn about all of this and it can also be helpful if in the future I have a site with
+ bigger static files (or someone reading this has!).</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ By now you have probably figured out this is more of a hobby than something useful, as the size
+ reduced is ridiculously small. <a href="#fnref1" title="Jump back to footnote 1 in the
+ text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ I don't really know the reason why. It might have something to do with <code>.svgz</code> files.
+ No idea. <a href="#fnref2" title="Jump back to footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-03-21-lighter-website.md b/content/blog/2020-03-21-lighter-website.md
@@ -1,64 +0,0 @@
-<!-- title: A lighter website -->
-<!-- slug: lighter-website -->
-<!-- categories: Personal domain -->
-<!-- date: 2020-03-21T00:00:00Z -->
-
-Following up with the [last post][post], I decided to make my website even
-faster (which probably doesn't make a difference anymore).
-
-## The logo
-
-My pages (HTML only) were about 21KB (without compression), but 11KB of those
-consisted of an SVG that appeared in all of them: the logo. The logo wasn't
-requested from a different static file because I needed to modify it using CSS
-(so that colors would change when switching to the dark theme) and, at the time,
-I thought inlining was the only option to allow that. However, investigating a
-little I found out there are alternatives to inlining: we can take advantage of
-the `use` tag of SVGs to "inline" an SVG from a different URL. By using that, my
-pages are now around 10KB of size (plus the statics files, which have a total
-size of 37KB for the pages without MathJax).
-
-## The static files
-
-Considering that the `favicon.ico` is already 15KB, 47KB for a page is very
-good! Nevertheless, I wanted to reduce it even more[^fun]. I looked into browser
-caching and liked the idea. I'll explain the basics. When our browser sends a
-request for a certain resource (URL/file), the server that responds can add
-information that tells the browser how long it should keep the file for. If the
-next time you browse that site and need the file again the file hasn't
-"expired", your browser will not request it, but instead make use of the copy
-previously downloaded. This reduces the number of requests made and the
-bandwidth used.
-
-[^fun]: By now you have probably figured out this is more of a hobby than
- something useful, as the size reduced is ridiculously small.
-
-The only problem with browser caching is that if the contents of a certain file
-change, your users will not see those until their copies expire. We want to
-maximize the time a file is used for before requesting it again while minimizing
-the time between update checks (unless our static files never change). To solve
-that, I used [Hugo's Pipes][hp], which allows you to add the SHA256 sum of a
-static file to its name automatically (and all the places where the file is
-referenced). Now when downloading the CSS file, your browser is requesting
-`https://oscarbenedito.com/css/style.min.<SHA256>.css`, which will (highly
-probably) change when the contents change. Since the URL will be different, the
-browser will request the new file.
-
-## The uncompressed SVGs
-
-I found out that SVG files where not being compressed by default[^reason]. So I
-also enabled that!
-
-[^reason]: I don't really know the reason why. It might have something to do
- with `.svgz` files. No idea.
-
-## Final comment
-
-My webpage is ridiculously small and all these optimizations aren't that
-important. However, it is fun to learn about all of this and it can also be
-helpful if in the future I have a site with bigger static files (or someone
-reading this has!).
-
-
-[post]: </blog/2020/03/lightweight-website/> "A lightweight website — Oscar Benedito"
-[hp]: <https://gohugo.io/hugo-pipes> "Hugo Pipes"
diff --git a/content/blog/2020-04-07-on-not-caring-about-your-privacy.html b/content/blog/2020-04-07-on-not-caring-about-your-privacy.html
@@ -0,0 +1,68 @@
+<!-- title: On not caring about your privacy -->
+<!-- slug: on-not-caring-about-your-privacy -->
+<!-- categories: Miscellany, Privacy -->
+<!-- date: 2020-04-07T16:17:00Z -->
+
+<p>
+ When talking about violations of our privacy, I've found that most people don't care because it is
+ a thing that happens "far away" (<em>who in that huge enterprise cares about me, my browsing
+ habits, etc.?</em>). I can see where those people are coming from, it looks as if you are
+ anonymous because there are just so many people whose data is collected.</p>
+<!-- /p -->
+
+<p>
+ Let's bring it closer: if you are connected to your work WiFi, your employer can—and probably
+ does—monitor your traffic. This sounds a lot "closer", but maybe not enough. What if a co-worker
+ showed you a screenshot with all the connections that the devices connected to the WiFi were
+ doing? That happened to me, I could see my phone in there, with the URL I was visiting a couple of
+ minutes ago. I could also see other co-workers' phones ("Someone's iPhone", "Someone's Samsung
+ Galaxy") also followed by URLs. Those URLs were harmless, so that particular screenshot wasn't
+ particularly dangerous. However, my superiors knew everything I was doing on the work's WiFi<sup
+ id="fnref1"><a href="#fn1">1</a></sup>. Not that I had anything to hide, but I also had no
+ intention to give up my privacy, so I started using Tor when connected to the WiFi. They would
+ probably never know I was using Tor (just that I was accessing a certain IP address), but even if
+ they did, I didn't really care, there's nothing wrong with using it.</p>
+<!-- /p -->
+
+<p>
+ It seems as people are fine with having their privacy violated when it's from someone "far away",
+ but they are not okay when someone "closer" does it. Another example of this is email. Most people
+ wouldn't give away their email password to anybody, but they are okay with the fact that their
+ email provider is reading all their emails. The same happens with most internet services.</p>
+<!-- /p -->
+
+<p>
+ One can have the feeling that they are anonymous because they are one in a million, but the
+ reality is we are not. Thanks to technology and data analysis, we are able to process all that
+ data and profile people based on it. It happens on such a great scale that <a
+ href="https://en.wikipedia.org/wiki/Real-time_bidding">real-time bidding</a> is a thing. When you
+ visit a webpage, there is a real-time bid between advertisers to publish their ad in the
+ designated spaces, and companies bid more or less depending on the profile they have made of you.
+ In less than a second companies retrieve your profile and bid for you, every time you surf the
+ Internet!</p>
+<!-- /p -->
+
+<p>
+ You are one of many, but you are definitely not anonymous because of it. Targeted ads might not
+ sound too terrible. However, today companies are bidding for your attention, can you ensure
+ tomorrow they won't use that information for other purposes? Today you may trust a big company,
+ but the information they have will last for very long, can you trust the future leadership not to
+ use it for other purposes?</p>
+<!-- /p -->
+
+<p>
+ Just like you don't go around giving everyone access to your browsing history or emails, you
+ shouldn't do the same with companies. You might have nothing to hide, but why would you give such
+ private information away?</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ Not everything. When connected through HTTPS, traffic monitoring can only see the domain you are
+ visiting, not the actual URL. <a href="#fnref1" title="Jump back to footnote 1 in the
+ text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-04-07-on-not-caring-about-your-privacy.md b/content/blog/2020-04-07-on-not-caring-about-your-privacy.md
@@ -1,56 +0,0 @@
-<!-- title: On not caring about your privacy -->
-<!-- slug: on-not-caring-about-your-privacy -->
-<!-- categories: Miscellany, Privacy -->
-<!-- date: 2020-04-07T16:17:00Z -->
-
-When talking about violations of our privacy, I've found that most people don't
-care because it is a thing that happens "far away" (*who in that huge enterprise
-cares about me, my browsing habits, etc.?*). I can see where those people are
-coming from, it looks as if you are anonymous because there are just so many
-people whose data is collected.
-
-Let's bring it closer: if you are connected to your work WiFi, your employer
-can—and probably does—monitor your traffic. This sounds a lot "closer", but
-maybe not enough. What if a co-worker showed you a screenshot with all the
-connections that the devices connected to the WiFi were doing? That happened to
-me, I could see my phone in there, with the URL I was visiting a couple of
-minutes ago. I could also see other co-workers' phones ("Someone's iPhone",
-"Someone's Samsung Galaxy") also followed by URLs. Those URLs were harmless, so
-that particular screenshot wasn't particularly dangerous. However, my superiors
-knew everything I was doing on the work's WiFi[^https]. Not that I had anything
-to hide, but I also had no intention to give up my privacy, so I started using
-Tor when connected to the WiFi. They would probably never know I was using Tor
-(just that I was accessing a certain IP address), but even if they did, I didn't
-really care, there's nothing wrong with using it.
-
-[^https]: Not everything. When connected through HTTPS, traffic monitoring can
- only see the domain you are visiting, not the actual URL.
-
-It seems as people are fine with having their privacy violated when it's from
-someone "far away", but they are not okay when someone "closer" does it. Another
-example of this is email. Most people wouldn't give away their email password to
-anybody, but they are okay with the fact that their email provider is reading
-all their emails. The same happens with most internet services.
-
-One can have the feeling that they are anonymous because they are one in a
-million, but the reality is we are not. Thanks to technology and data analysis,
-we are able to process all that data and profile people based on it. It happens
-on such a great scale that [real-time bidding][rtb] is a thing. When you visit a
-webpage, there is a real-time bid between advertisers to publish their ad in the
-designated spaces, and companies bid more or less depending on the profile they
-have made of you. In less than a second companies retrieve your profile and bid
-for you, every time you surf the Internet!
-
-You are one of many, but you are definitely not anonymous because of it.
-Targeted ads might not sound too terrible. However, today companies are bidding
-for your attention, can you ensure tomorrow they won't use that information for
-other purposes? Today you may trust a big company, but the information they have
-will last for very long, can you trust the future leadership not to use it for
-other purposes?
-
-Just like you don't go around giving everyone access to your browsing history or
-emails, you shouldn't do the same with companies. You might have nothing to
-hide, but why would you give such private information away?
-
-
-[rtb]: <https://en.wikipedia.org/wiki/Real-time_bidding> "Real-time bidding — Wikipedia"
diff --git a/content/blog/2020-04-18-use-web-feeds.html b/content/blog/2020-04-18-use-web-feeds.html
@@ -0,0 +1,162 @@
+<!-- title: Use web feeds! -->
+<!-- slug: use-web-feeds -->
+<!-- categories: Decentralization -->
+<!-- date: 2020-04-18T14:59:00Z -->
+
+<p>
+ Web feeds are data formats used to provide users with updates through web syndication. Websites
+ can use web feeds to post their content in a format that allows users to easily check for updates
+ regularly. Examples of web feeds are <a href="https://en.wikipedia.org/wiki/Atom_(Web_standard)">Atom</a>,
+ <a href="https://en.wikipedia.org/wiki/RSS">RSS</a> or <a href="https://en.wikipedia.org/wiki/JSON_Feed">JSON Feed</a>.</p>
+<!-- /p -->
+
+<p>
+ The most popular is RSS, you have probably heard of it. Until a year ago, RSS to me was an old
+ technology that some people used to get their news on an ugly feed reader. I thought this
+ technology was obsolete because of the couple <a href="https://indieweb.org/silo">silos</a> that
+ monopolize online social interactions. Well, this couldn't be further from the truth. Web feeds
+ are definitely not obsolete, and those "ugly readers" I remembered were just particular examples,
+ but there are a lot of beautiful readers out there. There's also a lot of people that want to be
+ able to get updates on different sites without the need to have an account on a centralized
+ third-party service.</p>
+<!-- /p -->
+
+<p>Let's see the benefits of using web feeds.</p>
+
+<h3>Web decentralization</h3>
+
+<p>
+ Web feeds allow for web syndication, which is key in order to decentralize the web. When you
+ follow a blog or a podcast through web feeds, neither you nor the content creator rely on a third
+ party to update you on the content. There's no need to post a new update on a social platform.
+ When new content is published, the subscribers will see the updates coming directly from the
+ original domain.</p>
+<!-- /p -->
+
+<h3>Centralized updates</h3>
+
+<p>
+ Wait, what?! Well, not as in "centralized service", but as in you get all the updates from all
+ these different websites in one app or program. Web feeds allow the subscriber to see all the
+ content updates in one place, so convenient! Without it, we probably would have to check every
+ single website regularly to see if new content was published (or maybe design a bot that would do
+ that for us, but still, annoying).</p>
+<!-- /p -->
+
+<h3>Control over content posting</h3>
+
+<p>
+ By not relying on a third party for content updates, creators have full control over their
+ communication channel. It will never shut down—disappearing along with the subscribers—, unless
+ the creator decides to do so. There also won't be any <em>magical</em> algorithms that decide
+ which updates are worth showing to their subscribers and which ones are not, or even which ones
+ <em>magically</em> get deleted. Subscribers get all of them.</p>
+<!-- /p -->
+
+<h3>Control over the consumption of content</h3>
+
+<p>
+ By using web feed readers, you can configure a dark theme, a bigger font, etc. You can even have
+ the content read to you. There are accessibility features for webpages as well, but when using a
+ web feed it is so much easier, since the content is presented in a standardized format. It is also
+ in the user's power to filter the content any way they want. Do you want to block certain words?
+ Done!</p>
+<!-- /p -->
+
+<h3>Privacy for the subscriber</h3>
+
+<p>
+ There's no need to insist on the fact that silos are a privacy nightmare. But there's more. If you
+ are reading a web feed, there are no advertisements tracking you and there are no <a
+ href="https://en.wikipedia.org/wiki/Web_beacon">tracking pixels</a>. You read the content (or not)
+ whenever you want, without anybody tracking you.</p>
+<!-- /p -->
+
+<h3>The disadvantages</h3>
+
+<p>
+ So, why doesn't everyone use it? First of all, most of the blogs I read have a web feed, Mastodon
+ does too, as well as Youtube<sup id="fnref1"><a href="#fn1">1</a></sup>. However, you cannot
+ comment through a feed reader and you normally don't see the "related content" and all those extra
+ features we can find on a website<sup id="fnref2"><a href="#fn2">2</a></sup>. There is also an
+ entry barrier: it takes a couple fewer seconds to hit subscribe/follow than to look for the web
+ feed and open your web feed reader to add it.</p>
+<!-- /p -->
+
+<p>
+ Web feeds also work best when you have a lot of sites that publish every once in a while. If you
+ subscribe to 500 sites that publish hourly, it can get overwhelming with the common feed readers
+ (although there are probably others that are ready for this kind of usage and make it nice).</p>
+<!-- /p -->
+
+<p>
+ Finally, web feeds avoid tracking subscribers and the embedding of adds. That can be an
+ inconvenience to the content owner, who might want to do that. Although I am not a fan of it, it
+ is definitely something that happens. If that is your case, there is an easy solution: don't post
+ the content on the web feed. Simply put your title and a two-line summary of the content.
+ Subscribers can then press on the link and open the content. This way you keep your subscribers up
+ to date, without losing the capacity to embed ads.</p>
+<!-- /p -->
+
+<h2>Why e-mail newsletters are not a web feed substitute</h2>
+
+<p>
+ E-mail newsletters have that decentralized component, you don't depend on a centralized service
+ (although most of them do, but that isn't necessary). However they are definitely not private.
+ First of all, you need to give out your e-mail address, who knows if it will end up on a spam
+ list? If you want to unsubscribe you have to go to their website and hope for them to erase your
+ data and not only archive it somewhere. Finally, e-newsletters can—and most do—contain tracking
+ pixels, so they can know how many times a subscriber accesses the content and when.</p>
+<!-- /p -->
+
+<p>
+ If you have an e-newsletter but don't have a website for it, then you have a reasonable excuse not
+ to have a feed (although you should definitely make a website!). If you post your newsletter
+ online, then add a web feed! It is very easy!</p>
+<!-- /p -->
+
+<h2>Fun fact!</h2>
+
+<p>
+ As a matter of fact, I started writing a post on RSS feeds about three weeks ago. When writing why
+ you should add the whole content on your RSS feed and not only a summary, I remembered that to do
+ so, I did a little hack. I would put the whole content in the <code>description</code> tag, which
+ was designed for a brief summary. That got me thinking, I wanted to follow the standards. After
+ searching for a while, I discovered you can use the <code>content:encoded</code> tag, which is
+ exactly what I needed, but there where other tags that also seemed to do the same. After some more
+ research, I discovered RSS has some standardization issues. So I looked at the alternative I had
+ heard about before: Atom. Apparently, Atom arose from the need to standardize RSS, with a new
+ design that wouldn't have backward compatibility. Atom is very similar to RSS, but I like the fact
+ that there is one clear specification (apparently it has other cool features in case you are
+ interested, but I didn't look into them much).</p>
+<!-- /p -->
+
+<p>
+ After reading about this I learned how it worked and implemented for my blog's feed (since Hugo's
+ default is RSS). So if you use my web feed, you are now retrieving an Atom feed!</p>
+<!-- /p -->
+
+<p>
+ As you probably figured my first draft had a different approach than the final post. This was
+ partially because shortly after I started writing, <a
+ href="https://kevq.uk/why-having-a-full-post-rss-feed-is-a-good-idea/">this</a> post came out so I
+ changed my focus a bit. If you don't post your full content on your web feed, read it!</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ If you want to follow people from other big social media sites, there are ways to do so! Use an
+ instance of <a href="https://github.com/zedeus/nitter">Nitter</a> for Twitter or an instance of
+ <a href="https://sr.ht/~cadence/bibliogram/">Bibliogram</a> for Instagram. If you have other
+ sites in mind, look around the Internet, someone probably implemented a web feed for it. <a
+ href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ This is actually seen as a good thing most of the time, as you get to consume the content
+ without any distractions. <a href="#fnref2" title="Jump back to footnote 2 in the
+ text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-04-18-use-web-feeds.md b/content/blog/2020-04-18-use-web-feeds.md
@@ -1,145 +0,0 @@
-<!-- title: Use web feeds! -->
-<!-- slug: use-web-feeds -->
-<!-- categories: Decentralization -->
-<!-- date: 2020-04-18T14:59:00Z -->
-
-Web feeds are data formats used to provide users with updates through web
-syndication. Websites can use web feeds to post their content in a format that
-allows users to easily check for updates regularly. Examples of web feeds are
-[Atom][atom], [RSS][rss] or [JSON Feed][json-feed].
-
-The most popular is RSS, you have probably heard of it. Until a year ago, RSS to
-me was an old technology that some people used to get their news on an ugly feed
-reader. I thought this technology was obsolete because of the couple
-[silos][silo] that monopolize online social interactions. Well, this couldn't be
-further from the truth. Web feeds are definitely not obsolete, and those "ugly
-readers" I remembered were just particular examples, but there are a lot of
-beautiful readers out there. There's also a lot of people that want to be able
-to get updates on different sites without the need to have an account on a
-centralized third-party service.
-
-Let's see the benefits of using web feeds.
-
-### Web decentralization
-
-Web feeds allow for web syndication, which is key in order to decentralize the
-web. When you follow a blog or a podcast through web feeds, neither you nor the
-content creator rely on a third party to update you on the content. There's no
-need to post a new update on a social platform. When new content is published,
-the subscribers will see the updates coming directly from the original domain.
-
-### Centralized updates
-
-Wait, what?! Well, not as in "centralized service", but as in you get all the
-updates from all these different websites in one app or program. Web feeds allow
-the subscriber to see all the content updates in one place, so convenient!
-Without it, we probably would have to check every single website regularly to
-see if new content was published (or maybe design a bot that would do that for
-us, but still, annoying).
-
-### Control over content posting
-
-By not relying on a third party for content updates, creators have full control
-over their communication channel. It will never shut down—disappearing along
-with the subscribers—, unless the creator decides to do so. There also won't be
-any *magical* algorithms that decide which updates are worth showing to their
-subscribers and which ones are not, or even which ones *magically* get deleted.
-Subscribers get all of them.
-
-### Control over the consumption of content
-
-By using web feed readers, you can configure a dark theme, a bigger font, etc.
-You can even have the content read to you. There are accessibility features for
-webpages as well, but when using a web feed it is so much easier, since the
-content is presented in a standardized format. It is also in the user's power to
-filter the content any way they want. Do you want to block certain words? Done!
-
-### Privacy for the subscriber
-
-There's no need to insist on the fact that silos are a privacy nightmare. But
-there's more. If you are reading a web feed, there are no advertisements
-tracking you and there are no [tracking pixels][tracking-pixel]. You read the
-content (or not) whenever you want, without anybody tracking you.
-
-### The disadvantages
-
-So, why doesn't everyone use it? First of all, most of the blogs I read have a
-web feed, Mastodon does too, as well as Youtube[^other-platforms]. However, you
-cannot comment through a feed reader and you normally don't see the "related
-content" and all those extra features we can find on a website[^distractions].
-There is also an entry barrier: it takes a couple fewer seconds to hit
-subscribe/follow than to look for the web feed and open your web feed reader to
-add it.
-
-[^other-platforms]: If you want to follow people from other big social media
- sites, there are ways to do so! Use an instance of [Nitter][nitter] for
- Twitter or an instance of [Bibliogram][bibliogram] for Instagram. If you have
- other sites in mind, look around the Internet, someone probably implemented a
- web feed for it.
-
-[^distractions]: This is actually seen as a good thing most of the time, as you
- get to consume the content without any distractions.
-
-Web feeds also work best when you have a lot of sites that publish every once in
-a while. If you subscribe to 500 sites that publish hourly, it can get
-overwhelming with the common feed readers (although there are probably others
-that are ready for this kind of usage and make it nice).
-
-Finally, web feeds avoid tracking subscribers and the embedding of adds. That
-can be an inconvenience to the content owner, who might want to do that.
-Although I am not a fan of it, it is definitely something that happens. If that
-is your case, there is an easy solution: don't post the content on the web feed.
-Simply put your title and a two-line summary of the content. Subscribers can
-then press on the link and open the content. This way you keep your subscribers
-up to date, without losing the capacity to embed ads.
-
-## Why e-mail newsletters are not a web feed substitute
-
-E-mail newsletters have that decentralized component, you don't depend on a
-centralized service (although most of them do, but that isn't necessary).
-However they are definitely not private. First of all, you need to give out your
-e-mail address, who knows if it will end up on a spam list? If you want to
-unsubscribe you have to go to their website and hope for them to erase your data
-and not only archive it somewhere. Finally, e-newsletters can—and most
-do—contain tracking pixels, so they can know how many times a subscriber
-accesses the content and when.
-
-If you have an e-newsletter but don't have a website for it, then you have a
-reasonable excuse not to have a feed (although you should definitely make a
-website!). If you post your newsletter online, then add a web feed! It is very
-easy!
-
-## Fun fact!
-
-As a matter of fact, I started writing a post on RSS feeds about three weeks
-ago. When writing why you should add the whole content on your RSS feed and not
-only a summary, I remembered that to do so, I did a little hack. I would put the
-whole content in the `description` tag, which was designed for a brief summary.
-That got me thinking, I wanted to follow the standards. After searching for a
-while, I discovered you can use the `content:encoded` tag, which is exactly what
-I needed, but there where other tags that also seemed to do the same. After some
-more research, I discovered RSS has some standardization issues. So I looked at
-the alternative I had heard about before: Atom. Apparently, Atom arose from the
-need to standardize RSS, with a new design that wouldn't have backward
-compatibility. Atom is very similar to RSS, but I like the fact that there is
-one clear specification (apparently it has other cool features in case you are
-interested, but I didn't look into them much).
-
-After reading about this I learned how it worked and implemented for my blog's
-feed (since Hugo's default is RSS). So if you use my web feed, you are now
-retrieving an Atom feed!
-
-As you probably figured my first draft had a different approach than the final
-post. This was partially because shortly after I started writing,
-[this][kevq-post] post came out so I changed my focus a bit. If you don't post
-your full content on your web feed, read it!
-
-
-[rss]: <https://en.wikipedia.org/wiki/RSS> "RSS — Wikipedia"
-[atom]: <https://en.wikipedia.org/wiki/Atom_(Web_standard)> "Atom — Wikipedia"
-[json-feed]: <https://en.wikipedia.org/wiki/JSON_Feed> "JSON Feed — Wikipedia"
-[silo]: <https://indieweb.org/silo> "Silo — IndieWeb Wiki"
-[tracking-pixel]: <https://en.wikipedia.org/wiki/Web_beacon> "Web beacon — Wikipedia"
-[nitter]: <https://github.com/zedeus/nitter> "Nitter — GitHub"
-[bibliogram]: <https://sr.ht/~cadence/bibliogram/> "Bibliogram — Sourcehut"
-[kevq-post]: <https://kevq.uk/why-having-a-full-post-rss-feed-is-a-good-idea/> "Why Having A Full Post RSS Feed Is A Good Idea — Kev Quirk"
diff --git a/content/blog/2020-05-05-my-journey-through-desktop-environments.html b/content/blog/2020-05-05-my-journey-through-desktop-environments.html
@@ -0,0 +1,137 @@
+<!-- title: My journey through desktop environments -->
+<!-- slug: my-journey-through-desktop-environments -->
+<!-- categories: FOSS, Miscellany -->
+<!-- date: 2020-05-05T19:26:00Z -->
+<!-- lastmod: 2020-05-06T07:52:00Z -->
+
+<p>
+ My first experience with GNU/Linux was with KDE. It is the desktop environment used on my college
+ computers, and it was more or less the only experience I had with the GNU/Linux operative system,
+ so it was the desktop environment I installed at home (at that point I don't think I knew the
+ difference between a distribution and a desktop environment). After some time, I got comfortable
+ with the new OS and learned that distributions and desktop environments were completely different
+ things, so I started to look around for other DEs and decided to go with GNOME. It was a weird
+ choice, as I had only read—and heard—bad things about GNOME, but I was reading a lot about the GNU
+ project and decided to go with the DE that was part of the project, just to try it out.</p>
+<!-- /p -->
+
+<p>
+ Well, GNOME is great. I love GNOME! I am glad I wanted to try it (for a more or less stupid
+ reason) against what people were writing/saying. It works great out of the box, it has programs
+ for everything I needed and can easily be configured to fit your needs<sup id="fnref1"><a
+ href="#fn1">1</a></sup>. With Debian 10, the dark theme is great, and other apps like firefox also
+ go dark with it<sup id="fnref2"><a href="#fn2">2</a></sup>. It was a bit confusing the first
+ couple of days, but it was easy to get used to. GNOME has worked great for me (and still does).
+ With the lack of a bar with all the open windows (like on KDE), I have gotten more used to moving
+ around with the keyboard. I also made a conscious effort to use the keyboard more, as I had seen
+ many people move around faster and more naturally when they weren't using the mouse. So, after
+ gaining confidence with the keyboard, I decided to finally give i3 a <em>real</em> shot a couple
+ of weeks ago.</p>
+<!-- /p -->
+
+<p>
+ <a href="https://i3wm.org/">i3</a> is a tiling window manager, which means that it is a window
+ manager that arranges windows in a way that they don't overlap. A window manager is the software
+ that manages your windows (resize, move, close, etc.). The difference with desktop environments is
+ that the latter come with a window manager, but also many more programs (like a terminal emulator
+ or a text editor) as well as panels, system menus, and other features. These normally all look
+ alike and work well together.</p>
+<!-- /p -->
+
+<p>
+ I say I decided to give it a <em>real</em> shot because I have tried i3 multiple times before:
+ mainly logging in, seeing how ugly everything looks, logging out<sup id="fnref3"><a href="#fn3">3</a></sup>.
+ This time it was different: I had time to figure everything out, so I decided to push through the
+ first days (when everything is to be configured"), and then decide. I installed it, tweaked it a
+ little, didn't like some things, installed <a href="https://swaywm.org/">sway</a>, it fixed some
+ things but messed up others, I also considered other tiling window managers like
+ <a href="https://dwm.suckless.org/">dwm</a>, and went back and forth a couple of times (all in one
+ day). Eventually, I decided sway had one problem I couldn't cope with<sup id="fnref4"><a href="#fn4">4</a></sup>
+ and decided to stick with i3. I made a list of everything that was missing (or "wrong") and went to bed.</p>
+<!-- /p -->
+
+<p>
+ The next day, I grabbed the list and started working on the items. Some of them were very easy to
+ fix, like make the sound buttons work. Some others were a little harder, like mounting USB
+ automatically. I even had to reinstall i3—a fork of i3 actually—so I could have gaps between
+ windows (yes! I needed those!). I also added more items to the "problems-to-fix" list as I kept
+ using i3. After about a week, I had fixed everything on the list!</p>
+<!-- /p -->
+
+<p>
+ This process of going through a lot of minor things made me realize how awesome GNOME is. It has
+ so many features, without a need for the user to spend hours and hours making everything work. KDE
+ probably also goes into this category, but I haven't used it as much so I can't say. Other DEs
+ that I have tried have given me some problems here or there, nothing major, but it isn't the
+ out-of-the-box experience I appreciate in GNOME.</p>
+<!-- /p -->
+
+<p>
+ Some people quickly disregard these DEs because they are "bloated". In my opinion, it is true.
+ They have an absurd number of features, but for myself, when I simply need everything to work
+ without any tweaking, this is great. As a new GNU/Linux user, I wanted my computer to work without
+ much configuration, while still being able to be "picky" about some stuff. Even as a
+ moderately-confident user, I didn't have a week to spend making i3 look and act as I wanted. For
+ all my little things to be included, there are probably many more that I don't want, and are also
+ included (and other people want). I am fine with my desktop environment being bloated. That
+ changes for pretty much any other software I run on my computer, I like simple things, but I also
+ don't have unlimited time. Indeed, my initial reason to switch to i3 (or a tiling window manager)
+ wasn't "less bloat" or simplicity<sup id="fnref5"><a href="#fn5">5</a></sup> (I find GNOME very
+ distraction-free, and it has a good performance on my computer). I switched because I was tired of
+ overlapping windows and I wanted to make more use of my keyboard for managing everything.</p>
+<!-- /p -->
+
+<p>
+ With all the changes, I am very satisfied with i3, and haven't gone back to GNOME for a week. It
+ did take a lot of time to figure everything out (and configure it), but it was something I had
+ wanted to do for a long time (that's why the many attempts) and I finally had extra time to do it.
+ It was definitely worth it!</p>
+<!-- /p -->
+
+<h2>Final note</h2>
+
+<p>
+ I think one of the major issues I had on my previous attempts was the <code>$mod</code> key used
+ for all i3 shortcuts. It is so hard to reach the <code>Super</code> key! I had already switched
+ the mapping of <code>Caps lock</code> and <code>Escape</code> (which improved my vim experience
+ drastically), so I knew <code>Caps lock</code> was the key I needed for my shortcuts (it is so
+ easy to reach!). I have now mapped <code>Caps lock</code> to act as <code>Escape</code> if I tap
+ it, and as <code>Super</code> if I hold down. With this little trick, i3 becomes a lot nicer, but
+ without damaging vim's experience. If you are considering using a tiling manager, think about it!
+ Also recommended if you use vim!</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ A very simple example is setting up "natural scroll" for the trackpad, which I had a couple of
+ issues the first time I tried with some DEs. But there are many things. <a href="#fnref1"
+ title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ I know this feature is not exclusive for GNOME (indeed, I configured i3 to act like this), but
+ it works out of the box, which is the point I am making. <a href="#fnref2" title="Jump back to
+ footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn3">
+ I have a HiDPI screen which made everything look super tiny. I had some issues with HiDPI
+ screens with KDE (there was always a weird app that didn't work well with it). This got solved
+ (out of the box!) with GNOME, and after all the frustration I had in the past, seeing it back
+ was a nightmare. This was finally solved pretty easily, although the solution is a little hacky
+ so I can also plug my computer into non-HiDPI screens. <a href="#fnref3" title="Jump back to
+ footnote 3 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn4">
+ The problem is that applications using Xwayland are blurry on HiDPI screens, and that wasn't
+ solvable as far as I could tell. They also had no plans to solve it anytime soon (according to
+ sway developers, it is an Xwayland problem, and it's on them to fix it, which is a fair point).
+ <a href="#fnref4" title="Jump back to footnote 4 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn5">
+ Now that I have tried it and feel comfortable, my next installation might come without GNOME and
+ probably have much less bloat, which I will appreciate for sure. It simply hasn't been a
+ priority so far. <a href="#fnref5" title="Jump back to footnote 5 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-05-05-my-journey-through-desktop-environments.md b/content/blog/2020-05-05-my-journey-through-desktop-environments.md
@@ -1,125 +0,0 @@
-<!-- title: My journey through desktop environments -->
-<!-- slug: my-journey-through-desktop-environments -->
-<!-- categories: FOSS, Miscellany -->
-<!-- date: 2020-05-05T19:26:00Z -->
-<!-- lastmod: 2020-05-06T07:52:00Z -->
-
-My first experience with GNU/Linux was with KDE. It is the desktop environment
-used on my college computers, and it was more or less the only experience I had
-with the GNU/Linux operative system, so it was the desktop environment I
-installed at home (at that point I don't think I knew the difference between a
-distribution and a desktop environment). After some time, I got comfortable with
-the new OS and learned that distributions and desktop environments were
-completely different things, so I started to look around for other DEs and
-decided to go with GNOME. It was a weird choice, as I had only read—and
-heard—bad things about GNOME, but I was reading a lot about the GNU project and
-decided to go with the DE that was part of the project, just to try it out.
-
-Well, GNOME is great. I love GNOME! I am glad I wanted to try it (for a more or
-less stupid reason) against what people were writing/saying. It works great out
-of the box, it has programs for everything I needed and can easily be configured
-to fit your needs[^detail]. With Debian 10, the dark theme is great, and other
-apps like firefox also go dark with it[^not-gnome]. It was a bit confusing the
-first couple of days, but it was easy to get used to. GNOME has worked great for
-me (and still does). With the lack of a bar with all the open windows (like on
-KDE), I have gotten more used to moving around with the keyboard. I also made a
-conscious effort to use the keyboard more, as I had seen many people move around
-faster and more naturally when they weren't using the mouse. So, after gaining
-confidence with the keyboard, I decided to finally give i3 a *real* shot a
-couple of weeks ago.
-
-[^detail]: A very simple example is setting up "natural scroll" for the
- trackpad, which I had a couple of issues the first time I tried with some DEs.
- But there are many things.
-
-[^not-gnome]: I know this feature is not exclusive for GNOME (indeed, I
- configured i3 to act like this), but it works out of the box, which is the
- point I am making.
-
-[i3][i3] is a tiling window manager, which means that it is a window manager
-that arranges windows in a way that they don't overlap. A window manager is the
-software that manages your windows (resize, move, close, etc.). The difference
-with desktop environments is that the latter come with a window manager, but
-also many more programs (like a terminal emulator or a text editor) as well as
-panels, system menus, and other features. These normally all look alike and work
-well together.
-
-I say I decided to give it a *real* shot because I have tried i3 multiple times
-before: mainly logging in, seeing how ugly everything looks, logging
-out[^hidpi]. This time it was different: I had time to figure everything out, so
-I decided to push through the first days (when everything is to be configured"),
-and then decide. I installed it, tweaked it a little, didn't like some things,
-installed [sway][sway], it fixed some things but messed up others, I also
-considered other tiling window managers like [dwm][dwm], and went back and forth
-a couple of times (all in one day). Eventually, I decided sway had one problem I
-couldn't cope with[^sway] and decided to stick with i3. I made a list of
-everything that was missing (or "wrong") and went to bed.
-
-[^hidpi]: I have a HiDPI screen which made everything look super tiny. I had
- some issues with HiDPI screens with KDE (there was always a weird app that
- didn't work well with it). This got solved (out of the box!) with GNOME, and
- after all the frustration I had in the past, seeing it back was a nightmare.
- This was finally solved pretty easily, although the solution is a little hacky
- so I can also plug my computer into non-HiDPI screens.
-
-[^sway]: The problem is that applications using Xwayland are blurry on HiDPI
- screens, and that wasn't solvable as far as I could tell. They also had no
- plans to solve it anytime soon (according to sway developers, it is an
- Xwayland problem, and it's on them to fix it, which is a fair point).
-
-The next day, I grabbed the list and started working on the items. Some of them
-were very easy to fix, like make the sound buttons work. Some others were a
-little harder, like mounting USB automatically. I even had to reinstall i3—a
-fork of i3 actually—so I could have gaps between windows (yes! I needed those!).
-I also added more items to the "problems-to-fix" list as I kept using i3. After
-about a week, I had fixed everything on the list!
-
-This process of going through a lot of minor things made me realize how awesome
-GNOME is. It has so many features, without a need for the user to spend hours
-and hours making everything work. KDE probably also goes into this category, but
-I haven't used it as much so I can't say. Other DEs that I have tried have given
-me some problems here or there, nothing major, but it isn't the out-of-the-box
-experience I appreciate in GNOME.
-
-Some people quickly disregard these DEs because they are "bloated". In my
-opinion, it is true. They have an absurd number of features, but for myself,
-when I simply need everything to work without any tweaking, this is great. As a
-new GNU/Linux user, I wanted my computer to work without much configuration,
-while still being able to be "picky" about some stuff. Even as a
-moderately-confident user, I didn't have a week to spend making i3 look and act
-as I wanted. For all my little things to be included, there are probably many
-more that I don't want, and are also included (and other people want). I am fine
-with my desktop environment being bloated. That changes for pretty much any
-other software I run on my computer, I like simple things, but I also don't have
-unlimited time. Indeed, my initial reason to switch to i3 (or a tiling window
-manager) wasn't "less bloat" or simplicity[^less-bloat] (I find GNOME very
-distraction-free, and it has a good performance on my computer). I switched
-because I was tired of overlapping windows and I wanted to make more use of my
-keyboard for managing everything.
-
-[^less-bloat]: Now that I have tried it and feel comfortable, my next
- installation might come without GNOME and probably have much less bloat, which
- I will appreciate for sure. It simply hasn't been a priority so far.
-
-With all the changes, I am very satisfied with i3, and haven't gone back to
-GNOME for a week. It did take a lot of time to figure everything out (and
-configure it), but it was something I had wanted to do for a long time (that's
-why the many attempts) and I finally had extra time to do it. It was definitely
-worth it!
-
-## Final note
-
-I think one of the major issues I had on my previous attempts was the `$mod` key
-used for all i3 shortcuts. It is so hard to reach the `Super` key! I had already
-switched the mapping of `Caps lock` and `Escape` (which improved my vim
-experience drastically), so I knew `Caps lock` was the key I needed for my
-shortcuts (it is so easy to reach!). I have now mapped `Caps lock` to act as
-`Escape` if I tap it, and as `Super` if I hold down. With this little trick, i3
-becomes a lot nicer, but without damaging vim's experience. If you are
-considering using a tiling manager, think about it! Also recommended if you use
-vim!
-
-
-[i3]: <https://i3wm.org/> "i3"
-[sway]: <https://swaywm.org/> "Sway"
-[dwm]: <https://dwm.suckless.org/> "dwm"
diff --git a/content/blog/2020-05-27-blocking-connections-on-android.html b/content/blog/2020-05-27-blocking-connections-on-android.html
@@ -0,0 +1,79 @@
+<!-- title: Blocking connections on Android -->
+<!-- slug: blocking-connections-on-android -->
+<!-- categories: Privacy -->
+<!-- date: 2020-05-27T19:01:00Z -->
+
+<p>
+ I have been a user of <a href="https://www.netguard.me/">NetGuard</a> for quite some time. It is a
+ great Android app that lets you control which apps get Internet access and which don't. The paid
+ version will allow you to block connection on a per-domain basis (for each app), as well as let
+ you see all the domains an app connects to (which are normally a lot!). Furthermore, you will be
+ able to block domains for the whole phone. This is useful because it can act as an add blocker (by
+ default it uses the list of domains gathered in <a href="https://github.com/StevenBlack/hosts">this repository</a>).
+ The Google Play version doesn't have this feature because Google doesn't allow add blocking on the
+ store, so make sure you get the app directly from GitHub!</p>
+<!-- /p -->
+
+<p>
+ A couple of months ago I decided to use a VPN, it felt like ISP's where very public about
+ everyone's data, and I decided to put my trust in a company whose business is protecting their
+ customers' privacy. The problem with VPNs is that you have to trust them. There is no way for you
+ to ensure they aren't selling your browsing habits to the best bidder, but I did my research on
+ the provider I chose and I trust them a lot more than an ISP. Now you may ask, how is this related
+ to NetGuard? Well, NetGuard uses the VPN functionality on Android to be able to block certain
+ connections without root access, and Android only allows one VPN at a time, so I had to choose
+ one<sup id="fnref1"><a href="#fn1">1</a></sup>.</p>
+<!-- /p -->
+
+<p>
+ Finally, I decided to go with my VPN. However, I really liked the domain blocking feature, so I
+ decided to investigate a little further. It turns out you can use the <code>/etc/hosts</code>
+ files to block certain domains just like in a GNU/Linux computer. It is an easy process and it
+ really makes a difference in your mobile browsing experience. I'll explain how I did it with my
+ phone in case it helps anyone else (although simply installing NetGuard is a simpler solution for
+ sure, and you get more features!).</p>
+<!-- /p -->
+
+<p>
+ First of all install Android Debug Bridge (ADB) on your computer. If you are using GNU/Linux, you
+ can use <code>pacman -S adb</code> on Arch based distributions or <code>apt install adb</code> on
+ Debian based distributions, look it up if you have other distributions or operative systems. Now
+ plug your phone into your computer and on your phone enable developer settings (look it up if you
+ don't know how to do it) and do the following:</p>
+<!-- /p -->
+
+<ol>
+ <li><code>Android debugging</code> > <code>on</code></li>
+ <li><code>Root access</code> > <code>ADB only</code></li>
+ <li>Make sure your computer has access to your phone by enabling <code>PTP</code> on your phone (instead of <code>No data transfer</code>).</li>
+ <li>On the computer run <code>$ adb root</code> to get root access.</li>
+ <li><code>$ adb remount</code>, which will allow you to modify the file on the phone.</li>
+ <li><code>$ adb push /path/to/hosts/on/computer /etc/hosts</code></li>
+ <li>Done! You can now unplug your phone (and disable the options you enabled previously if wanted).</li>
+</ol>
+
+<p>If you want to edit the file manually, do the following after step 5:</p>
+
+<ol>
+ <li><code>$ adb shell</code>, which will give you a terminal on the phone.</li>
+ <li><code># nano /etc/hosts</code> (<code>vim</code> also works on LineageOS).</li>
+ <li>Do your changes.</li>
+ <li><code># exit</code></li>
+</ol>
+
+<p>
+ Easy! However, I am using LineageOS and I am unsure if you can do step 2 on a stock ROM (if you
+ can't, you might need a rooted device). If you try it—whether on a stock ROM or another custom
+ ROM—, let me know if it works! You still won't be able to block certain apps' connections as with
+ NetGuard, but you won't have ads while keeping the VPN feature available for other uses.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ NetGuard offers a way to do what I wanted, through proxies, but I didn't like the workaround.
+ <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-05-27-blocking-connections-on-android.md b/content/blog/2020-05-27-blocking-connections-on-android.md
@@ -1,69 +0,0 @@
-<!-- title: Blocking connections on Android -->
-<!-- slug: blocking-connections-on-android -->
-<!-- categories: Privacy -->
-<!-- date: 2020-05-27T19:01:00Z -->
-
-I have been a user of [NetGuard][ng] for quite some time. It is a great Android
-app that lets you control which apps get Internet access and which don't. The
-paid version will allow you to block connection on a per-domain basis (for each
-app), as well as let you see all the domains an app connects to (which are
-normally a lot!). Furthermore, you will be able to block domains for the whole
-phone. This is useful because it can act as an add blocker (by default it uses
-the list of domains gathered in [this repository][repo]). The Google Play
-version doesn't have this feature because Google doesn't allow add blocking on
-the store, so make sure you get the app directly from GitHub!
-
-A couple of months ago I decided to use a VPN, it felt like ISP's where very
-public about everyone's data, and I decided to put my trust in a company whose
-business is protecting their customers' privacy. The problem with VPNs is that
-you have to trust them. There is no way for you to ensure they aren't selling
-your browsing habits to the best bidder, but I did my research on the provider I
-chose and I trust them a lot more than an ISP. Now you may ask, how is this
-related to NetGuard? Well, NetGuard uses the VPN functionality on Android to be
-able to block certain connections without root access, and Android only allows
-one VPN at a time, so I had to choose one[^proxies].
-
-[^proxies]: NetGuard offers a way to do what I wanted, through proxies, but I
- didn't like the workaround.
-
-Finally, I decided to go with my VPN. However, I really liked the domain
-blocking feature, so I decided to investigate a little further. It turns out you
-can use the `/etc/hosts` files to block certain domains just like in a GNU/Linux
-computer. It is an easy process and it really makes a difference in your mobile
-browsing experience. I'll explain how I did it with my phone in case it helps
-anyone else (although simply installing NetGuard is a simpler solution for sure,
-and you get more features!).
-
-First of all install Android Debug Bridge (ADB) on your computer. If you are
-using GNU/Linux, you can use `pacman -S adb` on Arch based distributions or `apt
-install adb` on Debian based distributions, look it up if you have other
-distributions or operative systems. Now plug your phone into your computer and
-on your phone enable developer settings (look it up if you don't know how to do
-it) and do the following:
-
-1. `Android debugging` > `on`
-2. `Root access` > `ADB only`
-3. Make sure your computer has access to your phone by enabling `PTP` on your
- phone (instead of `No data transfer`).
-4. On the computer run `$ adb root` to get root access.
-5. `$ adb remount`, which will allow you to modify the file on the phone.
-6. `$ adb push /path/to/hosts/on/computer /etc/hosts`
-7. Done! You can now unplug your phone (and disable the options you enabled
- previously if wanted).
-
-If you want to edit the file manually, do the following after step 5:
-
-1. `$ adb shell`, which will give you a terminal on the phone.
-2. `# nano /etc/hosts` (`vim` also works on LineageOS).
-3. Do your changes.
-4. `# exit`
-
-Easy! However, I am using LineageOS and I am unsure if you can do step 2 on a
-stock ROM (if you can't, you might need a rooted device). If you try it—whether
-on a stock ROM or another custom ROM—, let me know if it works! You still won't
-be able to block certain apps' connections as with NetGuard, but you won't have
-ads while keeping the VPN feature available for other uses.
-
-
-[ng]: <https://www.netguard.me/> "NetGuard's"
-[repo]: <https://github.com/StevenBlack/hosts> "Unified hosts — GitHub"
diff --git a/content/blog/2020-06-23-setting-up-a-personal-git-server.html b/content/blog/2020-06-23-setting-up-a-personal-git-server.html
@@ -0,0 +1,262 @@
+<!-- title: Setting up a personal Git server -->
+<!-- slug: setting-up-a-personal-git-server -->
+<!-- categories: Decentralization, Personal domain, Self-hosting -->
+<!-- date: 2020-06-23T16:10:00Z -->
+<!-- lastmod: 2020-07-24T15:17:00Z -->
+
+<p>
+ Running a personal Git server is something that has been on my mind for quite a long time. One of
+ the most popular solutions I have seen around is <a href="https://gitea.io">Gitea</a>. A couple of
+ months ago, when trying out different things, I decided to run Gitea locally to see how easy it
+ would be to implement on my server. It turns out pretty easy, especially if you are using Docker.
+ However, my server doesn't run Docker as of now and it also felt like customizing it would be hard
+ (for example, getting rid of the username in the URLs). Gitea looks like a very good solution for
+ self-hosting Git (and the sites look very nice!), but in my case, it felt like using a
+ sledgehammer to crack a nut. I figured most self-hosted Git solutions would turn out to be a bit
+ too much for my use case, so I decided to look into hosting Git without any other program.</p>
+<!-- /p -->
+
+<p>
+ I had experience setting up a bare-bones Git server only usable through SSH, so I looked up how to
+ create a website with the <code>bare</code> repositories. It turns out there's even a built-in
+ option<sup id="fnref1"><a href="#fn1">1</a></sup>! Other programs have more or less similar looks,
+ but I decided to check if there was any way to have a static generator for the webpage—the fewer
+ things running on my server the better! And there is one (that I found):
+ <a href="https://codemadness.org/stagit.html">stagit</a>. It is very simple, and it does the job.
+ On top of that, the program is super small, which makes it very easy to modify it if needed<sup
+ id="fnref2"><a href="#fn2">2</a></sup>. I gave it a try and it worked nicely. I decided that it
+ was a good solution for my use case, therefore having a vanilla Git server would work, so I
+ started building it<sup id="fnref3"><a href="#fn3">3</a></sup>.</p>
+<!-- /p -->
+
+<p>Let's see how to set it up!</p>
+
+<h2>Setting up a Git server</h2>
+
+<p>
+ What will happen is we'll have <code>bare</code> repositories on our server which we'll then
+ clone/fetch/push to using SSH<sup id="fnref4"><a href="#fn4">4</a></sup>. We'll put these
+ repositories on the <code>/srv/git</code> directory—because I keep everything served from my
+ server on <code>/srv</code>—but any location will work. To keep Git separated from the root user,
+ we'll create a new <code>git</code> user, with <code>/srv/git</code> as its home folder, this way,
+ the remote address will be <code>git@domain:repo.git</code> (no need for an absolute address).
+ Let's do that:</p>
+<!-- /p -->
+
+<pre><code><!--
+ -->useradd -d /srv/git git
+<!-- -->mkdir /srv/git
+<!-- -->chown git /srv/git</code></pre>
+
+<p>Now, let's create the folder for the SSH configuration where we'll add our public key.</p>
+
+<pre><code><!--
+ -->su git
+<!-- -->cd
+<!-- -->mkdir .ssh && chmod 700 .ssh
+<!-- -->touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys</code></pre>
+
+<p>
+ We could stop here, adding our key to the file (you can also use <code>ssh-copy-id</code>), but we
+ can take a couple more steps to isolate the user from the server, useful especially if you want to
+ share access to the git user with someone else.</p>
+<!-- /p -->
+
+<p>
+ To do that, we'll use the <code>git-shell</code> shell, which will only run scripts found on
+ <code>~/git-shell-commands</code>.<sup id="fnref5"><a href="#fn5">5</a></sup></p>
+<!-- /p -->
+
+<pre><code>chsh git -s $(which git-shell)</code></pre>
+
+<p>
+ Now if you add someone else's public SSH key to the server, they won't be able to run any command.
+ If you want to allow some commands, create scripts on <code>~/git-shell-commands</code>. For
+ example, I have scripts to initiate repositories, add SSH keys and other useful commands, you can
+ see them all <a href="https://git.oscarbenedito.com/git-shell-commands/">here</a>.</p>
+<!-- /p -->
+
+<h2>Making repositories public</h2>
+
+<p>
+ Now we can pull and push to our repository, and we can share access to them by adding SSH keys (or
+ sharing the password if you use one). However, we might want to have public repositories that
+ people should be able to clone without the need to have access to all of them. To do so, we'll use
+ the Git Daemon (that uses the Git Protocol). All we have to do is run the following command (and
+ keep it running, I recommend running a systemd service if you use systemd, there is an example
+ <a href="https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon">here</a>).</p>
+<!-- /p -->
+
+<pre><code>git daemon --reuseaddr --base-path=/srv/git/ /srv/git/</code></pre>
+
+<p>
+ This daemon will only serve repositories that have a file named <code>git-daemon-export-ok</code>
+ in them, so if you want to make a certain repository public, all you have to do is run:</p>
+<!-- /p -->
+
+<pre><code>touch /srv/git/repo.git/git-daemon-export-ok</code></pre>
+
+<p>
+ Remove that file to make it private again. The cloning address will be
+ <code>git://domain/repo.git</code> and you can't push to that address. You can also serve
+ repositories through HTTP which will allow you to have fine-grained control over who can access
+ which repositories, look it up if you are interested.</p>
+<!-- /p -->
+
+<h2>Making a website</h2>
+
+<p>
+ Now we can host private and public repositories, but we may want to share the public ones easily.
+ A website is a good way to allow people to quickly see your repositories without the need to clone
+ every single one of them. We'll use stagit to create the HTML files which we'll host as a static
+ site. First of all, let's install stagit:</p>
+<!-- /p -->
+
+<pre><code><!--
+ -->git clone git://git.codemadness.org/stagit
+<!-- -->cd stagit
+<!-- -->sudo make install</code></pre>
+
+<p>To create a website for a repository run</p>
+
+<pre><code>stagit /path/to/repo.git</code></pre>
+
+<p>from the directory where you want the site built. To create an index file with all your repositories simply run</p>
+
+<pre><code>stagit-index /path/to/repo-1.git /path/to/repo-2.git > index.html</code></pre>
+
+<p>
+ with the path to all your repositories. Make sure you have the correct information on the
+ <code>owner</code>, <code>description</code> and <code>url</code> files so that stagit uses them
+ when creating the HTML.</p>
+<!-- /p -->
+
+<p>
+ Having to do this is every time you update your repositories is not a reasonable solution, but we
+ can set up a <code>post-receive</code> hook to do it for us. There are examples of scripts to use
+ as an initial creation script for the whole site and a post-receive hook on stagit's source code
+ repository. I have changed those scripts a bit to only process public repositories (the ones with
+ the <code>git-daemon-export-ok</code> file) as well a modified the source a bit. You can find the
+ changes on my <a href="https://git.oscarbenedito.com/stagit/">stagit fork</a>.</p>
+<!-- /p -->
+
+<h2>Pros of this setup</h2>
+
+<p>
+ I have only been using this server for a couple of days, but I have also been setting up a bunch
+ of <a href="https://suckless.org">suckless</a> tools<sup id="fnref6"><a href="#fn6">6</a></sup>,
+ so I have been using Git a lot. One of the best things is that setting up repositories is very
+ easy. No need to open a browser, log in to GitHub and go through the process of creating a new
+ repository<sup id="fnref7"><a href="#fn7">7</a></sup>. I just run</p>
+<!-- /p -->
+
+<pre><code><!--
+ -->ssh git@oscarbenedito.com
+<!-- -->init reponame</code></pre>
+
+<p>
+ Done! I can also set it up as public by running a script I have on my <code>git-shell</code> and
+ change the description/owner/url just as easily.</p>
+<!-- /p -->
+
+<p>
+ Another thing I have noticed is that Git's clone/fetch/push commands are significantly faster on
+ this server than GitLab or GitHub. However, I don't know compared to a self-hosted instance of
+ Gitea or <a href="https://gogs.io">Gogs</a>.</p>
+<!-- /p -->
+
+<h2>Cons of this setup</h2>
+
+<p>
+ One thing that might be missed by this setup is the ability to download a tarball with the code
+ from a certain commit, browse the code as it was in a given commit, see git blame, etc. This could
+ be solved by using another tool for the website part—such as <a
+ href="https://git.zx2c4.com/cgit/about/">cgit</a>—so if I ever want to do that, it shouldn't be hard.</p>
+<!-- /p -->
+
+<p>
+ Another thing is how the website looks. Other self-hosting solutions like Gogs, Gitea, GitLab...
+ look a lot nicer than stagit. However this isn't a priority right now and I appreciate the ability
+ to have full control over how the server works—and it has been very interesting to learn about it
+ all. Once again this is something to do with the website, and not the repository hosting
+ itself.</p>
+<!-- /p -->
+
+<h2>Final comments</h2>
+
+<p>
+ It has been fun to set everything up and realize how easy it is to self-host Git without the need
+ for other software. On top of that, I can now share my repositories from my domain, which means it
+ is easier to stop using other hosting services if I stop wanting to accept their policies, similar
+ to having email on my domain.</p>
+<!-- /p -->
+
+<p>
+ For now, I will still have my public repositories hosted on GitLab and GitHub, as I don't mind it
+ and some people might be more used to those UIs. They also act as a backup in case something
+ happens to my server or if I want to edit my repositories from a computer without SSH access to my
+ server.</p>
+<!-- /p -->
+
+<p>
+ Finally, I have talked about some software that will allow you to self-host Git, but I don't want
+ to end this post without mentioning <a href="https://sourcehut.org/">sourcehut</a>. I find it a
+ very good solution because everyone can contribute to your projects without the need to create yet
+ another account. Everything is done through email, which is nicely supported by Git (learn more
+ <a href="https://git-send-email.io/">here</a>).</p>
+<!-- /p -->
+
+<p>
+ I almost forgot! If you want to check out my Git website or clone some repositories from my
+ domain, you can find all of that here: <a href="https://git.oscarbenedito.com">https://git.oscarbenedito.com</a>.</p>
+<!-- /p -->
+
+<p>
+ <em>Edit</em>: The post originally said that creating a new repository on GitLab was a long
+ process. However, you can just push to a new remote address and GitLab will automatically create
+ the new repository.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ Run <code>git instaweb</code> from a Git repository to try it. <a href="#fnref1" title="Jump
+ back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ I haven't modified the source code much yet, but I have some ideas in mind. <a href="#fnref2"
+ title="Jump back to footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn3">
+ Funnily enough, I had already set up a Git server there for a couple of repositories containing
+ a lot of personal information to avoid hosting them on GitLab or GitHub. I completely forgot
+ about it. I deleted it and started from scratch, as I wanted to document the process on my
+ personal wiki. <a href="#fnref3" title="Jump back to footnote 3 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn4">
+ Bare repositories are simply a folder with the files of the <code>.git</code> directory of a
+ repository. Indeed, you can clone a repository from your computer running <code>git clone
+ /path/to/repo/.git cloned-repo</code>. This directory contains all the information of the
+ repository, that is why Git is distributed. <a href="#fnref4" title="Jump back to footnote 4 in
+ the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn5">
+ If the <code>chsh</code> command doesn't work, make sure <code>git-shell</code> is in
+ <code>/etc/shells</code>, if not, add it manually. <a href="#fnref5" title="Jump back to
+ footnote 5 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn6">
+ Fun fact: after setting everything up I realized that suckless uses stagit to show their
+ repositories, indeed the author of stagit is the current maintainer of some suckless projects
+ like <a href="https://st.suckless.org/">st</a> and <a
+ href="https://tools.suckless.org/dmenu/">dmenu</a>. <a href="#fnref6" title="Jump
+ back to footnote 6 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn7">
+ I originally thought this was also the case for GitLab, however, you can push a new repository
+ to a new remote address and GitLab will automatically create it. <a href="#fnref7" title="Jump
+ back to footnote 7 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-06-23-setting-up-a-personal-git-server.md b/content/blog/2020-06-23-setting-up-a-personal-git-server.md
@@ -1,240 +0,0 @@
-<!-- title: Setting up a personal Git server -->
-<!-- slug: setting-up-a-personal-git-server -->
-<!-- categories: Decentralization, Personal domain, Self-hosting -->
-<!-- date: 2020-06-23T16:10:00Z -->
-<!-- lastmod: 2020-07-24T15:17:00Z -->
-
-Running a personal Git server is something that has been on my mind for quite a
-long time. One of the most popular solutions I have seen around is
-[Gitea][gitea]. A couple of months ago, when trying out different things, I
-decided to run Gitea locally to see how easy it would be to implement on my
-server. It turns out pretty easy, especially if you are using Docker. However,
-my server doesn't run Docker as of now and it also felt like customizing it
-would be hard (for example, getting rid of the username in the URLs). Gitea
-looks like a very good solution for self-hosting Git (and the sites look very
-nice!), but in my case, it felt like using a sledgehammer to crack a nut. I
-figured most self-hosted Git solutions would turn out to be a bit too much for
-my use case, so I decided to look into hosting Git without any other program.
-
-I had experience setting up a bare-bones Git server only usable through SSH, so
-I looked up how to create a website with the `bare` repositories. It turns out
-there's even a built-in option[^giw]! Other programs have more or less similar
-looks, but I decided to check if there was any way to have a static generator
-for the webpage—the fewer things running on my server the better! And there is
-one (that I found): [stagit][stagit]. It is very simple, and it does the job. On
-top of that, the program is super small, which makes it very easy to modify it
-if needed[^mods]. I gave it a try and it worked nicely. I decided that it was a
-good solution for my use case, therefore having a vanilla Git server would work,
-so I started building it[^already].
-
-[^giw]: Run `git instaweb` from a Git repository to try it.
-
-[^mods]: I haven't modified the source code much yet, but I have some ideas in
- mind.
-
-[^already]: Funnily enough, I had already set up a Git server there for a couple
- of repositories containing a lot of personal information to avoid hosting them
- on GitLab or GitHub. I completely forgot about it. I deleted it and started
- from scratch, as I wanted to document the process on my personal wiki.
-
-Let's see how to set it up!
-
-## Setting up a Git server
-
-What will happen is we'll have `bare` repositories on our server which we'll
-then clone/fetch/push to using SSH[^bare]. We'll put these repositories on the
-`/srv/git` directory—because I keep everything served from my server on
-`/srv`—but any location will work. To keep Git separated from the root user,
-we'll create a new `git` user, with `/srv/git` as its home folder, this way, the
-remote address will be `git@domain:repo.git` (no need for an absolute address).
-Let's do that:
-
-[^bare]: Bare repositories are simply a folder with the files of the `.git`
- directory of a repository. Indeed, you can clone a repository from your
- computer running `git clone /path/to/repo/.git cloned-repo`. This directory
- contains all the information of the repository, that is why Git is
- distributed.
-
-```sh
-useradd -d /srv/git git
-mkdir /srv/git
-chown git /srv/git
-```
-
-Now, let's create the folder for the SSH configuration where we'll add our
-public key.
-
-```sh
-su git
-cd
-mkdir .ssh && chmod 700 .ssh
-touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
-```
-
-We could stop here, adding our key to the file (you can also use `ssh-copy-id`),
-but we can take a couple more steps to isolate the user from the server, useful
-especially if you want to share access to the git user with someone else.
-
-To do that, we'll use the `git-shell` shell, which will only run scripts found
-on `~/git-shell-commands`.[^issue]
-
-[^issue]: If the `chsh` command doesn't work, make sure `git-shell` is in
- `/etc/shells`, if not, add it manually.
-
-```sh
-chsh git -s $(which git-shell)
-```
-
-Now if you add someone else's public SSH key to the server, they won't be able
-to run any command. If you want to allow some commands, create scripts on
-`~/git-shell-commands`. For example, I have scripts to initiate repositories,
-add SSH keys and other useful commands, you can see them all [here][gsc].
-
-## Making repositories public
-
-Now we can pull and push to our repository, and we can share access to them by
-adding SSH keys (or sharing the password if you use one). However, we might want
-to have public repositories that people should be able to clone without the need
-to have access to all of them. To do so, we'll use the Git Daemon (that uses the
-Git Protocol). All we have to do is run the following command (and keep it
-running, I recommend running a systemd service if you use systemd, there is an
-example [here][prot-doc]).
-
-```sh
-git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
-```
-
-This daemon will only serve repositories that have a file named
-`git-daemon-export-ok` in them, so if you want to make a certain repository
-public, all you have to do is run:
-
-```sh
-touch /srv/git/repo.git/git-daemon-export-ok
-```
-
-Remove that file to make it private again. The cloning address will be
-`git://domain/repo.git` and you can't push to that address. You can also serve
-repositories through HTTP which will allow you to have fine-grained control over
-who can access which repositories, look it up if you are interested.
-
-## Making a website
-
-Now we can host private and public repositories, but we may want to share the
-public ones easily. A website is a good way to allow people to quickly see your
-repositories without the need to clone every single one of them. We'll use
-stagit to create the HTML files which we'll host as a static site. First of all,
-let's install stagit:
-
-```sh
-git clone git://git.codemadness.org/stagit
-cd stagit
-sudo make install
-```
-
-To create a website for a repository run
-
-```sh
-stagit /path/to/repo.git
-```
-
-from the directory where you want the site built. To create an index file with
-all your repositories simply run
-
-```sh
-stagit-index /path/to/repo-1.git /path/to/repo-2.git > index.html
-```
-
-with the path to all your repositories. Make sure you have the correct
-information on the `owner`, `description` and `url` files so that stagit uses
-them when creating the HTML.
-
-Having to do this is every time you update your repositories is not a reasonable
-solution, but we can set up a `post-receive` hook to do it for us. There are
-examples of scripts to use as an initial creation script for the whole site and
-a post-receive hook on stagit's source code repository. I have changed those
-scripts a bit to only process public repositories (the ones with the
-`git-daemon-export-ok` file) as well a modified the source a bit. You can find
-the changes on my [stagit fork][sg-fork].
-
-## Pros of this setup
-
-I have only been using this server for a couple of days, but I have also been
-setting up a bunch of [suckless][sl] tools[^ff], so I have been using Git a lot.
-One of the best things is that setting up repositories is very easy. No need to
-open a browser, log in to GitHub and go through the process of creating a new
-repository[^gl]. I just run
-
-[^ff]: Fun fact: after setting everything up I realized that suckless uses
- stagit to show their repositories, indeed the author of stagit is the current
- maintainer of some suckless projects like [st][st] and [dmenu][dmenu].
-
-[^gl]: I originally thought this was also the case for GitLab, however, you can
- push a new repository to a new remote address and GitLab will automatically
- create it.
-
-```sh
-ssh git@oscarbenedito.com
-init reponame
-```
-
-Done! I can also set it up as public by running a script I have on my
-`git-shell` and change the description/owner/url just as easily.
-
-Another thing I have noticed is that Git's clone/fetch/push commands are
-significantly faster on this server than GitLab or GitHub. However, I don't know
-compared to a self-hosted instance of Gitea or [Gogs][gogs].
-
-## Cons of this setup
-
-One thing that might be missed by this setup is the ability to download a
-tarball with the code from a certain commit, browse the code as it was in a
-given commit, see git blame, etc. This could be solved by using another tool for
-the website part—such as [cgit][cgit]—so if I ever want to do that, it shouldn't
-be hard.
-
-Another thing is how the website looks. Other self-hosting solutions like Gogs,
-Gitea, GitLab... look a lot nicer than stagit. However this isn't a priority
-right now and I appreciate the ability to have full control over how the server
-works—and it has been very interesting to learn about it all. Once again this is
-something to do with the website, and not the repository hosting itself.
-
-## Final comments
-
-It has been fun to set everything up and realize how easy it is to self-host Git
-without the need for other software. On top of that, I can now share my
-repositories from my domain, which means it is easier to stop using other
-hosting services if I stop wanting to accept their policies, similar to having
-email on my domain.
-
-For now, I will still have my public repositories hosted on GitLab and GitHub,
-as I don't mind it and some people might be more used to those UIs. They also
-act as a backup in case something happens to my server or if I want to edit my
-repositories from a computer without SSH access to my server.
-
-Finally, I have talked about some software that will allow you to self-host Git,
-but I don't want to end this post without mentioning [sourcehut][sh]. I find it
-a very good solution because everyone can contribute to your projects without
-the need to create yet another account. Everything is done through email, which
-is nicely supported by Git (learn more [here][g-email]).
-
-I almost forgot! If you want to check out my Git website or clone some
-repositories from my domain, you can find all of that here:
-<https://git.oscarbenedito.com>.
-
-*Edit*: The post originally said that creating a new repository on GitLab was a
-long process. However, you can just push to a new remote address and GitLab will
-automatically create the new repository.
-
-
-[cgit]: <https://git.zx2c4.com/cgit/about/> "cgit's information"
-[dmenu]: <https://tools.suckless.org/dmenu/> "dmenu"
-[g-email]: <https://git-send-email.io/> "Learn to use email with Git!"
-[gitea]: <https://gitea.io> "Gitea"
-[gogs]: <https://gogs.io> "Gogs"
-[gsc]: <https://git.oscarbenedito.com/git-shell-commands/> "git-shell-commands — git.oscarbenedito.com"
-[prot-doc]: <https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon> "Git Daemon — Git"
-[sg-fork]: <https://git.oscarbenedito.com/stagit/> "stagit — git.oscarbenedito.com"
-[sh]: <https://sourcehut.org/> "Sourcehut"
-[sl]: <https://suckless.org> "Suckless"
-[st]: <https://st.suckless.org/> "st"
-[stagit]: <https://codemadness.org/stagit.html> "Stagit blog post — codemadness.org"
diff --git a/content/blog/2020-08-09-what-is-this-vim-talk-all-about.html b/content/blog/2020-08-09-what-is-this-vim-talk-all-about.html
@@ -0,0 +1,124 @@
+<!-- title: What is this vim talk all about? -->
+<!-- slug: what-is-this-vim-talk-all-about -->
+<!-- categories: FOSS, Miscellany -->
+<!-- date: 2020-08-09T15:16:00Z -->
+
+<p>
+ Oh no! Another <a href="https://www.vim.org/">vim</a> post! Well... yes. I have seen a lot of
+ people criticizing vim before even trying it, so I am going to try and explain my history with it
+ and what I like about it. If you aren't aware, vim is a text editor that is normally used from the
+ command line (and, normally, the mouse doesn't work in it or is deactivated).</p>
+<!-- /p -->
+
+<h2>Getting into vim</h2>
+
+<p>
+ When I first saw people that got around a computer with the keyboard, I realized how much faster
+ you can do stuff when you don't use your mouse. By that time, I used the copy/cut/paste shortcuts
+ and that was pretty much it, I didn't even use <code>Alt</code>+<code>Tab</code> to change between
+ windows, so I was mindblown when I saw people moving around so quickly without touching the mouse.
+ For me, the keyboard was simply a tool to write text.</p>
+<!-- /p -->
+
+<p>
+ Although I realized that being more familiar with the keyboard would make me more efficient, it
+ was hard to get used to it. I had to think before every keystroke, and everything was very slow.
+ GNU/Linux helped a lot with getting more used to the keyboard, not only did I use a couple more
+ shortcuts, but I also found myself using the terminal often.</p>
+<!-- /p -->
+
+<p>
+ At some point, a friend introduced me to vim. I remember<sup id="fnref1"><a href="#fn1">1</a></sup>
+ seeing such a weird program—and in the terminal!—and thinking: why would anyone use that?! I was
+ told that there were a lot of shortcuts, and experienced programmers could move through a file
+ very quickly with it, as well as do complex operations with the file contents. I believed it, but
+ I didn't want to spend years mastering vim, so I kept going with a simpler text editor. A couple
+ of months later, I had a programming class where the teacher would sometimes show us his screen
+ while writing solutions to exercises. He was fast, very fast. He moved around the file very
+ quickly and the craziest part was that he was using Geany. All that speed was reached with
+ <code>Home</code>, <code>End</code>, arrow keys, etc. No <em>real</em> shortcuts. I think that is
+ the point in time when I understood what a program focused on keyboard shortcuts (like vim) had to
+ offer.</p>
+<!-- /p -->
+
+<p>
+ Since then, I have tried vim many times and, truth be told, it is hard to start with. I also
+ didn't code a lot during certain times, and when I had to, I just wanted to get stuff done, so
+ finding times to figure out vim wasn't as easy. Another friend recommended using vim when editing
+ Latex files because of a plugin. I was creating Latex documents for some classes so I used vim for
+ a while to edit those files<sup id="fnref2"><a href="#fn2">2</a></sup>. This is how I started to
+ be able to do some things in vim. I eventually started managing servers and used it more and
+ finally, at the start of the confinement, I decided to use it exclusively. It took some time
+ adjusting to it, but I haven't opened any other editor except for a couple of occasions.</p>
+<!-- /p -->
+
+<h2>What I like about vim</h2>
+
+<p>
+ The first thing that I like is that it is a modal editor, meaning it has modes: you are always on
+ one mode, and the editor responds differently to keypresses depending on the mode. The two most
+ basic modes are normal and insert. Insert mode responds to keypresses like you would expect from a
+ text editor: if you press <code>x</code>, an <code>x</code> is appended to the file you are
+ editing, and so on. Normal mode, however, will not print the letter you just typed. For instance,
+ if you press <code>x</code> the letter under the cursor will be deleted, and if you press <code>w</code>
+ the cursor will move to the first character of the next word. This is great because there are a
+ lot of shortcuts on normal mode that are incredibly useful, and let you move around the document
+ without the need of leaving the <a href="https://en.wikipedia.org/wiki/Home_row">home row</a> or
+ pressing modifier keys.</p>
+<!-- /p -->
+
+<p>
+ Now, normal mode has a ridiculous amount of shortcuts, each key has some behavior assigned to it,
+ so it can be hard to learn it all. In the end, it is only a matter of practice and it is easier
+ than it looks like. On top of that, these shortcuts act like a language, which makes them really
+ powerful. With that, I mean that shortcuts can be mixed to create new shortcuts. It is hard to
+ explain and there are a lot of explanations online, so I will refer you to two sources, and you
+ can keep investigating if you are interested:</p>
+<!-- /p -->
+
+<ul>
+ <li><a href="https://stackoverflow.com/a/1220118">Your problem with Vim is that you don't grok vi</a>: A very detailed Stack Overflow answer.</li>
+ <li><a href="https://www.youtube.com/watch?v=wlR5gYd6um0">Mastering the Vim Language</a>: A YouTube video of a talk in the Boston Vim Meetup of 2015 by Chris Toomey.</li>
+</ul>
+
+<p>
+ This is it for me. The fact that you can do so many things with the keyboard without the need to
+ keep <code>Ctrl</code> or <code>Alt</code> pressed and do them in such a natural "language" is
+ what makes vim the best editor I have tried so far. Of course, you can make other editors behave
+ like vim (<a href="https://en.wikipedia.org/wiki/Vi">vi</a> really), but vim is the best one I've
+ tried. Well... I actually use <a href="https://neovim.io/">neovim</a>, but for my use-case, I
+ probably wouldn't be able to tell them apart.</p>
+<!-- /p -->
+
+<h2>Final comments</h2>
+
+<p>
+ There are still a lot of things left for me to learn about vim, especially when dealing with a
+ project with lots of files, but I am now more comfortable with vim than with a normal editor where
+ you move around using the mouse.</p>
+<!-- /p -->
+
+<p>
+ As you can see from this post, what I appreciate the most of vim is how it behaves, so I could
+ easily change to another editor that would copy this behavior and add other features. It is useful
+ that it is run on the terminal, as it is normally how I move around the computer, but I don't have
+ anything against other editors. I also want to try <a href="https://www.gnu.org/software/emacs/">Emacs</a>
+ again at some point (with <a href="https://www.emacswiki.org/emacs/Evil">Evil mode</a>, of
+ course), we'll see how that goes!</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ This is how I remember it, but it was—I think—three years ago, so it might not be completely
+ accurate. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ The plugin is really nice (especially when writing big amounts of text), but I was so
+ uncomfortable with vim that I would write everything in vim and then edit/review it with a
+ different editor. <a href="#fnref2" title="Jump back to footnote 2 in the text">↩</a>
+ </li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-08-09-what-is-this-vim-talk-all-about.md b/content/blog/2020-08-09-what-is-this-vim-talk-all-about.md
@@ -1,113 +0,0 @@
-<!-- title: What is this vim talk all about? -->
-<!-- slug: what-is-this-vim-talk-all-about -->
-<!-- categories: FOSS, Miscellany -->
-<!-- date: 2020-08-09T15:16:00Z -->
-
-Oh no! Another [vim][vim] post! Well... yes. I have seen a lot of people
-criticizing vim before even trying it, so I am going to try and explain my
-history with it and what I like about it. If you aren't aware, vim is a text
-editor that is normally used from the command line (and, normally, the mouse
-doesn't work in it or is deactivated).
-
-## Getting into vim
-
-When I first saw people that got around a computer with the keyboard, I realized
-how much faster you can do stuff when you don't use your mouse. By that time, I
-used the copy/cut/paste shortcuts and that was pretty much it, I didn't even use
-`Alt`+`Tab` to change between windows, so I was mindblown when I saw people
-moving around so quickly without touching the mouse. For me, the keyboard was
-simply a tool to write text.
-
-Although I realized that being more familiar with the keyboard would make me
-more efficient, it was hard to get used to it. I had to think before every
-keystroke, and everything was very slow. GNU/Linux helped a lot with getting
-more used to the keyboard, not only did I use a couple more shortcuts, but I
-also found myself using the terminal often.
-
-At some point, a friend introduced me to vim. I remember[^memory] seeing such a
-weird program—and in the terminal!—and thinking: why would anyone use that?! I
-was told that there were a lot of shortcuts, and experienced programmers could
-move through a file very quickly with it, as well as do complex operations with
-the file contents. I believed it, but I didn't want to spend years mastering
-vim, so I kept going with a simpler text editor. A couple of months later, I had
-a programming class where the teacher would sometimes show us his screen while
-writing solutions to exercises. He was fast, very fast. He moved around the file
-very quickly and the craziest part was that he was using Geany. All that speed
-was reached with `Home`, `End`, arrow keys, etc. No *real* shortcuts. I think
-that is the point in time when I understood what a program focused on keyboard
-shortcuts (like vim) had to offer.
-
-[^memory]: This is how I remember it, but it was—I think—three years ago, so it
- might not be completely accurate.
-
-Since then, I have tried vim many times and, truth be told, it is hard to start
-with. I also didn't code a lot during certain times, and when I had to, I just
-wanted to get stuff done, so finding times to figure out vim wasn't as easy.
-Another friend recommended using vim when editing Latex files because of a
-plugin. I was creating Latex documents for some classes so I used vim for a
-while to edit those files[^tex]. This is how I started to be able to do some
-things in vim. I eventually started managing servers and used it more and
-finally, at the start of the confinement, I decided to use it exclusively. It
-took some time adjusting to it, but I haven't opened any other editor except for
-a couple of occasions.
-
-[^tex]: The plugin is really nice (especially when writing big amounts of text),
- but I was so uncomfortable with vim that I would write everything in vim and
- then edit/review it with a different editor.
-
-## What I like about vim
-
-The first thing that I like is that it is a modal editor, meaning it has modes:
-you are always on one mode, and the editor responds differently to keypresses
-depending on the mode. The two most basic modes are normal and insert. Insert
-mode responds to keypresses like you would expect from a text editor: if you
-press `x`, an `x` is appended to the file you are editing, and so on. Normal
-mode, however, will not print the letter you just typed. For instance, if you
-press `x` the letter under the cursor will be deleted, and if you press `w` the
-cursor will move to the first character of the next word. This is great because
-there are a lot of shortcuts on normal mode that are incredibly useful, and let
-you move around the document without the need of leaving the [home row][hr] or
-pressing modifier keys.
-
-Now, normal mode has a ridiculous amount of shortcuts, each key has some
-behavior assigned to it, so it can be hard to learn it all. In the end, it is
-only a matter of practice and it is easier than it looks like. On top of that,
-these shortcuts act like a language, which makes them really powerful. With
-that, I mean that shortcuts can be mixed to create new shortcuts. It is hard to
-explain and there are a lot of explanations online, so I will refer you to two
-sources, and you can keep investigating if you are interested:
-
-- [Your problem with Vim is that you don't grok vi][so]: A very detailed Stack
- Overflow answer.
-- [Mastering the Vim Language][yt]: A YouTube video of a talk in the Boston Vim
- Meetup of 2015 by Chris Toomey.
-
-This is it for me. The fact that you can do so many things with the keyboard
-without the need to keep `Ctrl` or `Alt` pressed and do them in such a natural
-"language" is what makes vim the best editor I have tried so far. Of course, you
-can make other editors behave like vim ([vi][vi] really), but vim is the best
-one I've tried. Well... I actually use [neovim][nv], but for my use-case, I
-probably wouldn't be able to tell them apart.
-
-## Final comments
-
-There are still a lot of things left for me to learn about vim, especially when
-dealing with a project with lots of files, but I am now more comfortable with
-vim than with a normal editor where you move around using the mouse.
-
-As you can see from this post, what I appreciate the most of vim is how it
-behaves, so I could easily change to another editor that would copy this
-behavior and add other features. It is useful that it is run on the terminal, as
-it is normally how I move around the computer, but I don't have anything against
-other editors. I also want to try [Emacs][emacs] again at some point (with [Evil
-mode][em], of course), we'll see how that goes!
-
-
-[vim]: <https://www.vim.org/> "Vim"
-[hr]: <https://en.wikipedia.org/wiki/Home_row> "Home row — Wikipedia"
-[so]: <https://stackoverflow.com/a/1220118> "What is your most productive shortcut with Vim? — Stack Overflow"
-[yt]: <https://www.youtube.com/watch?v=wlR5gYd6um0> "Mastering the Vim Language — Youtube"
-[vi]: <https://en.wikipedia.org/wiki/Vi> "Vi — Wikipedia"
-[nv]: <https://neovim.io/> "Neovim"
-[emacs]: <https://www.gnu.org/software/emacs/> "Emacs"
-[em]: <https://www.emacswiki.org/emacs/Evil> "Evil mode — EmacsWiki"
diff --git a/content/blog/2020-08-15-adding-about-pages-to-stagit.html b/content/blog/2020-08-15-adding-about-pages-to-stagit.html
@@ -0,0 +1,54 @@
+<!-- title: Adding about pages to stagit -->
+<!-- slug: adding-about-pages-to-stagit -->
+<!-- categories: FOSS, Projects -->
+<!-- date: 2020-08-15T19:59:00Z -->
+
+<p>
+ I use <a href="https://codemadness.org/stagit.html">stagit</a> to show the public repositories of
+ my Git server on the web. I chose stagit because it is a very simple and lightweight tool, which
+ makes tinkering with the source code very straightforward (which I have been doing a bit lately)
+ and because the resulting website is static: easy to set up, faster, and there aren't any
+ application-specific issues (there is no application). Static sites are also nice because you know
+ exactly what is going on when a page is requested—the file is served—, whereas if it is a dynamic
+ site, you might or might not know what operations the server is doing to answer the request.</p>
+<!-- /p -->
+
+<p>
+ Stagit doesn't have many features. This isn't necessarily bad, as it keeps the source small and
+ readable and it still does everything I consider necessary, it even has an Atom feed for commits!
+ The one feature I really missed was being able to show an about page with the repository's readme
+ file when it is opened<sup id="fnref1"><a href="#fn1">1</a></sup>. For me, it is a basic feature,
+ especially with repositories for projects without a website/wiki. When I hear about a piece of
+ software, the first I do is go check out the repository and read a bit about it, and readme files
+ make that easier. Since most of my repositories have readmes written in Markdown, I wanted stagit
+ to convert them to HTML, so they could be shown nicely on the repositories' website.</p>
+<!-- /p -->
+
+<p>
+ If you want to try it out yourself, the change on stagit is very simple, just a couple of lines,
+ but it will add a dependency to the program<sup id="fnref2"><a href="#fn2">2</a></sup>. I use
+ <a href="https://github.com/mity/md4c">md4c</a> to parse the files, and it is ridiculously fast. I
+ haven't noticed any changes in the time it takes for stagit to run. Check out
+ <a href="https://git.oscarbenedito.com/stagit/commit/1fdbc7e8ef4025e50678261ca670daca85ac298c.html">this
+ commit</a> if you want to know how I did it, and feel free to suggest other approaches if you
+ think they are better.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ Stagit has a link on the navigation bar to the readme file, and you could easily make that the
+ default <code>index.html</code> file, but it is just the page with the raw file (as any other
+ file is shown), it isn't presented like an about page. <a href="#fnref1" title="Jump back to
+ footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ The dependency is only for parsing Markdown, if you don't need that, you can just show the raw
+ file without the line numbers and metadata, this is what
+ <a href="https://git.oscarbenedito.com/stagit/commit/1fdbc7e8ef4025e50678261ca670daca85ac298c.html#h5-5-16">I
+ do</a> when the readme file isn't a Markdown file. <a href="#fnref2" title="Jump back to
+ footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-08-15-adding-about-pages-to-stagit.md b/content/blog/2020-08-15-adding-about-pages-to-stagit.md
@@ -1,46 +0,0 @@
-<!-- title: Adding about pages to stagit -->
-<!-- slug: adding-about-pages-to-stagit -->
-<!-- categories: FOSS, Projects -->
-<!-- date: 2020-08-15T19:59:00Z -->
-
-I use [stagit][sg] to show the public repositories of my Git server on the web.
-I chose stagit because it is a very simple and lightweight tool, which makes
-tinkering with the source code very straightforward (which I have been doing a
-bit lately) and because the resulting website is static: easy to set up, faster,
-and there aren't any application-specific issues (there is no application).
-Static sites are also nice because you know exactly what is going on when a page
-is requested—the file is served—, whereas if it is a dynamic site, you might or
-might not know what operations the server is doing to answer the request.
-
-Stagit doesn't have many features. This isn't necessarily bad, as it keeps the
-source small and readable and it still does everything I consider necessary, it
-even has an Atom feed for commits! The one feature I really missed was being
-able to show an about page with the repository's readme file when it is
-opened[^nt]. For me, it is a basic feature, especially with repositories for
-projects without a website/wiki. When I hear about a piece of software, the
-first I do is go check out the repository and read a bit about it, and readme
-files make that easier. Since most of my repositories have readmes written in
-Markdown, I wanted stagit to convert them to HTML, so they could be shown nicely
-on the repositories' website.
-
-[^nt]: Stagit has a link on the navigation bar to the readme file, and you could
- easily make that the default `index.html` file, but it is just the page with
- the raw file (as any other file is shown), it isn't presented like an about
- page.
-
-If you want to try it out yourself, the change on stagit is very simple, just a
-couple of lines, but it will add a dependency to the program[^dep]. I use
-[md4c][md4c] to parse the files, and it is ridiculously fast. I haven't noticed
-any changes in the time it takes for stagit to run. Check out [this commit][cm]
-if you want to know how I did it, and feel free to suggest other approaches if
-you think they are better.
-
-[^dep]: The dependency is only for parsing Markdown, if you don't need that, you
- can just show the raw file without the line numbers and metadata, this is what
- [I do][nm] when the readme file isn't a Markdown file.
-
-
-[sg]: <https://codemadness.org/stagit.html> "Stagit blog post — codemadness.org"
-[md4c]: <https://github.com/mity/md4c> "md4c — GitHub"
-[cm]: <https://git.oscarbenedito.com/stagit/commit/1fdbc7e8ef4025e50678261ca670daca85ac298c.html> "Add about page for repos with REAMDE — git.oscarbenedito.com"
-[nm]: <https://git.oscarbenedito.com/stagit/commit/1fdbc7e8ef4025e50678261ca670daca85ac298c.html#h5-5-16>
diff --git a/content/blog/2020-08-30-davup.html b/content/blog/2020-08-30-davup.html
@@ -0,0 +1,18 @@
+<!-- title: DAVup: back up your contacts and calendars -->
+<!-- slug: davup -->
+<!-- categories: FOSS, Projects -->
+<!-- date: 2020-08-30T19:27:00Z -->
+
+<p>
+ Meet <a href="https://git.oscarbenedito.com/osf/file/davup.sh.html">DAVup</a>! It is a simple
+ script that will back up any contacts, calendars and to-do lists synchronized through CardDAV or
+ CalDAV.</p>
+<!-- /p -->
+
+<p>
+ I have always synchronized my contacts and calendars with online services to avoid losing them if
+ something happened to my phone and to have them synchronized with my computer. For some time, I
+ have been going a step further with my backups and have tried to keep a local backup of as many
+ things as I can. With that goal in mind, I made DAVup, which is very simple and does exactly what
+ I need. If you are interested, have a look!</p>
+<!-- /p -->
diff --git a/content/blog/2020-08-30-davup.md b/content/blog/2020-08-30-davup.md
@@ -1,17 +0,0 @@
-<!-- title: DAVup: back up your contacts and calendars -->
-<!-- slug: davup -->
-<!-- categories: FOSS, Projects -->
-<!-- date: 2020-08-30T19:27:00Z -->
-
-Meet [DAVup][d]! It is a simple script that will back up any contacts, calendars
-and to-do lists synchronized through CardDAV or CalDAV.
-
-I have always synchronized my contacts and calendars with online services to
-avoid losing them if something happened to my phone and to have them
-synchronized with my computer. For some time, I have been going a step further
-with my backups and have tried to keep a local backup of as many things as I
-can. With that goal in mind, I made DAVup, which is very simple and does exactly
-what I need. If you are interested, have a look!
-
-
-[d]: <https://git.oscarbenedito.com/osf/file/davup.sh.html> "DAVup — git.oscarbenedito.com"
diff --git a/content/blog/2020-09-27-switching-to-own-ssg.html b/content/blog/2020-09-27-switching-to-own-ssg.html
@@ -0,0 +1,193 @@
+<!-- title: Switching to my own static site generator -->
+<!-- slug: switching-to-own-ssg -->
+<!-- categories: FOSS, Personal domain, Projects -->
+<!-- date: 2020-09-27T16:27:00Z -->
+
+<p>
+ Since the start of this website (its first anniversary was a couple of weeks ago!) until recently,
+ I have been using the static site generator <a href="https://gohugo.io">Hugo</a>. Static site
+ generators are very useful when building relatively complex static websites, and Hugo has served
+ me well. I have also used <a href="https://www.getlektor.com">Lektor</a> and <a
+ href="https://jekyllrb.com">Jekyll</a> before for other projects, but for a site with a blog, I
+ like Hugo the most. However, with time, some issues have arisen with Hugo, and I finally decided
+ to change my site's generator.</p>
+<!-- /p -->
+
+<h2>Issues with Hugo</h2>
+
+<p>
+ If you build your website with a static site generator, it will probably be the most critical
+ dependency of your site. Of course, it's a dependency I'm fine with as it makes things much easier
+ (dealing with Markdown content, categories, web feeds...), but if something goes wrong, the site
+ won't render as you want. Hugo in particular is a very big project and I don't feel like jumping
+ into the source code every time I have an issue with the program (especially since I've never used
+ Go, and I don't want to spend hours for minor annoyances). Although Hugo works wonderfully, I have
+ encountered moments where it has acted unpredictably, and documentation doesn't help most of the
+ time.</p>
+<!-- /p -->
+
+<p>
+ On top of that, although it works perfectly well (and it is one of the most popular SSGs), it is
+ on a beta stage and the developers have made backward-incompatible changes without warning in the
+ past. The change I have in mind was clearly stated on the release page, but I normally let my
+ package manager handle the updates, and I want my computer to keep working correctly (or throw big
+ red warnings all over the place). In this case, HTML inside Markdown files stopped rendering, and
+ I only found out coincidentally a couple of weeks later as the web feed was not valid anymore.
+ From that moment on, I started checking the release notes for every update (which are frequent,
+ about once a week), but it was an annoying routine.</p>
+<!-- /p -->
+
+<p>
+ I understand that the program is in beta and it was on me to check for breaking changes, but to be
+ fair, Hugo is marketed as a fully functional program (as if it wasn't on a beta stage) on the
+ official website. Considering my last issue, this was concerning and ended up creating uncertainty
+ on the stability of Hugo and the transparency of the developers, so I decided to change my site
+ generator.</p>
+<!-- /p -->
+
+<h2>Taking the leap</h2>
+
+<p>
+ I wanted to move to something lightweight that could still be useful in a few years' time, ideally
+ a program that was easy to understand and maintain. The problem was that I had some very specific
+ needs that small programs didn't fulfill, leaving only big programs as an option (which I didn't
+ want to use). I thought of the possibility of creating my own site generator, but it looked like a
+ large task I didn't want to spend my time on. Hugo was working fine, and although I kept looking
+ up other SSGs when I discovered them, I stopped actively looking for alternatives or thinking
+ about designing my own.</p>
+<!-- /p -->
+
+<p>
+ Until the night of the 5th of September, when I came across <a
+ href="https://github.com/sunainapai/makesite">makesite.py</a>. This project was just perfect, and
+ I couldn't resist. Let me show you an extract of the README:</p>
+<!-- /p -->
+
+<blockquote>
+ <p>Have you used a popular static site generator like Jekyll to generate your blog?</p>
+</blockquote>
+
+<p>Yes...</p>
+
+<blockquote>
+ <p>
+ I have too. It is simple and great. But then did you yearn to use something even simpler to
+ generate your blog? Do you like Python? Perhaps the thought of writing your own static site
+ generator crossed your mind but you thought it would be too much work?</p>
+ <!-- /p -->
+</blockquote>
+
+<p>Yes, yes, and definitely yes!</p>
+
+<blockquote>
+ <p>If you answered "yes" to these questions, then this project is for you.</p>
+</blockquote>
+
+<p>
+ Nice! That night I read the README and the source code (which is shorter than the README). The
+ program is very simple and a lot of the basic functionality I needed out of a static site
+ generator was already there. On top of that, it didn't use any non-standard Python library except
+ for the Markdown parser. I really liked the project and I thought it could be the foundation of my
+ personal static site generator.</p>
+<!-- /p -->
+
+<p>
+ It was. The next morning, I started coding to make it usable for my website. I had to implement
+ many new features, but with Python it was <a href="https://xkcd.com/353/">easy and fun</a>. After
+ two days of working on it, I finally released my site using a personal fork of makesite.py,
+ <a href="https://git.oscarbenedito.com/oscarbenedito.com/file/gensite.py.html">gensite.py</a>!</p>
+<!-- /p -->
+
+<h2>The new benefits</h2>
+
+<p>
+ So, why change the SSG if Hugo was working fine? As I said, I've had my issues with Hugo, and I
+ don't want to be forced to leave my static site generator if more arise in the future. I don't
+ know if I'll be able to switch SSGs when (and if) the time comes, and now I have the time and
+ motivation needed to do it, so I decided to take the chance while it was there. On top of that,
+ <em>gensite.py</em> is not only my "way out of Hugo", it is a program that has many features that
+ could have made me do the change without having any troubles with the last SSG.</p>
+<!-- /p -->
+
+<p>
+ First of all, the program is very small, it's only about 270 lines of code and it's written in
+ Python. That makes it very easy for me to read and understand the whole program very quickly, even
+ if I have completely forgotten everything about it. Obviously, this doesn't count the lines of
+ code of the libraries it depends on, but those are all standard libraries and the functions are
+ easy to understand, except for the Markdown parser, but if that ever gives me any trouble I can
+ change it without much effort.</p>
+<!-- /p -->
+
+<p>
+ Since <em>gensite.py</em> is made exclusively for my website, it is more closely tied to the rest
+ of my site. For example, it doesn't have a complex template engine, instead, templates only
+ process the following two snippets:</p>
+<!-- /p -->
+
+<ul>
+ <li><code>{{ var }}</code>: substitutes the string for the value of variable <code>var</code>.</li>
+ <li>
+ <code>{{ _if var }}text{{ _fi }}</code>: will render the text <code>text</code> if variable
+ <code>var</code> is defined. You can't have an <code>_if</code> inside another.</li>
+ <!-- /li -->
+</ul>
+
+<p>
+ If I need anything more complex, I will use Python to create the text and pass it as a variable
+ when rendering the template. I prefer this approach as it is a lot nicer to implement those
+ features in Python than it is with a template engine. For some pages—for example, the
+ archive—Python does some more heavy lifting and creates part of the HTML. This can sound weird in
+ comparison with other static site generators, where HTML is only dealt with in the template files,
+ but it makes things simpler, and I no longer need hacky templates to create certain outputs.</p>
+<!-- /p -->
+
+<p>
+ Moreover, I like the file structure a lot better (I designed it!), and if I ever want to change
+ it, it shouldn't take long to do so. Similarly, any other design options are exactly as I want
+ them to be, since it is me who decided them. In case it is not clear: everything works exactly as
+ I want it to!</p>
+<!-- /p -->
+
+<p>
+ Finally, it's a project that doesn't move too fast. One of the problems with websites is that
+ links are easily broken: entities change their backend, run out of money, mess up an update, etc.
+ and let their links break. Right now, I am pretty dedicated to my website, and if my SSG broke
+ something on my website, I would spend the time to fix it, but I can't ensure I'll do the same in
+ two or five years (and I don't want to break any links, even on the long term, but that's a post
+ for another day). Unless something happens with Python, <em>gensite.py</em> will work and so will
+ the generation of my website. There won't be any updates that break some random page or that
+ change a certain behaviour<sup id="fnref1"><a href="#fn1">1</a></sup>. I hope <em>gensite.py</em>
+ can stand the test of time, but we'll see...</p>
+<!-- /p -->
+
+<h2>Final comments</h2>
+
+<p>
+ Forking <em>makesite.py</em> and setting up everything I needed for my website was very fun, but
+ it is surely a process that not everyone will enjoy. I have lately been leaning towards software
+ that is a simple as possible, software that is easy to understand and change if needed. It takes
+ time to set up, but once it's working, you can forget about it (and if you need to make changes,
+ they are quickly implemented) and you will have software that works exactly as you want it to. I
+ am very meticulous about this website and try to have good control over everything that happens
+ during the website's generation, and I couldn't be happier with <em>gensite.py</em>.</p>
+<!-- /p -->
+
+<p>
+ On another note, I don't want to end this post without saying that Hugo has been a great static
+ site generator, and I'd recommend it to anyone who wants to have a blog on a static website. In a
+ new update with breaking changes, they did throw errors if the old feature was used, so maybe my
+ experience wouldn't happen again. Just remember, it's still in beta.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ Also, whenever I make changes to <em>gensite.py</em>, I can run <code>diff -r</code> to check
+ for differences for the outputs before and after the update. With Hugo, many files changed
+ without explanation (although it was mostly style choices, it made it hard to see the real
+ changes in content between updates). <a href="#fnref1" title="Jump back to footnote 1 in the
+ text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-09-27-switching-to-own-ssg.md b/content/blog/2020-09-27-switching-to-own-ssg.md
@@ -1,165 +0,0 @@
-<!-- title: Switching to my own static site generator -->
-<!-- slug: switching-to-own-ssg -->
-<!-- categories: FOSS, Personal domain, Projects -->
-<!-- date: 2020-09-27T16:27:00Z -->
-
-Since the start of this website (its first anniversary was a couple of weeks
-ago!) until recently, I have been using the static site generator [Hugo][h].
-Static site generators are very useful when building relatively complex static
-websites, and Hugo has served me well. I have also used [Lektor][l] and
-[Jekyll][j] before for other projects, but for a site with a blog, I like Hugo
-the most. However, with time, some issues have arisen with Hugo, and I finally
-decided to change my site's generator.
-
-## Issues with Hugo
-
-If you build your website with a static site generator, it will probably be the
-most critical dependency of your site. Of course, it's a dependency I'm fine
-with as it makes things much easier (dealing with Markdown content, categories,
-web feeds...), but if something goes wrong, the site won't render as you want.
-Hugo in particular is a very big project and I don't feel like jumping into the
-source code every time I have an issue with the program (especially since I've
-never used Go, and I don't want to spend hours for minor annoyances). Although
-Hugo works wonderfully, I have encountered moments where it has acted
-unpredictably, and documentation doesn't help most of the time.
-
-On top of that, although it works perfectly well (and it is one of the most
-popular SSGs), it is on a beta stage and the developers have made
-backward-incompatible changes without warning in the past. The change I have in
-mind was clearly stated on the release page, but I normally let my package
-manager handle the updates, and I want my computer to keep working correctly (or
-throw big red warnings all over the place). In this case, HTML inside Markdown
-files stopped rendering, and I only found out coincidentally a couple of weeks
-later as the web feed was not valid anymore. From that moment on, I started
-checking the release notes for every update (which are frequent, about once a
-week), but it was an annoying routine.
-
-I understand that the program is in beta and it was on me to check for breaking
-changes, but to be fair, Hugo is marketed as a fully functional program (as if
-it wasn't on a beta stage) on the official website. Considering my last issue,
-this was concerning and ended up creating uncertainty on the stability of Hugo
-and the transparency of the developers, so I decided to change my site
-generator.
-
-## Taking the leap
-
-I wanted to move to something lightweight that could still be useful in a few
-years' time, ideally a program that was easy to understand and maintain. The
-problem was that I had some very specific needs that small programs didn't
-fulfill, leaving only big programs as an option (which I didn't want to use). I
-thought of the possibility of creating my own site generator, but it looked like
-a large task I didn't want to spend my time on. Hugo was working fine, and
-although I kept looking up other SSGs when I discovered them, I stopped actively
-looking for alternatives or thinking about designing my own.
-
-Until the night of the 5th of September, when I came across [makesite.py][ms].
-This project was just perfect, and I couldn't resist. Let me show you an extract
-of the README:
-
-> Have you used a popular static site generator like Jekyll to generate your
-> blog?
-
-Yes...
-
-> I have too. It is simple and great. But then did you yearn to use something
-> even simpler to generate your blog? Do you like Python? Perhaps the thought of
-> writing your own static site generator crossed your mind but you thought it
-> would be too much work?
-
-Yes, yes, and definitely yes!
-
-> If you answered "yes" to these questions, then this project is for you.
-
-Nice! That night I read the README and the source code (which is shorter than
-the README). The program is very simple and a lot of the basic functionality I
-needed out of a static site generator was already there. On top of that, it
-didn't use any non-standard Python library except for the Markdown parser. I
-really liked the project and I thought it could be the foundation of my personal
-static site generator.
-
-It was. The next morning, I started coding to make it usable for my website. I
-had to implement many new features, but with Python it was [easy and fun][xkcd].
-After two days of working on it, I finally released my site using a personal
-fork of makesite.py, [gensite.py][gs]!
-
-## The new benefits
-
-So, why change the SSG if Hugo was working fine? As I said, I've had my issues
-with Hugo, and I don't want to be forced to leave my static site generator if
-more arise in the future. I don't know if I'll be able to switch SSGs when (and
-if) the time comes, and now I have the time and motivation needed to do it, so I
-decided to take the chance while it was there. On top of that, *gensite.py* is
-not only my "way out of Hugo", it is a program that has many features that could
-have made me do the change without having any troubles with the last SSG.
-
-First of all, the program is very small, it's only about 270 lines of code and
-it's written in Python. That makes it very easy for me to read and understand
-the whole program very quickly, even if I have completely forgotten everything
-about it. Obviously, this doesn't count the lines of code of the libraries it
-depends on, but those are all standard libraries and the functions are easy to
-understand, except for the Markdown parser, but if that ever gives me any
-trouble I can change it without much effort.
-
-Since *gensite.py* is made exclusively for my website, it is more closely tied
-to the rest of my site. For example, it doesn't have a complex template engine,
-instead, templates only process the following two snippets:
-
-- `{{ var }}`: substitutes the string for the value of variable `var`.
-- `{{ _if var }}text{{ _fi }}`: will render the text `text` if variable `var` is
- defined. You can't have an `_if` inside another.
-
-If I need anything more complex, I will use Python to create the text and pass
-it as a variable when rendering the template. I prefer this approach as it is a
-lot nicer to implement those features in Python than it is with a template
-engine. For some pages—for example, the archive—Python does some more heavy
-lifting and creates part of the HTML. This can sound weird in comparison with
-other static site generators, where HTML is only dealt with in the template
-files, but it makes things simpler, and I no longer need hacky templates to
-create certain outputs.
-
-Moreover, I like the file structure a lot better (I designed it!), and if I ever
-want to change it, it shouldn't take long to do so. Similarly, any other design
-options are exactly as I want them to be, since it is me who decided them. In
-case it is not clear: everything works exactly as I want it to!
-
-Finally, it's a project that doesn't move too fast. One of the problems with
-websites is that links are easily broken: entities change their backend, run out
-of money, mess up an update, etc. and let their links break. Right now, I am
-pretty dedicated to my website, and if my SSG broke something on my website, I
-would spend the time to fix it, but I can't ensure I'll do the same in two or
-five years (and I don't want to break any links, even on the long term, but
-that's a post for another day). Unless something happens with Python,
-*gensite.py* will work and so will the generation of my website. There won't be
-any updates that break some random page or that change a certain behaviour[^u].
-I hope *gensite.py* can stand the test of time, but we'll see...
-
-[^u]: Also, whenever I make changes to *gensite.py*, I can run `diff -r` to
- check for differences for the outputs before and after the update. With Hugo,
- many files changed without explanation (although it was mostly style choices,
- it made it hard to see the real changes in content between updates).
-
-## Final comments
-
-Forking *makesite.py* and setting up everything I needed for my website was very
-fun, but it is surely a process that not everyone will enjoy. I have lately been
-leaning towards software that is a simple as possible, software that is easy to
-understand and change if needed. It takes time to set up, but once it's working,
-you can forget about it (and if you need to make changes, they are quickly
-implemented) and you will have software that works exactly as you want it to. I
-am very meticulous about this website and try to have good control over
-everything that happens during the website's generation, and I couldn't be
-happier with *gensite.py*.
-
-On another note, I don't want to end this post without saying that Hugo has been
-a great static site generator, and I'd recommend it to anyone who wants to have
-a blog on a static website. In a new update with breaking changes, they did
-throw errors if the old feature was used, so maybe my experience wouldn't happen
-again. Just remember, it's still in beta.
-
-
-[h]: <https://gohugo.io> "Hugo"
-[l]: <https://www.getlektor.com> "Lektor"
-[j]: <https://jekyllrb.com> "Jekyll"
-[ms]: <https://github.com/sunainapai/makesite> "makesite.py — GitHub"
-[xkcd]: <https://xkcd.com/353/> "Python — xkcd"
-[gs]: <https://git.oscarbenedito.com/oscarbenedito.com/file/gensite.py.html> "gensite.py — git.oscarbenedito.com"
diff --git a/content/blog/2020-10-18-atreus.html b/content/blog/2020-10-18-atreus.html
@@ -0,0 +1,118 @@
+<!-- title: Improving ergonomics: the Atreus keyboard -->
+<!-- slug: atreus -->
+<!-- categories: Miscellany -->
+<!-- date: 2020-10-18T21:05:00Z -->
+
+<p>
+ Back in March, at the start of the lockdown, I had a lot of free time. I also had a lot of ideas
+ for personal projects and functionalities for my server, so I started coding a lot. I realized
+ that since I was spending a lot of time on my computer, without any time constraints, I could use
+ the opportunity to try things I was always "too busy" to try. Things that I knew would make me
+ more efficient on my computer, but had a steep learning curve. For example, I started using
+ <a href="https://i3wm.org">i3</a>, which I eventually changed for <a href="https://dwm.suckless.org">dwm</a>,
+ and I started using <a href="https://neovim.io">neovim</a> as my main editor (I had some
+ experience with vim, but never used it for day-to-day tasks). I now use dwm exclusively and vim
+ nearly exclusively.</p>
+<!-- /p -->
+
+<p>
+ Both programs disregard the mouse completely (or nearly<sup id="fnref1"><a href="#fn1">1</a></sup>),
+ and most other programs I tried or got more comfortable with during the lockdown also used text as
+ the main input method. With all these changes towards a more keyboard-centric system, I couldn't
+ help but think: can I improve my keyboard experience? I already touch-type, so that area didn't
+ have a lot of room for improvement. I could get a mechanical keyboard, but back then, I had only
+ used membrane keyboards and I felt perfectly comfortable, I didn't think there was a lot of room
+ for improvement there either, and I could not justify the economic cost of such a change. That
+ sounded just about everything I could improve on, so I guess I already had a pretty optimal
+ experience.</p>
+<!-- /p -->
+
+<p><em>Wait a minute...</em></p>
+
+<p>
+ Why are the keyboards arranged the way they are? Is it the optimal position? Apparently, not even
+ close! If you look around, you will see that there are a lot of different kinds of keyboards with
+ the keys arranged in very different ways. Keyboards designed to be more comfortable than regular
+ ones are normally referred to as <a href="https://en.wikipedia.org/wiki/Ergonomic_keyboard">ergonomic keyboards</a>.
+ I did some research and I tried to understand—although it was hard to evaluate without trying
+ them—why they are considered more comfortable. Each keyboard had it's own pros and cons, and after
+ looking at many, I decided that my perfect keyboard would have the following properties:</p>
+<!-- /p -->
+
+<ul>
+ <li>
+ <strong>Arranged in columns</strong>: it makes no sense for keyboards' rows to be staggered.
+ Indeed, the reason for that design is that typewriters had to be staggered so that the levers
+ could all fit under the keys. With computers, this isn't an issue anymore, and columns are more
+ comfortable.</li>
+ <!-- /li -->
+ <li>
+ <strong>Make use of thumbs</strong>: my right thumb's job on a normal keyboard is to press one
+ big space bar and my left thumb doesn't even have a job! I would rather have a small space bar
+ and fit a couple more keys for each thumb.</li>
+ <!-- /li -->
+ <li>
+ <strong>Minimize the movements of my fingers</strong>: ideally, no finger would have to press
+ any key that's not adjacent to it's "resting" key (diagonally adjacent is fine).</li>
+ <!-- /li -->
+ <li>
+ <strong>Easy to type modifier keys</strong>: as I use the keyboard instead of the mouse as much
+ as I can, I use modifier keys often. I would like them to be reached easily.</li>
+ <!-- /li -->
+ <li><strong>High distance between hands</strong>: for a better posture when writing on my computer.</li>
+</ul>
+
+<p>
+ In short, I wanted to maximize the comfort of typing while minimizing the movements my hands had
+ to make. Additionally, I didn't want to spend a lot of money (I didn't know if I was going to like
+ moving to a different keyboard) and also would rather not have to build the keyboard myself,
+ although it looked like that was the only option.</p>
+<!-- /p -->
+
+<p>
+ After all the research, only one keyboard seemed to fulfill all my needs: the
+ <a href="https://atreus.technomancy.us">Atreus keyboard</a>. The Atreus seemed great, I would have
+ liked it more if it had an extra column on each side (like the
+ <a href="https://shop.profetkeyboards.com/product/atreus62-keyboard">Atreus62</a>), but it wasn't
+ a big deal. The reviews on the Atreus were all great, so I decided to give it a try.</p>
+<!-- /p -->
+
+<p>
+ Luckily for me, back then <a href="https://keyboard.io">Keyboardio</a> had just launched a
+ Kickstarter campaign for that precise keyboard. It had a good price for an ergonomic keyboard and
+ I didn't have to build it on my own. The only problem was that I'd have to wait until the end of
+ August to receive it, but time wasn't an issue for me, so I bought it. Fast forward five months to
+ two weeks ago, the keyboard finally arrived! <em>(There were some delays, although the people at
+ Keyboardio always kept us informed, great experience overall.)</em></p>
+<!-- /p -->
+
+<p>
+ I have been able to use the new keyboard for some time now and it looks good so far<sup
+ id="fnref2"><a href="#fn2">2</a></sup>. It took some time to get used to the columns instead of
+ staggered rows, but I am doing a lot better now. It also took some time to get used to the layers
+ (I had to re-learn where every character is!), but after I changed the layout to make it as
+ intuitive as possible, the learning process has been a lot faster.</p>
+<!-- /p -->
+
+<p>
+ Although I am liking the keyboard so far, I don't want to evaluate it extensively while still
+ getting used to it and I think I shouldn't reach any conclusions until I feel more comfortable
+ with it. I will probably write about my experience with the Atreus in the future.</p>
+<!-- /p -->
+
+<!-- footnotes -->
+<hr />
+
+<ol>
+ <li id="fn1">
+ In my case, I deactivate the mouse completely in neovim, as the only thing I use the mouse for
+ is to select text to easily paste it with the middle button on another application, but I like
+ the cursor staying where it is when I do it. For dwm, you can selects tags with the mouse, but I
+ rarely do that. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
+ <!-- /li -->
+ <li id="fn2">
+ I don't want to use it for day-to-day tasks yet, as I am still a bit slow and feel more
+ comfortable with a regular keyboard, so I haven't used it that much. <a href="#fnref2"
+ title="Jump back to footnote 2 in the text">↩</a></li>
+ <!-- /li -->
+</ol>
diff --git a/content/blog/2020-10-18-atreus.md b/content/blog/2020-10-18-atreus.md
@@ -1,104 +0,0 @@
-<!-- title: Improving ergonomics: the Atreus keyboard -->
-<!-- slug: atreus -->
-<!-- categories: Miscellany -->
-<!-- date: 2020-10-18T21:05:00Z -->
-
-Back in March, at the start of the lockdown, I had a lot of free time. I also
-had a lot of ideas for personal projects and functionalities for my server, so I
-started coding a lot. I realized that since I was spending a lot of time on my
-computer, without any time constraints, I could use the opportunity to try
-things I was always "too busy" to try. Things that I knew would make me more
-efficient on my computer, but had a steep learning curve. For example, I started
-using [i3][i3], which I eventually changed for [dwm][dwm], and I started using
-[neovim][nv] as my main editor (I had some experience with vim, but never used
-it for day-to-day tasks). I now use dwm exclusively and vim nearly exclusively.
-
-Both programs disregard the mouse completely (or nearly[^me]), and most other
-programs I tried or got more comfortable with during the lockdown also used text
-as the main input method. With all these changes towards a more keyboard-centric
-system, I couldn't help but think: can I improve my keyboard experience? I
-already touch-type, so that area didn't have a lot of room for improvement. I
-could get a mechanical keyboard, but back then, I had only used membrane
-keyboards and I felt perfectly comfortable, I didn't think there was a lot of
-room for improvement there either, and I could not justify the economic cost of
-such a change. That sounded just about everything I could improve on, so I guess
-I already had a pretty optimal experience.
-
-[^me]: In my case, I deactivate the mouse completely in neovim, as the only
- thing I use the mouse for is to select text to easily paste it with the middle
- button on another application, but I like the cursor staying where it is when
- I do it. For dwm, you can selects tags with the mouse, but I rarely do that.
-
-*Wait a minute...*
-
-Why are the keyboards arranged the way they are? Is it the optimal position?
-Apparently, not even close! If you look around, you will see that there are a
-lot of different kinds of keyboards with the keys arranged in very different
-ways. Keyboards designed to be more comfortable than regular ones are normally
-referred to as [ergonomic keyboards][ek]. I did some research and I tried to
-understand—although it was hard to evaluate without trying them—why they are
-considered more comfortable. Each keyboard had it's own pros and cons, and after
-looking at many, I decided that my perfect keyboard would have the following
-properties:
-
-- **Arranged in columns**: it makes no sense for keyboards' rows to be
- staggered. Indeed, the reason for that design is that typewriters had to be
- staggered so that the levers could all fit under the keys. With computers,
- this isn't an issue anymore, and columns are more comfortable.
-- **Make use of thumbs**: my right thumb's job on a normal keyboard is to press
- one big space bar and my left thumb doesn't even have a job! I would rather
- have a small space bar and fit a couple more keys for each thumb.
-- **Minimize the movements of my fingers**: ideally, no finger would have to
- press any key that's not adjacent to it's "resting" key (diagonally adjacent
- is fine).
-- **Easy to type modifier keys**: as I use the keyboard instead of the mouse as
- much as I can, I use modifier keys often. I would like them to be reached
- easily.
-- **High distance between hands**: for a better posture when writing on my
- computer.
-
-In short, I wanted to maximize the comfort of typing while minimizing the
-movements my hands had to make. Additionally, I didn't want to spend a lot of
-money (I didn't know if I was going to like moving to a different keyboard) and
-also would rather not have to build the keyboard myself, although it looked like
-that was the only option.
-
-After all the research, only one keyboard seemed to fulfill all my needs: the
-[Atreus keyboard][ak]. The Atreus seemed great, I would have liked it more if it
-had an extra column on each side (like the [Atreus62][ak62]), but it wasn't a
-big deal. The reviews on the Atreus were all great, so I decided to give it a
-try.
-
-Luckily for me, back then [Keyboardio][kbio] had just launched a Kickstarter
-campaign for that precise keyboard. It had a good price for an ergonomic
-keyboard and I didn't have to build it on my own. The only problem was that I'd
-have to wait until the end of August to receive it, but time wasn't an issue for
-me, so I bought it. Fast forward five months to two weeks ago, the keyboard
-finally arrived! *(There were some delays, although the people at Keyboardio
-always kept us informed, great experience overall.)*
-
-I have been able to use the new keyboard for some time now and it looks good so
-far[^nt]. It took some time to get used to the columns instead of staggered
-rows, but I am doing a lot better now. It also took some time to get used to the
-layers (I had to re-learn where every character is!), but after I changed the
-layout to make it as intuitive as possible, the learning process has been a lot
-faster.
-
-[^nt]: I don't want to use it for day-to-day tasks yet, as I am still a bit slow
- and feel more comfortable with a regular keyboard, so I haven't used it that
- much.
-
-Although I am liking the keyboard so far, I don't want to evaluate it
-extensively while still getting used to it and I think I shouldn't reach any
-conclusions until I feel more comfortable with it. I will probably write about
-my experience with the Atreus in the future.
-
-
-[i3]: <https://i3wm.org> "i3"
-[dwm]: <https://dwm.suckless.org> "dwm"
-[nv]: <https://neovim.io> "Neovim"
-[ek]: <https://en.wikipedia.org/wiki/Ergonomic_keyboard> "Ergonomic keyboard — Wikipedia"
-[ak]: <https://atreus.technomancy.us> "Atreus keyboard"
-[ak62]: <https://shop.profetkeyboards.com/product/atreus62-keyboard> "Atreus62 keyboard — Profet Keyboards"
-[kbio]: <https://keyboard.io> "Keyboardio"
-[vm]: <https://github.com/philc/vimium> "Vimium — GitHub"
diff --git a/content/blog/2020-11-11-give-back-to-foss.html b/content/blog/2020-11-11-give-back-to-foss.html
@@ -0,0 +1,70 @@
+<!-- title: Give back to free and open source software -->
+<!-- slug: give-back-to-foss -->
+<!-- categories: FOSS, Miscellany -->
+<!-- date: 2020-11-11T18:25:00Z -->
+<!-- lastmod: 2020-11-16T23:22:00Z -->
+
+<p>
+ Most people make use of free and open source software—or services based on it—that is made
+ available to the public for free. And I mean free, not services that you pay with your data, but
+ those that are truly free of cost. Projects that rely on donations, grants, and the resources of
+ the maintainers (and most of the time it's only the latter). If you are a heavy user of FOSS, you
+ are probably already aware of this, but even if you are not a big user, you probably still use
+ Wikipedia (or other sites based on the same engine), the VLC media player, or others.</p>
+<!-- /p -->
+
+<p>
+ These programs are great, not only because they are universally affordable (have no cost!), but
+ because they are focused on the user. Their goal is to serve the user, not the developer, which
+ often involves software that is more private, useful and easy to adapt to your needs. Software
+ that doesn't break after a couple of years, and that keeps working even on older devices.</p>
+<!-- /p -->
+
+<p>
+ But this post is not about how great FOSS is, but about helping out these projects. All projects
+ have a cost, if there is no monetary cost, then there must be people behind it contributing their
+ time and energy. If you regularly enjoy some of this software, consider giving back to the
+ developers. This kind of project normally requires a lot fewer resources than commercial ones, and
+ even then, the maintainers normally carry most of the burden. By helping out, we can enlarge the
+ community and have more people working on it, as well as help current projects grow. How can we
+ help? Glad you asked!</p>
+<!-- /p -->
+
+<ul>
+ <li>
+ <strong>Donate</strong>: It's easy, doesn't require a lot of your resources, and it helps. My
+ biggest issue is normally convenience. If every time that I have the thought "this is very
+ useful, I should donate", I could press a button to give 2 euros, I would probably do it. The
+ problem is that there is no such convenient button. My most successful strategy has been
+ thinking about a handful of projects I wanted to donate to, and then sit down on my computer and
+ donate a bigger amount to each one of them. This way I only have to do it once every so many
+ months, instead of a little donation every two weeks.</li>
+ <!-- /li -->
+ <li>
+ <strong>Report bugs</strong>: Instead of complaining that something doesn't work, take some time
+ to make sure it's something about the program (not just you messing up) and, if it is, go to the
+ project's bug tracker and either provide more details to an already open issue or file a new one
+ if you can't find it there. This is can be more time-consuming depending on the bug, but it's
+ free (except for the time you pay, of course :)).</li>
+ <!-- /li -->
+ <li>
+ <strong>Translate</strong>: This one takes even more time! Is that program not in your native
+ language? Translate it yourself!</li>
+ <!-- /li -->
+ <li>
+ <strong>Send patches</strong>: If you want a new feature, there is an annoying bug, etc.,
+ consider jumping into the code and implement it/solve it on your own (or asking for some help
+ doing it).</li>
+ <!-- /li -->
+</ul>
+
+<p>
+ There are other ways to help (feel free to contact me if you think of more and I'll add them), but
+ these are the ones that come to mind. I partially wanted the post to be a reminder that donating
+ money and coding are not the only ways to help. In particular, reporting bugs is something most
+ users will be able to do and it helps—you can't fix it if you don't know about it. On the other
+ hand, depending on the project, such bugs will get fixed in a matter of days, so you'll be able to
+ reap the benefit.</p>
+<!-- /p -->
+
+<p>Enjoy a project? Help out!</p>
diff --git a/content/blog/2020-11-11-give-back-to-foss.md b/content/blog/2020-11-11-give-back-to-foss.md
@@ -1,59 +0,0 @@
-<!-- title: Give back to free and open source software -->
-<!-- slug: give-back-to-foss -->
-<!-- categories: FOSS, Miscellany -->
-<!-- date: 2020-11-11T18:25:00Z -->
-<!-- lastmod: 2020-11-16T23:22:00Z -->
-
-Most people make use of free and open source software—or services based on
-it—that is made available to the public for free. And I mean free, not services
-that you pay with your data, but those that are truly free of cost. Projects
-that rely on donations, grants, and the resources of the maintainers (and most
-of the time it's only the latter). If you are a heavy user of FOSS, you are
-probably already aware of this, but even if you are not a big user, you probably
-still use Wikipedia (or other sites based on the same engine), the VLC media
-player, or others.
-
-These programs are great, not only because they are universally affordable (have
-no cost!), but because they are focused on the user. Their goal is to serve the
-user, not the developer, which often involves software that is more private,
-useful and easy to adapt to your needs. Software that doesn't break after a
-couple of years, and that keeps working even on older devices.
-
-But this post is not about how great FOSS is, but about helping out these
-projects. All projects have a cost, if there is no monetary cost, then there
-must be people behind it contributing their time and energy. If you regularly
-enjoy some of this software, consider giving back to the developers. This kind
-of project normally requires a lot fewer resources than commercial ones, and
-even then, the maintainers normally carry most of the burden. By helping out, we
-can enlarge the community and have more people working on it, as well as help
-current projects grow. How can we help? Glad you asked!
-
-- **Donate**: It's easy, doesn't require a lot of your resources, and it helps.
- My biggest issue is normally convenience. If every time that I have the
- thought "this is very useful, I should donate", I could press a button to give
- 2 euros, I would probably do it. The problem is that there is no such
- convenient button. My most successful strategy has been thinking about a
- handful of projects I wanted to donate to, and then sit down on my computer
- and donate a bigger amount to each one of them. This way I only have to do it
- once every so many months, instead of a little donation every two weeks.
-- **Report bugs**: Instead of complaining that something doesn't work, take some
- time to make sure it's something about the program (not just you messing up)
- and, if it is, go to the project's bug tracker and either provide more details
- to an already open issue or file a new one if you can't find it there. This is
- can be more time-consuming depending on the bug, but it's free (except for the
- time you pay, of course :)).
-- **Translate**: This one takes even more time! Is that program not in your
- native language? Translate it yourself!
-- **Send patches**: If you want a new feature, there is an annoying bug, etc.,
- consider jumping into the code and implement it/solve it on your own (or
- asking for some help doing it).
-
-There are other ways to help (feel free to contact me if you think of more and
-I'll add them), but these are the ones that come to mind. I partially wanted the
-post to be a reminder that donating money and coding are not the only ways to
-help. In particular, reporting bugs is something most users will be able to do
-and it helps—you can't fix it if you don't know about it. On the other hand,
-depending on the project, such bugs will get fixed in a matter of days, so
-you'll be able to reap the benefit.
-
-Enjoy a project? Help out!
diff --git a/content/blog/2020-12-20-gemini-links.html b/content/blog/2020-12-20-gemini-links.html
@@ -0,0 +1,100 @@
+<!-- title: Gemini's different approach to links -->
+<!-- slug: gemini-links -->
+<!-- categories: Miscellany -->
+<!-- date: 2020-12-20T20:01:00Z -->
+
+<p>
+ I have lately been reading many pages on <a href="https://gemini.circumlunar.space">Gemini</a>.
+ There has been a lot of interest around it on the blogs/microblogs I follow, which has lead to me
+ check it out as well. The project is very interesting, and if you have ever been interested in how
+ much bandwidth the current web wastes, the lack of privacy there is when we navigate it, the
+ constant security issues that come up with browsers, etc., I recommend you to take a look at the
+ project and read the FAQs. This post, however, is not about the Gemini protocol, but about how the
+ <code>text/gemini</code> media type handles links in comparison to HTML.</p>
+<!-- /p -->
+
+<p>
+ <code>text/gemini</code> is a very lightweight markup format. It only allows text, headers,
+ sub-headers, sub-sub-headers, preformatted text, unordered lists, quotes, and links. As you can
+ see, it has a (small) subset of the functionality of other hypertext formats such as HTML,
+ Markdown or org-mode. On top of that, links have to be on their own line, and you can optionally
+ give them a title. If I wanted to link to the Gemini homepage as I did in the last paragraph using
+ <code>text/gemini</code>, it would have to be in its own line:</p>
+<!-- /p -->
+
+<ul>
+ <li><a href="https://gemini.circumlunar.space">Project Gemini</a></li>
+</ul>
+
+<p>
+ That sounds very inconvenient, right? Why not just put the link inside the paragraph like in HTML?
+ I have found this way of linking a lot more pleasant when reading articles, and that's the reason
+ for this post.</p>
+<!-- /p -->
+
+<p>
+ When links are in the middle of text, sometimes you click on them while reading—maybe even before
+ you've finished reading the sentence! Even if you don't, they are distracting, you will probably
+ have to make a mental note: read the link once done with the paragraph, or you'll have to think:
+ is this link worth it? To decide whether to do the mental note in the first place. If you don't do
+ this, then you probably rescan the whole paragraph for links you have ignored (or just ignore
+ links altogether). By having the links at the end of the paragraph, you won't get distracted in
+ the middle of your reading, and you won't have to rescan for ignored links.</p>
+<!-- /p -->
+
+<p>
+ Aside from that, HTML links don't take up any space, they merely decorate a word that was already
+ there, while in <code>text/gemini</code> they take up a line of text, which means authors will
+ probably think twice before linking to 5 different websites that don't provide any useful
+ knowledge to the reader. But even if that doesn't stop them, now links have titles, which means
+ the visitor knows what the link is about before clicking it. That is a nice feature because it
+ makes it easy to ignore anything you are not interested in. If the author doesn't specify the
+ title, the URL will be shown in its place, and that already gives a lot of information. I know
+ that in most browsers, you can hover over a link to see the URL, but you have to reach for the
+ mouse to do it (and it is even harder to see the URL when on a phone or tablet).</p>
+<!-- /p -->
+
+<p><em>But the words with HTML links already tell what the link is about!</em></p>
+
+<p>
+ Not always. For example, let's look at the start of the post, where the word Gemini links
+ somewhere. Three options of possible links come to mind: I'm linking to the homepage of the
+ project, the Wikipedia page (or some other wiki), or a previous post where I talk about how I've
+ been using Gemini lately. Two types of readers also come to mind: someone that doesn't know what
+ Gemini is (interested to click if it's one of the first two options) or someone that knows about
+ Gemini, but is curious about others' experience with it (interested only in the last link). So
+ it's not only about whether the link is useful or not but also about the particular visitor.
+ However, if at the end of the paragraph there was a line with one of the following texts, it is
+ obvious for the reader what kind of content the link is pointing to.</p>
+<!-- /p -->
+
+<ul>
+ <li>Project Gemini</li>
+ <li>Gemini — Wikipedia</li>
+ <li>Why I started using Gemini — Oscar Benedito</li>
+</ul>
+
+<p>
+ Two notes: this way of writing titles is the one I follow for HTML's <code>a</code> tags'
+ <code>title</code> attribute, but other authors will do them differently. Also, the correct way to
+ link to a blog post would be to link using the whole sentence ("I have lately been reading many
+ pages on Gemini"), but not everyone does it.</p>
+<!-- /p -->
+
+<h2>Final thoughts</h2>
+
+<p>
+ When first reading about links in <code>text/gemini</code> I thought they were too limiting, but
+ they turned out to be quite nice. Don't get me wrong, links inside text can be very useful,
+ especially considering that the web is not only made of large articles but, for this particular
+ type of webpage, I find Gemini's approach better. This also made me realize how distracting links
+ can be, and I am now trying to reduce the amounts of links to a minimum, as well as footnotes, to
+ reduce the distractions caused by them. For now, I will still use links the "HTML way" because
+ this blog is hosted on the world wide web, but I might change my mind in the future.</p>
+<!-- /p -->
+
+<p>
+ On another note, if Gemini sounds interesting, check out the
+ <a href="https://gemini.circumlunar.space/docs/specification.html">specification</a>, it is easy
+ to read and the approach is very interesting.</p>
+<!-- /p -->
diff --git a/content/blog/2020-12-20-gemini-links.md b/content/blog/2020-12-20-gemini-links.md
@@ -1,91 +0,0 @@
-<!-- title: Gemini's different approach to links -->
-<!-- slug: gemini-links -->
-<!-- categories: Miscellany -->
-<!-- date: 2020-12-20T20:01:00Z -->
-
-I have lately been reading many pages on [Gemini][gmi]. There has been a lot of
-interest around it on the blogs/microblogs I follow, which has lead to me check
-it out as well. The project is very interesting, and if you have ever been
-interested in how much bandwidth the current web wastes, the lack of privacy
-there is when we navigate it, the constant security issues that come up with
-browsers, etc., I recommend you to take a look at the project and read the FAQs.
-This post, however, is not about the Gemini protocol, but about how the
-`text/gemini` media type handles links in comparison to HTML.
-
-`text/gemini` is a very lightweight markup format. It only allows text, headers,
-sub-headers, sub-sub-headers, preformatted text, unordered lists, quotes, and
-links. As you can see, it has a (small) subset of the functionality of other
-hypertext formats such as HTML, Markdown or org-mode. On top of that, links have
-to be on their own line, and you can optionally give them a title. If I wanted
-to link to the Gemini homepage as I did in the last paragraph using
-`text/gemini`, it would have to be in its own line:
-
-- [Project Gemini][gmi]
-
-That sounds very inconvenient, right? Why not just put the link inside the
-paragraph like in HTML? I have found this way of linking a lot more pleasant
-when reading articles, and that's the reason for this post.
-
-When links are in the middle of text, sometimes you click on them while
-reading—maybe even before you've finished reading the sentence! Even if you
-don't, they are distracting, you will probably have to make a mental note: read
-the link once done with the paragraph, or you'll have to think: is this link
-worth it? To decide whether to do the mental note in the first place. If you
-don't do this, then you probably rescan the whole paragraph for links you have
-ignored (or just ignore links altogether). By having the links at the end of the
-paragraph, you won't get distracted in the middle of your reading, and you won't
-have to rescan for ignored links.
-
-Aside from that, HTML links don't take up any space, they merely decorate a word
-that was already there, while in `text/gemini` they take up a line of text,
-which means authors will probably think twice before linking to 5 different
-websites that don't provide any useful knowledge to the reader. But even if that
-doesn't stop them, now links have titles, which means the visitor knows what the
-link is about before clicking it. That is a nice feature because it makes it
-easy to ignore anything you are not interested in. If the author doesn't specify
-the title, the URL will be shown in its place, and that already gives a lot of
-information. I know that in most browsers, you can hover over a link to see the
-URL, but you have to reach for the mouse to do it (and it is even harder to see
-the URL when on a phone or tablet).
-
-*But the words with HTML links already tell what the link is about!*
-
-Not always. For example, let's look at the start of the post, where the word
-Gemini links somewhere. Three options of possible links come to mind: I'm
-linking to the homepage of the project, the Wikipedia page (or some other wiki),
-or a previous post where I talk about how I've been using Gemini lately. Two
-types of readers also come to mind: someone that doesn't know what Gemini is
-(interested to click if it's one of the first two options) or someone that knows
-about Gemini, but is curious about others' experience with it (interested only
-in the last link). So it's not only about whether the link is useful or not but
-also about the particular visitor. However, if at the end of the paragraph there
-was a line with one of the following texts, it is obvious for the reader what
-kind of content the link is pointing to.
-
-- Project Gemini
-- Gemini — Wikipedia
-- Why I started using Gemini — Oscar Benedito
-
-Two notes: this way of writing titles is the one I follow for HTML's `a` tags'
-`title` attribute, but other authors will do them differently. Also, the correct
-way to link to a blog post would be to link using the whole sentence ("I have
-lately been reading many pages on Gemini"), but not everyone does it.
-
-## Final thoughts
-
-When first reading about links in `text/gemini` I thought they were too
-limiting, but they turned out to be quite nice. Don't get me wrong, links inside
-text can be very useful, especially considering that the web is not only made of
-large articles but, for this particular type of webpage, I find Gemini's
-approach better. This also made me realize how distracting links can be, and I
-am now trying to reduce the amounts of links to a minimum, as well as footnotes,
-to reduce the distractions caused by them. For now, I will still use links the
-"HTML way" because this blog is hosted on the world wide web, but I might change
-my mind in the future.
-
-On another note, if Gemini sounds interesting, check out the
-[specification][spec], it is easy to read and the approach is very interesting.
-
-
-[gmi]: <https://gemini.circumlunar.space> "Project Gemini"
-[spec]: <https://gemini.circumlunar.space/docs/specification.html> "Gemini protocol specification"
diff --git a/content/blog/2021-03-03-new-home-server.html b/content/blog/2021-03-03-new-home-server.html
@@ -0,0 +1,113 @@
+<!-- title: New home server -->
+<!-- slug: new-home-server -->
+<!-- categories: Decentralization, Self-hosting -->
+<!-- date: 2021-03-03T18:39:00Z -->
+
+<p>
+ During this past year, I have been coming up with a variety of services that I want to host from
+ home. The problem was that I didn't have a computer to host them on, so I decided to buy one
+ before my Christmas vacation, when I would have time to tinker with it. Because of the gifting
+ tradition, I was asked if there was anything that I wanted, so I ended up getting it for Christmas
+ instead. In case you are curious, the computer is a Raspberry Pi 4 Model B, I decided to go with a
+ Raspberry Pi because it's the only device I have experience with and it has worked great, on top
+ of having good specs at a good price. I already have a server running round-the-clock (the one
+ hosting this website), so why did I need another machine running nonstop? For two reasons: control
+ and proximity.</p>
+<!-- /p -->
+
+<p>
+ When I talk about "my server", I mean a virtual private server (VPS) that I rent. "My server" can
+ be more accurately described as a virtual machine that lives in someone else's computer and that I
+ can administer for a certain fee. This is great for many reasons which can be summarized in "I
+ don't have to deal with any infrastructure-related matter": the server's owner takes care of
+ maintenance, broken parts, refrigeration, etc. On top of that, the server has a very fast internet
+ connection and a static IP. So it's a machine that has all the needed features to start serving
+ content to the internet. However, because this is someone else's computer, they have complete
+ access to it. My guess is nobody is accessing my data—it probably takes some effort to automate
+ scraping virtual machines, and I think I'm not interesting enough to be a target—, but that is not
+ a reassuring argument, so I don't trust my VPS with my private data. With a computer at home, I
+ have full control of everything that is happening, and I am more comfortable saving personal data
+ there.</p>
+<!-- /p -->
+
+<p>
+ That was related to control, let's look at proximity. The VPS is hosted somewhere far away (I
+ believe in Germany), so the only feasible way to connect to it is through an internet connection.
+ This comes with limitations—you need internet, and internet connections are slower than local
+ ones. Moreover, I want to be able to unplug external hard drives and plug them into my computer to
+ have instant access to any data (for example to make a copy to give to someone), as well as the
+ other way around: I want to be able to grab a USB drive, connect it to my local server and have
+ all the data available from all the devices in the network. For obvious reasons, I can't do that
+ with my VPS. Finally, because my home server is not exposing any service to the internet, it is
+ much harder to hack it or for some data to get leaked.</p>
+<!-- /p -->
+
+<p>
+ More arguments come to mind of why some things are better hosted at home, but I think by now the
+ general feeling has gotten across, so let's jump into what I've done so far and what are some
+ ideas I have for the future.</p>
+<!-- /p -->
+
+<p>What I currently have:</p>
+
+<ul>
+ <li>
+ <strong>Media center</strong>: Well, something like it... I originally thought about
+ self-hosting Jellyfin or Plex, but the first time I wanted to use the media center I didn't have
+ much time to set it up, so I made a <em>very</em> minimal Apache site with an HTML file linking
+ to multiple videos and podcasts I had downloaded. Surprisingly, this setup has been working
+ great so far. I have created a script that autogenerates the page from a JSON with all the
+ metadata of the files I have and I have added some features (like marking media as "seen"). Now,
+ all I need to access the files is a web browser and, in some cases, <a href="https://mpv.io">mpv</a>
+ or <a href="https://www.videolan.org">VLC</a> if the format is not supported on the browser (did
+ you know you can stream videos with them?)</li>
+ <!-- /li -->
+ <li>
+ <strong>Git backup</strong>: It backs up all my Git repositories from different providers. It
+ does so with a <a href="https://git.oscarbenedito.com/git-backup/">Python script</a> I made some
+ time ago that given some authentication tokens, will mirror all my repositories (and any others
+ that I tell it to).</li>
+ <!-- /li -->
+ <li>
+ <strong>Syncthing</strong>: It runs Syncthing as another peer for all my folders. This way, all
+ my devices are always synchronized with the Raspberry Pi. Previously, two of them had to be on
+ and connected to have any synchronization. This also acts as a quick transparent backup for my
+ data, since the RPi is backed up daily.</li>
+ <!-- /li -->
+</ul>
+
+<p>My plans for the future are the following:</p>
+
+<ul>
+ <li>
+ <strong>Expanding the media center</strong>: Add more functionality to the scripts generating
+ the webpage, add functionality to the website to be able to do some basic operations without the
+ need to SSH into the Raspberry Pi, and add more types of content.</li>
+ <!-- /li -->
+ <li>
+ <strong>Backup center</strong>: I'm not sure if "backup center" means anything (or if I'm using
+ it correctly), but as my backup center, the Raspberry Pi would be in charge of backing up all my
+ devices. Syncthing already helps with my phone and some other small folders, but I'd like to
+ improve my backup system so that a lot more data can be automatically backed up. I think with my
+ home server it will be much easier to regularly pull data from the services I use as well as
+ have a centralized location to which send my files.</li>
+ <!-- /li -->
+ <li>
+ <strong>Calendar and contacts synchronization</strong>: Right now, I use my email provider to
+ synchronize my contacts, calendar and reminders using the CardDAV and CalDAV protocols. I would
+ like to stop sending that information online and just have it synchronize with my home server
+ (ideally with the same protocols).</li>
+ <!-- /li -->
+ <li>
+ <strong>Photo and video library</strong>: I want to centralize all the photos and videos I have
+ (and the rest of the family's as well) and have a good interface to access them. This will
+ include sorting them out and will probably take a lot of time, so I'm not sure if I'll end up
+ doing it.</li>
+ <!-- /li -->
+</ul>
+
+<p>
+ ... and anything else that comes to mind! I enjoy playing around with new software and I have been
+ enjoying every step of the move towards a more self-hosting setup, so I am sure that more things
+ will come up!</p>
+<!-- /p -->
diff --git a/content/blog/2021-03-03-new-home-server.md b/content/blog/2021-03-03-new-home-server.md
@@ -1,99 +0,0 @@
-<!-- title: New home server -->
-<!-- slug: new-home-server -->
-<!-- categories: Decentralization, Self-hosting -->
-<!-- date: 2021-03-03T18:39:00Z -->
-
-During this past year, I have been coming up with a variety of services that I
-want to host from home. The problem was that I didn't have a computer to host
-them on, so I decided to buy one before my Christmas vacation, when I would have
-time to tinker with it. Because of the gifting tradition, I was asked if there
-was anything that I wanted, so I ended up getting it for Christmas instead. In
-case you are curious, the computer is a Raspberry Pi 4 Model B, I decided to go
-with a Raspberry Pi because it's the only device I have experience with and it
-has worked great, on top of having good specs at a good price. I already have a
-server running round-the-clock (the one hosting this website), so why did I need
-another machine running nonstop? For two reasons: control and proximity.
-
-When I talk about "my server", I mean a virtual private server (VPS) that I
-rent. "My server" can be more accurately described as a virtual machine that
-lives in someone else's computer and that I can administer for a certain fee.
-This is great for many reasons which can be summarized in "I don't have to deal
-with any infrastructure-related matter": the server's owner takes care of
-maintenance, broken parts, refrigeration, etc. On top of that, the server has a
-very fast internet connection and a static IP. So it's a machine that has all
-the needed features to start serving content to the internet. However, because
-this is someone else's computer, they have complete access to it. My guess is
-nobody is accessing my data—it probably takes some effort to automate scraping
-virtual machines, and I think I'm not interesting enough to be a target—, but
-that is not a reassuring argument, so I don't trust my VPS with my private data.
-With a computer at home, I have full control of everything that is happening,
-and I am more comfortable saving personal data there.
-
-That was related to control, let's look at proximity. The VPS is hosted
-somewhere far away (I believe in Germany), so the only feasible way to connect
-to it is through an internet connection. This comes with limitations—you need
-internet, and internet connections are slower than local ones. Moreover, I want
-to be able to unplug external hard drives and plug them into my computer to have
-instant access to any data (for example to make a copy to give to someone), as
-well as the other way around: I want to be able to grab a USB drive, connect it
-to my local server and have all the data available from all the devices in the
-network. For obvious reasons, I can't do that with my VPS. Finally, because my
-home server is not exposing any service to the internet, it is much harder to
-hack it or for some data to get leaked.
-
-More arguments come to mind of why some things are better hosted at home, but I
-think by now the general feeling has gotten across, so let's jump into what I've
-done so far and what are some ideas I have for the future.
-
-What I currently have:
-
-- **Media center**: Well, something like it... I originally thought about
- self-hosting Jellyfin or Plex, but the first time I wanted to use the media
- center I didn't have much time to set it up, so I made a *very* minimal Apache
- site with an HTML file linking to multiple videos and podcasts I had
- downloaded. Surprisingly, this setup has been working great so far. I have
- created a script that autogenerates the page from a JSON with all the metadata
- of the files I have and I have added some features (like marking media as
- "seen"). Now, all I need to access the files is a web browser and, in some
- cases, [mpv][] or [VLC][] if the format is not supported on the browser (did
- you know you can stream videos with them?)
-- **Git backup**: It backs up all my Git repositories from different providers.
- It does so with a [Python script][gb] I made some time ago that given some
- authentication tokens, will mirror all my repositories (and any others that
- I tell it to).
-- **Syncthing**: It runs Syncthing as another peer for all my folders. This way,
- all my devices are always synchronized with the Raspberry Pi. Previously, two
- of them had to be on and connected to have any synchronization. This also acts
- as a quick transparent backup for my data, since the RPi is backed up daily.
-
-My plans for the future are the following:
-
-- **Expanding the media center**: Add more functionality to the scripts
- generating the webpage, add functionality to the website to be able to do some
- basic operations without the need to SSH into the Raspberry Pi, and add more
- types of content.
-- **Backup center**: I'm not sure if "backup center" means anything (or if I'm
- using it correctly), but as my backup center, the Raspberry Pi would be in
- charge of backing up all my devices. Syncthing already helps with my phone and
- some other small folders, but I'd like to improve my backup system so that a
- lot more data can be automatically backed up. I think with my home server it
- will be much easier to regularly pull data from the services I use as well as
- have a centralized location to which send my files.
-- **Calendar and contacts synchronization**: Right now, I use my email provider
- to synchronize my contacts, calendar and reminders using the CardDAV and
- CalDAV protocols. I would like to stop sending that information online and
- just have it synchronize with my home server (ideally with the same
- protocols).
-- **Photo and video library**: I want to centralize all the photos and videos I
- have (and the rest of the family's as well) and have a good interface to
- access them. This will include sorting them out and will probably take a lot
- of time, so I'm not sure if I'll end up doing it.
-
-... and anything else that comes to mind! I enjoy playing around with new
-software and I have been enjoying every step of the move towards a more
-self-hosting setup, so I am sure that more things will come up!
-
-
-[mpv]: <https://mpv.io> "mpv"
-[VLC]: <https://www.videolan.org> "VLC"
-[gb]: <https://git.oscarbenedito.com/git-backup/> "git-backup — git.oscarbenedito.com"
diff --git a/content/blog/2021-05-20-tv-shows-web-feeds.html b/content/blog/2021-05-20-tv-shows-web-feeds.html
@@ -0,0 +1,55 @@
+<!-- title: Follow TV shows with web feeds -->
+<!-- slug: tv-shows-web-feeds -->
+<!-- categories: FOSS, Projects -->
+<!-- date: 2021-05-20T19:19:00Z -->
+
+<p>
+ I am quite strict about which messages make it to a push notification on my phone. I don't like to
+ receive notifications unless they are important or urgent. The same thing happens with emails—indeed,
+ it's one of the few applications which have notifications enabled. However, I also don't want to
+ regularly check different places for updates. Because of this, most of the updates I receive are
+ through another channel: web feeds.</p>
+<!-- /p -->
+
+<p>
+ <a href="/blog/2020/04/use-web-feeds/">I have written before</a> about using web feeds (Atom, RSS,
+ JSON feed...) to keep track of updates to sites. I use my feed reader to get updates about some of
+ the software I use, YouTube videos, newsletters, and, of course, blogs. They are all things I
+ don't want to miss out on, but I don't want to be notified about. Instead, Miniflux (my feed
+ reader) stores them until I decide to log in and read them. This allows me to disable any
+ notifications but have them all centralized in one place.</p>
+<!-- /p -->
+
+<p>
+ Lately, many TV shows are starting to air again, meaning that there are new episodes weekly of
+ some series that I am watching, and soon more will follow. Because of this, I want to keep up to
+ date with which TV series are coming up, but I don't want push notifications or emails (or
+ checking their websites). I just want a way to know that there are new episodes for me to watch,
+ but without the hassle of looking it up... Ring a bell? Web feeds!</p>
+<!-- /p -->
+
+<p>
+ Yesterday I quickly looked around to see if there was any service offering that for free or
+ cheaply, and there was none. The ones I saw were about 5€/month, which is more than any other
+ service I use (a small VPS, email provider or Miniflux). I was not willing to pay that much, and I
+ was motivated enough to do such a service myself, it sounded like a fun and easy project to take
+ on for a day or two, so I did.</p>
+<!-- /p -->
+
+<p>
+ Luckily, <a href="https://www.tvmaze.com">TVmaze</a> offers a free API with all the information I
+ needed, and there I went with a Python script. After some time, I had it running, and today I
+ polished it a bit. I can say it is fully working now!</p>
+<!-- /p -->
+
+<p>
+ The script takes TV series IDs (as many as you want) and creates an Atom feed with an entry for
+ each episode there is. Just run it as a cron job every hour and put the output on a static site,
+ you're done! Alternatively, you can make one feed per show, so multiple people can subscribe to
+ their desired shows.</p>
+<!-- /p -->
+
+<p>
+ If you are interested, there is a bit more information about how it works <a href="/projects/tv2feed/">here</a>
+ and the code is <a href="https://git.oscarbenedito.com/osf/file/tv2feed.py.html">here</a>.</p>
+<!-- /p -->
diff --git a/content/blog/2021-05-20-tv-shows-web-feeds.md b/content/blog/2021-05-20-tv-shows-web-feeds.md
@@ -1,51 +0,0 @@
-<!-- title: Follow TV shows with web feeds -->
-<!-- slug: tv-shows-web-feeds -->
-<!-- categories: FOSS, Projects -->
-<!-- date: 2021-05-20T19:19:00Z -->
-
-I am quite strict about which messages make it to a push notification on my
-phone. I don't like to receive notifications unless they are important or
-urgent. The same thing happens with emails—indeed, it's one of the few
-applications which have notifications enabled. However, I also don't want to
-regularly check different places for updates. Because of this, most of the
-updates I receive are through another channel: web feeds.
-
-[I have written before][feeds] about using web feeds (Atom, RSS, JSON feed...)
-to keep track of updates to sites. I use my feed reader to get updates about
-some of the software I use, YouTube videos, newsletters, and, of course, blogs.
-They are all things I don't want to miss out on, but I don't want to be notified
-about. Instead, Miniflux (my feed reader) stores them until I decide to log in
-and read them. This allows me to disable any notifications but have them all
-centralized in one place.
-
-Lately, many TV shows are starting to air again, meaning that there are new
-episodes weekly of some series that I am watching, and soon more will follow.
-Because of this, I want to keep up to date with which TV series are coming up,
-but I don't want push notifications or emails (or checking their websites). I
-just want a way to know that there are new episodes for me to watch, but without
-the hassle of looking it up... Ring a bell? Web feeds!
-
-Yesterday I quickly looked around to see if there was any service offering that
-for free or cheaply, and there was none. The ones I saw were about 5€/month,
-which is more than any other service I use (a small VPS, email provider or
-Miniflux). I was not willing to pay that much, and I was motivated enough to do
-such a service myself, it sounded like a fun and easy project to take on for a
-day or two, so I did.
-
-Luckily, [TVmaze][] offers a free API with all the information I needed, and
-there I went with a Python script. After some time, I had it running, and today
-I polished it a bit. I can say it is fully working now!
-
-The script takes TV series IDs (as many as you want) and creates an Atom feed
-with an entry for each episode there is. Just run it as a cron job every hour
-and put the output on a static site, you're done! Alternatively, you can make
-one feed per show, so multiple people can subscribe to their desired shows.
-
-If you are interested, there is a bit more information about how it works
-[here][tv2feed] and the code is [here][code].
-
-
-[feeds]: </blog/2020/04/use-web-feeds/> "Use web feeds! - oscarbenedito.com"
-[TVmaze]: <https://www.tvmaze.com>
-[tv2feed]: </projects/tv2feed/>
-[code]: <https://git.oscarbenedito.com/osf/file/tv2feed.py.html>
diff --git a/content/blog/_index.html b/content/blog/_index.html
@@ -0,0 +1,9 @@
+<!-- title: Personal blog -->
+<!-- description: My personal blog. Subscribe to my web feed if you want to keep up to date! -->
+<!-- feed_title: Oscar's Blog -->
+
+<p>
+ This is my personal blog. You can subscribe to <a href="/blog/index.xml">my feed</a> or look
+ through all the posts on <a href="/blog/archive/">the archive</a>. You can find links to other
+ blogs I follow on <a href="/blogroll/">my blogroll</a>.</p>
+<!-- /p -->
diff --git a/content/blog/_index.md b/content/blog/_index.md
@@ -1,12 +0,0 @@
-<!-- title: Personal blog -->
-<!-- description: My personal blog. Subscribe to my web feed if you want to keep up to date! -->
-<!-- feed_title: Oscar's Blog -->
-
-This is my personal blog. You can subscribe to [my feed][] or look through all
-the posts on [the archive][]. You can find links to other blogs I follow on [my
-blogroll][].
-
-
-[my feed]: </blog/index.xml> "Blog feed"
-[the archive]: </blog/archive/> "Blog archive"
-[my blogroll]: </blogroll/> "Blogroll"
diff --git a/content/blog/categories/cryptography.md b/content/blog/categories/cryptography.html
diff --git a/content/blog/categories/decentralization.md b/content/blog/categories/decentralization.html
diff --git a/content/blog/categories/foss.md b/content/blog/categories/foss.html
diff --git a/content/blog/categories/miscellany.md b/content/blog/categories/miscellany.html
diff --git a/content/blog/categories/personal-domain.md b/content/blog/categories/personal-domain.html
diff --git a/content/blog/categories/privacy.md b/content/blog/categories/privacy.html
diff --git a/content/blog/categories/projects.md b/content/blog/categories/projects.html
diff --git a/content/blog/categories/self-hosting.md b/content/blog/categories/self-hosting.html
diff --git a/content/blogroll.html b/content/blogroll.html
@@ -0,0 +1,27 @@
+<!-- title: Blogroll -->
+
+<p>
+ Blogs I have found interesting, alphabetically sorted. You can easily import all the blogs to your
+ feed reader using <a href="/blogroll/blogroll.ompl">this OMPL file</a>.</p>
+<!-- /p -->
+
+<!-- blogroll -->
+<ul>
+ <li><a href="https://icyphox.sh">Anirudh Oppiliappan (icyphox)</a> — <a href="https://icyphox.sh/blog/feed.xml">Feed</a></li>
+ <li><a href="https://brendan.abolivier.bzh">Brendan Abolivier</a> — <a href="https://brendan.abolivier.bzh/index.xml">Feed</a></li>
+ <li><a href="https://www.codesections.com/blog/">Codesections</a> — <a href="https://www.codesections.com/rss.xml">Feed</a></li>
+ <li><a href="https://chown.me">Daniel Jakots</a> — <a href="https://chown.me/blog/feeds/atom.xml">Feed</a></li>
+ <li><a href="https://www.davd.io">David Prandzioch</a> — <a href="https://www.davd.io/index.xml">Feed</a></li>
+ <li><a href="https://desmondrivet.com/blog/">Desmond Rivet</a> — <a href="https://desmondrivet.com/feeds/blog.rss">Feed</a></li>
+ <li><a href="https://emanuelpina.pt">Emanuel Pina</a> — <a href="https://emanuelpina.pt/index.xml">Feed</a></li>
+ <li><a href="https://hacdias.com/articles/">Henrique Dias</a> — <a href="https://hacdias.com/articles/feed.xml">Feed</a></li>
+ <li><a href="https://www.paritybit.ca/blog">Jake Bauer</a> — <a href="https://www.paritybit.ca/feeds/sitewide-feed.xml">Feed</a></li>
+ <li><a href="https://jlelse.blog">Jan-Lukas Else</a> — <a href="https://jlelse.blog/.rss">Feed</a></li>
+ <li><a href="https://atthis.link">Marc</a> — <a href="https://atthis.link/rss.xml">Feed</a></li>
+ <li><a href="https://mcol.xyz">mcol</a> — <a href="https://mcol.xyz/rss.xml">Feed</a></li>
+ <li><a href="https://mikebabb.com/blog/">Mike Babb</a> — <a href="https://mikebabb.com/feed.xml">Feed</a></li>
+ <li><a href="https://mikestone.me">Mike Stone</a> — <a href="https://mikestone.me/feed.xml">Feed</a></li>
+ <li><a href="https://blog.polynom.me">PapaTutuWawa</a> — <a href="https://blog.polynom.me/atom.xml">Feed</a></li>
+ <li><a href="https://shivering-isles.com/#blog">Sheogorath</a> — <a href="https://shivering-isles.com/feed.xml">Feed</a></li>
+</ul>
+<!-- /blogroll -->
diff --git a/content/blogroll.md b/content/blogroll.md
@@ -1,25 +0,0 @@
-<!-- title: Blogroll -->
-
-Blogs I have found interesting, alphabetically sorted. You can easily import all
-the blogs to your feed reader using [this OMPL file][ompl].
-
-<!-- blogroll -->
-- [Anirudh Oppiliappan (icyphox)](https://icyphox.sh) — [Feed](https://icyphox.sh/blog/feed.xml)
-- [Brendan Abolivier](https://brendan.abolivier.bzh) — [Feed](https://brendan.abolivier.bzh/index.xml)
-- [Codesections](https://www.codesections.com/blog/) — [Feed](https://www.codesections.com/rss.xml)
-- [Daniel Jakots](https://chown.me) — [Feed](https://chown.me/blog/feeds/atom.xml)
-- [David Prandzioch](https://www.davd.io) — [Feed](https://www.davd.io/index.xml)
-- [Desmond Rivet](https://desmondrivet.com/blog/) — [Feed](https://desmondrivet.com/feeds/blog.rss)
-- [Emanuel Pina](https://emanuelpina.pt) — [Feed](https://emanuelpina.pt/index.xml)
-- [Henrique Dias](https://hacdias.com/articles/) — [Feed](https://hacdias.com/articles/feed.xml)
-- [Jake Bauer](https://www.paritybit.ca/blog) — [Feed](https://www.paritybit.ca/feeds/sitewide-feed.xml)
-- [Jan-Lukas Else](https://jlelse.blog) — [Feed](https://jlelse.blog/.rss)
-- [Marc](https://atthis.link) — [Feed](https://atthis.link/rss.xml)
-- [mcol](https://mcol.xyz) — [Feed](https://mcol.xyz/rss.xml)
-- [Mike Babb](https://mikebabb.com/blog/) — [Feed](https://mikebabb.com/feed.xml)
-- [Mike Stone](https://mikestone.me) — [Feed](https://mikestone.me/feed.xml)
-- [PapaTutuWawa](https://blog.polynom.me) — [Feed](https://blog.polynom.me/atom.xml)
-- [Sheogorath](https://shivering-isles.com/#blog) — [Feed](https://shivering-isles.com/feed.xml)
-<!-- /blogroll -->
-
-[ompl]: </blogroll/blogroll.ompl> "Blogroll's OMPL file"
diff --git a/content/contact.html b/content/contact.html
@@ -0,0 +1,20 @@
+<!-- title: Contact -->
+<!-- description: Contact information. -->
+
+<p>You can contact me sending an email to <a href="mailto:oscar@oscarbenedito.com">oscar@oscarbenedito.com</a>.</p>
+
+<h2>Encrypt your message</h2>
+
+<p>
+ If you want to encrypt your message using PGP, you can either use the Web Key Directory standard
+ or get my public key from <a href="/pgp/pubkey.asc" title="Oscar Benedito's public PGP key">this
+ address</a>. My PGP key fingerprint is:</p>
+<!-- /p -->
+
+<pre><code>2D64 7040 7548 446A 3F35 D775 621D 67E0 9F48 82A6</code></pre>
+
+<p>
+ If you don't know how to use PGP but still want to encrypt your message, you can use <a
+ href="https://keyoxide.org/oscar@oscarbenedito.com" title="Keyoxide profile">Keyoxide</a> at your
+ own risk.</p>
+<!-- /p -->
diff --git a/content/contact.md b/content/contact.md
@@ -1,22 +0,0 @@
-<!-- title: Contact -->
-<!-- description: Contact information. -->
-
-You can contact me sending an email to [oscar@oscarbenedito.com][email].
-
-## Encrypt your message
-
-If you want to encrypt your message using PGP, you can either use the Web Key
-Directory standard or get my public key from [this address][key]. My PGP key
-fingerprint is:
-
-```
-2D64 7040 7548 446A 3F35 D775 621D 67E0 9F48 82A6
-```
-
-If you don't know how to use PGP but still want to encrypt your message, you can
-use [Keyoxide][ko] (at your own risk).
-
-
-[email]: <mailto:oscar@oscarbenedito.com>
-[key]: </pgp/pubkey.asc> "Oscar Benedito's public PGP key"
-[ko]: <https://keyoxide.org/oscar@oscarbenedito.com> "Keyoxide profile"
diff --git a/content/projects/tv2feed.html b/content/projects/tv2feed.html
@@ -0,0 +1,65 @@
+<!-- title: TV2Feed -->
+<!-- description: TV2Feed: Follow TV shows using Atom feeds! -->
+
+<p>Follow TV shows using Atom feeds!</p>
+
+<p>
+ TV2Feed is a Python script that creates Atom feeds for TV shows, creating one entry per episode.
+ The script can be found <a href="https://git.oscarbenedito.com/osf/file/tv2feed.py.html">here</a>.
+ For examples of outputs (which are not updated periodically), see <a
+ href="/projects/tv2feed/feed">feed</a> (combined shows feed) or <a
+ href="/projects/tv2feed/show/210">show/210</a> (single show feed).</p>
+<!-- /p -->
+
+<h2>How to use</h2>
+
+<p>
+ Download the script and edit the global variables to your liking. Go to <a
+ href="https://www.tvmaze.com">https://www.tvmaze.com</a> and search the TV shows you want to
+ follow. Write down their IDs (the number in the URL) and then run the following:</p>
+<!-- /p -->
+
+<pre><code>tv2feed id1 id2 ...</code></pre>
+
+<p>Or run it multiple times to get one feed per TV show. The feeds are expected to go under:</p>
+
+<ul>
+ <li><code>https://<domain>/<path>/feed</code>: if multiple shows specified</li>
+ <li><code>https://<domain>/<path>/show/<show_id></code>: if only one show specified</li>
+</ul>
+
+<p>
+ Were <code><domain></code> and <code><path></code> are the values specified on the
+ script variables. That is because the feed URIs will point there. Note that if only one show is
+ specified, TV2Feed will generate it assuming there is one feed per show (which will make the feed
+ title the same as the show's).</p>
+<!-- /p -->
+
+<p>The API where the data is gathered from caches results for one hour, so you can add cron jobs to run every hour:</p>
+
+<pre><code>0 * * * * /usr/local/bin/tv2feed 210 431 > /srv/www/tv2feed/feed</code></pre>
+
+<p>or, alternatively (could also be scripted with just one cronjob):</p>
+
+<pre><code>0 * * * * /usr/local/bin/tv2feed 210 > /srv/www/tv2feed/show/210
+<!-- -->0 * * * * /usr/local/bin/tv2feed 431 > /srv/www/tv2feed/show/431</code></pre>
+
+<h2>Contact</h2>
+
+<p>If you have any questions or there is an edge case I did not account for, please <a href="/contact/">let me know</a>.</p>
+
+<h2>Other notes</h2>
+
+<p>
+ Each show will make two API requests, and there is a limit of 20 requests every 10 seconds (for
+ contents that are not cached). If you are following many shows, this script will sleep for 10
+ seconds and try again if an API call returns a 429 error code, if it fails again (or the error
+ code is not 429), it will raise an error and exit.</p>
+<!-- /p -->
+
+<p>
+ TV2Feed is licensed under the GNU Affero General Public License version 3 or later (available <a
+ href="https://www.gnu.org/licenses/agpl-3.0.html">here</a>).</p>
+<!-- /p -->
+
+<p>All data generated is gathered from <a href="https://www.tvmaze.com">TVmaze</a>'s API.</p>
diff --git a/content/projects/tv2feed.md b/content/projects/tv2feed.md
@@ -1,71 +0,0 @@
-<!-- title: TV2Feed -->
-<!-- description: TV2Feed: Follow TV shows using Atom feeds! -->
-
-Follow TV shows using Atom feeds!
-
-TV2Feed is a Python script that creates Atom feeds for TV shows, creating one
-entry per episode. The script can be found [here][script]. For examples of
-outputs (which are not updated periodically), see [feed][] (combined shows feed)
-or [show/210][showfeed] (single show feed).
-
-## How to use
-
-Download the script and edit the global variables to your liking. Go to
-<https://www.tvmaze.com> and search the TV shows you want to follow. Write down
-their IDs (the number in the URL) and then run the following:
-
-```
-tv2feed id1 id2 ...
-```
-
-Or run it multiple times to get one feed per TV show. The feeds are expected to
-go under:
-
-- `https://<domain>/<path>/feed`: if multiple shows specified
-- `https://<domain>/<path>/show/<show_id>`: if only one show specified
-
-Were `<domain>` and `<path>` are the values specified on the script variables.
-That is because the feed URIs will point there. Note that if only one show is
-specified, TV2Feed will generate it assuming there is one feed per show (which
-will make the feed title the same as the show's).
-
-The API where the data is gathered from caches results for one hour, so you
-can add cron jobs to run every hour:
-
-```
-0 * * * * /usr/local/bin/tv2feed 210 431 > /srv/www/tv2feed/feed
-```
-
-or, alternatively (could also be scripted with just one cronjob):
-
-```
-0 * * * * /usr/local/bin/tv2feed 210 > /srv/www/tv2feed/show/210
-0 * * * * /usr/local/bin/tv2feed 431 > /srv/www/tv2feed/show/431
-```
-
-## Contact
-
-If you have any questions or there is an edge case I did not account for, please
-[let me know][contact].
-
-## Other notes
-
-Each show will make two API requests, and there is a limit of 20 requests every
-10 seconds (for contents that are not cached). If you are following many shows,
-this script will sleep for 10 seconds and try again if an API call returns a 429
-error code, if it fails again (or the error code is not 429), it will raise an
-error and exit.
-
-TV2Feed is licensed under the GNU Affero General Public License version 3 or
-later (available [here][agpl]).
-
-All data generated is gathered from [TVmaze][]'s API.
-
-
-[script]: <https://git.oscarbenedito.com/osf/file/tv2feed.py.html>
-[raw]: <https://git.oscarbenedito.com/osf/raw/tv2feed.py>
-[feed]: </projects/tv2feed/feed>
-[showfeed]: </projects/tv2feed/show/210>
-[contact]: </contact/> "Contact page"
-[agpl]: <https://www.gnu.org/licenses/agpl-3.0.html> "GNU Affero General Public License - GNU Project"
-[TVmaze]: <https://www.tvmaze.com>
diff --git a/gensite.py b/gensite.py
@@ -50,7 +50,6 @@ import glob
import sys
import datetime
import hashlib
-import markdown
def fread(filename):
@@ -167,8 +166,9 @@ def read_content(filename):
text = text[end:]
# convert Markdown content to HTML
- if filename.endswith('.md'):
- text = markdown.markdown(text, extensions=['footnotes', 'fenced_code'])
+ # if filename.endswith('.md'):
+ # import markdown
+ # text = markdown.markdown(text, extensions=['footnotes', 'fenced_code'])
content.update({
'content': text,
@@ -248,16 +248,16 @@ def make_pages(src, dst, layout, blog=False, **params):
def make_lists(posts, dst, l_html, l_html_item, l_feed, l_feed_item, **params):
"""Generate HTML lists and Atom feed for a set of posts."""
- if os.path.isfile('content/' + dst + '_index.md'):
- text = fread('content/' + dst + '_index.md')
+ if os.path.isfile('content/' + dst + '_index.html'):
+ text = fread('content/' + dst + '_index.html')
else:
- text = fread('content/' + dst[:-1] + '.md')
+ text = fread('content/' + dst[:-1] + '.html')
end = 0
for key, val, end in read_headers(text):
params[key] = val
- params['intro'] = markdown.markdown(text[end:], extensions=['footnotes', 'fenced_code'])
+ params['intro'] = text[end:]
# make HTML lists
ipp = 5 # items per page
@@ -393,7 +393,7 @@ def main():
item_xml = fread('layouts/item.xml')
# create site pages
- make_pages('content/_index.md', '', l_page, **params)
+ make_pages('content/_index.html', '', l_page, **params)
make_pages('content/[!_]*.*', '{{ slug }}/', l_page, **params)
make_pages('content/projects/[!_]*.*', 'projects/{{ slug }}/', l_page, **params)
fwrite('404.html', render(fread('layouts/404.html'), **params))
diff --git a/misc/update-blogroll.py b/misc/update-blogroll.py
@@ -23,7 +23,7 @@ tree = xml.etree.ElementTree.parse('misc/blogroll.ompl')
root = tree.getroot()
blogs = []
-for category in root[0]:
+for category in root[1]:
if category.attrib['text'] == 'Blogroll':
for entry in category:
blogs.append({
@@ -36,25 +36,25 @@ for category in root[0]:
ompl = '<?xml version="1.0" encoding="utf-8"?>\n<opml version="1.0">\n' \
' <head>\n <title>Oscar Benedito\'s Blogroll</title>\n </head>\n' \
' <body>\n <outline text="Oscar Benedito\'s Blogroll">\n'
-md = '<!-- blogroll -->\n'
+md = '<!-- blogroll -->\n<ul>\n'
ompl_item = ' <outline type="rss" text="{}" xmlUrl="{}" htmlUrl="{}" />\n'
-md_item = '- [{}]({}) — [Feed]({})\n'
+md_item = ' <li><a href="{}">{}</a> — <a href="{}">Feed</a></li>\n'
for blog in sorted(blogs, key=lambda i: i['text'].lower()):
ompl += ompl_item.format(blog['text'], blog['feed'], blog['html'])
- md += md_item.format(blog['text'], blog['html'], blog['feed'])
+ md += md_item.format(blog['html'], blog['text'], blog['feed'])
ompl += ' </outline>\n </body>\n</opml>\n'
-md += '<!-- /blogroll -->'
+md += '</ul>\n<!-- /blogroll -->'
with open('static/blogroll/blogroll.ompl', 'w') as f:
f.write(ompl)
-with open('content/blogroll.md', 'r') as f:
+with open('content/blogroll.html', 'r') as f:
text = f.read()
text = re.sub('<!-- blogroll -->.*<!-- /blogroll -->', md, text, flags=re.DOTALL)
-with open('content/blogroll.md', 'w') as f:
+with open('content/blogroll.html', 'w') as f:
f.write(text)
