add drone ci

2022-10-17 20:45:04 +01:00
16 changed files with 1 additions and 510 deletions
--- a/.gitattributes
+++ b/.gitattributes
@ -1 +0,0 @@
 *.png filter=lfs diff=lfs merge=lfs -text
--- a/blogs/2022/10/17/drone-ci.md
+++ b/blogs/2022/10/17/drone-ci.md
@ -6,7 +6,7 @@ However, I have some gripes: I mostly only use it for the CI, but it comes with
 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](https://gitea.io/) instance to host the source.
+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/).
@ -114,8 +114,3 @@ I also want to try building some more complex projects, such as those using game
 Those are adventures for another day, though.
 That's all for now, thanks for reading and see you next time!
 ## References
 * [GitLab CI config to deploy via SSH](https://medium.com/@hfally/a-gitlab-ci-config-to-deploy-to-your-server-via-ssh-43bf3cf93775)
--- a/blogs/2022/10/18/the-prince-of-milk.md
+++ b/blogs/2022/10/18/the-prince-of-milk.md
@ -1,30 +0,0 @@
 # The Prince of Milk
 The Prince of Milk is a science fiction novel by Exurb1a of YouTube fame.
 It follows the story of a fictional village in southern England named Wilthail, which ends up the unwilling venue for the settling of an ancient grudge.
 Deities ("Etherics") exist alongside the mundanity of 21st century Wilthail, and engage in absurdity, sodomy and violence with its quaint population.
 The books makes reference to a number of popular philosophical debates, and takes inspiration from a number of classical sci-fi authors.
 A common theme is the idea that power is relative.
 The Etherics are immortal - their grudge has played out across hundreds of 'Corporic' incarnations - and have power and abilities far beyond the comprehension of their human counterparts.
 However, they do not necessarily view themselves as gods.
 This is particularly true of the character Beomus, who frequently plays down their immortality and returns fire with questions about modern humans' relationship to their primitive ancestors, or with ants.
 This relativity of power recurs plenty, and is reminiscient of Arthur C. Clarke's assertion that sufficiently advanced technology is indistinguishable from magic.
 As characters in a book, the Etherics are understandably cagey about how any of their abilities work - but broadly refuse to classify them as either magic or technology.
 Reincarnation is viewed as a fundamental way of the world - Chalmers' panpsychism, or the Hard Problem of Philosophy.
 This goes further than to suggest that people are simply reincarnated as others when they die, rather suggesting that consciousness is a fundamental force of the universe, in just the way electromagnetism is.
 It's a recursive thing, from the lowliest atom up through rocks, mice, snakes, cats, people, stars and gods.
 It's a neat and satisfying view, and one that has yet to be disproven by neuroscience.
 The human characters are invariably damaged - mental health issues, broken relationships, toxic parentage, drug use, suicide, difficult histories.
 This paints PoM's world as realistic, and grounds it through the fantastical happenings in the middle act.
 It grips the reader with its variety of characters, and follows them all as they confront not only their own personal hells, but the one they now find themselves sharing, in a twisted take on country bumpkinism.
 Overall, I thoroughly enjoyed this book, and am looking forward to reading more of Exurb1a's writing.
 I am a little biased, as I have already enjoyed the YouTube channel for a number of years.
 There is a short glossary at the end naming and exploring some of the particular concepts explored in the novel, which prompt the reader to explore further.
 Top marks!
--- a/blogs/2022/11/13/un-cafe-dans-lespace.md
+++ b/blogs/2022/11/13/un-cafe-dans-lespace.md
@ -1,11 +0,0 @@
 # Un Cafe Dans l'Espace
 J'ai acheté ce livre quand j'ai visité la Cité de l'Espace à Toulouse. C'est écrit par Michel Tognini, un astronaute français qui été dans l'espace deux fois. Il a travillé sur la station spatiale de Mir, et sur la navette spatiale pour décoller CHANDRA, une observatoir dans le bas orbite. Depuis, il a selectionné et entrainé de nouveaux astronautes européens.
 Ce livre parle de plusiers subjets en relation à l'espace: de l'entrainement de l'auteur à la Cité des Étoiles en Russie, de les échecs et défis dans l'espace, aux réalisations des sociétés privés comme SpaceX, Blue Origin et Virgin Galactic. Comme d'autres astronautes, Tognini a étudié comme pilote de chasse, et puis comme pilote d'essai. Il a rejoint l'agence spatiale française CNES avant la formation de l'ESA, qui existe encore aujourd'hui. 
 J'ai trouvé que je connaissais déjà beaucoup des histoires dans ce livre, parce que j'ai toujours eu une adoration pour l'espace, et c'est écrit pour une audience générale. Ma première raison de lire ce livre est que c'était mon premier français! Cela m'a pris quelques mois, mais c'etait une experience agréable. Au début, j'avais besoin de rechercer plusiers mots à chaque page, mais à la fin j'ai trouvé que je pouvais lire beaucoup d'aisance.
 Je recommende ce livre aux francophones qui sont interessés par l'espace, mais qui sont peut-être moins familiers avec le jargon comme moi.
 Encore, merci à mon cher Ethel pour m'aider avec mon français ! <3
--- a/blogs/2022/12/03/automount-nfs.md
+++ b/blogs/2022/12/03/automount-nfs.md
@ -1,96 +0,0 @@
 # Automounting network drives with NFS
 This is the first part of a series of posts about setting up a music server using a NAS and Raspberry Pi. The next part is [here](https://ktyl.dev/blog/2022/12/19/pi-mpd-music-server.md).
 ---
 I have a NAS which supports NFS, which I use to store all of my photos, music and other media on my local network.
 This gives me OS-independent to all of these files, and frees up drive space on my laptops and desktop - most of which are dual-booted.
 On Windows it's fairly straightforward to establish a network drive, but on Linux-based systems - at least on the Debian- and Arch- based distros I find myself using - the process is a little more involved.
 Here I'll use `systemd` to automatically mount a shared folder when they're accessed by a client machine.
 There are other ways to do this, but as my machines predimonantly run Debian- or Arch-derived Linux distributions, `systemd` is a choice that works for both.
 This post is largely based on the description on the [ArchWiki](https://wiki.archlinux.org/title/NFS#As_systemd_unit).
 My NAS' hostname is `sleeper-service`, and I'll be mounting the `Music` shared folder.
 You'll need the appropriate package to mount NFS filesytems.
 On Arch Linux, `nfs-utils` is what you'll be after.
 On Debian, the client pckage is `nfs-common`, which may already be installed.
 You may also need to configure security on your NAS to allow NFS connections from your local machine's IP.
 ## Initial mount
 Before doing anything automatically, we first need to create a `systemd` unit to mount the remote filesystem at a path in our local filesystem.
 I'll mount the remote folder onto the local path `/sleeper-service/Music`.
 When creating this file, pay attention to its name, as it's important for it to correspond to the path of the mountpoint.
 The correct name can be determined using `systemd-escape` - pay attention to escape characters in the output, this caught me out several times.
 ```
 $ systemd-escape /sleeper-service/Music
 -sleeper\x2dservice-Music
 $ sudo touch /etc/systemd/system/sleeper\\x2dservice-Music.mount
 ```
 Don't ask me why `systemd` is like this - I think it's silly too.
 After creating the unit file, we then need to edit it and fill out some information, specifying where the remote filesystem is and also when we need to initialise it.
 Here I used a name instead of an address for the `What=` part - I have an entry for `sleeper-service` configured in `/etc/hosts`, but you can equally use an IP address just as well.
 ```
 [Unit]
 Description=Mount music at boot
 [Mount]
 What=sleeper-service:/volume1/Music
 Where=/sleeper-service/Music
 Options=vers=3
 Type=nfs
 TimeoutSec=30
 [Install]
 WantedBy=multi-user.target
 ```
 Once we've created this, we can try to manually mount the shared folder by starting the unit:
 ```
 $ sudo systemctl start sleeper\\x2dservice-Music.mount
 $ ls /sleeper-service/Music
 ```
 At this stage you ought to see the contents of your shared folder.
 Next, we want to set up the automount, so that this remote folder is mounted automatically when we try to access it.
 To do that, we need to first stop/disable the unit we just created:
 ```
 $ sudo systemctl disable sleeper\\x2dservice-Music.mount
 ```
 Then, let's create an `.automount` unit with the same name as the `.mount` file we already have.
 The automount unit expects the mount unit to exist alongside it - it doesn't replace it.
 ```
 $ sudo touch /etc/systemd/system/sleeper\\x2dservice-Music.automount
 ```
 ```
 [Unit]
 Description=Automount NAS music
 [Automount]
 Where=/sleeper-service/Music
 [Install]
 WantedBy=multi-user.target
 ```
 Then, enable the new `.automount` unit to have it run automatically:
 ```
 $ sudo systemctl enable sleeper\\x2dservice-Music.automount
 ```
 The folder should now be automatically mounted at the target location when trying to access it.
 As always, thanks for reading and I hope this was helpful.
 If I got something wrong, or there's an easier way to do it, or you just want to say hi, please don't hesitate to [get in touch!](mailto:me@ktyl.dev)
--- a/blogs/2022/12/15/astronaut_rides_horse.jpg
+++ b/blogs/2022/12/15/astronaut_rides_horse.jpg
--- a/blogs/2022/12/15/astronaut_rides_horse.png
+++ b/blogs/2022/12/15/astronaut_rides_horse.png
--- a/blogs/2022/12/15/stable-diffusion.md
+++ b/blogs/2022/12/15/stable-diffusion.md
@ -1,128 +0,0 @@
 # Local Stable Diffusion
 ![astronaut rides horse](astronaut_rides_horse.jpg)
 Stable diffusion (SD) is an AI technique for generating images from text prompts.
 Similar to DALL-E, which drives the popular [craiyon](https://www.craiyon.com/), SD is available as an [online tool](https://huggingface.co/spaces/stabilityai/stable-diffusion).
 These web tools are amazing, and easy to use, but can be frustrating - they're often under high load, and impose long waiting times.
 They use a good chunk of computational resources, specifically GPUs and so have generally been out of reach for even people with powerful personal machines.
 Now, however, SD has reached the point it can be run using (admittedly, high-end) consumer video cards.
 Stability AI - the model's developers - recently [published a blog post](https://stability.ai/blog/stable-diffusion-v2-release) open-sourcing SD 2.
 There's a README for getting started [here](https://huggingface.co/stabilityai/stable-diffusion-2/blob/main/README.md), but it has a couple of gotchas and assumptions which plenty of people (like myself) won't have known if they're not already familiar with the technologies in use, such as Python and CUDA.
 This post is descibes my experience setting up SD 2 on my local workstation.
 For hardware, I have an i7-6700k, RTX 2080 Super and 48GB of RAM.
 If you have an AMD video card, you won't be able to use CUDA, but you may be able to use GPU acceleration regardless using something ROCm.
 In this post I'm using Arch Linux, but I have successfully set it up on Windows too.
 Python is an exceedingly portable language, so it should work wherever you're able to get a Python installation.
 This post assumes that you already have a working Python installation.
 ## Install CUDA
 CUDA needs to be installed separately from Python dependencies.
 It is quite large, and as with all NVIDIA driver installations, can be a bit confusing.
 On Linux, it's straightforward to install it from your distribution's package manager.
 ```bash
 sudo pacman -Syu
 sudo pacman -S cuda
 ```
 On Windows, you will need to go to NVIDIA's site to download the correct version of CUDA.
 At time of writing, the SD 2 script expects CUDA 11.7, and will not work if you install the latest 12.0 version.
 To get older versions, go to their [download archive](https://developer.nvidia.com/cuda-toolkit-archive) and select the appropriate one.
 ## Set up a virtual environment and PyTorch
 Python can be installed at a system level, but it's usually a good idea to set up a virtual environment for your project.
 This isolates the project dependencies from the wider system, and makes your setup reproducible.
 I will use [`pipenv`](https://pipenv.pypa.io/en/latest/index.html) as it's what I'm familiar with.
 PyTorch is a deep-learning framework, used to put together machine learning pipelines.
 To get a command to install the relevant dependencies, go to [PyTorch's site](https://pytorch.org/get-started/locally/) and choose the options for your setup.
 In my case, I replaced `pip3` with `pipenv` as I want to install dependencies to a new virtual environment instead of to the system.
 ```bash
 mkdir stable-diffusion && cd stable-diffusion
 pipenv install torch torchvision torchaudio
 ```
 ## Install Stable Diffusion
 SD 2 is provided by the `diffusers` package.
 We can install it in our virtual environment as follows:
 ```bash
 pipenv shell
 pip3 install git+https://github.com/huggingface/diffusers.git transformers accelerate scipy
 exit
 ```
 We use `pipenv shell` to enter a shell using the virtual environment, before using the `pip3` command described on their README.
 After installing dependencies, we can leave the virtual environment shell and return to our original one.
 `transformers` and `accelerate` are optional, but used to reduce memory usage and so are recommended.
 ## Create a Python script
 Python does have an interactive envronment, but so save our fingers let's use a `stable-diffusion.py` script to contain and run our Python code.
 Here I'll mostly copy the Python included in their README:
 ```python
 import torch
 from diffusers import StableDiffusionPipeline, EulerDiscreteScheduler
 model_id = "stabilityai/stable-diffusion-2"
 # Use the Euler scheduler here instead
 scheduler = EulerDiscreteScheduler.from_pretrained(model_id, subfolder="scheduler")
 pipe = StableDiffusionPipeline.from_pretrained(model_id, scheduler=scheduler, revision="fp16", torch_dtype=torch.float16)
 pipe = pipe.to("cuda")
 pipe.enable_attention_slicing()
 prompt = "a photo of an astronaut riding a horse on mars"
 image = pipe(prompt, height=768, width=768).images[0]
 image.save("astronaut_rides_horse.png")
 ```
 I've made two additions here.
 First, I've added `import torch` at the top - I'm not sure why the code in the README omits this, but it's needed to work.
 I've also added `pipe.enable_attention_slicing()` - this is a more memory-efficient running mode, which is less intensive at the cost of taking longer.
 If you have a monster video card, this may not be necessary.
 At this point, we're done - after running the script successfully, you should have a new picture of an astronaut riding a horse on mars.
 ## Some nice-to-haves
 In this basic script we only have the one, hardcoded prompt.
 To change it, we need to update the file itself.
 Instead, we can change how `prompt` is set, and have it read from command-line parameters instead.
 ```python
 # at the top of the file
 import sys
 ...
 prompt = " ".join(sys.argv[1:])
 ```
 While we're at it, we can also base the filename on the input prompt:
 ```python
 image.save(f'{prompt.replace(" ", "_")}.png')
 ```
 ## Wrapping up
 And that's it!
 Enjoy making some generative art.
 My favourites so far have been prefixing "psychedelic" to things.
 I've also been enjoying generating descriptions with [ChatGPT](https://chat.openai.com/chat) and plugging them into SD, for some zero-effort creativity.
 As always, if anything's out of place of if you'd like to get in touch, please [send me an email!](mailto:me@ktyl.dev).
--- a/blogs/2022/12/17/gpt-game-dialogue.md
+++ b/blogs/2022/12/17/gpt-game-dialogue.md
@ -1,58 +0,0 @@
 # Game dialogue with ChatGPT
 [ChatGPT](https://chat.openai.com/chat) has become the latest AI application to enjoy viral popularity.
 At time of writing it's a closed-source research tool developed by OpenAI, with the only access being via their web portal.
 Users have to create an account to interact with the bot, and have no API access, though they no doubt have one internally.
 I think given its capabilities, this is probably a good idea for now, but I'd like to outline the impact it can already have in game development, even in its fairly limited form.
 However, it can already be made immensely useful for content generation, without any kind of API access.
 Generally, characters come in two flavours: main characters, whose motivations and actions shape the story; and generic NPCs, who exist to fill out the world for the player.
 For the story to carry the author's intent (which they might not necessarily care about), it would probably be best not to leave ChatGPT to generate a plotline on its own.
 Its susceptibilty to bias is a problem - try generating men or women and count how often they're describing as petite, as having chiseled jaws or as wearing form-fitting dresses.
 It can be coaxed out of this with enough description, but lots of manual intervention defeats any content generation technique.
 The other group of characters, though, I think represents ripe pickings.
 Often in a game world, background dialogue quickly becomes stale, as lines are reused.
 ChatGPT can already easily be used as a supporting writer to generate a huge amount of less-than-critical dialogue.
 Take, for example, a merchant.
 ![generating merchant dialogue](merchant_prompt.png)
 This psuedo-format is instantly combatible with a simple templating system.
 It would be trivial to generate variations using perfectly traditional programming techniques.
 This prompt took a minute to write, and includes specific about the character's context, as well as a slightly more than default personality.
 We've instantly generated 8 perfectly workable dialogue options for our character, from some basic and mostly templated information about their context.
 However, we notice that our item choices weren't included in the output, though we described them.
 So we ask:
 ![merchant items](merchant_items.png)
 And, instantly, another 8 lines.
 We now have, after a modicum of input, 16 possible lines for a background merchant character to respond with when interacted with.
 With some templated prompt generation, this could be made even faster than the description given here.
 It's also capable of going beyond just lines dialogue.
 [Ibralogue](https://github.com/Ibralogue/Ibralogue)'s developer taught it the syntax, had it generate an example and then taught it a new feature:
 ![sprite prompt](sprite_prompt.png)
 ![sprite response](sprite_response.png)
 All that's left is to copy the output and paste it into a text file for a game to use.
 ---
 This is barely even a scratch on what ChatGPT or systems like it are already capable of.
 At present, the website gets overloaded, you can't save and reload conversations, and its content filtering is very much evolving problem. 
 However, even with those limitations it's an extraordinarily powerful tool, and this is just one very minor example of an application.
 That's it from me, but I'd love to read more discussion about use cases and the ethical issues at play.
 If you have anything interesting, please [get in touch](mailto:me@ktyl.dev)!
--- a/blogs/2022/12/17/merchant_items.png
+++ b/blogs/2022/12/17/merchant_items.png
--- a/blogs/2022/12/17/merchant_prompt.png
+++ b/blogs/2022/12/17/merchant_prompt.png
--- a/blogs/2022/12/17/sprite_prompt.png
+++ b/blogs/2022/12/17/sprite_prompt.png
--- a/blogs/2022/12/17/sprite_response.png
+++ b/blogs/2022/12/17/sprite_response.png
--- a/blogs/2022/12/19/pi-mpd-music-server.md
+++ b/blogs/2022/12/19/pi-mpd-music-server.md
@ -1,126 +0,0 @@
 # NAS-based music with a Raspberry Pi
 This follows on from my [previous post](https://ktyl.dev/blog/2022/12/03/automount-nfs.html) about setting up NFS.
 ---
 I have a large digitised collection of music, and have been experimenting with ways to set up a communal music player in my living room without defaulting to Spotify, or any other such streaming platform.
 Thus far I have used an old laptop with as much music as it will fit loaded onto it, running [MPD](https://www.musicpd.org/) and plugged into some speakers.
 Then, on the laptop (or usually, another, closer laptop) I can connect to the MPD instance with [ncmpcpp](https://github.com/ncmpcpp/ncmpcpp) to change tunes.
 This is an OK solution, but has a few drawbacks: I'm limited to the disk of the laptop, the laptop uses more power than it needs to, and I kind of want that laptop back!
 I had the luck to grab a Raspberry Pi from a pop-up store a few weeks ago, and felt that would make a perfect, low-power, unintrusive box to attach to the speakers.
 Ostensibly, the Pi is overkill for just playing music, but it's better than a whole laptop and I'm sure I'll find other jobs for it to do as time goes on.
 As for requirements, I have a desktop machine from which I often work from home, and would like my music collection available there too.
 I also often use my laptop in the living room or kitchen, which is also in earshot of the speakers, and I'd like to be able to control the music from my laptop with ease - no cables.
 Ideally, these should be stored in the same place, to save having to manage duplicate files and manually synchronising locations, since I am likely to add to my collection from a variety of locations.
 I have spent enough time `rsync`ing albums between machines, life is too short even on a gigabit local network.
 I've recently had the good fortune to acquire a Synology NAS, so I'm going to use that to host my music collection.
 However, it's more than possible to jerry-rig a NAS using anything with a hard-drive - maybe even a second Pi.
 Nothing I'm doing should be specific to Synology's hardware or software, as we'll be using [NFS](https://wiki.archlinux.org/title/NFS) to mount remote drives - but exposing an NFS shared folder to the network is therefore out of scope for this post.
 ## Set up a shared folder
 The first step is to centralise my music storage.
 To do this, I created a shared folder from my NAS' web interface, and exposed it to the network.
 In my case, I had to specifically add permission for other devices to access the folder via NFS - such as the Pi, my desktop and my laptop.
 It was therefore prudent to assign each of these machines a static IP on my network, so that the NAS can continue to recognise them.
 I also had to set it to map all users to admin, but this is almost certainly a misconfiguration on my part - don't follow me for security advice, I am just tinkering!
 My previous blog post goes into detail regarding setting up the NFS configuration.
 ## Setting up the Pi
 My Pi is a Pi 4 Model B, with 4GB of RAM.
 This is more than enough for my needs, and you should be able to get by with much less.
 I went through the initial default setup, noticing that it's much, much slicker than it was on my gen 1 Pi, which ultimately landed me on a graphical desktop.
 First, I set a hostname and enabled SSH access, since this is to be a headless machine.
 For the same reason, I disabled the auto-launch of the graphical user interface.
 I would have thought that if it's booted headless, it shouldn't think to launch a graphical session in the first place, but better safe than sorry.
 The point of the thing is to sip power!
 ## MPD
 Next, I installed MPD.
 By default, MPD sets itself up with a `systemd` unit, so it connects as soon as I run `ncmpcpp` from the Pi itself.
 After a reboot, this still seems to be the case, so I'm happy with the default installation.
 I pointed it to the automounted music directory by editing `/etc/mpd.conf` and added it to the `audio` group:
 ```
 music_directory     "/sleeper-service/Music"
 group               "audio"
 ```
 Configured an output for ALSA (I was not able to make it work with Pulse):
 ```
 audio_output {
    type        "alsa"
    name        "My ALSA Device"
    mixer_type  "software"
 }
 ```
 We also have to add the `mpd` user to the `audio` group to allow it to access sound devices:
 ```
 sudo usermod -G audio -a mpd
 ```
 And enable the driver on boot for the 3.5mm audio jack in  `/etc/modules`:
 ```
 sudo echo "snd-bcm2835" >> /etc/modules
 ```
 I found I had errors with MPD failing to create a pid file, so I gave the `mpd` user ownership of the directory it was trying to create it in:
 ```
 sudo chown -R mpd /run/mpd/
 ```
 This was a bit of a weird one, since it didn't have this error to start with.
 Nonetheless, after all of that, it works!
 I'm able to play music by running `ncmpcpp` on the Pi itself.
 ## Remote access
 The last thing to configure is access from remote machines.
 I only intend to access it from the local network, so this is pretty straightforward.
 First, to expose MPD to the network, I set its address and port in `/etc/mpd.conf`:
 ```
 bind_to_address "192.168.1.17"
 port            "6600"
 ```
 Then, I need only specify the location of the Pi on the network in a local machine's `ncmpcpp` config:
 ```
 mpd_host = "pifi"
 mpd_port = "6600"
 ```
 Of course, `pifi` is an entry in my remote machine's `/etc/hosts`.
 It's possible you have multiple MPD installations - one on your remote machine, such as a laptop, as well as an installation like the Pi.
 In that case, recall that `ncmpcpp` can be launched with different configs using the `-c` flag:
 ```
 alias bops="ncmpcpp -c ~/.config/ncmpcpp/config.alt
 ```
 ## Wrapping up
 That's all for now.
 At some point in the future I'll write another post on making this setup more accessible.
 I certainly like `ncmpcpp`, but it often garners a scoff from houseguests.
 So, I'd like to pursue the ultimate goal of making it as straightforward to use as something like Spotify.
 As always, I hope this was helpful and please don't hesitate to [get in touch](mailto:me@ktyl.dev)!
--- a/blogs/2023/01/08/how-not-to-be-wrong.md
+++ b/blogs/2023/01/08/how-not-to-be-wrong.md
@ -1,13 +0,0 @@
 # How Not To Be Wrong: The Hidden Maths of Everyday Life
 _How Not To Be Wrong_ by Jordan Ellenberg explores mathematical concepts and ideas which permeate our everyday life.
 A broad look at mathematical principles which govern some parts of everyday life, and some parts of the not-so-everyday life.
 Generally well-written and approachable, as someone with a maths-adjacent background, there were some parts that I was familiar with, and others less so.
 The author has a sense of humour, and writes well about topics he clearly understands deeply, mostly without boring the reader.
 I particularly enjoyed the first few chapters, where a difference is established between the "default" view of mathematics as purely a numbers game about finding exact answers to questions, versus the author's view that it's about finding the questions to ask in the first place.
 Such questions include those such as "how Swedish is too Swedish?", "does lung cancer cause smoking?" and "can slime mold predict elections?".
 The book reminded me a bit of Chaos: Making a New Science which I read at the beginning of 2022, though less dry, and pitched to a more general audience.
 I enjoyed some specific parts of the book a lot - particularly those involving geometry and calculus - though could have done without the extensive pieces on statistics, which was always my least favourite sub-discipline at school.
--- a/fantasy-telescope-1.md
+++ b/fantasy-telescope-1.md
@ -1,26 +0,0 @@
 # Building a fantasy space telescope
 TODO: link rti1w
 Space-based telescopes are particularly cool bits of kit.
 They function in extreme conditions, for years or decades at a time, without any maintenance (barring [one incredible exception](https://www.nasa.gov/mission_pages/hubble/servicing/index.html)) or support beyond instructions from the ground.
 The mechanical engineering and astrodynamic understanding that goes into [balancing Kepler against solar pressure](https://www.nasa.gov/kepler/keplers-second-light-how-k2-will-work), [cooling JWST to near-absolute zero](https://jwst.nasa.gov/content/about/innovations/cryocooler.html) or precisely [manoeuvring LISA's constituent spacecraft](https://sci.esa.int/web/lisa/-/lisa-technology-interferometry-explained) in a formation millions of kilometres across is humbling.
 I don't have access to my own space-based telescope - though plenty of the raw data such instruments produce is [made available to the public](https://archive.stsci.edu/index.html).
 I also live in a particularly light-polluted part of the world, I can't do much stargazing, either.
 What I can do, however, is write software, which is a critical part of any robotic spacecraft, telescope or otherwise.
 So, I thought it would be interesting to try my hand at making my own fantasy space telescope!
 This is an open-ended endeavour, as there are lots of interesting things about telescopes to simulate, but it makes sense to start with something graphical, as telescopes are for making pretty pictures!
 I've already some experience with simulating optics using ray tracing.
 I'll initially base this project on my implementation of [Ray Tracing in One Weekend](https://raytracing.github.io/), an excellent, approachable introduction to generating ray-traced images.
 Though I've written [real-time ray tracers](https://github/ktyldev/oglc.git) as well, I think this is a better place to start because it's an offline renderer - you can't see what you'll render before you render it.
 That's a nice analogue to space-based telescopes, which have long exposure times and no viewfinders.
 Another nice aspect 
 ## Networks