3 changed files with 0 additions and 163 deletions
--- a/blogs/2022/8/13/decentralised-password-management.md
+++ b/blogs/2022/8/13/decentralised-password-management.md
@ -43,7 +43,6 @@ GPG is also often used to encrypt email and other forms of communication in open
 GPG keys are very similar to SSH keys, but notably different in that they force the use of a password, while SSH keys may be passwordless.
 They also differ in that GPG keys aren't named, but rather are stored on a keyring.
 I will leave it for a future post or to someone else entirely to explain what a keyring is.
 I first installed [gnupg](https://gnupg.org/) and created a GPG key using `gpg --full-gen-key`.
 I gave it my email address, set it to expire after a year and used otherwise default encrpytion options.
--- a/blogs/2022/8/8/wading-into-tidal.md
+++ b/blogs/2022/8/8/wading-into-tidal.md
@ -1,91 +0,0 @@
 # Wading into Tidal
 I stumbled across [TidalCycles](https://tidalcycles.org/) lately.
 It exists at my happy cross-section of automation, rave music and open source software.
 It's a [livecoding]() language/interpreter/instrument based on Haskell (in which I am also particularly interested!) and I decided to try it out.
 This is a short post explaining the steps I took and resources I used to install and get started playing with Tidal on Arch Linux using Neovim.
 # Realtime Scheduling
 Similarly to a DAW - I suppose Tidal is kind of a DAW? Audio engineers will squirm - it's important for Tidal to have high-precision timing, unlike most software.
 This kind of control can be risky, so most systems don't make it available straight out the gate - Arch is one of them.
 See [this post](https://jackaudio.org/faq/linux_rt_config.html) for a more detailed explanation, as well as a list of distributions which do enable realtime scheduling straight away.
 In my case, I found a section on the [JACK ArchWiki page](https://wiki.archlinux.org/title/JACK_Audio_Connection_Kit#Realtime_scheduling_and_additional_resources) that provided an easier solution.
 Install the `realtime-privileges` package and add your user to it:
 ```
 sudo pacman -S realtime-privileges
 sudo usermod -a -G realtime ktyl
 ```
 As with all group changes, you'll need to re-log or reboot for changes to take effect.
 # Linux Audio
 There are three components to my local audio setup in the context of Tidal.
 First is [JACK](https://wiki.archlinux.org/title/JACK_Audio_Connection_Kit#Realtime_scheduling_and_additional_resources), which is a low-latency audio daemon with a confusing number of implementations.
 There is a list and comparison on the ArchWiki page, but I found the package I needed to install was `pipewire-jack` (as opposed to `jack` or `jack2`), which leads nicely into Pipewire, the second component.
 [Pipewire](https://wiki.archlinux.org/title/Pipewire) is a multimedia framework which aims to solve audio problems on Linux Once And For All.
 It's an abstraction and doesn't directly play audio itself, rather deferring that responsibility further down the line.
 To actually play audio, I am using the [PulseAudio](https://wiki.archlinux.org/title/PulseAudio) which I already had installed.
 However, this didn't work out of the box because Pulse and Pipewire had no idea about each other.
 To resolve this, I had to install the `pipewire-pulse` package.
 # SuperCollider and SuperDirt
 Now we're getting to the fun stuff!
 I mostly followed [this guide](https://roosnaflak.com/tech-and-research/install-tidal-cycles-on-arch-linux/), but I found I had to do a couple things a little differently - maybe it's a bit of a dated guide? - which I'll describe here.
 First I installed `haskell-tidal` from the AUR (I use the [`yay` AUR helper](https://github.com/Jguer/yay).
 Then, as I wanted to use Neovim, I had to install the `tidalcycles/vim-tidal` plugin, using the [`vim-plug` plugin manager](https://github.com/junegunn/vim-plug), and remembering to run `:PlugUpdate`.
 The guide then describes steps to make the `tidal` binary available system-wide - however I found the path it describes didn't exist.
 Instead, based on the path `vim-plug` installs to (`~/.local/share/nvim/` rather than `~/.config/nvim/`), I found my actual steps were:
 ```
 cd ~/.local/share/nvim/plugged/vim-tidal
 sudo make install
 ```
 Next I opened SuperCollider with `scide` and installed SuperDirt.
 Again the guide seemed a bit out of date in the version of SuperDirt it lists - I found I needed to use `"v1.7.2"` as the version string, rather than `"v1.1.3"` as shown in the guide.
 By the time you're reading this, the version listed here may be out of date, so if you have trouble with this stage that's what I'd check first.
 ```
 Quarks.checkForUpdates({Quarks.install("SuperDirt", "v1.7.2");
 thisProcess.recompile()})
 ```
 To run code in SuperCollider, select the block you'd like to execute and press `Ctrl + Enter`.
 At this stage, everything should be installed (notwithstanding any error messages, troubleshooting section not included) and we should be ready to go.
 Start SuperDirt up in SuperCollider:
 ```
 SuperDirt.start;
 ```
 Now, open a tidal file in Neovim:
 ```
 nvim test.tidal
 ```
 And enter a Tidal pattern!
 ```
 d1 $ sound "bd sn"
 ```
 To play it, put the cursor in the line and press `Ctrl + E`.
 Neovim should open a new window containing a Tidal terminal, and find and connect to the runing Tidal instance.
 That's it!
 Have fun making beats.
 If you have any trouble with this guide, there's an off chance I've learned a bit more about in the interim, so feel free to [ping me an email](mailto:me@ktyl.dev)!
 Or of course, ask the nice folk over at [Tidal Club](https://club.tidalcycles.org/).
--- a/drone-ci.md
+++ b/drone-ci.md
@ -1,71 +0,0 @@
 # Drone CI
 When it comes to automation, [GitLab CI](https://gitlab.com) has been my go-to for running builds, tests and deployments of projects from static websites to 3D open-world games.
 This has generally been on a self-hosted installation, and often makes use of physical runners.
 However, I have some gripes: I mostly only use it for the CI, but it comes with an issue tracker and Git hosting solution too - great for some cases, but overkill in so many others.
 Because it's such a complete solution, GitLab is a bit of a resource hog, and can often run frustratingly slowly.
 Recently I've been playing with a friend's self-hosted instance of [Drone CI](https://drone.io/) as a lightweight alternative, and I much prefer it.
 I didn't set up the instance, so that part is out of scope for this post, but in case it's relevant, we're using a self-hosted [Gitea](gitea.io) instance to host the source.
 You can find out about configuring Drone with Gitea [here](https://docs.drone.io/server/provider/gitea/).
 ## Yet Another Yaml Config
 Like GitLab, Drone is configured via a YAML file at the project root, called `.drone.yml`.
 Drone is configured by creating 'steps' to the pipeline, where GitLab uses 'jobs'.
 My first project's automation requirements were small - all I needed for a deployment was to copy all the files in a directory on every push to the `main` branch.
 This means I needed secure access to the host, and the ability to copy files to it.
 I didn't want to dedicate any permanent resources to such a small project, so opted for the `docker` pipeline option.
 My pipeline would contain a single `deploy` step which would configure SSH access to the host, and then use it to copy the relevant files from the checked out version of the project.
 I decided to use `ubuntu` as the Docker image for familiarity and accessibility - there are probably better options.
 Drone widely supports Docker image registries; I have not used Docker much, but would like to get more experience with it.
 ```yml
 kind: pipeline
 type: docker
 name: deploy
 steps:
 - name: deploy
  image: ubuntu
  when:
    branch:
    - main
  commands:
    - echo hello world
 ```
 ## Secrets
 A hugely important aspect of automation is ensuring the security of one's pipelines.
 Automated access between pipelines is a big risk, and should be locked down as much as possible.
 For passing around secrets such as passwords and SSH keys, Drone has a concept of secrets.
 I created a private key on my local machine for the runner's access to the remote host, and added a [per-repository secret](https://docs.drone.io/secret/repository/) to contain the value.
 This is a named string value which can be accessed from within the context of a single pipeline step.
 I also created secrets to contain values for the remote host address and the user to login as.
 These are less of a security concern than the private SSH key, but we should obfuscate them anyway.
 It's also a useful step towards generalising the pipeline for other projects, which we'll get into later.
 This block was placed in the same step definition as above, below the `image:` entry:
 ```
 environment:
  HOST:
    from_secret: host
  USER:
    from_secret: user
  SSH_KEY:
    from_secret: ssh_key
 ```
 ## Templates
 ## References
 * [GitLab CI config to deploy via SSH](https://medium.com/@hfally/a-gitlab-ci-config-to-deploy-to-your-server-via-ssh-43bf3cf93775)