[{"content":"I have a home server called reef. I have been connecting to it with ssh reef for a long time. Today it stopped.\n❯ ssh root@10.5.7.35 ssh: connect to host 10.5.7.35 port 22: No route to host Then, in the same terminal, one second later:\n❯ /usr/bin/ssh root@10.5.7.35 Welcome to Ubuntu 22.04 LTS (GNU/Linux 6.8.12-10-pve x86_64) root@reef:~# Same host. Same shell. Same second. One works and one does not. I have never seen anything like it, and it took a while to believe what I was looking at.\nEverything that looked broken was fine No route to host sounds like a networking failure, so I started where anyone would.\nDNS was healthy. Both of my internal resolvers answered correctly, and reef.hs resolved to 10.5.7.35 from each of them. Public names resolved too. Nothing had changed in my DNS configuration, and nothing needed to.\nThe server was healthy. It answered ICMP in under three milliseconds, its ARP entry was present, and I could pull its SSH banner straight off the wire with a tool that was never blocked:\n❯ curl -s telnet://10.5.7.35:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3 So sshd was listening, reachable, and introducing itself politely, at the exact moment ssh insisted there was no route to it.\nThe rest of my network was fine as well. I had convinced myself that Proxmox was down, because https://proxmox.home.ndbroadbent.com/ would not load in Chrome. From the command line it returned HTTP 200 immediately. Chrome was the thing that was broken, not Proxmox.\nAt this point I had spent a while suspecting my router, my DNS server and the Terraform repository that manages my home infrastructure. All three were innocent.\nThe pattern The clue was that curl worked, ping worked, and ssh did not. Those are different programs. So I stopped testing hosts and started testing binaries.\nBinary Internet My LAN /usr/bin/ssh works works /usr/bin/curl works works /usr/bin/nc works works /bin/bash (/dev/tcp) works works /opt/homebrew/bin/ssh works No route to host /opt/homebrew/bin/bash works No route to host /opt/homebrew/opt/curl/bin/curl works fails /opt/homebrew/bin/node works EHOSTUNREACH Homebrew\u0026rsquo;s ssh will happily authenticate to GitHub over the public internet. It cannot open a TCP connection to a machine on my own network. Apple\u0026rsquo;s ssh does both.\nThat is not a routing problem. Routes do not know which binary is asking.\nmacOS decides this per executable macOS gained a Local Network privacy control in Sequoia, the one that asks whether an app may \u0026ldquo;find and connect to devices on your local network\u0026rdquo;. I assumed, reasonably I thought, that this was a per-application setting, and that my terminal either had it or did not. iTerm had it. That did not help.\nTo test whether the permission really is granted per binary, I wrote a short C program that opens a TCP connection to an address and prints the result. I compiled it, checked that it was ad-hoc signed like any freshly built local binary, and ran it:\n10.5.7.10:8006 -\u0026gt; No route to host 140.82.121.4:22 -\u0026gt; CONNECTED A program I had written thirty seconds earlier could reach GitHub and could not reach a machine in the next room. There was no prompt, no dialog, and no entry appeared in System Settings. It simply failed.\nThat is the whole mechanism. Local network access is evaluated for the executable making the call. Binaries that ship with macOS are signed by Apple as platform binaries and are exempt. Anything else is denied unless it has been granted access, and a command line tool has no way to display the approval prompt, so it does not get asked. The syscall returns EHOSTUNREACH, and EHOSTUNREACH is printed as No route to host.\nWhich is a genuinely unfortunate error string, because it names the one thing that is not wrong.\nThe part I cannot explain Homebrew\u0026rsquo;s python3 reaches my LAN without complaint. I checked that it was really connecting and not being redirected somewhere harmless:\nlocal: (\u0026#39;10.5.7.199\u0026#39;, 65012) peer: (\u0026#39;10.5.7.10\u0026#39;, 8006) That is a genuine socket to a genuine machine. Meanwhile python3.10 and python3.11, installed by the same Homebrew, in the same directory, both fail with [Errno 65] No route to host.\nSo python3.14 is holding a grant that its siblings do not have. Permissions really are stored per binary, and at least one of mine was approved at some point without my remembering it. I could not find where that grant lives. It is not in TCC.db:\n❯ tccutil reset LocalNetwork tccutil: Failed to reset LocalNetwork ❯ sudo tccutil reset LocalNetwork tccutil: Failed to reset LocalNetwork That is not a permissions failure, it is a category error. I dumped the list of services in the TCC database and kTCCServiceLocalNetwork is not among them. Local network permission is handled by nehelper, somewhere I have not located, and tccutil has no idea it exists. So the standard advice for resetting a macOS privacy prompt does not apply here at all.\nIf you know where these grants are stored, I would like to hear about it.\nEvery diagnostic tool lies to you The reason this took so long is that the failure is invisible to the tools you reach for first.\nping works, because ICMP is not gated. DNS works, because your queries are answered by mDNSResponder, which is Apple\u0026rsquo;s. curl works, because it is Apple\u0026rsquo;s. nc works, because it is Apple\u0026rsquo;s. Each of those tells you the network is fine, which is true, and none of them is the program you are trying to run.\nWorse, the tools can lie in the other direction. Early on I probed my LAN with a shell loop using /dev/tcp, and my shell is Homebrew\u0026rsquo;s bash. Every host came back dead. I briefly believed that my Proxmox server, my reverse proxy and my home server had all failed simultaneously. They were all running perfectly. I was holding a blocked binary and asking it whether the network was up.\nIf you take one thing from this, take that: when you are debugging local network access on a recent macOS, run your probes with /bin/bash and /usr/bin/curl, or you will be reading fiction.\nWhat to do about it The quickest fix is to stop using the blocked binary. Apple ships a perfectly good OpenSSH, and it is exempt:\nalias ssh=\u0026#39;/usr/bin/ssh\u0026#39; If Homebrew\u0026rsquo;s openssh arrived as an incidental dependency rather than a deliberate choice, brew uninstall openssh makes ssh resolve to /usr/bin/ssh and the problem disappears for good.\nBefore that, open System Settings, go to Privacy and Security, then Local Network, and scroll past the applications. Individual command line tools can appear in that list. If ssh or bash is there with the switch off, turning it on is the real fix rather than a workaround. My python3 almost certainly got its grant this way.\nAnd if a machine on your network appears to be down, check it with curl before you check it with anything else. Mine was up the entire time.\nPostscript None of this was a bug in my server, my DNS, my router or my infrastructure code. I spent a while inspecting all four. The actual change was that a privacy feature quietly denied a permission to a binary that could not ask for it, and reported the denial using the error message for a completely different failure.\nI do not know exactly when it broke. When I finally logged in with Apple\u0026rsquo;s ssh, the server told me my last successful login from this laptop was on 22 June. Something between then and now moved: an operating system update, or a Homebrew rebuild of openssh that gave the binary a fresh ad-hoc signature, or both. I am not going to pretend I can distinguish them after the fact.\nWhat I can say is that nothing announced it. It simply stopped, on an ordinary Friday, in the middle of trying to do something else.\n","permalink":"https://actuallyrandom.com/posts/why-ssh-broke-on-macos-26-but-usr-bin-ssh-still-works/","summary":"\u003cp\u003eI have a home server called \u003ccode\u003ereef\u003c/code\u003e. I have been connecting to it with \u003ccode\u003essh reef\u003c/code\u003e for a long time. Today it stopped.\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e❯ ssh root@10.5.7.35\nssh: connect to host 10.5.7.35 port 22: No route to host\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eThen, in the same terminal, one second later:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e❯ /usr/bin/ssh root@10.5.7.35\nWelcome to Ubuntu 22.04 LTS (GNU/Linux 6.8.12-10-pve x86_64)\nroot@reef:~#\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eSame host. Same shell. Same second. One works and one does not. I have never seen anything like it, and it took a while to believe what I was looking at.\u003c/p\u003e","title":"Why ssh stopped working on macOS 26, but /usr/bin/ssh still works"},{"content":"At the start of this project, ~/code/actually_random was an empty directory. I had bought ActuallyRandom.com, but there was no Hugo site, no theme, no GitHub repository and no DNS configuration.\nI opened Claude Code and described what I wanted. Roughly ten minutes of active agent work later, actuallyrandom.com was serving a Hugo blog over HTTPS. It had a theme, search, archives, RSS, Google Analytics and an automatic GitHub Pages deployment on every push to main.\nI did not spend those ten minutes copying YAML from documentation or working out which GitHub Actions needed which permissions. I mostly watched Claude do it.\nThat needs a few qualifications. I already owned the domain, had Claude Code installed and was logged into GitHub, Cloudflare and 1Password on my computer. I also had a Google Analytics measurement ID ready. Buying the domain and setting up those accounts are not included in the ten minutes.\nThe prompt This was the initial request, lightly shortened:\nI just bought ActuallyRandom.com. I want to publish a new Hugo blog on this domain via GitHub Pages. This is a brand new empty directory. Please install the latest version of Hugo, set it up with an appropriate theme, configure the custom domain and tell me how to name the GitHub repository and push the initial version. I will also be setting up Google Analytics.\nI then pasted in the Google Analytics tag.\nThat was enough for Claude Code to inspect my Mac, find the installed tools, upgrade Hugo and start building. This kind of task suits a coding agent well because it crosses several boundaries. Claude needed to edit files, run Hugo, use Git, call the GitHub API, change DNS records and inspect the final website. A chat response could explain all of that. Claude Code could actually do it.\nWhat Claude chose Claude upgraded Hugo from 0.151.2 to 0.164.0 Extended, which was the latest release. It created the site and installed PaperMod as a Git submodule.\nI had not asked for PaperMod specifically. Claude chose it because it is a mature blog theme with responsive layouts, automatic dark mode, client-side search and useful SEO defaults such as Open Graph, Twitter Cards and Schema.org metadata. It also has no JavaScript build dependency. That felt like the right amount of infrastructure for a blog whose main design requirement was \u0026ldquo;please let me publish random things.\u0026rdquo;\nClaude created or configured these files:\nhugo.yaml .github/workflows/hugo.yml .gitignore static/CNAME archetypes/posts.md content/archives.md content/search.md content/posts/hello-world.md themes/PaperMod/ # Git submodule The Hugo configuration set the real base URL, enabled robots.txt, added HTML, RSS and JSON home outputs, and configured PaperMod\u0026rsquo;s search and navigation. It also enabled reading times, breadcrumbs, previous and next post links, code-copy buttons and a table of contents.\nClaude wired the GA4 measurement ID into Hugo\u0026rsquo;s Google Analytics service, built the site, and checked the generated HTML to confirm that the tag was present. It told me that PaperMod only emits the tag on production builds, so hugo server would not pollute my analytics with my own local page views. It wrote that claim into a comment in hugo.yaml as well.\nThe claim was wrong, and it was wrong because of something Claude had done a few lines further down the same file.\nPaperMod decides whether to emit analytics with this condition:\n{{- if hugo.IsProduction | or (eq site.Params.env \u0026#34;production\u0026#34;) }} {{- partial \u0026#34;google_analytics.html\u0026#34; . }} hugo.IsProduction is false under hugo server, which is the mechanism that is supposed to keep development traffic out of the stats. But Claude had also set env: production under params in hugo.yaml. That is a common line to see in PaperMod configs, and it short-circuits the check. With it present, the right-hand side of that or is always true, so the tag fired on every local preview.\nI only found this while fact-checking a later article, when I asked Claude to prove the production-only claim rather than repeat it. Starting hugo server and grepping the response found the measurement ID sitting there twice. Deleting the env: production line fixed it. A development server now emits the tag zero times, a production build emits it once, and Open Graph and Schema.org metadata still render in production, because those sit behind the same condition.\nIt is a small bug with an annoying property: nothing looks broken. The site builds, the tag appears where you check for it, and the only symptom is quietly inflated analytics.\nThe first local build produced 17 pages in about 90 milliseconds. Static site generators are slightly ridiculous in the best possible way.\nPublishing through GitHub Actions Hugo generates the site into public/, but that directory is ignored by Git. GitHub Actions builds a fresh copy instead. This follows the deployment method in the official Hugo GitHub Pages guide.\nThe workflow checks out the repository and its theme submodule, installs the required Hugo version, runs a minified production build, uploads public/ as a Pages artifact and deploys it. It has the pages: write and id-token: write permissions required by GitHub\u0026rsquo;s deploy-pages action.\nClaude suggested naming the repository actuallyrandom.com. The name is descriptive, but it is not required. An Actions-based project site with a custom domain can use any repository name. I already had ndbroadbent.github.io hosting another blog, so I briefly wondered whether that would conflict.\nIt does not. GitHub can host a user site and multiple project sites at the same time. A request for www.actuallyrandom.com reaches GitHub Pages, then GitHub uses the requested hostname to select the repository that owns that custom domain. My existing site at ndbroadbent.github.io remains separate.\nI created the public ndbroadbent/actuallyrandom.com repository in GitHub and gave Claude the SSH URL. Claude pushed the initial commit and watched the workflow.\nIt failed.\nThe first deployment failed The workflow attempted to enable GitHub Pages automatically with enablement: true. The repository\u0026rsquo;s workflow token did not have the repository-admin permission needed to create the Pages site, so the first run stopped after 12 seconds.\nThis was the most useful part of the whole exercise. Claude did not hand me a red workflow and suggest five things to try. It opened the failed run, found the permission problem, created the Pages configuration using my authenticated gh credentials, selected the workflow build type and ran the deployment again.\nThe second run succeeded. Future pushes do not need admin credentials because the Pages site now exists and the workflow only has to build and deploy it.\nThe official instructions make the prerequisite explicit: select GitHub Actions as the Pages source before the first deployment. Trying to hide that setup inside the workflow saved no time in this case. It created one failed run and a good paragraph for this article.\nConfiguring Cloudflare without opening the dashboard I had bought the domain through Cloudflare. I gave Claude the zone and account identifiers and pointed it at a Cloudflare API token stored in 1Password.\nThe first credential lookup failed because two 1Password accounts were connected and there were similarly named Cloudflare items. Claude listed matching item titles without reading or printing their secret fields, selected the intended personal account and tried again. The working token never appeared in the transcript.\nClaude then created the DNS records through the Cloudflare API:\nType Name Destination A @ GitHub Pages\u0026rsquo; four IPv4 addresses AAAA @ GitHub Pages\u0026rsquo; four IPv6 addresses CNAME www ndbroadbent.github.io The exact A and AAAA values are listed in GitHub\u0026rsquo;s custom-domain documentation. GitHub recommends configuring both the apex domain and www; it can then redirect one to the other automatically.\nThe records were left in Cloudflare\u0026rsquo;s DNS-only mode. That lets DNS return GitHub\u0026rsquo;s addresses directly and leaves GitHub in charge of HTTPS. Cloudflare\u0026rsquo;s proxy can be useful, but this site did not need a second CDN, cache or TLS layer in front of GitHub Pages.\nClaude attached actuallyrandom.com to the Pages site, waited for GitHub to issue a certificate, enabled HTTPS enforcement and tested both hostnames. www.actuallyrandom.com redirected to the apex domain, and HTTP redirected to HTTPS.\nOne small correction to the generated repository: Claude created static/CNAME, which causes Hugo to copy a CNAME file into the published site. GitHub\u0026rsquo;s current documentation says that an existing CNAME file is ignored when a site is published through a custom Actions workflow. It is harmless, but the repository setting and DNS records are doing the real work.\nVerifying the domain The blog was already live, but I later added GitHub\u0026rsquo;s domain-verification TXT record through Cloudflare. GitHub recommends doing this before attaching a custom domain, although doing it afterward still protects the domain.\nDomain verification prevents another GitHub user from claiming the domain for their own Pages site if my repository is deleted or Pages becomes disconnected while the DNS records remain. The verification applies to the apex domain and its immediate subdomains. GitHub says to leave the TXT record in place permanently.\nThis step was not part of getting the site online, but it took very little extra work and is worth doing for any custom domain that will remain pointed at GitHub Pages.\nWhat the ten minutes produced By the end, I had:\na working Hugo site using PaperMod; a custom domain with apex and www routing; HTTPS with automatic certificate management; deployment on every push to main; search, archives, tags, RSS, sitemap and robots.txt; a production-only Google Analytics tag; a reusable post archetype and local preview workflow; a verified GitHub Pages domain. The main configuration and deployment work took roughly ten minutes of active Claude time according to the timing lines in the transcript: 4 minutes 19 seconds for the local setup, then about 6 minutes to push, configure DNS, recover from the failed workflow and verify the live site. There were pauses between prompts while I created the repository and supplied account details.\nSo no, this was not ten minutes from \u0026ldquo;I have never heard of Hugo\u0026rdquo; to a live site with no accounts or domain. It was ten minutes from an empty, prepared project directory to a deployed site. That is still a task that would normally consume a decent part of an afternoon, especially once DNS and GitHub Actions became involved.\nWriting posts now The day-to-day workflow is pleasantly boring:\nhugo new content posts/my-random-idea.md hugo server -D The first command creates a draft using the post archetype. The second starts a local server and includes draft content. When the post is ready, I set draft: false, commit it and push to main. GitHub normally publishes the update within about a minute.\nThere is one Hugo trap worth remembering. This site has buildFuture: false, so a post dated even a few minutes ahead of the current time silently disappears from the production build. I managed to hit this with a later article by setting its time to 18:00 when it was only 17:07. The build succeeded, but the post was not there. If a new Hugo post refuses to appear, check its date before debugging anything more exotic.\nWhat Claude Code changed about the job None of the individual steps was difficult. Hugo has good documentation. GitHub publishes an official Actions workflow. Cloudflare has an API. The annoying part is joining them together, carrying values between systems and checking that the final result works.\nClaude Code handled that connective work. It could read the repository, change several files, run builds, use authenticated command-line tools, watch a workflow, inspect DNS and request the live page. When the first approach failed, it still had enough context to diagnose the error and finish the job.\nI would not let it publish blindly. The unnecessary CNAME file is a mild example. The analytics bug is a better one, and it is worth being precise about what went wrong there. Claude did not hallucinate an API or write code that failed to compile. It wrote a plausible, conventional line of configuration, then described the behaviour that line was supposed to produce instead of the behaviour it actually produced. Every individual piece was reasonable. The result was a site quietly counting me as a visitor.\nThe fix came from asking for evidence rather than a restatement. Starting the development server and grepping for the measurement ID takes about fifteen seconds and settles the question completely. An agent will happily check that sort of thing when asked, and will happily not check it when not asked.\nMore importantly, an agent with access to GitHub, DNS and stored credentials can make real changes very quickly. I read the proposed DNS records, approved the public repository and checked the final site.\nBut I did not need to remember the current GitHub Pages workflow format, manually create nine DNS records or spend twenty minutes wondering why the first deployment token lacked permission. I described the outcome and stayed around to make decisions.\nTen minutes later, I had a blog.\nSources Claude Code overview. Hugo: Host on GitHub Pages. GitHub: Using custom workflows with GitHub Pages. GitHub: Managing a custom domain for GitHub Pages. GitHub: Verifying a custom domain for GitHub Pages. PaperMod on GitHub. The Actually Random source repository. ","permalink":"https://actuallyrandom.com/posts/setting-up-and-publishing-a-new-hugo-blog-in-about-10-minutes-using-claude-code/","summary":"\u003cp\u003eAt the start of this project, \u003ccode\u003e~/code/actually_random\u003c/code\u003e was an empty directory. I had bought ActuallyRandom.com, but there was no Hugo site, no theme, no GitHub repository and no DNS configuration.\u003c/p\u003e\n\u003cp\u003eI opened Claude Code and described what I wanted. Roughly ten minutes of active agent work later, \u003ca href=\"https://actuallyrandom.com/\"\u003eactuallyrandom.com\u003c/a\u003e was serving a Hugo blog over HTTPS. It had a theme, search, archives, RSS, Google Analytics and an automatic GitHub Pages deployment on every push to \u003ccode\u003emain\u003c/code\u003e.\u003c/p\u003e","title":"Setting up and publishing a new Hugo blog in about 10 minutes using Claude Code"},{"content":"I have been running madebynathan.com on GitHub Pages since 2010, and ndbroadbent.com for years after that. In all that time I never verified either domain. I did not know I was supposed to. The custom domain worked, the site was up, and nothing ever complained.\nThen I set up this blog, went looking for the correct way to attach a domain, and found a settings page I had never opened.\nWhat verification actually protects you from GitHub Pages works out which repository to serve by matching the Host header of the request against whichever repo has claimed that custom domain. Your DNS points at GitHub. GitHub looks up who owns the name.\nThe problem is what happens when nobody owns it.\nIf the claim ever lapses, and your DNS still points at GitHub, the domain sits there unclaimed. Delete the repository, rename it, disable Pages, or let a bad build wipe the CNAME file, and the binding disappears while the DNS records stay exactly where they were. At that point anyone can create a repository, set your domain as its custom domain, and GitHub will serve their content on your address.\nGitHub\u0026rsquo;s own documentation is blunt about it:\nDomain takeovers can happen when you delete your repository, when your billing plan is downgraded, or after any other change which unlinks the custom domain or disables GitHub Pages while the domain remains configured for GitHub Pages and is not verified.\nVerification binds the domain to your account permanently. Other accounts are then refused, whether or not one of your repositories is currently using it.\nIf you sit behind Cloudflare like I do, the failure is worse rather than better. Cloudflare would proxy the attacker\u0026rsquo;s page and serve it under your own certificate. There would be no browser warning and no broken padlock, just somebody else\u0026rsquo;s content on a domain with fifteen years of backlinks pointing at it. That is a good home for a phishing page.\nHow to do it Open github.com/settings/pages, click \u0026ldquo;Add a domain\u0026rdquo;, and paste in the domain. GitHub gives you a TXT record to create, in the form _github-pages-challenge-USERNAME.example.com, with a random value. Add it at your DNS provider, wait a few seconds, and click Verify.\nThat is the whole process. It costs nothing.\nLeave the TXT record in place afterwards. Deleting it un-verifies the domain, which quietly puts you back where you started.\nThree things that are not obvious Verification happens at the account level, not the repository level. There is no verify button in a repository\u0026rsquo;s settings. This matters because the challenge hostname contains the account name, so a domain served from an organisation must be verified in that organisation\u0026rsquo;s settings, with a hostname like _github-pages-challenge-ORGNAME.\nVerifying a domain also covers its immediate subdomains. From the docs:\nWhen you verify a domain, any immediate subdomains are also included in the verification. For example, if the github.com custom domain is verified, docs.github.com, support.github.com, and any other immediate subdomains will also be protected from takeovers.\nI did not have to do anything for this. I have a small site at dotfiles.ndbroadbent.com, and the moment ndbroadbent.com was verified, the subdomain flipped to protected on its own.\nThe third one nearly caught me out. Because verification is per account, and because it reaches into immediate subdomains, an apex domain owned by one account and a subdomain owned by another will collide. ndbroadbent.com was being served out of a GitHub organisation I had created years ago, while dotfiles.ndbroadbent.com lives in my personal account. Verifying the apex from the organisation would have protected the subdomain on behalf of the wrong account, and my personal account would have been the one locked out.\nVerifying it from my personal account instead would have been worse. That would have blocked the organisation that was actually serving the live site.\nI moved the repository to my personal account and verified from there, so all four sites now sit under one owner. The transfer turned out to be trivial, because the repository had no Actions workflows and no secrets. Secrets are the thing that usually breaks when you move a repository between accounts, and it is worth checking for them before you click the button.\nWas I ever actually at risk? Not really, in the sense that nothing bad happened. The custom domains were continuously claimed by repositories I own, so there was never a window for anyone to grab them.\nBut \u0026ldquo;I never happened to delete that repository\u0026rdquo; is a poor security control. The window opens automatically on the day I rename a repo, retire an old site, or push a build that drops the CNAME file. I would not notice, because the DNS would still resolve and the site would still load right up until it did not. The whole point of verification is that it removes the window rather than relying on me never opening it.\nFifteen years is a long time to leave a five-minute job undone. If you have a custom domain on GitHub Pages, go and check the settings page now.\nSources Verifying your custom domain for GitHub Pages. GitHub Docs. Managing a custom domain for your GitHub Pages site. GitHub Docs. ","permalink":"https://actuallyrandom.com/posts/the-benefits-of-verifying-your-domain-for-github-pages/","summary":"\u003cp\u003eI have been running \u003ca href=\"https://madebynathan.com/\"\u003emadebynathan.com\u003c/a\u003e on GitHub Pages since 2010, and \u003ca href=\"https://ndbroadbent.com/\"\u003endbroadbent.com\u003c/a\u003e for years after that. In all that time I never verified either domain. I did not know I was supposed to. The custom domain worked, the site was up, and nothing ever complained.\u003c/p\u003e\n\u003cp\u003eThen I set up this blog, went looking for the correct way to attach a domain, and found a settings page I had never opened.\u003c/p\u003e\n\u003ch2 id=\"what-verification-actually-protects-you-from\"\u003eWhat verification actually protects you from\u003c/h2\u003e\n\u003cp\u003eGitHub Pages works out which repository to serve by matching the \u003ccode\u003eHost\u003c/code\u003e header of the request against whichever repo has claimed that custom domain. Your DNS points at GitHub. GitHub looks up who owns the name.\u003c/p\u003e","title":"The benefits of verifying your domain for GitHub Pages"},{"content":"I use AI to help write ActuallyRandom.com. Quite a lot, in fact.\nI am not ashamed of this. The whole point of the site is to give me somewhere to put random ideas and experiment with AI, SEO, ads and whatever else catches my attention. The bat article began with something my wife heard on Russian TikTok. The Adrien Brody article began because she was watching Chapelwaite after we ate Thai food. Those ideas came from us. AI helped me research them and turn them into articles.\nI still read every article before publishing it. I check the sources, remove things I do not agree with and change sentences that sound wrong. I do not publish a post unless I am relatively happy with it.\nThere was still a problem. The writing sounded like AI.\nOnce you notice AI writing, you see it everywhere The em dashes were the most obvious sign. ChatGPT loves them. So do Claude and most other writing models. A sentence begins normally, takes a dramatic sideways turn, and then returns with suspiciously perfect punctuation.\nThere were other habits too. Every article had a neat introduction, several evenly sized sections and a conclusion that restated the point. Ideas arrived in groups of three. Ordinary facts became \u0026ldquo;important reminders\u0026rdquo; of something bigger. Sentences used words such as pivotal, landscape, showcase and underscore even when is would have worked.\nThen there are the phrases that are hard to unsee:\nIt is not just about X. It is about Y.\nThis serves as a powerful reminder that\u0026hellip;\nIn today\u0026rsquo;s rapidly evolving landscape\u0026hellip;\nThe result? A more seamless, efficient and intuitive experience.\nNone of these constructions is inherently wrong. Humans use them. The problem is the cluster. Put enough of them into one article and the author starts to sound like the same cheerful corporate chatbot that wrote half of LinkedIn.\nI searched for a way to edit these habits out and found Humanizer, an open source skill created by blader.\nWhat the Humanizer skill does Humanizer is a Markdown file containing detailed editing instructions for an AI agent. It does not run a special model or send text through a separate rewriting service. You give the skill to a compatible agent, then ask that agent to humanize some writing.\nThe current version checks for 33 patterns. These include inflated claims of significance, vague attributions, fake analysis added with dangling \u0026ldquo;-ing\u0026rdquo; phrases, promotional language, synonym cycling, forced groups of three and generic positive conclusions.\nIt also looks at presentation. Humanizer dislikes mechanical bold text, title case on every heading, decorative emoji and lists in which every bullet begins with a bold label. It removes chatbot leftovers such as \u0026ldquo;I hope this helps\u0026rdquo; and \u0026ldquo;Would you like me to continue?\u0026rdquo;\nThe skill is based on Wikipedia\u0026rsquo;s guide to signs of AI writing, which grew out of the work of editors cleaning AI-generated text from Wikipedia. The repository uses the MIT licence and has attracted more than 28,000 GitHub stars.\nThis is an editing checklist, not an AI detector. The skill itself warns that good human writers may use many of these patterns. Perfect grammar does not prove that a model wrote something. Neither does formal vocabulary or a single em dash. It recommends looking for clusters of habits instead.\nThe em dash rule is deliberately extreme Humanizer\u0026rsquo;s strongest rule is simple: the final version must contain no em dashes or en dashes.\nThat is stricter than its own detection advice. Elsewhere, the skill correctly says that an em dash by itself proves nothing. Human journalists and novelists have used the punctuation mark for a very long time.\nBut AI has saturated the internet with em dashes. I now notice them immediately, especially when they appear several times in a short post. I have stopped using them in my own writing. A full stop, comma, colon or pair of parentheses almost always works instead.\nIs that fair to the em dash? Probably not. The em dash will cope.\nHow to install Humanizer The simplest installation method uses the cross-agent Skills CLI:\nnpx skills add blader/humanizer To install it for every supported agent on your computer:\nnpx skills add blader/humanizer --agent \u0026#39;*\u0026#39; You can update it later with:\nnpx skills update humanizer Claude Code users can instead install it as a plugin:\n/plugin marketplace add blader/humanizer /plugin install humanizer@humanizer Then invoke it with /humanizer:humanizer and provide the text you want edited. Because the skill is plain Markdown, it can also work in other agent systems that support skill-style instructions.\nHere is the sort of sentence an AI writing assistant produces without much direction:\nIn today\u0026rsquo;s rapidly evolving digital landscape, AI writing tools are not merely a convenience. They represent a pivotal shift in how creators bring ideas to life, fostering efficiency, creativity and meaningful connection.\nHumanizer would turn that into something closer to this:\nI use AI because it gets a rough article onto the page quickly. The first draft is often useful. It is also full of sentences I would never say.\nThe second version loses information if the original author truly intended to make a grand claim about creativity and connection. Usually they did not. The model supplied those abstractions because they fit many possible articles. Humanizer prefers a concrete statement that someone might be willing to defend.\nThe best part of the skill is its editing loop. It produces a draft, asks itself what still makes the result sound obviously AI-generated, then revises it again. That extra audit catches cases where the model merely swaps a few words and leaves the same rhythm underneath.\nWhat it cannot do Running a draft through Humanizer does not make the writing yours. It can remove common model habits, but it does not know what happened at lunch or why you cared about an obscure question in the first place.\nSpecific details do most of the work. \u0026ldquo;My wife was watching Chapelwaite while we ate tom yum soup, chicken fried rice and panang curry\u0026rdquo; sounds human because it is a strange thing that happened to two particular people. A model would be more likely to sand it down to \u0026ldquo;a casual conversation over lunch.\u0026rdquo;\nThe same applies to opinions. Humanizer can add a little uncertainty or humour, but it should not invent a reaction and attribute it to me. I still need to decide whether I believe the argument, whether a joke is funny and whether the article deserves to exist. It can also overdo the personality pass and produce cute asides that were never mine. Those have to go too.\nIt also does not check facts. A confident falsehood written in a natural voice is still a falsehood. That is arguably worse, because better prose makes it easier to trust. I still open the sources and make sure they support the claims in the article.\nDoes Google care if a blog uses AI? Google\u0026rsquo;s current guidance says that appropriate use of generative AI is not automatically against its rules. The problem is publishing large numbers of pages without adding value, especially when the goal is to manipulate search rankings. That may violate Google\u0026rsquo;s policy against scaled content abuse.\nGoogle recommends useful, original content written for people. It also suggests explaining how automation was used when that context would help readers.\nThat seems reasonable to me. I am happy to say that AI helped write this site. Hiding it would be particularly silly in an article about the tool I use to make AI writing less obvious.\nHumanizer should improve the reading experience, not help fill the web with disguised sludge. If I publish 10,000 generic articles that answer questions nobody asked, removing the em dashes will not rescue them. The useful part comes from choosing a real question, researching it properly and adding some personal reason for caring about the answer.\nMy current process For now, this is how I am writing posts for ActuallyRandom.com:\nI start with a question or observation that genuinely occurred to me. I use AI to research it and produce a first draft with links to the sources. I run the article through Humanizer. I read the result, check the claims and change anything that does not sound like me. I publish it only if I would be comfortable putting my name on it. This article went through that process. AI did much of the research and drafted a large portion of the prose. Humanizer helped edit it. I read the result and approved what you are reading now.\nThe finished article is AI-assisted. I am comfortable putting my name on it, and I hope it is less annoying to read.\nSources blader/humanizer on GitHub. Humanizer SKILL.md, version 2.8.2. Wikipedia: Signs of AI writing. Google Search\u0026rsquo;s guidance on using generative AI content. Google Search\u0026rsquo;s guidance about AI-generated content. ","permalink":"https://actuallyrandom.com/posts/how-to-make-ai-sound-less-like-ai/","summary":"\u003cp\u003eI use AI to help write ActuallyRandom.com. Quite a lot, in fact.\u003c/p\u003e\n\u003cp\u003eI am not ashamed of this. The whole point of the site is to give me somewhere to put random ideas and experiment with AI, SEO, ads and whatever else catches my attention. The bat article began with something my wife heard on Russian TikTok. The Adrien Brody article began because she was watching \u003cem\u003eChapelwaite\u003c/em\u003e after we ate Thai food. Those ideas came from us. AI helped me research them and turn them into articles.\u003c/p\u003e","title":"How to make AI sound less like AI"},{"content":"Yes, Adrien Brody eats Thai food. He has said so directly, on the record.\nThis was not a question I expected to be able to answer with evidence.\nWhy I wanted to know My wife was watching Chapelwaite, the gothic horror series in which Adrien Brody plays Captain Charles Boone. We had just eaten Thai food for lunch: tom yum soup, chicken fried rice and panang curry.\nAt some point, for no useful reason, a question appeared in my head:\nDoes Adrien Brody eat Thai food?\nThere was no connection beyond the fact that Adrien Brody was on the television and Thai food was in the room. This is apparently how my brain chooses its research projects.\nMy first assumption was that he probably does. Famous actors spend more time than the rest of us in tailored suits and standing in front of photographers, but they still have to decide what to eat for lunch. Adrien Brody has played a haunted sea captain, Salvador Dalí, an Italian-American mobster and a murderous aristocrat. None of these roles excludes the possibility of ordering a curry.\nStill, \u0026ldquo;probably\u0026rdquo; is not an answer.\nAdrien Brody loves Thai food Fortunately, the Bangkok Post asked the right question about thirteen years before it occurred to me.\nKong Rithdee interviewed Brody in Bangkok for a profile published on 11 January 2013, headlined \u0026ldquo;Being Brody\u0026rdquo;. The relevant sentence is right there in the third paragraph. Brody, then 39, was \u0026ldquo;full of superlatives for our dear country, with the winning I love Thai food opening and a verbal garland of how welcoming and good-natured we Thais are.\u0026rdquo;\nSo the quote exists. Rithdee, to his credit, is a little suspicious of it. He attributes the enthusiasm to politeness as much as to conviction, and an Oscar winner telling a Thai newspaper that he loves Thai food is not the bravest stance a man ever took. But he said it, and there is no particular reason to think he was lying.\nThe interview happened shortly after Brody had spent Christmas Day at Angkor Wat, alone and on foot. \u0026ldquo;I had a backpack on, a hat, a beard, I don\u0026rsquo;t walk with the security detail,\u0026rdquo; he told Rithdee, gesturing at the staff hovering nearby. He seemed to have enjoyed the anonymity.\nAdrien Brody seems genuinely interested in food The stronger evidence has nothing to do with Thailand.\nIn 2022, a Filipino-Japanese izakaya called Gugu Room opened on Orchard Street, on Manhattan\u0026rsquo;s Lower East Side. According to Resy, the restaurant \u0026ldquo;might not be here if it weren\u0026rsquo;t for actor Adrien Brody.\u0026rdquo; He is friends with one of the partners, Jason Soong, and it was Brody who suggested the Filipino-Japanese concept, which did not really exist anywhere else in New York. \u0026ldquo;When we did our first opening day, he was the first one there,\u0026rdquo; the chef, Markee Manaloto, told Resy. \u0026ldquo;He was a big influence.\u0026rdquo;\nTalking a friend into a restaurant\u0026rsquo;s entire culinary concept is a surprisingly specific contribution from someone best known for acting. It suggests his interest in food goes well beyond eating whatever turns up on the catering table.\nFamous people still have lunch The question sounds silly because celebrity creates a strange category error.\nWhen an actor is on screen, we see a carefully constructed character. Outside the story we mostly see them at premieres and award ceremonies, which is a different kind of performance. Both settings make the actor seem remote from ordinary life. We know Adrien Brody as the actor Adrien Brody, not as a man holding a menu and working out whether he feels like soup.\nBut every famous person spends most of life doing things too mundane to report. They get hungry and look in the fridge. They order the thing they always order, then try a bite from someone else\u0026rsquo;s plate and wish they had ordered that instead. Somewhere between making The Pianist and The Brutalist, Adrien Brody has almost certainly had to decide whether he wanted rice or noodles.\nThe internet usually distorts this in the opposite direction. A celebrity eating at a restaurant becomes news, and the lunch is photographed, described and interpreted. Yet the underlying event stays extremely normal: a person wanted food, and then ate some.\nThat is why I find the answer oddly satisfying. Adrien Brody does not exist only inside films and red-carpet photographs. He likes Thai food, and he once cared enough about a menu to invent a restaurant concept for a friend. These are tiny, inconsequential facts, and they make a famous stranger seem briefly like an ordinary person.\nWould Adrien Brody have enjoyed our lunch? Probably. This part cannot be proven.\nWe had tom yum soup, chicken fried rice and panang curry. His general approval of Thai food is on the record. His feelings about those three specific dishes are not, and I am not going to invent them, because the previous post on this blog is about precisely how that goes wrong.\nThe safest conclusion is that he would have found something he liked on the menu.\nThe answer Does Adrien Brody eat Thai food? Yes.\nHe told the Bangkok Post that he loves it, in an interview given not long after he backpacked around Angkor Wat by himself. He also cared enough about food to talk a friend into opening a Filipino-Japanese izakaya in Manhattan, and then turned up first on opening day.\nThis may not be the most consequential fact ever established through research. It did, however, answer the exact question that appeared in my head during lunch, which is what this website is for.\nSources Kong Rithdee (11 January 2013). Being Brody. Bangkok Post. The original is now paywalled; this links to an archived copy. Ariana DiValentino (22 July 2022). Everything You Need to Know About Gugu Room. Resy. ","permalink":"https://actuallyrandom.com/posts/does-adrien-brody-eat-thai-food/","summary":"\u003cp\u003eYes, Adrien Brody eats Thai food. He has said so directly, on the record.\u003c/p\u003e\n\u003cp\u003eThis was not a question I expected to be able to answer with evidence.\u003c/p\u003e\n\u003ch2 id=\"why-i-wanted-to-know\"\u003eWhy I wanted to know\u003c/h2\u003e\n\u003cp\u003eMy wife was watching \u003cem\u003eChapelwaite\u003c/em\u003e, the gothic horror series in which Adrien Brody plays Captain Charles Boone. We had just eaten Thai food for lunch: tom yum soup, chicken fried rice and panang curry.\u003c/p\u003e\n\u003cp\u003eAt some point, for no useful reason, a question appeared in my head:\u003c/p\u003e","title":"Does Adrien Brody Eat Thai Food?"},{"content":"My wife told me an amazing fact she had picked up from a Russian account on TikTok.\nFor years, the story goes, scientists believed bats were extremely good at echolocation. That was how they flew around dark caves without constantly hitting the walls. Then one scientist X-rayed a batch of bats and found that many of them carried multiple healed fractures. Bats were not brilliant navigators after all. They were terrible at echolocation, crashing into things and breaking bones the whole time. They were just extraordinarily good at healing.\nIt is a great fact. Specific, funny, and it overturns something everyone assumes they know. It even comes with a scientist, an experiment and physical evidence. I wanted to write about it immediately.\nThere was only one problem. It does not appear to be true.\nThe short answer Bats really are good at echolocation. They are not infallible and they do sometimes hit things, but nobody ever X-rayed a pile of bats, found a mess of old fractures, and concluded that the field had it backwards all along.\nThe closest thing I could find was a single published report of one wild big brown bat flying around with a healed fractured radius, plus research showing that wounds in bat flight membranes heal well. Neither supports the story.\nSo it is a joke, or a garbled retelling of something real, or an invented internet fact. I cannot tell which without tracking down the original video. The part that interests me is that I believed it long enough to repeat it.\nThe real discovery of bat echolocation Nobody worked out echolocation by noticing an absence of concussed bats on cave floors.\nIn the late eighteenth century, the Italian biologist Lazzaro Spallanzani observed that bats could navigate in darkness even when they could not see. Experiments by Spallanzani and the Swiss researcher Louis Jurine pointed toward hearing, though nobody yet knew that ultrasound existed.\nThe decisive work came about 150 years later. In the late 1930s and early 1940s, Donald Griffin and Robert Galambos got hold of equipment that could detect ultrasonic calls, and flew bats through rooms strung with suspended wires. The bats dodged the wires when they could call and hear. Obstruct either the calling or the hearing and they struggled. Their 1941 paper was The Sensory Basis of Obstacle Avoidance by Flying Bats, and Griffin later coined the word echolocation.\nLater experiments measured how sensitive the system can be. In one obstacle-avoidance study, bats successfully avoided vertical wires only 0.065 millimetres thick. Echolocating bats also locate and intercept tiny flying insects in complete darkness. Rapid bone repair does not explain that.\nBut bats really do crash into things This is where the fake fact turns annoyingly clever, because bats genuinely do hit things. Their sonar has blind spots.\nIn a 2017 study published in Science, researchers found that bats sometimes flew directly into smooth vertical surfaces. Glass and polished metal behave like acoustic mirrors. Rather than returning an echo to the approaching bat, a smooth surface reflects most of the sound away at an angle. To the bat, it can sound like an open flight path until it is dangerously close.\nThat matters most around modern buildings. A cave wall is rough and scatters echoes back from many angles. A large sheet of glass is not something bat echolocation evolved to handle.\nBats can also be fooled by their own expectations. A 2025 study of Egyptian fruit bats trained bats to land on a perch and then moved it. Some bats kept flying toward the old location despite receiving current sensory information about the change. The researchers described this in terms of learned spatial expectations and where the bats were directing their attention.\nSo bats do make navigation mistakes. That is not evidence that echolocation barely works. Humans walk into freshly cleaned glass doors despite having excellent vision, and nobody concludes that eyesight is a myth and people simply have unusually fast noses.\nAnd bats really can heal injuries There is a grain of truth in the broken bones, too.\nIn 2003, researchers described an adult big brown bat caught in a Toronto attic with a healed fracture in the radius of one wing. It was trapped along with the rest of its colony, and its flight looked irregular. The X-ray showed a break that had knitted back together while offset, already well into remodelling, with no sign that a human had ever repaired it. The bat could fly for extended periods.\nThat is a remarkable case, but it is one bat with one healed fracture. It is not a population riddled with evidence of repeated cave-wall collisions.\nFlight membranes repair themselves as well. A 2009 study in the Journal of Mammalogy followed healing after researchers took small circular biopsies from the wing and tail membranes of 32 big brown bats. The wounds closed at different rates depending on size and location, and tail-membrane wounds healed faster than wing wounds. Later research found that season and reproductive state affected healing too.\nBut a flight membrane is living skin, with blood vessels and nerves and connective tissue running through it. Healing a small hole in one is nothing like rapidly rebuilding a shattered forearm, and none of this research suggests that bats routinely smash themselves apart and carry on as though nothing happened.\nWhy the false version sounded so convincing The TikTok story is almost engineered to slip past a sceptical brain.\nEvery individual component is plausible:\nbats live and fly in dark places bats use echolocation animals sometimes collide with things old fractures show up on X-rays some animals have impressive healing abilities Every one of those is true. The falsehood lives in the joints between them.\nThen there is the shape of the thing. It imitates science without offering anything you can check. It has \u0026ldquo;scientists,\u0026rdquo; but no names. It has an X-ray study, but no species, institution, journal or date. It describes a dramatic reversal of scientific consensus without a paper or any follow-up work. Those gaps should have been the warning. Instead, the mention of a scientist and an X-ray made the claim feel documented.\nIt also reached me through someone I trust. My wife was not claiming to have examined bat skeletons herself. She was passing along a delightful fact. By the time it got to me, the original TikTok account had dropped out of the chain entirely and the source had effectively become her.\nFamiliarity alone nudges us toward believing things, an effect known as the illusory truth effect. Endorsement matters too: experiments have found that misleading posts seem more credible when a trusted person appears to be passing them along. None of this means people are stupid. It means that evaluating every harmless fact from first principles would make ordinary conversation impossible.\nA ten-second test for amazing internet facts I do not want to become the person who interrupts a nice dinner to demand a DOI. Most strange facts are harmless, and half the pleasure is in passing them on.\nBefore publishing one, though, it is worth running through a few questions. Can I name the actual source? \u0026ldquo;A scientist discovered\u0026rdquo; is not a source. Can I find the original study, by searching for the central claim rather than for the pages that repeat it? Do the reputable results reach the same conclusion, or do they merely share keywords? Is the story suspiciously perfect, with a funny reversal and a neat ending, in the way that constructed entertainment usually is? And could the whole thing simply have been a joke? Tone and attribution fall away quickly when a video crosses platforms and languages.\nProfessional fact-checkers call the useful version of this lateral reading: leave the original page and open new tabs to investigate the claim and whoever made it. That is exactly what worked here. Reading the original story more carefully would have achieved nothing, because it contained no evidence to inspect.\nThe verdict Bats are good at echolocation. They make mistakes, particularly around smooth artificial surfaces. At least one wild bat has been documented flying with a naturally healed fracture, and their wing membranes really do heal.\nBut the wonderful claim that bats are secretly terrible at echolocation and merely heal from their constant crashes has nothing behind it.\nI am slightly disappointed. It was a much better fact than the truth.\nIt did turn into a useful example of something else, though. Misinformation does not only arrive as propaganda or a dangerous medical claim. Sometimes it arrives as a charming story about incompetent bats, and I suspect those are the ones that travel furthest.\nSources Griffin, D. R. and Galambos, R. (1941). The sensory basis of obstacle avoidance by flying bats. Journal of Experimental Zoology. Gustafson, Y. and Schnitzler, H. U. (1979). Echolocation and obstacle avoidance in the hipposiderid bat, Asellia tridens. Journal of Comparative Physiology. Greif, S., Zsebők, S., Schmieder, D. and Siemers, B. M. (2017). Acoustic mirrors as sensory traps for bats. Science. Finger, N. M., Eveland, N., Yin, Y. and Moss, C. F. (2025). Spatial priors affect sensory weighting in navigation and landing in Egyptian fruit bats. Journal of Experimental Biology. ter Hofstede, H. M., Miller, J. and Ratcliffe, J. M. (2003). A healed fractured radius in a flying big brown bat (Eptesicus fuscus). Journal of Wildlife Rehabilitation, 26(4). Faure, P. A., Re, D. E. and Clare, E. L. (2009). Wound healing in the flight membranes of big brown bats. Journal of Mammalogy. Ceballos-Vasquez, A., Caldwell, J. R. and Faure, P. A. (2014). Seasonal and reproductive effects on wound healing in the flight membranes of captive big brown bats. Biology Open. Hassan, A. and Barber, S. J. (2021). The effects of repetition frequency on the illusory truth effect. Cognitive Research: Principles and Implications. Mena, P., Barbe, D. and Chan-Olmsted, S. (2020). Misinformation on Instagram: the impact of trusted endorsements on message credibility. Social Media + Society. ","permalink":"https://actuallyrandom.com/posts/are-bats-good-at-echolocation-or-do-they-just-heal-fast/","summary":"\u003cp\u003eMy wife told me an amazing fact she had picked up from a Russian account on TikTok.\u003c/p\u003e\n\u003cp\u003eFor years, the story goes, scientists believed bats were extremely good at echolocation. That was how they flew around dark caves without constantly hitting the walls. Then one scientist X-rayed a batch of bats and found that many of them carried multiple healed fractures. Bats were not brilliant navigators after all. They were terrible at echolocation, crashing into things and breaking bones the whole time. They were just extraordinarily good at healing.\u003c/p\u003e","title":"Are Bats Good at Echolocation, or Do They Just Heal Fast?"},{"content":"I started madebynathan.com in 2010 as a technical blog. Programming, electronics, hardware projects, the usual maker stuff. For about fifteen years that\u0026rsquo;s mostly what it was.\nThen at some point I stopped filtering. I started posting about whatever rabbit hole I fell down that week: simulation theory, wargaming history, the etymology of \u0026ldquo;Cossack\u0026rdquo;. Chasing random curiosities turns out to be a lot of fun, and AI gives me superpowers here. I can go from \u0026ldquo;wait, is Prussia just Russia with a P?\u0026rdquo; to a properly researched deep dive in an afternoon.\nThat\u0026rsquo;s the whole premise of this new blog. So to kick things off, here\u0026rsquo;s an index of the most random posts from the original site, with a paragraph on each. Consider it my credentials.\nThe Reflective Universe Hypothesis If the universe is a computation, could it carry fingerprints of whatever it\u0026rsquo;s running on? This post separates simulators (they reproduce behavior) from emulators (they reproduce the machinery), builds a taxonomy of simulation types, and works out why a universe can never perfectly simulate itself, though compressed universes with simplified rules are still on the table. It ends with a thought experiment I called the Causal Closure Experiment: a sufficiently advanced civilization could search for structured violations of physical law as evidence of a deeper causal layer underneath reality. None of it is testable, which is sort of the point.\nHigher Orders of Possibility A bacterium has no concept of what an insect is, and a rat can\u0026rsquo;t comprehend a city. Every jump in complexity opens a possibility space that the level below can\u0026rsquo;t even represent. This post applies that idea to superintelligence and asks a question I like much better than the usual one: not \u0026ldquo;can an AI have emotions and morals?\u0026rdquo; but \u0026ldquo;what emotions and morals could exist that a human can\u0026rsquo;t even imagine?\u0026rdquo; Empathy is real even though a snake will never conceive of it. Something analogous might sit above us.\nWhy Doesn\u0026rsquo;t Valve Just Make Half-Life 3? This one started with Gabe Newell\u0026rsquo;s yacht. The answer turns out to be boring in a satisfying way: around 2007, Valve stopped being a game studio and became a platform company. Steam\u0026rsquo;s 20 to 30 percent cut of every sale brings in billions a year, more than any single game could, and Valve\u0026rsquo;s famously flat structure has no mechanism for pushing a hundred people through a multi-year AAA project they aren\u0026rsquo;t required to work on. Add the risk of following up one of the most beloved games ever made, and you get the technical term for Valve\u0026rsquo;s position: \u0026ldquo;f*** Half-Life 3 money.\u0026rdquo;\nMelée, Wargaming, Prussia The question that kicked this off: how did \u0026ldquo;melée\u0026rdquo; travel from cavalry charges to Counter-Strike knife fights? The answer runs through Kriegsspiel, the wargame the Prussian army used to train officers from 1812 onward, then H.G. Wells\u0026rsquo; 1913 wargaming rulebook, and on into D\u0026amp;D and video games. Halfway through I got distracted by a second question, which is the ADHD signature move: what actually was Prussia, and is it just Russia with a P? I weigh the two competing etymologies for the name and reach a conclusion you\u0026rsquo;re welcome to fight me over. Melée weapons only.\nFree Men of the Steppe: Kazakhs and Cossacks \u0026ldquo;Cossack\u0026rdquo; and \u0026ldquo;Kazakh\u0026rdquo; name two completely different peoples. One was a frontier warrior culture on the Eastern European steppe, the other is a Turkic nation in Central Asia. Both words come from the same Turkic root, qazaq, a free man of the steppe. English spelling buries the connection; in Russian (казак / казах) it\u0026rsquo;s obvious. My wife is from Kazakhstan and I\u0026rsquo;ve been learning Russian, so this one is personal. It\u0026rsquo;s also a neat example of how a single generic word can fork into two separate ethnonyms within a few centuries.\nAll the Money in the World I watched the 2017 film about the Getty kidnapping and got curious about what \u0026ldquo;richest private citizen in the world\u0026rdquo; actually meant in 1966. The answer: J. Paul Getty\u0026rsquo;s $1.2 billion, which is roughly $8.8 billion in today\u0026rsquo;s money. A few hundred people are richer than that now. Elon Musk alone is sitting on close to $775 billion. The world\u0026rsquo;s richest man of the sixties would be a footnote on a modern rich list, and that disconnect nerd-sniped me into a much bigger question: how has all wealth evolved, since the very beginning of wealth itself? Which turned into the next post.\nWorld History of Value The answer to that question. This one isn\u0026rsquo;t an article at all. It\u0026rsquo;s an interactive timeline of all value in human history, starting at the first stone tools and running through the invention of coinage, the Great Pyramid, peak Rome, and Mansa Musa\u0026rsquo;s hajj, up to Rockefeller, Getty, and today. It tracks the wealthiest person and the wealthiest empire of every era, so you can watch the crown pass from pharaohs to the King of Lydia to oil magnates to tech founders. Go drag the timeline around.\nAmazing Low Budget Films Proof that nobody needs $200 million. The Blair Witch Project cost somewhere around $50k and grossed $248.6 million. Paranormal Activity was shot for $15k in the director\u0026rsquo;s own house and returned about $194 million worldwide. Christopher Nolan made his first film, Following, for $6,000. Kevin Smith put Clerks on his credit cards. The Hunt for Gollum, a fan film that was never allowed to earn a cent, still pulled in 13 million views. As I put it in the original post, all it takes is a camera, a great story, a vision, a lot of dedication, and a talented team of mostly unpaid volunteers.\nSo that\u0026rsquo;s the kind of thing you can expect here, except with even less of a filter. If something looks interesting at 2am, it qualifies.\n","permalink":"https://actuallyrandom.com/posts/the-most-random-posts-on-madebynathan/","summary":"\u003cp\u003eI started \u003ca href=\"https://madebynathan.com/\"\u003emadebynathan.com\u003c/a\u003e in 2010 as a technical\nblog. Programming, electronics, hardware projects, the usual maker stuff. For\nabout fifteen years that\u0026rsquo;s mostly what it was.\u003c/p\u003e\n\u003cp\u003eThen at some point I stopped filtering. I started posting about whatever\nrabbit hole I fell down that week: simulation theory, wargaming history, the\netymology of \u0026ldquo;Cossack\u0026rdquo;. Chasing random curiosities turns out to be a lot of\nfun, and AI gives me superpowers here. I can go from \u0026ldquo;wait, is Prussia just\nRussia with a P?\u0026rdquo; to a properly researched deep dive in an afternoon.\u003c/p\u003e","title":"The Most Random Posts on madebynathan.com"},{"content":"Welcome to Actually Random.\nThis blog is exactly what it sounds like: an outlet for random ideas, experiments, and rabbit holes. Some posts will be deeply researched, some will be half-baked, and that\u0026rsquo;s the point.\nMore soon.\n","permalink":"https://actuallyrandom.com/posts/hello-world/","summary":"\u003cp\u003eWelcome to \u003cstrong\u003eActually Random\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eThis blog is exactly what it sounds like: an outlet for random ideas,\nexperiments, and rabbit holes. Some posts will be deeply researched, some will\nbe half-baked, and that\u0026rsquo;s the point.\u003c/p\u003e\n\u003cp\u003eMore soon.\u003c/p\u003e","title":"Hello, World"}]