s/etc./*etc.*/g

5 files changed, 12 insertions, 12 deletions

diff --git a/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md b/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md
index a9a605b..34b0c63 100644
--- a/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md
+++ b/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md
@@ -25,7 +25,7 @@ privacy](https://staltz.com/what-happens-when-you-block-internet-giants.html):
 > full control of how much they can know about me. I don't want to be in
 > autopilot mode. (...) Which leads us to YouTube. While I was able to
 > find alternatives to Gmail (Fastmail), Calendar (Fastmail), Translate
-> (Yandex Translate), etc, YouTube remains as the most indispensable
+> (Yandex Translate), *etc.* YouTube remains as the most indispensable
 > Google-owned web service. It is really really hard to avoid consuming
 > YouTube content. It was probably the smartest startup acquisition
 > ever. My privacy-oriented alternative is to watch YouTube videos
@@ -254,7 +254,7 @@ without filling your disk with gigabytes of content all at once.
 The `download_playlist` function could be aware of the specific machine
 that it is running on and apply specific policies depending on the
 machine: always download everything; only download videos that aren't
-present anywhere else; etc.
+present anywhere else; *etc.*
 
 ## Conclusion
 
diff --git a/_articles/2019-06-02-stateless-os.md b/_articles/2019-06-02-stateless-os.md
index 2614b44..eae470a 100644
--- a/_articles/2019-06-02-stateless-os.md
+++ b/_articles/2019-06-02-stateless-os.md
@@ -125,7 +125,7 @@ manager](https://nixos.org/nix/) (not the whole NixOS) on your current
 distribution (it can live alongside any other package manager).
 
 If you have experience with declarative Emacs package managements, GNU
-Stow or any similar tool, etc., [I'd like some
+Stow or any similar tool, *etc.*, [I'd like some
 tips](mailto:eu@euandre.org). If you don't have any experience at all,
 [I'd still love to hear from you](mailto:eu@euandre.org).
 
diff --git a/_articles/2020-08-31-the-database-i-wish-i-had.md b/_articles/2020-08-31-the-database-i-wish-i-had.md
index 004a558..a134e2c 100644
--- a/_articles/2020-08-31-the-database-i-wish-i-had.md
+++ b/_articles/2020-08-31-the-database-i-wish-i-had.md
@@ -48,7 +48,7 @@ Let's go over what I mean by each of those aspects one by one.
 I think the server-side database landscape is diverse and mature enough for
 my needs (even though I end up choosing SQLite most of the time), and what I'm
 after is a database to be embedded on client-side applications itself, be it
-desktop, browser, mobile, etc.
+desktop, browser, mobile, *etc.*
 
 The purpose of such database is not to keep some local cache of data in case of
 lost connectivity: we have good solutions for that already. It should serve as
@@ -84,13 +84,13 @@ that would have to be emulated~~[^posix-sqlite].
     page. SQLite still is an implementation of a update-in-place, SQL,
     table-oriented database. It is probably true that cherry-picking the
     relevant parts of SQLite (like storage access, consistency, crash recovery,
-    parser generator, etc.) and leaving out the unwanted parts (SQL, tables,
-    threading, etc.) would be better than including the full SQLite stack, but
+    parser generator, *etc.*) and leaving out the unwanted parts (SQL, tables,
+    threading, *etc.*) would be better than including the full SQLite stack, but
     that's simply an optimization. Both could even coexist, if desired.
 
     SQLite would have to be treated similarly to how Datomic treats SQL
     databases: instead of having a table for each entities, spread attributes
-    over the tables, etc., it treats SQL databases as a key-value storage so it
+    over the tables, *etc.*, it treats SQL databases as a key-value storage so it
     doesn't have to re-implement interacting with the disk that other databases
     do well.
 
@@ -107,7 +107,7 @@ Node.js. However I want a tool that can be deployed anywhere, and not limit its
 applications to places that already have a JavaScript runtime environment, or
 force the developer to bundle a JavaScript runtime environment with their
 application. This is true for GTK+ applications, command line programs, Android
-apps, etc.
+apps, *etc.*
 
 [pouchdb]: https://pouchdb.com/
 [couchdb]: https://couchdb.apache.org/
@@ -133,7 +133,7 @@ This would allow the database to adapt to where it is embedded: when targeting
 the browser the IndexedDB storage API would provide the persistence layer
 that the database requires, and similarly the POSIX filesystem storage API would
 provide the persistence layer when targeting POSIX systems (like desktops,
-mobile, etc.).
+mobile, *etc.*).
 
 But there's also an extra restriction that comes from by being embedded: it
 needs to provide and embeddable artifact, most likely a binary library object
diff --git a/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md b/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
index 7960b8b..dad4334 100644
--- a/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
+++ b/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
@@ -119,7 +119,7 @@ Instead a much saner approach could be:
    filesystem layout with dependencies (i.e. exposing what the package manager
    expects to find), let's call it `local-registry.json`;
 4. if a `local-registry.json` was provided, do a build using that. Otherwise
-   generate its own, by downloading the dependencies, arranging them, etc.
+   generate its own, by downloading the dependencies, arranging them, *etc.*
 
 The point is just making what the package manager requires visible to the
 outside world via some declarative data. If this data wasn't provided, it can
@@ -185,7 +185,7 @@ Package managers should provide exact dependencies via a data representation,
 i.e. lockfiles, and expose via another data representation how they expect those
 dependencies to appear on the filesystem, i.e. `local-registry.json`. This
 allows package managers to provide an API so that external tools can create
-mirrors, offline builds, other registries, isolated builds, etc.
+mirrors, offline builds, other registries, isolated builds, *etc.*
 
 "\*2nix" tools should build simple functions that leverage that
 `local-registry.json`[^local-registry] data and offload all the rest back to the
diff --git a/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md b/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md
index 4a0e4a0..320f3ab 100644
--- a/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md
+++ b/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md
@@ -8,7 +8,7 @@ ref: send-emails-using-the-command-line-for-fun-and-profit
 Here are a few reasons why:
 
 1. send yourself and other people notification of cronjobs, scripts runs, CI
-   jobs, etc.
+   jobs, *etc.*
 
 2. leverage the POSIX pipe `|`, and pipe emails away!