Compare commits
18 Commits
3b04aaf8be
...
master
Author | SHA1 | Date | |
---|---|---|---|
3dface826f
|
|||
a55712032b
|
|||
33a959fcea
|
|||
4ed4c87acf
|
|||
68f9eb2a7d
|
|||
c407e8be9e
|
|||
f52b241dc2
|
|||
c0755da29f
|
|||
c3afb4b562
|
|||
f5b3d969fd
|
|||
7e2487f0d3
|
|||
3fec180a14
|
|||
c08ad6f175
|
|||
1a17ffda7f
|
|||
556dba6f29
|
|||
b7a79951c5
|
|||
2d95304da4
|
|||
8e64f8f58e
|
1
Makefile
1
Makefile
@@ -38,6 +38,7 @@ $(databases): .dbs/%.rec: %/ | .dbs/
|
||||
|
||||
# This two-variable read can only happen because of the quotes in the titles.
|
||||
db.rec: $(databases)
|
||||
$(warning rebuilding from $? )
|
||||
printf '%s\n' '%rec: guide' > $@
|
||||
printf '%s\n' '%key: title' >> $@
|
||||
printf '%s\n' '%type: requires rec guide' >> $@
|
||||
|
@@ -44,6 +44,8 @@ They should not assume the reader knows much beyond common terminal commands, an
|
||||
People should be able to read an article from the beginning, then keep going until the end, and then stop.
|
||||
Articles should not take a detour through a chain of other articles of unknown size.
|
||||
|
||||
[Do not Jaquays documentation](https://splint.rs/posts/no_links)
|
||||
|
||||
## Be Opinionated
|
||||
|
||||
- Guides should not ask the reader to select options half-way through.
|
||||
|
@@ -6,36 +6,40 @@ tags: [ "data" ]
|
||||
|
||||
## New Machines
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git config --global user.email "$YOUR_EMAIL"
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git config --global user.name "$YOUR_NAME"
|
||||
```
|
||||
|
||||
# New Git
|
||||
|
||||
Start a git in directory `$DIR`:
|
||||
Decide on algorithm:
|
||||
|
||||
```bash
|
||||
mkdir $DIR && cd $DIR
|
||||
```
|
||||
- If you're scared of insecure hash-sums, go with `hash=sha256`.
|
||||
- If you don't know what a hash sum is, go with `hash=sha1`.
|
||||
|
||||
```bash
|
||||
git init
|
||||
## Init the Git
|
||||
|
||||
Start a git in directory `${DIR}`:
|
||||
|
||||
```sh
|
||||
git init --object-format=${hash} ${DIR}
|
||||
cd ${DIR}
|
||||
```
|
||||
|
||||
Make a file explaining what the project does, and tell `git` to track it:
|
||||
|
||||
```bash
|
||||
echo "I hereby solemnly swear never to commit a binary." > README.md
|
||||
```sh
|
||||
echo "I hereby solemnly swear never to commit a binary file." > README.md
|
||||
git add README.md
|
||||
```
|
||||
|
||||
Then make the initial commit, explaining the change you just made:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git commit
|
||||
```
|
||||
|
||||
@@ -43,17 +47,17 @@ git commit
|
||||
|
||||
Once you make a change to some file, add it and make a commit explaining it.
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git add $FILE
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git commit -m"change $FILE"
|
||||
```
|
||||
|
||||
Check your history:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git log
|
||||
```
|
||||
|
||||
@@ -64,20 +68,20 @@ Give it the same name as the `$DIR` directory, above.
|
||||
|
||||
Add this as a remote:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
REMOTE=gitlab
|
||||
git remote add $REMOTE https://gitlab.com/$USERNAME/$DIR
|
||||
```
|
||||
|
||||
Tell git you're pushing the branch "master" to the remote repo "origin":
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git push -u master origin
|
||||
```
|
||||
|
||||
If someone makes a change on the remote, pull it down with:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git pull
|
||||
```
|
||||
|
||||
@@ -86,31 +90,31 @@ git pull
|
||||
A branch is a full copy of the project to test additional ideas.
|
||||
You can make a new branch called 'featurez' like this:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git branch $FEATURE_BRANCH
|
||||
```
|
||||
|
||||
Have a look at all your branches:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git branch
|
||||
```
|
||||
|
||||
Switch to your new branch:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git checkout $FEATURE_BRANCH
|
||||
```
|
||||
|
||||
And if your changes are rubbish, checkout the "master" branch again, then delete "featurez":
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git branch -D $FEATURE_BRANCH
|
||||
```
|
||||
|
||||
Or if it's a good branch, push it to the remote:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
remote=origin
|
||||
git push $remote $FEATURE_BRANCH
|
||||
```
|
||||
@@ -119,13 +123,13 @@ git push $remote $FEATURE_BRANCH
|
||||
|
||||
Once you like the feature, merge it into the main branch. Switch to master then merge it:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git merge $FEATURE_BRANCH
|
||||
```
|
||||
|
||||
And delete the branch, as you've already merged it:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git branch -d $FEATURE_BRANCH
|
||||
```
|
||||
|
||||
@@ -133,7 +137,7 @@ git branch -d $FEATURE_BRANCH
|
||||
|
||||
## Pulling another git repo into a subtree
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git subtree add -P config git@gitlab.com:bindrpg/config.git master
|
||||
```
|
||||
|
||||
@@ -141,27 +145,27 @@ git subtree add -P config git@gitlab.com:bindrpg/config.git master
|
||||
|
||||
## Delete All History
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git checkout --orphan temp
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git add -A
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git commit -am "release the commits!"
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git branch -D master
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git branch -m master
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git push -f origin master
|
||||
```
|
||||
|
||||
@@ -169,21 +173,21 @@ Gitlab requires more changes, such as going to `settings > repository` and switc
|
||||
|
||||
## Clean up Bloated Repo
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git fsck --full
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git gc --prune=now --aggressive
|
||||
```
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git repack
|
||||
```
|
||||
|
||||
## Find Binary Blobs
|
||||
|
||||
```bash
|
||||
```sh
|
||||
git rev-list --objects --all \
|
||||
| git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
|
||||
| sed -n 's/^blob //p' \
|
||||
|
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: "git-lfs"
|
||||
tags: [ "data", "git" ]
|
||||
requires: [ "git" ]
|
||||
---
|
||||
|
||||
Git Large File Storage ('LFS') needs to change your `~/.gitconfig` to check out those binary files:
|
||||
|
69
data/git/git_stash.md
Normal file
69
data/git/git_stash.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: "git stash"
|
||||
tags: [ "data", "git" ]
|
||||
requires: [ "git" ]
|
||||
---
|
||||
|
||||
Save file-changes without committing anything.
|
||||
|
||||
Change a file:
|
||||
|
||||
```sh
|
||||
file=README.md
|
||||
fortune >> ${file}
|
||||
git diff
|
||||
git stash save
|
||||
```
|
||||
|
||||
List which stashes you have:
|
||||
|
||||
|
||||
```sh
|
||||
git stash list
|
||||
|
||||
stash@{1}: WIP on master: c21f102 init git
|
||||
```
|
||||
|
||||
Make a new file, then stash it:
|
||||
|
||||
|
||||
```sh
|
||||
otherfile=file.log
|
||||
fortune > ${otherfile}
|
||||
git add ${otherfile}
|
||||
stashname=logfile
|
||||
git stash save ${stashname}
|
||||
```
|
||||
|
||||
Now you can see two stashed changes, and the most recent has a name:
|
||||
|
||||
```sh
|
||||
git stash list
|
||||
|
||||
stash@{0}: On master: logfile
|
||||
stash@{1}: WIP on master: c21f102 init git
|
||||
```
|
||||
|
||||
You can delete a stash by referring to its index number, or name (if it has one).
|
||||
|
||||
```sh
|
||||
choice=1
|
||||
git stash drop ${choice}
|
||||
|
||||
choice=${stashname}
|
||||
git stash drop ${choice}
|
||||
```
|
||||
|
||||
Or just run `git stash drop` to remove the most recent (labelled `{0}`).
|
||||
|
||||
Return stashed changes with an index number (or the most recent).
|
||||
|
||||
```sh
|
||||
git stash pop ${choice}
|
||||
```
|
||||
|
||||
Delete all stashes:
|
||||
|
||||
```sh
|
||||
git stash clear
|
||||
```
|
13
data/json.md
Normal file
13
data/json.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: "ijq"
|
||||
tags: [ "data", "json", "TUI" ]
|
||||
---
|
||||
|
||||
Analyse `json` easier with `ijq`.
|
||||
|
||||
```sh
|
||||
column -J -ts: -H PW,GID,shell -N User,PW,UID,GID,Description,Home,shell /etc/passwd > host.json
|
||||
ijq !$
|
||||
```
|
||||
|
||||
If you get stuck, try adding `.[]`.
|
34
data/task/contexts.md
Normal file
34
data/task/contexts.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Taskwarrior Contexts"
|
||||
tags: [ "data", "task" ]
|
||||
requires: [ "Taskwarrior" ]
|
||||
---
|
||||
|
||||
# Contexts
|
||||
|
||||
Set three contexts by their tags:
|
||||
|
||||
```sh
|
||||
task context define work +sa or +hr
|
||||
```
|
||||
|
||||
```sh
|
||||
task context define study +ed or +void or +rat
|
||||
```
|
||||
|
||||
```sh
|
||||
task context define home -sa -hr -ed -void -rat
|
||||
```
|
||||
|
||||
Change to the first context.
|
||||
|
||||
```sh
|
||||
task context work
|
||||
```
|
||||
|
||||
Then stop.
|
||||
|
||||
```sh
|
||||
task context none
|
||||
```
|
||||
|
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: "task"
|
||||
tags: [ "organization" ]
|
||||
title: "Taskwarrior"
|
||||
tags: [ "data", "organization" ]
|
||||
---
|
||||
|
||||
Set up the configuration file:
|
||||
@@ -9,6 +9,18 @@ Set up the configuration file:
|
||||
task
|
||||
```
|
||||
|
||||
Taskwarrior published a new feature to synchronize tasks others, but the feature was not ready.
|
||||
The server's default installation instructions assume that users pay for hosting services.
|
||||
All listed providers run proprietary software and actively support genocide.
|
||||
|
||||
|
||||
To ignore the synchronization, tell the configuration file to use a local synchronization file.
|
||||
|
||||
```
|
||||
task config sync.local.server_dir
|
||||
task config data.location ~/.local/state/
|
||||
```
|
||||
|
||||
Add a task:
|
||||
|
||||
```sh
|
||||
@@ -44,18 +56,16 @@ task add project:house buy potted plant
|
||||
task add proj:house.repair buy screwdriver
|
||||
task add proj:house.repair buy shelf brackets
|
||||
task add pro:house.paint buy white paint
|
||||
task add pro:house.paint buy red paint
|
||||
task add pro:house.paint buy black paint
|
||||
task add pro:house.paint buy brushes
|
||||
|
||||
for t in "buy red paint" "buy black paint" "buy brushes" ; do
|
||||
task add pro:house.paint $t
|
||||
done
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
```sh
|
||||
task pro:house sum
|
||||
```
|
||||
|
||||
```sh
|
||||
task burndown.daily pro:house
|
||||
```
|
||||
|
||||
@@ -63,44 +73,12 @@ The summaries will show how fast a project is being completed, and when you can
|
||||
|
||||
# Tags
|
||||
|
||||
|
||||
```sh
|
||||
task add +buy toothbrush
|
||||
```
|
||||
|
||||
You can then see only tasks which involve buying something with:
|
||||
|
||||
```sh
|
||||
task +buy
|
||||
```
|
||||
|
||||
# Contexts
|
||||
|
||||
Set three contexts by their tags:
|
||||
|
||||
```sh
|
||||
task context define work +sa or +hr
|
||||
```
|
||||
|
||||
```sh
|
||||
task context define study +ed or +void or +rat
|
||||
```
|
||||
|
||||
```sh
|
||||
task context define home -sa -hr -ed -void -rat
|
||||
```
|
||||
|
||||
Change to the first context.
|
||||
|
||||
```sh
|
||||
task context work
|
||||
```
|
||||
|
||||
Then stop.
|
||||
|
||||
```sh
|
||||
task context none
|
||||
```
|
||||
|
||||
# Review
|
||||
|
||||
View list of tasks completed in the last week:
|
||||
@@ -111,21 +89,17 @@ task end.after:today-1wk completed
|
||||
|
||||
# User Defined Attributes
|
||||
|
||||
Make a UDA 'size'.
|
||||
Define a new attribute for tasks called 'size'.
|
||||
The 'user defined attribute' (UDA) needs a `type` and `label`.
|
||||
|
||||
```sh
|
||||
task config uda.size.type string
|
||||
```
|
||||
|
||||
```sh
|
||||
task config uda.size.label Size
|
||||
```
|
||||
You can also ensure task tasks can only be `large`, `medium`, or `small`, then set a default.
|
||||
|
||||
```sh
|
||||
task config uda.size.values large,medium,small
|
||||
```
|
||||
|
||||
```sh
|
||||
uda.size.default=medium
|
||||
```
|
||||
|
20
data/task/taskwarrior_configuration.md
Normal file
20
data/task/taskwarrior_configuration.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Taskwarrior Configuration"
|
||||
tags: [ "data", "task" ]
|
||||
requires: [ "Taskwarrior" ]
|
||||
---
|
||||
|
||||
Show your current config:
|
||||
|
||||
|
||||
```sh
|
||||
task show
|
||||
```
|
||||
|
||||
Use machine-readable output to make a config file with all configuration keys shown, then make it your configuration file.
|
||||
|
||||
```sh
|
||||
task _show > ${file}
|
||||
mv ${file} ~/.config/task/taskrc
|
||||
```
|
||||
|
25
networking/port_scan.md
Normal file
25
networking/port_scan.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Port Scan"
|
||||
tags: [ "networking" ]
|
||||
repo: 'https://github.com/mrjackwills/havn/'
|
||||
---
|
||||
|
||||
`havn` scans ports.
|
||||
It's not in many repos, but if you can `cargo install havn`.
|
||||
|
||||
|
||||
```sh
|
||||
havn -h
|
||||
havn -a
|
||||
domain=splint.rs
|
||||
havn -p 19-90 ${domain}
|
||||
```
|
||||
|
||||
That last command doesn't work reliably, so increase the number of retries (`-r`), or decrease concurrent requests (`-c`).
|
||||
|
||||
|
||||
```sh
|
||||
havn -p 19-443 -r 6 ${domain}
|
||||
havn -p 1-1000 -c 500 -r 5 ${domain}
|
||||
```
|
||||
|
114
system/ansible/ansible_with_docker.md
Normal file
114
system/ansible/ansible_with_docker.md
Normal file
@@ -0,0 +1,114 @@
|
||||
---
|
||||
title: "Ansible with Docker"
|
||||
tags: [ "system", "ansible", "docker" ]
|
||||
requires: [ "Docker" ]
|
||||
---
|
||||
|
||||
Set up two containers: `deb` and `arch`, add them to an `ansible` hosts file, then do a 'ping' to see if they respond.
|
||||
|
||||
## Required Packages
|
||||
|
||||
- `ansible`
|
||||
- `jq`
|
||||
- `docker`
|
||||
|
||||
## Debian Container
|
||||
|
||||
```sh
|
||||
docker run -di --rm --name deb --hostname deb debian
|
||||
docker exec -it deb sh -c 'apt update && apt -y install openssh-server python3 sudo'
|
||||
```
|
||||
|
||||
Generate the host's ssh keys, then start the ssh daemon:
|
||||
|
||||
```sh
|
||||
docker exec -it deb sh -c 'ssh-keygen -A'
|
||||
docker exec -d deb /usr/sbin/sshd -D
|
||||
```
|
||||
|
||||
## Arch Linux Container
|
||||
|
||||
```sh
|
||||
docker run -di --rm --name arch --hostname arch archlinux
|
||||
docker exec -it arch sh -c 'pacman -Syu --noconfirm python sudo openssh'
|
||||
docker exec -it arch sh -c 'ssh-keygen -A'
|
||||
docker exec -d arch /usr/sbin/sshd -D
|
||||
```
|
||||
|
||||
## `ssh` Keys
|
||||
|
||||
Copy across your public ssh key to the container's `authorized_keys` file:
|
||||
|
||||
```sh
|
||||
pubkey=~/.ssh/id_rsa.pub
|
||||
for hostname in arch deb; do
|
||||
docker cp $pubkey $hostname:/root/.ssh/authorized_keys
|
||||
docker exec -it $hostname sh -c "chown -R root:root /root/.ssh/"
|
||||
docker exec -it $hostname sh -c "chmod -R 700 /root/.ssh/"
|
||||
done
|
||||
```
|
||||
|
||||
## Hosts File
|
||||
|
||||
Find name of containers' IPv4 addresses.
|
||||
|
||||
```sh
|
||||
docker network inspect bridge
|
||||
```
|
||||
|
||||
The output is awful.
|
||||
Use `jq` to parse the `json`:
|
||||
|
||||
```sh
|
||||
docker network inspect bridge | jq -r '.[].Containers | .[].IPv4Address'
|
||||
```
|
||||
|
||||
Now put those into a host file:
|
||||
|
||||
```sh
|
||||
docker_hosts=hosts.txt
|
||||
echo '[containers]' > $docker_hosts
|
||||
|
||||
docker network inspect bridge | \
|
||||
jq -r '.[].Containers | .[] | "root@" + .IPv4Address' | \
|
||||
cut -d/ -f1 >> $docker_hosts
|
||||
```
|
||||
|
||||
You may need to add those host keys to your known hosts file.
|
||||
Either connect interactively, or (for scripts):
|
||||
|
||||
```sh
|
||||
hosts="$(docker network inspect bridge | jq -r '.[].Containers | .[] | .Name + " " + .IPv4Address' | \
|
||||
cut -d/ -f1)"
|
||||
|
||||
echo "$hosts"
|
||||
|
||||
echo "$hosts" | while read hostname ip; do
|
||||
printf "%s" "$ip"
|
||||
key="$(docker exec $hostname cat /etc/ssh/ssh_host_ed25519_key.pub)"
|
||||
echo "$ip $key" >> ~/.ssh/known_hosts
|
||||
done
|
||||
```
|
||||
|
||||
Check if they ping:
|
||||
|
||||
```sh
|
||||
ansible -i $docker_hosts all -m ping
|
||||
```
|
||||
|
||||
This command produces an irritating warning about the python interpreter (i.e., `python3`).
|
||||
|
||||
Make the warning shut-up:
|
||||
|
||||
```sh
|
||||
echo '
|
||||
[containers:vars]
|
||||
ansible_python_interpreter=/usr/bin/python3.13' >> $docker_hosts
|
||||
```
|
||||
|
||||
Now the ping is cleaner:
|
||||
|
||||
```sh
|
||||
ansible -i $docker_hosts all -m ping
|
||||
```
|
||||
|
@@ -1,4 +1,3 @@
|
||||
|
||||
---
|
||||
title: "Makefile Patterns"
|
||||
tags: [ "system", "make" ]
|
98
system/makefiles/python_projects.md
Normal file
98
system/makefiles/python_projects.md
Normal file
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: "Python Projects with Makefiles"
|
||||
tags: [ "tutorial", "system", "makefiles", "graphviz", "python" ]
|
||||
requires: [ "Makefiles" ]
|
||||
---
|
||||
|
||||
If you have a python script which requires a packages - e.g. `graphviz` - you can automate the setup with a `Makefile`.
|
||||
The `Makefile` will:
|
||||
|
||||
1. Make three copies of an 8-line installer script.
|
||||
2. Use one of the installer script to install local packages.
|
||||
3. Install a symbolic link to python.
|
||||
3. Make a script called `activate`, which tells python to use
|
||||
|
||||
# Context
|
||||
|
||||
Python coders don't like updating their projects, they just expect everyone to install the same version of everything that they have.
|
||||
Historically, people dealt with this by installing only half a dozen copies of `graphviz`; but now each python project uses a local environment, with a local copy of `graphviz`, which means everyone gets to install a new copy of `graphviz` every time they try out a project.
|
||||
|
||||
Downloading 40MB of software for each 40-line script you write is called 'virtual environments' because it sounds cool.
|
||||
We can make it even cooler with `make`, but not yet, because python - like the fae of old - will not fetch anything until you know its true name.
|
||||
|
||||
# Setup
|
||||
|
||||
```sh
|
||||
command -v python
|
||||
realpath `!!`
|
||||
```
|
||||
|
||||
You must reveal that true path, because `python` is always a relative symbolic link, to an absolute symbolic link, which leads to a shortcut.
|
||||
We can finally let `make` know how to invoke python, and where it will install `graphviz`.
|
||||
|
||||
If your python's version is '3.14', then python needs its packages placed in `${somewhere}/lib/python3.14/site-packages/`.
|
||||
You must create a new, local, name for these packages, because - like the fey of old - python demands a private name in return for revealing its true name.
|
||||
|
||||
I'll call mine `camelot`, because the path is long and arduous.
|
||||
Set up the Makefiles like this:
|
||||
|
||||
```make
|
||||
py_link != command -v python
|
||||
py != realpath $(py_link)
|
||||
version != basename $(py)
|
||||
|
||||
virtenv = camelot
|
||||
```
|
||||
|
||||
Now you can ask for a local `pip` script, which can install the python packages:
|
||||
|
||||
```make
|
||||
[...]
|
||||
|
||||
$(virtenv)/bin/pip:
|
||||
$(py) -m venv $(virtenv)
|
||||
```
|
||||
|
||||
Finally, list the packages you want in `requirements.txt`, and make `pip` install from it.
|
||||
|
||||
|
||||
```sh
|
||||
ppkg=graphviz
|
||||
echo ${ppkg} > requirements.txt
|
||||
```
|
||||
|
||||
```make
|
||||
[...]
|
||||
|
||||
pkgs = $(virtenv)/lib/$(version)/site-packages/
|
||||
|
||||
$(pkgs): $(virtenv)/bin/pip
|
||||
$(pkgs): requirements.txt
|
||||
$(virtenv)/bin/pip install -r $<
|
||||
```
|
||||
|
||||
The complete Makefile looks like this:
|
||||
|
||||
|
||||
```make
|
||||
all: .default
|
||||
|
||||
py_link != command -v python
|
||||
py != realpath $(py_link)
|
||||
version != basename $(py)
|
||||
|
||||
virtenv = camelot
|
||||
|
||||
$(virtenv)/bin/pip:
|
||||
$(py) -m venv $(virtenv)
|
||||
|
||||
pkgs = $(virtenv)/lib/$(version)/site-packages/
|
||||
|
||||
$(pkgs): $(virtenv)/bin/pip
|
||||
$(pkgs): requirements.txt
|
||||
$(virtenv)/bin/pip install -r $<
|
||||
|
||||
.PHONY: .default
|
||||
.default: $(pkgs)
|
||||
```
|
||||
|
@@ -17,10 +17,10 @@ Remove yourself from all groups, and add yourself back to only `wheel`, `audio`,
|
||||
sudo usermod --groups wheel,audio,$USER
|
||||
```
|
||||
|
||||
Add yourself to the `wheel` group:
|
||||
Add yourself to the `docker` group:
|
||||
|
||||
```sh
|
||||
su root -c "usermod --append --groups wheel $USER"
|
||||
su root -c "usermod --append --groups docker $USER"
|
||||
```
|
||||
Add yourself to the `network` group:
|
||||
|
||||
@@ -28,5 +28,11 @@ Add yourself to the `network` group:
|
||||
sudo usermod -aG network $USER
|
||||
```
|
||||
|
||||
The changes will not take effect until you log in again, so reboot or log into `localhost` with [ssh](../networking/ssh.md).
|
||||
The changes have not taken effect, so log into your own account again with `su`:
|
||||
|
||||
|
||||
```sh
|
||||
groups
|
||||
sudo su $USER
|
||||
groups
|
||||
```
|
||||
|
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: "Docker"
|
||||
tags: [ "documentation", "virtualization" ]
|
||||
requires: [ "Managing Groups" ]
|
||||
---
|
||||
```sh
|
||||
sudo pacman -S docker
|
||||
|
@@ -10,7 +10,7 @@ ffmpeg -i [input file] output_file.mkv
|
||||
|
||||
The input file might be a device, such as a camera.
|
||||
|
||||
#Record screen
|
||||
# Record screen
|
||||
|
||||
Take the format as 'grab the x11 screen'.
|
||||
|
||||
@@ -30,7 +30,8 @@ or maybe just...
|
||||
ffmpeg -f x11grab -s "$(xdpyinfo | grep dimensions | awk '{print $2}')" -i :1.0 out.mkv
|
||||
```
|
||||
|
||||
#Add default pulse audio
|
||||
# Add default pulse audio
|
||||
|
||||
```bash
|
||||
ffmpeg -f x11grab -s [screensize] -i :0.0 -f alsa -i default out.mkv
|
||||
```
|
||||
|
22
vision/make_a_gif.md
Normal file
22
vision/make_a_gif.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Make a gif"
|
||||
tags: [ "vision" ]
|
||||
---
|
||||
|
||||
Split your video into frames.
|
||||
|
||||
```sh
|
||||
d=$(mktemp -d)
|
||||
cp $vid.mp4 $d
|
||||
cd $d
|
||||
|
||||
ffmpeg -i $vid.mp4 -vf "fps=10, scale=360:-1" frame%04d.png
|
||||
gifski --fps 10 -o ${out}.gif frame*.png
|
||||
```
|
||||
|
||||
Optimize:
|
||||
|
||||
```sh
|
||||
gifsicle --optimize=3 --lossy=100 -o ${final}.gif ${out}.gif
|
||||
```
|
||||
|
12
writing/tex/calendar.md
Normal file
12
writing/tex/calendar.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Calendar"
|
||||
tags: [ "writing", "tex", "fun" ]
|
||||
requires: [ "LaTeX Packages" ]
|
||||
---
|
||||
|
||||
```sh
|
||||
yplan $(date +%Y) > ${file}.tex
|
||||
pdflatex -output-directory=/tmp/ ${file}.tex
|
||||
mv /tmp/${file}.pdf .
|
||||
```
|
||||
|
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "LaTeX Setup the Hard Way"
|
||||
title: "LaTeX Packages"
|
||||
tags: [ "writing" ]
|
||||
---
|
||||
|
||||
@@ -21,7 +21,7 @@ ls /opt/texlive/${YEAR}/texmf-dist/scripts/texlive/tlmgr.pl
|
||||
```
|
||||
|
||||
Double-check the year.
|
||||
It should *not* match the real year, it should match the `texlive`.
|
||||
It should *not* match the current year, it should match the `texlive`.
|
||||
|
||||
## Problems along the Path
|
||||
|
@@ -3,13 +3,14 @@ title: "vim basics"
|
||||
tags: [ "vim", "basic" ]
|
||||
---
|
||||
|
||||
1. Insert text by pressing `i`.
|
||||
1. Insert text by pressing `a`.
|
||||
1. Stop inserting text by pressing `Ctrl+[`.
|
||||
1. Exit with `ZZ`.
|
||||
1. Congratulations, you now know `vim`.
|
||||
|
||||
## Extras
|
||||
|
||||
- [Learning Vim](vim/vi.md)
|
||||
- [Navigation](vim/navigate.md)
|
||||
- [Completion](vim/completion.md)
|
||||
- [Search](vim/search.md)
|
||||
|
46
writing/vim/vi.md
Normal file
46
writing/vim/vi.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "How to Learn `vim`"
|
||||
tags: [ "vim", "learning" ]
|
||||
requires: [ "vim basics" ]
|
||||
---
|
||||
|
||||
1. Uninstall `vim`.
|
||||
1. Install `vi`.
|
||||
1. Write a few blog posts.
|
||||
|
||||
The [ancient wisdom](https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118) is correct - everyone should start with `vi`.
|
||||
But the standard wisdom fails to mention writing.
|
||||
So people just 'try to remember', then they edit a couple of configuration files with `vim`, then stop, because it's a pain to think about keystrokes while thinking about how the configuration file works.
|
||||
Nobody can learn like that.
|
||||
|
||||
Learn with a blog, or writing emails in `vim`, or writing anything, as long as it's *real writing*.
|
||||
Write a journal or some recipes.
|
||||
Write literally anything which is written in paragraphs.
|
||||
|
||||
And while you're writing, remember one rule: if you want something, `vi` can do it, you just need to look up how.
|
||||
|
||||
Blog first, then try out some of these commands:
|
||||
|
||||
- `hjkl`
|
||||
- `x`
|
||||
- `:!grep very %`
|
||||
- `onew line<Esc>...`
|
||||
- `Onew line<Esc>...`
|
||||
- `~`
|
||||
- `~~~~`
|
||||
- `$r!`
|
||||
- `w %-2`
|
||||
- `x!`
|
||||
- `0RTipex`
|
||||
- `_4rX`
|
||||
- `bc2e`
|
||||
- `c2E`
|
||||
- `cw`
|
||||
- `cW`
|
||||
- `ci'`
|
||||
- `zz`
|
||||
- `:set number`
|
||||
- `:set nonumber`
|
||||
- `:set relativenumber`
|
||||
- `:set number relativenumber`
|
||||
|
Reference in New Issue
Block a user