From a45c0929daac4075e9d1705398ed7e7c969a651c Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Tue, 13 Oct 2020 10:08:36 -0300 Subject: s/etc./*etc.*/g --- ...12-21-using-youtube-dl-to-manage-youtube-subscriptions.md | 4 ++-- _articles/2019-06-02-stateless-os.md | 2 +- _articles/2020-08-31-the-database-i-wish-i-had.md | 12 ++++++------ .../2020-10-05-swift2nix-run-swift-inside-nix-builds.md | 4 ++-- ...-send-emails-using-the-command-line-for-fun-and-profit.md | 2 +- 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! -- cgit v1.2.3