Update notebook with Linux-related notes

notebook/cli.youtube-dl.org

@@ -3,7 +3,7 @@
 :END:
 #+title: Command-line: youtube-dl
 #+date: "2021-07-08 17:36:26 +08:00"
-#+date_modified: "2021-07-28 14:38:09 +08:00"
+#+date_modified: "2022-04-22 11:25:43 +08:00"
 #+language: en
 #+property: header-args  :eval no
 
@@ -11,6 +11,9 @@
 One of the archivists' best friends.
 At least you don't have to go to those shady YouTube conversion sites anymore when you have a [[https://ytdl-org.github.io/youtube-dl/supportedsites.html][complete list of other video sites]] you can download from.
 
+Take note, I use [[https://github.com/yt-dlp/yt-dlp][yt-dlp]].
+Any yt-dlp-specific options should be in the appropriate note.
+
 For complete information, you can always inspect =youtube-dl.1= manual page.
 
 
@@ -35,30 +38,21 @@ youtube-dl [OPTIONS...] [URLS...]
 - =--audio-quality QUALITY= sets the quality of the audio from 0 to 9, best to worst respectively;
   bitrates are also accepted (e.g., =320K=, =1M=)
 
-- =-c, --continue= resumes the download;
-  useful if the download process is interrupted
+- =--date RANGE= finds videos that are uploaded from a certain date range.
+  See the [[Date ranges]] section to see the format required.
 
-- =--config-location PATH= set the config to be used;
-  useful for local configs with specific options
-
-- =-F, --list-format= prints a list of format available for downloading
+- =--dateafter RANGE= and =--datebefore RANGE= is a similar option to =--date= but to find videos before or after the specified date range, respectively.
+  Accepts the same format as =--date=.
 
 - =--list-extractors= prints a list of supported sites and their specific features.
 
 - =--format QUALITY= downloads the video with the format shown in =--list-format=;
   there are convenient options such as =bestaudio= and =bestvideo= referring to the best quality it could find
 
-- =--match-title REGEX= downloads only with the matched titles;
-  for the inverse operation, =--reject-title REGEX=
-
-- =-j, --dump-json= completes a dry-run and prints in JSON format
-
 - =-o, --output STRING= formats the resulting filename of the tracks to be downloaded
 
 - =--no-overwrite= throws an error if the file already exists which is handy for scripts
 
-- =--write-sub= writes the subtitle file into disk
-
 - =-x, --extract-audio= extracts only the audio track
 
 
@@ -77,6 +71,7 @@ A few of the usual stuff I use:
 
 - =title= (string) is the title of the track
 - =ext= (string) is the extension to be used; pretty much recommended to use it
+- =creator= (string) and =uploader= (string)
 
 A lot of the things I have to do is to download multiple tracks from an album or playlist.
 Unfortunately, these are often different from one site to another.
@@ -87,6 +82,17 @@ Unfortunately, these are often different from one site to another.
   Usually, these are used from Bandcamp and Vimeo playlists.
 
 
+** Date ranges
+
+The options =--date= and the like accept a certain format for date ranges in =(now|today)[-|+][\\d+](day|week|month|year)s?= or =YYYYMMDD= for absolute date.
+
+| Example       | Description                    |
+|---------------+--------------------------------|
+| =now-2weeks=  | From today to 2 weeks ago.     |
+| =today+3days= | From today to 3 days from now. |
+| =20000505=    | Equivalent to =2000-05-05=.    |
+
+
 
 
 * Examples
@@ -125,3 +131,14 @@ This is will only succeed if the format is available to download which you can d
 #+begin_src shell
 youtube-dl --format 'bestvideo[width=1080,ext=mp4]+bestaudio[abr=320K,ext=opus]' https://www.youtube.com/watch?v=wy9VvdaLuSs
 #+end_src
+
+
+** Check the first 50 videos at certain date range
+
+In this example, I want to download videos from [[roam:David Revoy]]'s YouTube channel that uploaded up to 2 months ago while checking only the first 50 videos.
+This is a useful template especially if the channel has a large selection of videos.
+Also useful if you're checking for videos daily to mitigate against potential bans from overusing it.
+
+#+begin_src shell
+youtube-dl --playlist-end 50 --dateafter 'today-2weeks' "https://www.youtube.com/c/DavidRevoy"
+#+end_src

notebook/cloud.github-actions.org

@@ -3,7 +3,7 @@
 :END:
 #+title: GitHub Actions
 #+date: "2021-06-20 18:58:48 +08:00"
-#+date_modified: "2022-01-05 22:37:05 +08:00"
+#+date_modified: "2022-06-19 11:46:41 +08:00"
 #+language: en
 
 
@@ -42,7 +42,10 @@
 
 * Actions
 
-- each of the job is mostly built with the actions
+- each of the job is mostly built with the actions;
+  the job can be controlled further through the workflow file;
+  see the [[https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions][Workflow Syntax]] for more information
+- related information such as the current branch, runners specifics, and so forth are stored in [[https://docs.github.com/en/actions/learn-github-actions/contexts][Contexts]]
 - like previously mentioned, you can search these actions in GitHub's marketplace
 - the actions are primarily defined with =actions.yml= from the root which can serve as a documentation for the parameters
 
@@ -73,7 +76,16 @@ jobs:
 
 ** Docker container integration
 
-In this case, we'll push an image to docker.io registry.
+GitHub workflows can make use of containers for easier delivering of dependencies and reproducing the development environment (among other things).
+This includes...
+
+- [[https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry][GitHub's own container registry]],
+- [[https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer][using a container to be used in a workflow]] which is nice for building for multiple operating systems (e.g., multiple Linux distros)
+- [[https://docs.github.com/en/actions/using-containerized-services/about-service-containers][service containers]] to make use of tools to your workflow,
+- and even [[https://docs.github.com/en/actions/publishing-packages/publishing-docker-images][publishing containers to a registry from a workflow]].
+
+In this example, we'll push an image to docker.io registry.
+Be sure to have the necessary credentials and set it to the workflow environment to successfully run this workflow.
 
 #+begin_src yaml  :tangle (my/concat-assets-folder "docker-image.yaml")
 name: Docker build image
@@ -107,7 +119,7 @@ jobs:
 
 ** Building a Nix binary cache
 
-We'll use [[id:366aeb8f-5a84-40c8-bf16-a919639790ab][Cachix]] as our binary cache service.
+We'll use [[id:366aeb8f-5a84-40c8-bf16-a919639790ab][Cachix]] as our binary cache service which has a free 10GB space (as of 2022-06-19).
 This makes it easier to setup and distribute your own project built with [[id:3b3fdcbf-eb40-4c89-81f3-9d937a0be53c][Nix package manager]].
 
 #+begin_src yaml  :tangle (my/concat-assets-folder "cachix-build.yaml")
@@ -132,7 +144,9 @@ jobs:
 #+end_src
 
 
-** Multiple jobs with matrix
+** Building packages in multiple architectures
+
+This makes use of job matrix allowing to easily create similar workflows with different configurations.
 
 We'll use the GitHub Actions workflow file from the NUR template.
 It is somewhat complex and it is doing a fine job showcasing some of GitHub Actions features.
@@ -143,35 +157,18 @@ on:
   pull_request:
   push:
   schedule:
-    # rebuild everyday at 2:51
-    # TIP: Choose a random time here so not all repositories are build at once:
-    # https://www.random.org/clock-times/?num=1&earliest=01%3A00&latest=08%3A00&interval=5&format=html&rnd=new
     - cron:  '27 4 * * *'
 jobs:
   tests:
     strategy:
       matrix:
-        # Set this to notify the global nur package registry that changes are
-        # available.
-        #
-        # The repo name as used in
-        # https://github.com/nix-community/NUR/blob/master/repos.json
         nurRepo:
           - '<YOUR_NUR_REPO>'
-        # Set this to cache your build results in cachix for faster builds
-        # in CI and for everyone who uses your cache.
-        #
-        # Format: Your cachix cache host name without the ".cachix.org" suffix.
-        # Example: mycache (for mycache.cachix.org)
-        #
-        # For this to work, you also need to set the CACHIX_SIGNING_KEY secret
-        # in your repository settings in Github found at https://github.com/<your_githubname>/nur-packages/settings/secrets
         cachixName:
           - '<YOUR_CACHIX_NAME>'
         nixPath:
           - nixpkgs=channel:nixos-unstable
           - nixpkgs=channel:nixpkgs-unstable
-          - nixpkgs=channel:nixos-21.05
     runs-on: ubuntu-latest
     steps:
     - name: Checkout repository
@@ -198,7 +195,6 @@ jobs:
           -I nixpkgs=$(nix-instantiate --find-file nixpkgs) \
           -I $PWD
     - name: Build nix packages
-      # TODO switch to default nixpkgs channel once nix-build-uncached 1.0.0 is in stable
       run: nix run -I 'nixpkgs=channel:nixos-unstable' nixpkgs.nix-build-uncached -c nix-build-uncached ci.nix -A cacheOutputs
     - name: Trigger NUR update
       if: ${{ matrix.nurRepo != <YOUR_NUR_REPO>' }}

notebook/cookbook.bash.percent-encoding.org

@@ -3,12 +3,13 @@
 :END:
 #+title: Percent encoding in Bash
 #+date: "2021-06-23 21:10:33 +08:00"
-#+date_modified: "2021-07-01 13:46:04 +08:00"
+#+date_modified: "2022-04-16 20:17:53 +08:00"
 #+language: en
 
 
 Percent-encoding is commonly used in URLs.
 Pretty nice especially when used with spaces.
+Though, this is something that is rarely needed in [[id:dd9d3ffa-03ff-42a1-8c5d-55dc9fcc70fe][GNU Bash]] except if you're writing a quick script.
 
 Based from [[https://gist.github.com/cdown/1163649][this implementation]].
 It was modified to be closer to the output from [[https://docs.python.org/3.8/library/urllib.parse.html#urllib.parse.urlencode][Python =urlencode=]].

notebook/linux.all-distros-are-their-own.org

@@ -0,0 +1,32 @@
+:PROPERTIES:
+:ID:       c64836f4-19db-4da7-8532-4ebacf6c1ed1
+:END:
+#+title: How all Linux distros are technically operating systems of their own
+#+date: 2022-05-22 21:02:46 +08:00
+#+date_modified: 2022-06-19 12:10:16 +08:00
+#+language: en
+
+
+In all technicality, Linux distributions (distros) are their own operating system.
+Linux distros have one thing in common: the Linux kernel.
+
+It just so happens that most Linux distros follow certain standards such as the Filesystem hierarchy standard (FHS), some Freedesktop standards, some POSIX standards, and similarly placed files from packages that makes them compatible... for the most part.
+This also contributes to the public consciousness of presenting different Linux distros as a collective single thing.
+Whether or not this can be misleading is another question (see [[id:a8c6f23f-d642-4cf6-abe2-edcf054f1823][Does presenting Linux distributions as a single thing proves beneficial for newcomers?]]).
+
+Even by then, some of them follow the standard differently with their own tweaks ranging from subtle difference to distinct modifications.
+
+- Linux distros such as [[id:7e8e83d5-4b08-44f6-800d-a322f6960a62][NixOS]] and [[roam:Guix system]] throws the FHS completely.
+
+- Other Linux distros such as roam:GoboLinux redefines the FHS completely considering user-friendliness by making the filesystem as the database itself.
+
+- Several software have been patched differently on several Linux distributions.
+  [[roam:Fedora Linux]], for example, has patches on Firefox that eventually made their way upstream.
+  [[roam:Debian Linux]]
+
+- Ecosystems move at a different pace with different focus.
+  [[id:f3f1201a-9fb9-4481-981f-5f50f8982a5e][Arch Linux]], for example, takes the pragmatic approach with an up-to-date list of software.
+  [[roam:Fedora Linux]], as another example, is heading towards futuristic approaches for application development with a bias for Red Hat-backed products (e.g., roam:Flatpak, [[id:20830b22-9e55-42a6-9cef-62a1697ea63d][systemd]]).
+
+A lot of the distros are made by small pockets of communities that also interacts with the rest of the ecosystem.
+This is where [[id:31c16009-b965-4288-8654-93a404c0961c][Collaboration through competition]] manifests from parallel efforts.

notebook/linux.distros.nixos.org

@@ -0,0 +1,23 @@
+:PROPERTIES:
+:ID:       7e8e83d5-4b08-44f6-800d-a322f6960a62
+:END:
+#+title: NixOS
+#+date: 2021-08-28 17:11:24 +08:00
+#+date_modified: 2022-05-22 21:23:19 +08:00
+#+language: en
+
+
+- an operating system that uses [[id:3b3fdcbf-eb40-4c89-81f3-9d937a0be53c][Nix package manager]] as the core component to build a whole operating system;
+  this make NixOS as an image-based operating system similar to [[roam:Fedora Silverblue]], roam:MicroOS, and [[roam:Endless OS]]
+- despite being mentioned to the aforementioned image-based operating systems, it isn't an immutable system;
+  NixOS itself is not immutable as you can still interact with the system just like with traditional Linux-based OS;
+  most of the system is set up by the package manager which does have an inherent property of being immutable but this doesn't make NixOS an immutable system
+- most of the workflow and ecosystem comes from the central repository for any Nix-related system: roam:nixpkgs;
+  it is where most of the [[roam:NixOS modules]] come from
+- it isn't really like the traditional Linux distros that you'll see as it has made decisions that can majorly affect how you daily-drive the system
+  - the Filesystem Hierarchy Standard (FHS) is nowhere to be found;
+    there is only the =/bin/sh= and =/usr/bin/env= which is there for convenience purposes which is nice if you rely on some scripts
+  - the absence of the FHS alone has some implications;
+    one of them is the inability to run precompiled binaries (including AppImages which rely on system libraries) since most of them rely on the files that are expected to be present in the traditional distros like Debian and Fedora
+  - because of the non-existent FHS, you have to compile and/or create a derivation for that project;
+    workarounds exists for certain situations like AppImages and programs that expects a system with FHS but you still have to create a Nix package for it

notebook/linux.why-a-unified-linux-distro-is-a-bad-idea.org

@@ -0,0 +1,33 @@
+:PROPERTIES:
+:ID:       9612e378-6d3f-4871-8fcf-03fe17691c55
+:END:
+#+title: Why wishing a unified Linux distro is a pointless task
+#+date: 2022-06-19 12:02:03 +08:00
+#+date_modified: 2022-06-19 12:07:17 +08:00
+#+language: en
+
+
+There's nothing wrong with wishful thinking but time and time again I've seen the complaint from other Linux users' frustrating wishful thinking how they wish all developers would stop developing more Linux distros and instead focus on one.
+The following list shows why it could be a bad idea.
+
+- Each Linux distro is its own project.
+  See [[id:c64836f4-19db-4da7-8532-4ebacf6c1ed1][How Linux distributions are technically their own operating system]].
+
+- Consequently, different projects also promote different philosophies.
+  Disagreements between projects will inevitably happen.
+  For example, [[id:f3f1201a-9fb9-4481-981f-5f50f8982a5e][Arch Linux]] represents simplicity, modernity (up-to-date packages), and pragmatism (accepting both free and non-free software) where it would contrast with roam:Debian with their mission to create a free operating system and stability.
+
+- With so many projects, there a chance one of them might get popular enough.
+  Just like what happened with some projects like Zorin OS initially created by two teenagers tackling their first computer science project and to make a more accessible version of Ubuntu for their parents.
+
+- [[id:d885e93b-f919-4338-a6b9-3438538e18c0][Every copy of the techniques is personalized]];
+  different people have different idea and understanding how to implement something.
+  Most ideas might just get stuck in a discussion by people disagreeing on one unified way, prompting people to implement it with a separate project (and rendering the unified distro development pointless).
+
+- A lot of the projects are run by volunteers.
+  What's to interest them from helping developing other distributions if they were forced to help?
+
+- This is the least important reason but Linux-based operating systems are [[id:e8c1218f-35a4-4dd3-a174-5d8f848b74b2][Free software]] therefore promoting the idea of [[id:d73e539c-5bf5-4853-99bb-ac95dd52fbc3][Openness makes diversity]].
+  There's nothing stopping someone from exploring other ideas that may or may not have been explored before.
+
+The closest thing to unify them is major distributions and projects such as [[id:20830b22-9e55-42a6-9cef-62a1697ea63d][systemd]] and roam:FreeDesktop standards.