Using 3rd party packages for Powershell Install-Module

It make sense by default if you download 3rd party powershell packages like kbupdate, it should not run right away until you’ve done your due dilligence. You’ll get a warning like this during installation:

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from 'PSGallery'?

But when I try to use it, I get an error message:

Get-KbUpdate : The 'Get-KbUpdate' command was found in the module 'kbupdate', but the module could not be loaded. For more information, run 'Import-Module kbupdate'.

Import-Module gives a cryptic message like this:

Import-Module : Errors occurred while loading the format data file:
D:\Administrator\Documents\WindowsPowerShell\Modules\PSFramework\1.6.214\xml\PSFramework.Format.ps1xml, ,
D:\Administrator\Documents\WindowsPowerShell\Modules\PSFramework\1.6.214\xml\PSFramework.Format.ps1xml: The file was
skipped because of the following validation exception: File
D:\Administrator\Documents\WindowsPowerShell\Modules\PSFramework\1.6.214\xml\PSFramework.Format.ps1xml cannot be
loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at

Turns out either the package needs to be marked safe or just stop checking altogether:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted


Text manipulation idioms in linux

awk: select columns
sed: stream editor (operations like select, substitute, add/delete lines, modify)
sed expressions can be separated by ";"
sed can substitute all occurrences with 'g' modified at the end: 's/(find)/(replace)/g'


# arg I/O
$@: unpack all input args
$*: join all inputs as ONE arg, separated by FIRST character of IFS (empty space if unspecified)

# Remember the double quotes around "$*" or "$array[*]" usages or else IFS won't function

array[@]: entire array
${array[@]}: unpacks entire array into MULTIPLE arguments
${array[*]}: join entire array into ONE argument separated by FIRST character of IFS (defaults to an empty space if unspecified)
( IFS=$'\n'; echo "${my_array[*]}" )

${#str}: length of string
${#array[@]}: length of array
${#array[@]:start:after_stop}: select array[start] ... array[after_stop-1]

${str:="my_string"}: initializes variable str with "my_string" (useful for side-effect)

$(str##my_pattern}: delete front matching my_pattern
${str%%my_pattern}: deletes tail matching my_pattern (can use one % instead)
$(str%?}: delete last character (the my_pattern is a single character wildcard "?")

$( whatever_command ): captures stdout created by running whatever_command
( $str ): tokenize to string array, governed by IFS (specify delimiter)
( $( whatever_command ) ): combines the two operations above: capture stdout from command and tokenize the results

function strjoin { local IFS="$1"; shift; echo "$*"; }


Auto mount USB drives

Raspbian OS (Raspberry Pi) do not mount USB drives automatically out of the box.

I’m pretty annoyed by the lack of easy to use packages by 2021 and I still have to do it myself with the instructions here:

These are cookbook instructions, but I’ll add some insights to what each component means so it’s easier to remember the steps.

At top level, to auto-detect and mount USB drives, we need the following components

  • udev: analogous to what happens behind device manager, it keeps track of and updates devices as they are connected and disconnected immediately. Need to register USB sticks by adding a event handler, which triggers a systemd service (see below)
  • systemd: analogous to Windows’ services. Need to register the service by stating what commands it will call on start (mostly mounting) and cleanup (mostly unmounting)
  • automount script: it’s a user defined script that abstracts most of the hard work detecting the partitions on the USB stick, assign the mount point names, and mount them
# Register udev event handler (rules)
# /etc/udev/rules.d/usbstick.rules

ACTION=="add", KERNEL=="sd[a-z][0-9]", TAG+="systemd", ENV{SYSTEMD_WANTS}="usbstick-handler@%k"

# It triggers a systemd call to "usbstick-handler@" service registered under /etc/systemd/system/
# Register systemd service
# /etc/systemd/system/usbstick-handler@.service
# (Note: instructions used /lib instead of /etc. It's better to add it as /etc as this is manually registered as user-defined service rather than from a package)

Description=Mount USB sticks

ExecStart=/usr/local/bin/automount %I
ExecStop=/usr/bin/pumount /dev/%I

# %I is the USB stick's device name under /dev, usually sda
# Abstracted the logic of determining the mount point name and mounting to 'automount' (see below)

Create the file /usr/local/bin/automount and give it execution permission: chmod +x /usr/local/bin/automount


# $1 (first argument) is usually "sda" (supposedly USB stick device name) seen from %I in the systemd service commands

# Within the "sda" (USB stick device of interest), extract the partition labels (if applicable) from lsblk command. The first column (name) is dropped
FS_LABEL=`lsblk -o name,label | grep ${PART} | awk '{print $2}'`

# Decide the mount point name {partition label}_{partition name}
# e.g. MS-DOS_sda1
MOUNT_LABEL=$(IFS='_'; echo "${tokens[*]}")
# Using string array makes it easier to drop the prefix if there's no {partition label}
# Bash use IFS to specify separators for listing all elements of the array

# Suggestion: drop --sync for faster USB access (if you can umount properly)
/usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${MOUNT_LABEL}

This automount script is adapted from with my improvements.


Descriptive names for logic operations on a pair (x, y)

It reads as “The output is TRUE only when the reduction (x,y)\rightarrow z meets the description of the operations below”

0 inputs:

  • Constant: gives the same hard-coded result regardless of inputs

1 input:

  • Transfer: Hardwired to one of the inputs
  • Complement: NOT

2 inputs (symmetric):

  • Comparison: different (XOR), identical (NXOR or equivalence)
  • Arithmetic: AND, OR and its complements NAND, NOR

2 inputs (asymmetric):

  • Inhibition: ONLY 1 followed by 0 is an inhibition. It’s a WHITE-list: anything else is not an inhibition (starting with 0 doesn’t inhibit)
  • Implication: ANYTHING GOES as long as 1 is be followed by 1. It’s a BLACK-list: anything else qualifies as an implication (starting with 0 does not break the implication)

Implication is the complement of Inhibition, as the only case that breaks an implication is inhibition.

This ‘operator’ instead of truth-table view is more often used in electrical engineering than in computer science. There are many names for the same thing, but I put in some thought to find the intuitive words to make it easy to understand and remember

WARNING: Those there are tempting faint similarities between logic and set theory, there’s no direct tight duality between the two. Whitelist/Blacklist in inhibition/implication do not make sense with set-diff/subset as we are talking about a one-shot relationship here in logic, while set theory talks about the relationship between elements picked after it is quantified by “for all” vs “there is”. i.e. Truth table do not mix with sets


Experimental Worldview Framework Desires x Problems x Mechanisms x Device

I am experimenting with a framework to summarize how I observe things that are going on around me, analyzing situations and coming up with solution approaches. Currently this is what I have:

{Desires} × {Problems} × {Mechanisms} × {Devices}

Everything I see can be analyzed as a result of the cross-product (a fancy word for combinations of contents) between these 4 broad categories. To make it easier to remember, they can be factored into 2 major categories:

{Questions} × {Answers}

Where obviously

  • [Questions] Desires (objectives) lead to problems (practicalities) to solve
  • [Answers] Mechanisms (abstract concepts) hosted by a device (implementation) to address questions

Why the cross product? By tabulating everything I learned or know in 4 columns (categories), I can always select a few of them (subset) and notice a lot of recurring themes (questions) and common solution approaches (answers). This corresponds to an old saying “there’s nothing new under the sun”.

Then what about innovations? Are we constantly creating something new? Yes, we still are, but if you look closely, there are very few ideas that are fundamentally new that cannot be synthesized by combining the old ones (sometimes recursively).

Let me use the framework itself as an example on how to apply this framework (yes, it’s recursive):

  • Desires: predict and understand many phenomenon
  • Problems: mental capacity is limited
  • Mechanisms: this framework (breaking observations into 4 categories)
  • Devices: tabulation (cross-products, order reduction)

Feedback as an example:

  • Desires: have good outcomes (or meet set objectives)
  • Problems: not there yet
  • Mechanism: take advantage of past data for future outputs (through correction)
  • Devices: feedback path (e.g. regulator or control systems.)

Feedforward as an example that shares a lot of properties as feedback:

  • Desires: have good outcomes (or meet set objectives)
  • Problems: not there yet
  • Mechanism: take advantage of past data for future outputs (through prediction)
  • Devices: predictor (e.g. algorithm or formula)

Abstraction as an example:

  • Desires: understand complexities (e.g. large code base)
  • Problems: limited mental capacity (programmers are humans after all)
  • Mechanism: abstraction (generic view grouping similar ideas together)
  • Devices: black-boxes (e.g. functions, classes)

Trade as an example:

  • Desires: improves utility (utility = happiness in economics lingo)
  • Problems: one cannot do everything on its own (limited capacity)
  • Mechanism: exchange competitive advantages
  • Devices: market (goods and services)

Business as an example:

  • Desires: improves utility (through trade)
  • Problems: need to offer something for trade
  • Mechanism: create value
  • Devices: operations

Money (and Markets) as two examples:

  • Desires: facilitate trade
  • Problems: difficult valuation and transfer through barter, decentralized
  • Mechanism: a common medium
  • Devices: money (currencies), markets (platform for trade)

Law as an example:

  • Desires: make the pie bigger by working cooperatively
  • Problems: every individual tries to maximize their own interest but mentally too limited to consider working together to grow the pie (pareto efficient solutions)
  • Mechanism: set rules and boundaries (I personally think it’s a sloppy patch fix that is way overused and way abused) and get everybody to buy it
  • Devices: law and enforcement

Religion as an example

  • Desires: coexist peacefully
  • Problems: irreconcilable differences
  • Mechanism: blind unverified trust (faith)
  • Devices: Deities and religion

Just with the examples above, many desires can be consolidated along the lines of making ourselves better off, and many problems can be consolidated along the lines of we’re too stupid. Of course it’s not everything, but it shows the power of tabulating into 4 categories and consolidating the parts into few unique themes.

I chose to abstract the framework into 4 broad categories instead of 2 because two are too simplified to be useful: since the framework is a way to organize (compactify) observations into manageable number of unique items, there will be too many distinct entries if I have only two categories. Nonetheless, I would refrain from having more than 7 categories because most humans cannot reason effectively with that many levels of nested for-loops (that’s what cross products boils down to).

I also separated desires from problems because I realized that way too often people (manager, clients, customers, government, etc.) ask the wrong question (because they narrowed it to the wrong problem) that leads to a lot of wasted work and frequent direction changes. People are too often asked to solve hard problems that turns out to be the wrong ones for fulfilling the motivating desires. Very few learn to trace it back to the source (desires) and find the correct problem to address, which often have easy solutions that’s more valuable to the requester than what was originally asked. This often leads to unhappy outcomes for everybody that’s avoidable. An emphasis on desires is one of my frequently used approaches to prevent these kind of mishaps.