Update Linux-related notes

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

@@ -3,7 +3,7 @@
 :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
+#+date_modified: 2022-06-19 12:52:58 +08:00
 #+language: en
 
 
@@ -20,13 +20,15 @@ Even by then, some of them follow the standard differently with their own tweaks
 
 - 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]]
+- Different Linux distributions have different policies on certain things.
+  [[roam:Debian Linux]] is a major example of this with the packages modified to suit Debian's packaging policies.
+  This makes usage a bit differently: you're not using a web server in a traditional Linux way, you're using it in Debian's way.
+  [[roam:Fedora Linux]] is an example of trying to follow upstream as close as possible.
 
 - 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]]).
+  [[roam:Debian Linux]] is focused on stability.
 
 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

@@ -3,7 +3,7 @@
 :END:
 #+title: NixOS
 #+date: 2021-08-28 17:11:24 +08:00
-#+date_modified: 2022-05-22 21:23:19 +08:00
+#+date_modified: 2022-07-15 21:06:54 +08:00
 #+language: en
 
 
@@ -21,3 +21,19 @@
     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
+
+* Benefits of NixOS
+:PROPERTIES:
+:ID:       97b63788-e8b3-42d2-81f0-76b85b6aaf65
+:END:
+- one of the nicest advantage of Nix-based systems is having hermetic builds;
+  this means that configurations are made only from the package manager;
+  with Nix being the way it is, all of its files come from the Nix store which contains unique versions of different packages and inputs (derivations);
+  in practice, configuration are applied by building it first by the package manager then symlinking the output from the store to various points in the filesystem;
+- coming from the sysadmin perspective, hermetic builds means it has mitigations against configuration drifts;
+  - in roam:Ansible, configurations are applied by processes which can leave files behind;
+    while it can keep track of changes and processes are usually idempotent, Ansible doesn't deal with removed changes which means manual intervention and a potential configuration drift;
+    in short, Ansible looks more of a task runner than a configuration framework
+  - in Nix-based systems, configurations are built and then applied over the system by the package manager as an atomic update;
+    having the configuration seen as one output by the package manager means removed changes are not much of a problem since they are part of another output which can be reapplied if those changes are needed
+    additionally, Nix keeps track of the configurations through generations

notebook/linux.systemd.org

@@ -3,7 +3,7 @@
 :END:
 #+title: systemd
 #+date: "2021-05-20 22:37:22 +08:00"
-#+date_modified: "2022-04-19 20:21:56 +08:00"
+#+date_modified: "2022-09-29 12:21:34 +08:00"
 #+language: en
 #+property: header-args  :eval no
 
@@ -53,7 +53,16 @@ systemctl --user start $SERVICE
 
 
 
-* Extra information
+* Navigating systemd documentation
+:PROPERTIES:
+:ID:       352629df-916a-442a-b81c-af71ef34a475
+:END:
+
+Because of the wide scope of the tool, it is best to know where you can find certain information.
+Here's an exhaustive list of the locations.
+
+- Most sensible distributions should include the manual pages from the software.
+  systemd has a lot of them from knowing [[id:f1b21fc8-86a5-47cd-b3d8-da6ac7a34427][systemd timers]] at =systemd.timers.5=, the unit formats and their locations at =systemd.unit.5=.
 
 - =systemd.directives.7= is an index of configuration directives including unit keys, environment variables, and command line options for systemd-related things.
   Also contains the related manual pages for a deeper references.
@@ -61,5 +70,18 @@ systemctl --user start $SERVICE
 
 - On a similar note, =systemd.index.7= is an alphabetical index of the important keywords found in systemd.
 
+
+
+
+
+* Extra information
+
 - =systemd.mount= units require the filename to be the mountpoint.
   Though, it has to be converted to what systemd accepts (e.g., =systemd-escape --path $PATH=).
+
+- systemd has a few usual units such as =default.target= which is a target for the current environment of the user.
+  It can be get with =systemctl get-default= command.
+  More can be seen with =systemd.special.7= from the manual.
+
+- Not all units are equal as systemd treats some units specially.
+  You can see what these specific units are and what it does with =systemd.special.7= from the manual.

notebook/linux.systemd.transient-units.org

@@ -3,13 +3,13 @@
 :END:
 #+title: systemd transient units
 #+date: 2021-08-02 12:01:49 +08:00
-#+date_modified: 2022-04-16 20:01:51 +08:00
+#+date_modified: 2022-09-20 19:44:14 +08:00
 #+language: en
 
 
 You can create units on-the-go with =systemd-run=.
 Very useful for quickly creating and scheduling one-off services.
-This tool mainly involves [[id:cd5f0d04-d9bb-44e8-a0f2-630ea58c1e94][systemd services]] and [[id:f1b21fc8-86a5-47cd-b3d8-da6ac7a34427][systemd timers]].
+Among other things, this can easily create [[id:cd5f0d04-d9bb-44e8-a0f2-630ea58c1e94][systemd services]], [[id:f1b21fc8-86a5-47cd-b3d8-da6ac7a34427][systemd timers]], and [[roam:systemd path units]] which can be interacted with systemd tools as usual.
 
 Like most systemd-related binaries, this can be run at system- and user-level (see [[id:c7edff80-6dea-47fc-8ecd-e43b5ab8fb1e][systemd at user-level]]).
 
@@ -17,8 +17,14 @@ Like most systemd-related binaries, this can be run at system- and user-level (s
 # This will create a user-level service file with the given command as the task.
 systemd-run --user borgmatic --config emergency-config.yaml --verbose
 
-# Create a transient timer for the service.
-systemd-run --user borg-backup@external-drive.service --on-calendar=12:00
+# Create a transient timer for a unit.  This is useful for one-off scheduling
+# for a certain service.
+systemd-run --user --unit borg-backup@external-drive.service --on-calendar=12:00
+
+# Create a transient path unit. This is useful for situations such as debugging
+# configurations that is being used by a service. Take note, it does not
+# properly escape unit specifiers and will not be considered an absolute path.
+systemd-run --user --unit bspwm.service --path-property="PathChanged=${XDG_CONFIG_HOME}/bspwmrc"
 #+end_src
 
 The result should give you the generated name of the unit.