migrated to markdown. Deleted scripts in favor of justfile.
This commit is contained in:
parent
48b0facc76
commit
e763ca78ed
|
|
@ -4,12 +4,15 @@ type = 'about'
|
|||
showToc = false
|
||||
+++
|
||||
|
||||
=== Hi There!
|
||||
### Hi There!
|
||||
|
||||
Im Gabe Venberg.
|
||||
|
||||
Professionally, Im a newly minted computer scientist, with interest in embedded software, OS development (and anything backend, really), and strongly typed languages (🦀).
|
||||
|
||||
_Unprofessionally_, Im a general nerd, ever tinkering on my 3d printer, learning basic electrical engineering, managing my self-hosted cloud, and reading *_way_* too many sci-fi books.
|
||||
*Unprofessionally*, Im a general nerd, ever tinkering on my 3d printer,
|
||||
learning embedded systems programming,
|
||||
building split keyboards,
|
||||
managing my self-hosted cloud, and reading **way** too many sci-fi books.
|
||||
|
||||
For my would-be assassins, you can generally find me in the Fargo, North Dakota area.
|
||||
|
|
@ -3,13 +3,6 @@ title = "Archlinux install with btrfs, systemd-boot, full-disk encryption, and s
|
|||
date = 2021-04-11T19:19:51-05:00
|
||||
draft = false
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 6
|
||||
|
||||
Ive been using Arch Linux for several years now.
|
||||
Of course, my first installs were... blunderous, as i wanted to do full disk encryption from the get-go, and I didnt know what I was doing.
|
||||
|
|
@ -23,7 +16,7 @@ With my newest laptop, I decided to try out btrfs, in large part due to its snap
|
|||
However, suspend-to-disk is also quite important to me, and the Arch Wiki is really only clear on how to do that with unencrypted partitions, LVM on LUKS, and on swapfiles.
|
||||
The archwiki has some info on how to do it for the encrypt hook with a custom mkinitcpio hook, or with sd-encrypt hooks by just specifying multiple devices, but I didnt want to be writing a ton of custom config for the encrypt hook, and the section on sd-encrypt was not very clear at all, so I decided to do some experimentation and write up what worked for me.
|
||||
|
||||
== A note on security and risk profiles
|
||||
## A note on security and risk profiles
|
||||
|
||||
The encryption schema I am setting up in this guide is only meant to protect your data from theft of your physical device when it is turned off or suspended to the disk.
|
||||
Full disk encryption will not protect you from anything while you laptop is powered on. After boot, the encryption is completely transparent to userspace.
|
||||
|
|
@ -33,7 +26,7 @@ This means that an attacker could hypothetically replace your boot partition or
|
|||
|
||||
To reiterate, this setup by itself only protect your data if your powered down machine is stolen. It does not protect you data from being stolen in any scenario where your laptop is powered on during tampering or you log in after it has been tampered with.
|
||||
|
||||
== Things you should do first
|
||||
## Things you should do first
|
||||
|
||||
Because some things are quite dependent on your system and network, as well as the type of system you end up with,
|
||||
I will not be detailing some of the early setup steps, such as creating and booting from the arch ISO, or the final steps,
|
||||
|
|
@ -46,16 +39,13 @@ You should clearly understand what most of these commands do before typing them
|
|||
|
||||
Anyway, start by booting up the arch ISO...
|
||||
|
||||
== Installing via ssh
|
||||
## Installing via ssh
|
||||
|
||||
Sometimes, you dont want to be switching from the computer you are installing Linux on and the computer with the documentation and a search engine on it,
|
||||
and Ive found the best way to avoid that is to set up a simple ssh session from the arch ISO to the computer with the documentation on it.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
On a normal, already installed machine, *NEVER* use just a password for SSH. *ESPECIALLY* if it is internet-facing or connected to a public network.
|
||||
⚠️ **WARNING:** On a normal, already installed machine, *NEVER* use just a password for SSH. *ESPECIALLY* if it is internet-facing or connected to a public network.
|
||||
We are only doing this because we are (hopefully) on a personal network, and the password-based SSH session only exists on the Arch ISO, so as soon as you boot into your fresh system, the SSH session will be gone.
|
||||
====
|
||||
|
||||
On the installee, make a password for the root account
|
||||
|
||||
|
|
@ -93,7 +83,7 @@ And type in the password you set on the installee
|
|||
|
||||
Now lets continue with the installation.
|
||||
|
||||
== initial setup
|
||||
## initial setup
|
||||
|
||||
Verify you are connected to the internet
|
||||
|
||||
|
|
@ -107,7 +97,7 @@ Turn on ntp
|
|||
$ timedatectl set-ntp true
|
||||
{{</highlight>}}
|
||||
|
||||
== Partitioning
|
||||
## Partitioning
|
||||
|
||||
Create partitions using the tools of your choice. I will be using the following partition map.
|
||||
|
||||
|
|
@ -117,7 +107,7 @@ A swap partition with a size equal to your RAM.
|
|||
|
||||
A btrfs partition containing the rest of the space.
|
||||
|
||||
== Encryption
|
||||
## Encryption
|
||||
|
||||
Encrypt the btrfs partition with
|
||||
|
||||
|
|
@ -145,7 +135,7 @@ $ cryptsetup open /dev/sda2 swap
|
|||
$ cryptsetup open /dev/sda3 btrfs
|
||||
{{</highlight>}}
|
||||
|
||||
== Filesystem creation
|
||||
## Filesystem creation
|
||||
|
||||
Format the EFI partition with FAT32 and give it the label EFI (label can be something else.)
|
||||
|
||||
|
|
@ -165,7 +155,7 @@ Format the root partition with btrfs and give the label root (label can be somet
|
|||
$ mkfs.btrfs -L btrfs /dev/mapper/btrfs
|
||||
{{</highlight>}}
|
||||
|
||||
== Creating and mounting subvolumes
|
||||
## Creating and mounting subvolumes
|
||||
|
||||
{{<highlight console "linenos=false">}}
|
||||
$ mount /dev/mapper/btrfs /mnt
|
||||
|
|
@ -193,7 +183,7 @@ $ mount /dev/sda1 /mnt/boot
|
|||
$ swapon /dev/mapper/swap
|
||||
{{</highlight>}}
|
||||
|
||||
== installing base system, generating *stab
|
||||
## installing base system, generating *stab
|
||||
|
||||
Install the base packages. Adjust the package list to suit your needs. Change intel-ucode to amd-ucode if using an AMD processor.
|
||||
|
||||
|
|
@ -217,7 +207,7 @@ swap LABEL=swap
|
|||
btrfs LABEL=btrfs
|
||||
{{</highlight>}}
|
||||
|
||||
== system config
|
||||
## system config
|
||||
|
||||
Chroot into the new system
|
||||
|
||||
|
|
@ -265,7 +255,7 @@ And add matching entries to /etc/hosts, like so (if static ip, use that. if dyna
|
|||
127.0.1.1 myhostname.localdomain myhostname
|
||||
{{</highlight>}}
|
||||
|
||||
== installing the boot loader
|
||||
## installing the boot loader
|
||||
|
||||
Edit /etc/mkinitcpio.conf so the HOOKS line looks like this:
|
||||
|
||||
|
|
@ -304,7 +294,7 @@ console-mode max
|
|||
editor no
|
||||
{{</highlight>}}
|
||||
|
||||
== system config
|
||||
## system config
|
||||
|
||||
Set root password
|
||||
|
||||
|
|
@ -324,7 +314,7 @@ Remove the install media, and boot back up.
|
|||
Make sure everything boots.
|
||||
From now on, configure the system as normal.
|
||||
|
||||
== configuring userspace
|
||||
## configuring userspace
|
||||
|
||||
Add a non-root user
|
||||
|
||||
|
|
@ -3,28 +3,21 @@ title = "Getting the Nextcloud client to save login info on arch linux (or any b
|
|||
date = 2021-12-12T14:59:31-05:00
|
||||
draft = false
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 6
|
||||
|
||||
During the 5 or so years Ive had nextcloud, Ive always been quite happy with the webclient, but the device clients... need some work.
|
||||
I recently figured out how to resolve one of my biggest pain points on the Linux desktop client, and am recording it here, mostly so I dont forget next time I setup a new computer,
|
||||
and to save others with the same problem from endless forum post and GitHub issue crawling.
|
||||
|
||||
== The cause
|
||||
## The cause
|
||||
Nextcloud expects the environment it is running in to have a 'keychain manager' installed and accessible by libsecret.
|
||||
However, currently, the Arch Linx nextcloud package does not list libsecret nor any keychain manager as a dependency.
|
||||
This does not cause a problem if you are using a desktop environment, as they will come with one in their own dependency cloud, but if you are just using a window manager, you may very well not have one installed.
|
||||
|
||||
(as a side note, this also seems to cause a significant delay in the client starting up, probably some sort of timeout waiting to access the keyring
|
||||
|
||||
== The solution
|
||||
## The solution
|
||||
|
||||
The solution is... surprisingly simple. You just need to install the `+gnome-keyring+` and `+libsecret+` packages, and set them up to autostart. In order to autostart them properly, adding these 2 lines to your `+.xinitrc+` is enough.
|
||||
The solution is... surprisingly simple. You just need to install the `gnome-keyring` and `libsecret` packages, and set them up to autostart. In order to autostart them properly, adding these 2 lines to your `.xinitrc` is enough.
|
||||
|
||||
{{<highlight bash "linenos=false">}}
|
||||
#get gnome-keyring running
|
||||
|
|
@ -32,4 +25,4 @@ dbus-update-activation-environment --all
|
|||
gnome-keyring-daemon --start --components=secrets
|
||||
{{</highlight>}}
|
||||
|
||||
(yes, you do need `+dbus-update-activiation-environment+`, as `+gnome-keyring+` seemingly relies on certain environment variables to start properly.)
|
||||
(yes, you do need `dbus-update-activiation-environment`, as `gnome-keyring` seemingly relies on certain environment variables to start properly.)
|
||||
|
|
@ -3,13 +3,6 @@ title = "Mapping caps lock to ctrl in the TTY"
|
|||
date = 2021-05-23T04:59:28-05:00
|
||||
draft = false
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 4
|
||||
|
||||
In the past 2 years or so, I have been using my caps lock key as a separate ctrl key on my desktop keyboard.
|
||||
This is very easy to do in X11 with a setxkmap command.
|
||||
|
|
@ -33,16 +26,13 @@ From what I can tell, the only way to 'release' control is to reboot.
|
|||
|
||||
In order to figure out why this is happening, we read the man page 'man keymaps'.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
You should be very careful when binding the modifier keys, otherwise you can end up with an unusable keyboard mapping.
|
||||
⚠️ **WARNING:** You should be very careful when binding the modifier keys, otherwise you can end up with an unusable keyboard mapping.
|
||||
If you for example define a key to have Control in its first column and leave the rest of the columns to be VoidSymbols, you're in trouble.
|
||||
This is because pressing the key puts Control modifier in effect and the following actions are looked up from the fifth column (see the table above).
|
||||
So, when you release the key, the action from the fifth column is taken.
|
||||
It has VoidSymbol in it, so nothing happens.
|
||||
This means that the Control modifier is still in effect, although you have released the key.
|
||||
Re-pressing and releasing the key has no effect.
|
||||
====
|
||||
|
||||
So what is happening seems to be that when we press caps lock, it looks for what keycode to send when no modifier keys are pressed.
|
||||
Finding Control in the first column (the only column we specified), it activates the control modifier.
|
||||
|
|
@ -62,7 +52,7 @@ Well, it should!
|
|||
However, there seems to be a bug in 'loadkeys', as the above only works when defining a complete keymap, not when overriding parts of default.map.
|
||||
This means, that in order to correctly modify the keymap, we either have to define all columns manually, or we have to copy the default keymap, edit it, and load it as a complete keymap.
|
||||
|
||||
== Keymap patch
|
||||
## Keymap patch
|
||||
|
||||
To continue overriding the default keymap, you can simply manually repeat the control command.
|
||||
Now, technically, there are 256 columns in the keymap file, but, at least for latin keyboards, only the first 16 are used.
|
||||
|
|
@ -75,7 +65,7 @@ keycode 58 = Control Control Control Control Control Control Control Control Con
|
|||
Now just put it in '/usr/share/kbd/keymaps/', and set it as your keymap with 'sudo localectl set-keymap [filename without .map extention]'.
|
||||
|
||||
|
||||
== Full keymap
|
||||
## Full keymap
|
||||
|
||||
In order to create a new full keymap, copy the keymap you want to edit from '/usr/share/kbd/keymaps/i386/[couple more folders here]' to somewhere in 'usr/share/kbd/keymaps/' and unzip it with 'sudo gzip -d [filename]'.
|
||||
Edit it with sudoedit and replace
|
||||
|
|
@ -106,4 +96,4 @@ EndSection
|
|||
{{</highlight>}}
|
||||
|
||||
Some people may suggest `setxkbmap` as a way to do this.
|
||||
However, unfortuantely, `setxkbmap` tends to be overwritten when a usb input device is plugged in or unplugged, and `xorg.conf.d` is the only persistent way to set it.
|
||||
However, unfortunately, `setxkbmap` tends to be overwritten when a usb input device is plugged in or unplugged, and `xorg.conf.d` is the only persistent way to set it.
|
||||
|
|
@ -3,67 +3,61 @@ title = "A modern CLI renaissance?"
|
|||
date = 2024-03-04T12:20:02-06:00
|
||||
draft = true
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 6
|
||||
<!--
|
||||
btop, 2021, c++
|
||||
bat, 2018, rust
|
||||
helix, 2020, rust
|
||||
zoxide, 2020, rust
|
||||
starship, 2019, rust
|
||||
difftastic, 2018, rust
|
||||
git-delta, 2019, rust
|
||||
nushell, 2018, rust
|
||||
hyperfine, 2018, rust
|
||||
sd, 2018, rust
|
||||
tre, 2019, rust
|
||||
typst, 2019, rust
|
||||
yazi, 2024, rust
|
||||
fd, 2017, rust
|
||||
ripgrep, 2016, rust
|
||||
ast-grep, 2022, rust
|
||||
pueue, 2015, rust
|
||||
diskonaut, 2020, rust
|
||||
broot, 2018, rust
|
||||
just, 2016, rust
|
||||
zellij, 2020, rust
|
||||
scc, 2018, go
|
||||
fzf, 2013, go
|
||||
lazygit, 2018, go
|
||||
grex, 2019, rust
|
||||
micro, 2016, go
|
||||
oh-my-posh, 2019, go
|
||||
nnn, 2016, c
|
||||
qalculate, 2016, c++
|
||||
eza/exa, 2014, rust
|
||||
lsd, 2018, rust
|
||||
neovim, 2015, c
|
||||
|
||||
// btop, 2021, c++
|
||||
// bat, 2018, rust
|
||||
// helix, 2020, rust
|
||||
// zoxide, 2020, rust
|
||||
// starship, 2019, rust
|
||||
// difftastic, 2018, rust
|
||||
// git-delta, 2019, rust
|
||||
// nushell, 2018, rust
|
||||
// hyperfine, 2018, rust
|
||||
// sd, 2018, rust
|
||||
// tre, 2019, rust
|
||||
// typst, 2019, rust
|
||||
// yazi, 2024, rust
|
||||
// fd, 2017, rust
|
||||
// ripgrep, 2016, rust
|
||||
// ast-grep, 2022, rust
|
||||
// pueue, 2015, rust
|
||||
// diskonaut, 2020, rust
|
||||
// broot, 2018, rust
|
||||
// just, 2016, rust
|
||||
// zellij, 2020, rust
|
||||
// scc, 2018, go
|
||||
// fzf, 2013, go
|
||||
// lazygit, 2018, go
|
||||
// grex, 2019, rust
|
||||
// micro, 2016, go
|
||||
// oh-my-posh, 2019, go
|
||||
// nnn, 2016, c
|
||||
// qalculate, 2016, c++
|
||||
// eza/exa, 2014, rust
|
||||
// lsd, 2018, rust
|
||||
// neovim, 2015, c
|
||||
|
||||
// cat, cd, rm, cp, man was included in the first version of unix, in 1971
|
||||
// ls specifically can trace its history to 1961 (https://tldp.org/LDP/LG/issue48/fischer.html)
|
||||
// vi was made in 1976
|
||||
// sed in 1974
|
||||
// awk in 1985
|
||||
// grep in 1973
|
||||
// bc in 1975
|
||||
// diff in 1974
|
||||
// make in 1976
|
||||
// vim in 1991
|
||||
// ssh in 1995
|
||||
// midnight commander in 1994
|
||||
// screen in 1987
|
||||
// tmux in 2007
|
||||
// rust 1.0 in 2015
|
||||
cat, cd, rm, cp, man was included in the first version of unix, in 1971
|
||||
ls specifically can trace its history to 1961 (https://tldp.org/LDP/LG/issue48/fischer.html)
|
||||
vi was made in 1976
|
||||
sed in 1974
|
||||
awk in 1985
|
||||
grep in 1973
|
||||
bc in 1975
|
||||
diff in 1974
|
||||
make in 1976
|
||||
vim in 1991
|
||||
ssh in 1995
|
||||
midnight commander in 1994
|
||||
screen in 1987
|
||||
tmux in 2007
|
||||
rust 1.0 in 2015
|
||||
-->
|
||||
|
||||
Id like to talk about a trend Ive seen these past few years, where people are rewriting core CLI tools,
|
||||
why I think this trend is a good thing, and why I think this trend might be happening.
|
||||
|
||||
== History
|
||||
## History
|
||||
|
||||
The terminal has been a staple of computer user interfaces since before computer monitors were available,
|
||||
with some of the first computers offering an interactive mode in the late 1950's.
|
||||
|
|
@ -74,7 +68,7 @@ Other tools are a bit newer, such as `sed` (1974), `diff` (1974) `bc` (1975), `m
|
|||
There were a few more tools introduced in the 90's, such as `vim` (1991) and `ssh`, (1995), but you get the picture.
|
||||
The majority of the foundational CLI tools on a Linux pc, even one installed yesterday, are older than Linux itself is.
|
||||
|
||||
== Ok, so?
|
||||
## Ok, so?
|
||||
|
||||
Now, theres nothing wrong with this, the tools work fine still, but,
|
||||
in the half-century since they were first written,
|
||||
|
|
@ -92,44 +86,44 @@ the way that error messages can teach,
|
|||
the value of a good out of the box experience,
|
||||
and the value of documentation that is easy to find and digest.
|
||||
|
||||
== The new tools
|
||||
## The new tools
|
||||
|
||||
These changes to the environment surrounding CLI apps has, in recent years,
|
||||
led to a resurgence in development of command line utilities.
|
||||
Instead of just developing tools that dont exist,
|
||||
Ive noticed that people are rethinking and reinventing tools that have existed since the early days of Unix.
|
||||
|
||||
== Exploration of the design space
|
||||
## Exploration of the design space
|
||||
|
||||
== The lessons learned from the past
|
||||
## The lessons learned from the past
|
||||
|
||||
=== A good out of the box experience
|
||||
### A good out of the box experience
|
||||
|
||||
// look at helix compared to (neo)vim
|
||||
<!-- look at helix compared to (neo)vim-->
|
||||
|
||||
=== Friendly error messages
|
||||
### Friendly error messages
|
||||
|
||||
// look at nushells error messages
|
||||
<!-- look at nushells error messages-->
|
||||
|
||||
=== Concise and discoverable documentation
|
||||
### Concise and discoverable documentation
|
||||
|
||||
// look at zellij and helix and their built in keymap cheatsheets
|
||||
<!-- look at zellij and helix and their built in keymap cheatsheets-->
|
||||
|
||||
=== Common usecases should be easy
|
||||
### Common usecases should be easy
|
||||
|
||||
// look at sd, rg, and fd
|
||||
<!-- look at sd, rg, and fd-->
|
||||
|
||||
== Shedding historical baggage
|
||||
## Shedding historical baggage
|
||||
|
||||
// look at just command runner, simplifying the common use case of make
|
||||
<!-- look at just command runner, simplifying the common use case of make-->
|
||||
|
||||
== The trendsetter
|
||||
## The trendsetter
|
||||
|
||||
// did neovim kick this all off?
|
||||
<!-- did neovim kick this all off?-->
|
||||
|
||||
== The languages
|
||||
## The languages
|
||||
|
||||
// most of the new tools are written in rust and go.
|
||||
<!-- most of the new tools are written in rust and go.-->
|
||||
|
||||
// rusts clap and gos cobra
|
||||
<!-- rusts clap and gos cobra-->
|
||||
|
||||
|
|
@ -3,23 +3,16 @@ title = "Dotfile Management with GNU Stow"
|
|||
date = 2023-07-29T16:37:34-05:00
|
||||
draft = false
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 6
|
||||
|
||||
So ive been using git to managing my dotfiles since [checks `git log`]... 2018.
|
||||
At first, I was going to write some inevitably brittle shell script to handle symlinking from the dotfile repo to where each file should be,
|
||||
but before I got about to implementing it, I discovered `stow`.
|
||||
Now, after using stow for dotfile management for over 5 years, I figure I should really document exactly how I go about managing my dotfiles, with an aim to help other people who want to have an easy to manage dotfiles repo that can be quickly deployed on new machines.
|
||||
|
||||
== What Stow does
|
||||
## What Stow does
|
||||
|
||||
https://www.gnu.org/software/stow/[stow] is a 'symlink farm manager', but I almost prefer to think of it a simplistic package manager that makes it incredibly easy to create packages from scratch.
|
||||
Like most of the gnu progect utility, the https://www.gnu.org/software/stow/manual/stow.html[documentation] covers a lot, but is a bit intimidating if you dont already know the software.
|
||||
[stow](https://www.gnu.org/software/stow/) is a 'symlink farm manager', but I almost prefer to think of it a simplistic package manager that makes it incredibly easy to create packages from scratch.
|
||||
Like most of the gnu progect utility, the [documentation](https://www.gnu.org/software/stow/manual/stow.html) covers a lot, but is a bit intimidating if you dont already know the software.
|
||||
|
||||
At its core, if you are in directory `~/foo`, containing a directory `bar`, whitch itself contains some files and folders like so:
|
||||
```
|
||||
|
|
@ -71,7 +64,7 @@ then running stow on baz, (`stow baz`) will result in:
|
|||
└── baz -> ~/foo/bar/.config/baz
|
||||
```
|
||||
stow realized that both `bar` and `baz` had `.config` in common, and turned it into a real directory, and remade the symlinks one level lower.
|
||||
Stow calls this https://www.gnu.org/software/stow/manual/stow.html#Tree-folding[tree folding].
|
||||
Stow calls this [tree folding](https://www.gnu.org/software/stow/manual/stow.html#Tree-folding).
|
||||
It can do the reverse, as well, running `stow -d bar` will result in:
|
||||
```
|
||||
.
|
||||
|
|
@ -91,14 +84,14 @@ Note that if .config contained files that stow doesnt 'own', it would leave it a
|
|||
|
||||
In short, you can think of stow taking a folder, and symlinking the contents of that folder exactly 2 levels up the directory tree, symlinking `~/foo/bar/contents` directly to `~/contents`.
|
||||
|
||||
== Ok, how do I use this to manage my dotfiles?
|
||||
## Ok, how do I use this to manage my dotfiles?
|
||||
|
||||
So now you know how to stow operates, you can make a 'package' for every program you have dotfiles for.
|
||||
Id encorage you to take a look at the directory structure of my dotfiles https://git.venberg.xyz/Gabe/dotfiles[repo] if you want more examples of the directory structure you should aim for.
|
||||
Id encorage you to take a look at the directory structure of my dotfiles [repo](https://git.venberg.xyz/Gabe/dotfiles) if you want more examples of the directory structure you should aim for.
|
||||
|
||||
Once you have the file structure down, all you need to install on a new machine is `git` and `stow`, git clone your dotfile repo, `cd` into it, and `stow` the folders for the software you want to install configs for.
|
||||
|
||||
== Non-stow considerations
|
||||
## Non-stow considerations
|
||||
|
||||
Stow helps you manage your configs, but nothing else.
|
||||
A lot of your more complex configs probably reqire other software beyond the program that reads that config.
|
||||
|
|
@ -115,12 +108,12 @@ Id also reccomend you create a directory called `scripts` or something similar t
|
|||
but is put on your `$PATH` by your `.zshrc` / `.bashrc` / `.fishrc` / the dotfile for whatever shell you use.
|
||||
This is for you to put any scripts you develop that may be called by/aliased by your configurations.
|
||||
|
||||
== Bootstrapping
|
||||
## Bootstrapping
|
||||
|
||||
Stow can be found on pretty much every linux distributions package manager. If for some reason it is not, building from source is... suprisingly easy.
|
||||
|
||||
You can find the source http://ftp.gnu.org/gnu/stow/[here], download `stow-latest.tar.gz`, and decompress it with `tar xvf stow-latest.tar.gz`. cd into the uncompressed folder, and simply run `autoreconf -iv`, `./configure`, and `make`. The binary will be in `./bin/stow` free for you to move it into your `$PATH`.
|
||||
|
||||
== Conclusion, or something
|
||||
## Conclusion, or something
|
||||
|
||||
So, that more or less explains how I manage every bit of text-based configuration on my machine. Again, Id highly reccomend you check out my https://git.venberg.xyz/Gabe/dotfiles[repo] or the repo of anyone else using stow for dotfile management.
|
||||
So, that more or less explains how I manage every bit of text-based configuration on my machine. Again, Id highly reccomend you check out my [repo](https://git.venberg.xyz/Gabe/dotfiles) or the repo of anyone else using stow for dotfile management.
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
+++
|
||||
title = "Gitea"
|
||||
date = 2022-02-10T01:33:49-05:00
|
||||
draft = true
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 6
|
||||
5
content/posts/gitea.md
Normal file
5
content/posts/gitea.md
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
+++
|
||||
title = "Gitea"
|
||||
date = 2022-02-10T01:33:49-05:00
|
||||
draft = true
|
||||
+++
|
||||
|
|
@ -3,13 +3,6 @@ title = "Rust Embedded Unit Testing"
|
|||
date = 2023-10-28T18:41:37-05:00
|
||||
draft = false
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 6
|
||||
|
||||
Ive been messing around with embedded rust recently, using the BBC micro:bit as a learning platform.
|
||||
Its really cool to see a high level language achieving the same results as low level c.
|
||||
|
|
@ -19,25 +12,25 @@ Obviously we cant run tests on our local machine that rely on hardware only foun
|
|||
but most of a project is going to be logic independent of the hardware its running on.
|
||||
What we really want to do is be able to unit test those independent blocks of logic on our local dev machine.
|
||||
|
||||
== The Root Problem
|
||||
## The Root Problem
|
||||
|
||||
The root of the problem is that our entire project is setup to depend on our target architecture and its hardware features.
|
||||
(you are using cargo embed, right?)
|
||||
As long as there is no compiler separation between our logic and our hardware interaction, we cant compile only one for our local machine while leaving out the rest.
|
||||
Fortunately, that realization leads us directly to...
|
||||
|
||||
== The Solution
|
||||
## The Solution
|
||||
|
||||
In Rust, the minimum unit of compilation is the crate.
|
||||
This means that if we want to separate our logic from our hardware interaction, we have to put them in separate crates.
|
||||
Thankfully, Rust has a feature called https://doc.rust-lang.org/cargo/reference/workspaces.html[workspaces] dedicated to managing several crates in a single project/repo.
|
||||
Thankfully, Rust has a feature called [workspaces](https://doc.rust-lang.org/cargo/reference/workspaces.html) dedicated to managing several crates in a single project/repo.
|
||||
|
||||
So, what we will do is make a https://doc.rust-lang.org/cargo/reference/workspaces.html[virtual workspace] at the top level of our repo,
|
||||
So, what we will do is make a [virtual workspace](https://doc.rust-lang.org/cargo/reference/workspaces.html) at the top level of our repo,
|
||||
containing 2 or more crates: one (or more, if it makes sense) for our main hardware layer that is set up for cross compilation and flashing using cargo-embed,
|
||||
one `#![no-std]` crate containing only hardware independent logic that can be used on any architecture, and do not have cross-compilation explicitly setup.
|
||||
The latter set of crate(s) are the ones that we will be able to put unit tests in.
|
||||
|
||||
== Implementation
|
||||
## Implementation
|
||||
|
||||
Our `main_hardware` crate will depend on the `independent_logic` crate, and our `independent_logic` crate cannot depend on any crate that is hardware specific, such as any HALs or BSPs in use.
|
||||
|
||||
|
|
@ -63,7 +56,7 @@ Lets say that we have a project that looks something like this:
|
|||
└── tilt_compensation.rs
|
||||
{{</highlight>}}
|
||||
|
||||
=== Separating the crates
|
||||
### Separating the crates
|
||||
|
||||
`calibration.rs` and `main.rs` are the only modules that depend on hardware features, so they will be the modules going into `hardware_main`.
|
||||
The rest will be going into `independent_logic`.
|
||||
|
|
@ -73,7 +66,7 @@ First we create the two new crates, with `hardware_main` being a binary crate an
|
|||
Then, we move the existing `Cargo.toml`, `Embed.toml`, `build.rs`, `memory.x`, and `.cargo/config` into the `hardware_main`.
|
||||
Then, we create a new `Cargo.toml` at the top level, with the only section being a `[workspace]` section,
|
||||
including both of the crates in the workspace.
|
||||
We edit the `Cargo.toml` of `hardware_main` to point to `independent_logic` as a https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies[path dependency], and remove any dependencies that are no longer used.
|
||||
We edit the `Cargo.toml` of `hardware_main` to point to `independent_logic` as a [path dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies), and remove any dependencies that are no longer used.
|
||||
We edit the `Cargo.toml` of `independent_logic` to add any packages that our code depends on.
|
||||
We edit `lib.rs` to declare all the modules in `independent_logic` (and declare the crate as `#![no_std]`),
|
||||
and remove those declarations from `main.rs`.
|
||||
|
|
@ -107,7 +100,7 @@ In the end, our file tree should look something like this:
|
|||
└── tilt_compensation.rs
|
||||
{{</highlight>}}
|
||||
|
||||
=== Adding tests
|
||||
### Adding tests
|
||||
|
||||
Now that we have separated the crates from each other, we are free to add unit tests to `independent_logic` the same way we would for any 'normal' rust project.
|
||||
However, we must keep in mind that we will only be able to run `cargo test` from inside the `independent_logic` crate.
|
||||
|
|
@ -3,21 +3,14 @@ title = "Syncthing"
|
|||
date = 2022-03-10T01:33:59-05:00
|
||||
draft = true
|
||||
+++
|
||||
:caution-caption: pass:[<span style="font-size: 2em">☠</span>]
|
||||
:important-caption: pass:[<span style="font-size: 2em">❗</span>]
|
||||
:note-caption: pass:[<span style="font-size: 2em">✏️</span>]
|
||||
:tip-caption: pass:[<span style="font-size: 2em">💡</span>]
|
||||
:warning-caption: pass:[<span style="font-size: 2em">⚠</span>]
|
||||
:toc:
|
||||
:toclevels: 6
|
||||
|
||||
https://syncthing.net/[Syncthing] is one of the best file syncing tools in existence,
|
||||
[Syncthing](https://syncthing.net/) is one of the best file syncing tools in existence,
|
||||
and I dont say that lightly.
|
||||
Syncthing is a distributed, peer to peer file syncing service.
|
||||
This means that it doesnt rely on a central, always online server ran by you or someone else,
|
||||
but that your devices directly send files between themselves whenever they are online at the same time.
|
||||
|
||||
== Syncthing vs Nextcloud
|
||||
## Syncthing vs Nextcloud
|
||||
|
||||
I use both Syncthing and Nextcloud for data storage and syncing,
|
||||
and while nextcloud has a lot of features and provides a nice web interface,
|
||||
|
|
@ -47,7 +40,7 @@ for folders with large number of files,
|
|||
I only have one device syncing with Nextcloud,
|
||||
and all other devices use Syncthing to sync with the device connected to Nextcloud.
|
||||
|
||||
== Distributed?
|
||||
## Distributed?
|
||||
|
||||
With Dropbox or Google drive, files are not sent directly between your devices,
|
||||
but are sent from one device to the server,
|
||||
|
|
@ -59,7 +52,7 @@ Instead, devices all connect to each other, sending changes made on one device t
|
|||
This makes all of your devices into a cluster, where no device has to always be online,
|
||||
but any devices that happen to be online at the same time synchronize while they can.
|
||||
|
||||
== Introducers
|
||||
## Introducers
|
||||
|
||||
If you have a lot of devices, making sure every device is connected to every other device can become a hassle.
|
||||
Thankfully, Syncthing has the concept of 'introducer' devices.
|
||||
|
|
@ -6,81 +6,82 @@ showToc = true
|
|||
:toc:
|
||||
:toclevels: 2
|
||||
|
||||
== Contact info
|
||||
* link:++https://git.venberg.xyz/Gabe++[Personal Git Server]
|
||||
* link:++https://github.com/gabevenberg++[GitHub]
|
||||
* link:++mailto:gabevenberg@gmail.com++[Email]
|
||||
## Contact info
|
||||
* [Personal Git Server](https://git.venberg.xyz/Gabe)
|
||||
* [GitHub](https://github.com/gabevenberg)
|
||||
* [Email](mailto:gabevenberg@gmail.com)
|
||||
|
||||
== Work Experience
|
||||
## Work Experience
|
||||
|
||||
=== John Deere
|
||||
Embedded Linux Engineer::
|
||||
### John Deere
|
||||
**Embedded Linux Engineer**\
|
||||
August 2023--current
|
||||
* Develop Linux distributions for embedded systems with Yocto
|
||||
* Develop Linux hardware drivers for embedded system
|
||||
* Develop python based Hardware In the Loop testing.
|
||||
* Use Git to collaborate across teams
|
||||
|
||||
=== Appareo
|
||||
Embedded Systems Intern::
|
||||
### Appareo
|
||||
**Embedded Systems Intern**\
|
||||
Summer 2023
|
||||
* Implemented and ran functional testing on embedded Linux product,
|
||||
including designing test fixtures using Raspberry Pis to automate testing of electrical properties and RF connectivity
|
||||
|
||||
=== Kata Containers
|
||||
Capstone Student::
|
||||
### Kata Containers
|
||||
**Capstone Student**\
|
||||
Spring Semester 2023
|
||||
* Implemented a Rust-based log parser for the Kata Containers project,
|
||||
including writing unit tests, integrating the tool with existing codebase,
|
||||
and implementing suggestions from code reviewers.
|
||||
* Collaborated using the GitHub workflow, chat rooms, and video chat remotely and across 8+hr timezone difference.
|
||||
|
||||
=== Corvent Medical
|
||||
Software Engineering Intern::
|
||||
### Corvent Medical
|
||||
**Software Engineering Intern**\
|
||||
Summer 2022
|
||||
* Wrote python scripts to translate requirements from word documents into a
|
||||
format understood by a propriatary requirements analysis tool.
|
||||
* Performed requirements analysis, wrote and performed software and hardware test procedures,
|
||||
and analyzed test coverage to enable regulatory approval of new medical device.
|
||||
|
||||
=== ByteSpeed
|
||||
Computer Technician::
|
||||
### ByteSpeed
|
||||
**Computer Technician**\
|
||||
Summer 2021
|
||||
* Performed troubleshooting and repair on warrantied computers.
|
||||
* Helped customers with a variety of problems over email, phone, and instant messaging.
|
||||
|
||||
=== NDSU Precision Agriculture Center
|
||||
Part time Developer::
|
||||
### NDSU Precision Agriculture Center
|
||||
**Part time Developer**\
|
||||
2020--2021
|
||||
* Implemented methods of preprocessing LIDAR data with python for a project to predict crop yield using machine learning.
|
||||
|
||||
=== Integrated Networking
|
||||
Tier 1 and 2 Tech::
|
||||
### Integrated Networking
|
||||
**Tier 1 and 2 Tech**\
|
||||
2019--2020
|
||||
* Performed troubleshooting, repairs, and upgrades on customer computers.
|
||||
* Performed network setup for institutional and home networks.
|
||||
* Estimated cost of customer solutions, including researching and comparing price across vendors.
|
||||
* Implemented a variety of more complex 'one off' projects for clients with specific needs.
|
||||
|
||||
== Education
|
||||
## Education
|
||||
|
||||
=== NDSU
|
||||
==== BS in Computer Science
|
||||
### NDSU
|
||||
**BS in Computer Science**
|
||||
Fargo, North Dakota
|
||||
|
||||
Graduated 2023
|
||||
|
||||
=== Alexandria Community College
|
||||
==== General Ed Associates Degree
|
||||
### Alexandria Community College
|
||||
**General Ed Associates Degree**
|
||||
Alexandria, Minnesota
|
||||
|
||||
Graduated 2020
|
||||
|
||||
== Skills
|
||||
## Skills
|
||||
* Rust
|
||||
* Python
|
||||
* Java
|
||||
* Bash
|
||||
* C
|
||||
* Git version control system.
|
||||
* Linux administration
|
||||
* Embedded Linux
|
||||
|
|
@ -90,23 +91,23 @@ Graduated 2020
|
|||
* LaTeX document markup language
|
||||
* Googling 😉
|
||||
|
||||
== Other Experience
|
||||
=== Homelab
|
||||
Home Linux Lab::
|
||||
## Other Experience
|
||||
### Homelab
|
||||
**Home Linux Lab**\
|
||||
2019--present
|
||||
|
||||
Run a home network consisting of 2 physical servers and 6 virtual machines doing a variety of tasks,
|
||||
such as a DNS, an NGINX reverse proxy, and several web servers serving static and dynamic content.
|
||||
Currently running: Nextcloud, GitTea, PiHole, Mainsail, and this static website.
|
||||
|
||||
=== Open Source Development
|
||||
==== Contributor to various open source projects
|
||||
### Open Source Development
|
||||
**Contributor to various open source projects**\
|
||||
2022--present
|
||||
|
||||
Have contributed patches of a variety of sizes to open source projects including Python and Kata Containers.
|
||||
|
||||
=== National Cyber League
|
||||
==== Four-time competitor in the National Cyber League
|
||||
### National Cyber League
|
||||
**Four-time competitor in the National Cyber League**\
|
||||
2021, '22, and '23
|
||||
|
||||
Competed for NDSU in the bi-annual National Cyber League in individual and team games,
|
||||
12
deploy.sh
12
deploy.sh
|
|
@ -1,12 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
set -e
|
||||
|
||||
USER=root
|
||||
HOST=10.10.1.5
|
||||
DIR=/srv/gabevenberg
|
||||
|
||||
hugo --minify
|
||||
rsync -rvz --delete public/ ${USER}@${HOST}:${DIR} # this will delete everything on the server that's not in the local public folder
|
||||
|
||||
exit 0
|
||||
10
justfile
Normal file
10
justfile
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
preview:
|
||||
hugo serve --buildDrafts --buildExpired --buildFuture --navigateToChanged
|
||||
|
||||
USER:='root'
|
||||
HOST:='10.10.1.5'
|
||||
DIR:='/srv/gabevenberg'
|
||||
|
||||
deploy:
|
||||
hugo --minify
|
||||
rsync -rvz --delete public/ {{USER}}@{{HOST}}:{{DIR}} # this will delete everything on the server that's not in the local public folder
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
hugo serve --buildDrafts --buildExpired --buildFuture --navigateToChanged
|
||||
Loading…
Reference in a new issue