Add timeline for legal chaos

Reviewed-on: #23

.gitea/workflows/build_push.yml

@@ -1,61 +1,72 @@
 name: Build and Push Image
 on:
-    push:
-        branches:
-            - master
+  push:
+    branches:
+      - master
 
 jobs:
-    build:
-        name: Build and push image
-        runs-on: ubuntu-latest
-        container: catthehacker/ubuntu:act-latest
-        if: gitea.ref == 'refs/heads/master'
+  build:
+    name: Build and push image
+    runs-on: ubuntu-latest
+    container: catthehacker/ubuntu:act-latest
+    if: gitea.ref == 'refs/heads/master'
 
-        steps:
-            - name: Checkout
-              uses: actions/checkout@v4
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
 
-            - name: Create Kubeconfig
-              run: |
-                  mkdir $HOME/.kube
-                  echo "${{ secrets.KUBEC_CONFIG_BUILDX_NEW }}" > $HOME/.kube/config
+      - name: Create Kubeconfig
+        run: |
+          mkdir $HOME/.kube
+          echo "${{ secrets.KUBEC_CONFIG_BUILDX_NEW }}" > $HOME/.kube/config
 
-            - name: Set up Docker Buildx
-              uses: docker/setup-buildx-action@v3
-              with:
-                  driver: kubernetes
-                  driver-opts: |
-                      namespace=gitea-runner
-                      qemu.install=true
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+        with:
+          driver: kubernetes
+          driver-opts: |
+            namespace=gitea-runner
+            qemu.install=true
 
-            - name: Login to Docker Registry
-              uses: docker/login-action@v3
-              with:
-                  registry: git.aridgwayweb.com
-                  username: armistace
-                  password: ${{ secrets.REG_PASSWORD }}
+      - name: Login to Docker Registry
+        uses: docker/login-action@v3
+        with:
+          registry: git.aridgwayweb.com
+          username: armistace
+          password: ${{ secrets.REG_PASSWORD }}
 
-            - name: Build and push
-              uses: docker/build-push-action@v5
-              with:
-                  context: .
-                  push: true
-                  platforms: linux/amd64,linux/arm64
-                  tags: |
-                      git.aridgwayweb.com/armistace/blog:latest
+      - name: Build and push
+        uses: docker/build-push-action@v5
+        with:
+          context: .
+          push: true
+          platforms: linux/amd64,linux/arm64
+          tags: |
+            git.aridgwayweb.com/armistace/blog:latest
 
-            - name: Deploy
-              run: |
-                  echo "Installing Kubectl"
-                  apt-get update
-                  apt-get install -y apt-transport-https ca-certificates curl gnupg
-                  curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
-                  chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
-                  echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | tee /etc/apt/sources.list.d/kubernetes.list
-                  chmod 644 /etc/apt/sources.list.d/kubernetes.list
-                  apt-get update
-                  apt-get install kubectl
-                  kubectl delete namespace blog
-                  kubectl create namespace blog
-                  kubectl create secret docker-registry regcred --docker-server=${{ vars.DOCKER_SERVER }} --docker-username=${{ vars.DOCKER_USERNAME }} --docker-password='${{ secrets.DOCKER_PASSWORD }}' --docker-email=${{ vars.DOCKER_EMAIL }} --namespace=blog
-                  kubectl apply -f kube/blog_pod.yaml && kubectl apply -f kube/blog_deployment.yaml && kubectl apply -f kube/blog_service.yaml
+      - name: Trivy Scan
+        run: |
+          echo "Installing Trivy "
+          sudo apt-get update
+          sudo apt-get install -y wget apt-transport-https gnupg lsb-release
+          wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
+          echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
+          sudo apt-get update
+          sudo apt-get install -y trivy
+          trivy image --format table --exit-code 1 --ignore-unfixed --vuln-type os,library --severity HIGH,CRITICAL git.aridgwayweb.com/armistace/blog:latest
+
+      - name: Deploy
+        run: |
+          echo "Installing Kubectl"
+          apt-get update
+          apt-get install -y apt-transport-https ca-certificates curl gnupg
+          curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
+          chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
+          echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | tee /etc/apt/sources.list.d/kubernetes.list
+          chmod 644 /etc/apt/sources.list.d/kubernetes.list
+          apt-get update
+          apt-get install kubectl
+          kubectl delete namespace blog
+          kubectl create namespace blog
+          kubectl create secret docker-registry regcred --docker-server=${{ vars.DOCKER_SERVER }} --docker-username=${{ vars.DOCKER_USERNAME }} --docker-password='${{ secrets.DOCKER_PASSWORD }}' --docker-email=${{ vars.DOCKER_EMAIL }} --namespace=blog
+          kubectl apply -f kube/blog_pod.yaml && kubectl apply -f kube/blog_deployment.yaml && kubectl apply -f kube/blog_service.yaml

\

@@ -0,0 +1,22 @@
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[remote "origin"]
+	url = gitea@192.168.178.155:armistace/blog.git
+	fetch = +refs/heads/*:refs/remotes/origin/*
+[branch "master"]
+	remote = origin
+	merge = refs/heads/master
+[branch "kube_deployment"]
+	remote = origin
+	merge = refs/heads/kube_deployment
+[branch "when_to_use_ai"]
+	remote = origin
+	merge = refs/heads/when_to_use_ai
+[pull]
+	rebase = false
+[branch "an_actual_solution_to_the_social_media_ban"]
+	remote = origin
+	merge = refs/heads/an_actual_solution_to_the_social_media_ban

src/content/an_actual_solution_to_the_social_media_ban.md

@@ -11,34 +11,42 @@ Summary: The Social Media ban is an abject failure of policy. I propose an actua
 
 The Australian Government recently announced it would be “watering down” the requirements of the upcoming legislation regarding online safety. The irony isn’t lost on anyone observing the situation. Specifically, the planned mandatory minimum “flag rate” for underage detection technology has been dropped – a clear indication that initial testing proved unachievable. Furthermore, the legislation now only requires tech companies to demonstrate “reasonable steps” to remove children from their platforms.
 
-Let’s be frank: this legislation, as it stands, achieves very little. Experts in the field consistently warned that the approach was flawed and ignored industry input. The result? Parents are arguably in a worse position than before. The focus on punitive measures, rather than practical solutions, has been a misstep, and the relentless pursuit of this agenda by the eSafety Commissioner feels increasingly disconnected from reality.
+Let’s be frank: this legislation, as it stands, achieves very little. Experts in the field consistently warned that the proposed age verification approach was flawed and ignored industry input. The result? Parents are arguably in a worse position than before. The focus on punitive measures, rather than practical solutions, has been a misstep, and the relentless pursuit of this agenda by the eSafety Commissioner feels increasingly disconnected from reality.
 
-It’s important to state that criticism of this legislation isn’t an endorsement of big tech. While I’m actively working to reduce my own reliance on these platforms, this situation was never about punishing companies. It was about the Australian Government overreaching in an area where it lacks the necessary expertise and, frankly, the authority. The driving force behind this appears to be a personal vendetta, fuelled by someone unfamiliar with the fundamental principles of how the internet operates.
+It’s important to state that criticism of this legislation isn’t an endorsement of big tech, in fact I’m actively working to reduce my own reliance on these platforms. It is about the Australian Government overreaching in an area where it lacks the necessary expertise and, frankly, the authority. The driving force behind this appears to be a personal vendetta, fuelled by someone unfamiliar with the fundamental principles of how the internet operates.
 
 So, with the current legislation effectively neutered, what *can* the government do to genuinely help parents navigate the challenges of online safety? I believe there’s a technically feasible solution that doesn’t involve trampling on privacy or creating massive security vulnerabilities.
 
 The answer lies in a system we’ve been using for decades: the Domain Name System (DNS). Simply put, DNS translates human-readable URLs like [https://blog.aridgwayweb.com](https://blog.aridgwayweb.com) into the corresponding IP address (e.g., x.x.x.x). It’s a foundational component of the internet, and while seemingly simple, it’s incredibly powerful.
 
+## What is DNS?
+
 Most people rely on the DNS provided by their Internet Service Provider (ISP) or the manufacturer of their router. However, it’s possible to change this setting. Popular alternatives include Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and paid family-friendly options like OpenDNS. For those with more technical expertise, it’s even possible to run your own DNS server – I personally use Pi-hole to block ads at the network level.
 
-This existing infrastructure offers a unique opportunity. The Chinese government has long leveraged DNS for its “Great Firewall,” demonstrating its capability for large-scale internet control. While that application raises obvious concerns, the underlying technology itself isn’t inherently malicious.
+This existing infrastructure offers a unique opportunity. The Chinese government has long leveraged DNS as part of its “Great Firewall,” demonstrating its capability for large-scale internet censorship and control. While that application raises obvious concerns, the underlying technology itself isn’t inherently malicious and is a good fit for the purposes of *opt in* age verification.
 
 <img alt="Current DNS" height="auto" width="100%" src="{attach}/images/dns_currently.png">
 
+## How can we leverage DNS for age verification?
+
 My proposal is straightforward: the Australian Government could establish a large-scale DNS server within the Communications Department. This server could be configured to redirect requests to specific websites – like Facebook or TikTok – to an internal service that requires some form of authentication or identity verification. Once verified, the request would then be forwarded to the correct IP address.
 
 <img alt="Optional Government DNS" height="auto" width="100%" src="{attach}/images/optional_gov_dns.png">
 
 This DNS server could be *optionally* configured on any router, with ISPs assisting less technically inclined customers. The result? Access to certain websites from that router would require passing through the government’s age verification process.
 
-The authentication could be managed by an adult in the household, providing a valid identity document to establish a secure connection. Mobile phones could also be updated by manufacturers to incorporate this DNS setting.
+The authentication could be managed by an adult in the household, providing a valid identity document to receive some form of auth mechanism (password? passkey? authenticator?) to allow the user to continue to their 'restricted' website.
 
-This would allow for the creation of “Government-certified” or “Family-Friendly” devices – routers or phones pre-configured with this DNS server – ensuring a consistent level of online safety. These devices could be subsidised by the government to ensure accessibility for all families.
+Mobile phones could also have the internal DNS updated by manufacturers to incorporate this DNS setting.
 
-Crucially, this system is optional. Individuals who prefer to manage their own online security – as I do – would remain unaffected. However, for parents who lack the technical skills or desire to implement their own solutions, this offers a practical and effective alternative.
+This would allow for the creation of “Government-certified” or “Family-Friendly” devices – routers or phones pre-configured with this DNS server – ensuring a consistent level of online safety as defined by the Australian Government. These devices could be subsidised by the government to ensure accessibility for all families.
+
+Crucially, this system is optional. Individuals who prefer to manage their own online security – as I do – would remain unaffected. However, for parents who lack the technical skills or desire to implement their own solutions, this offers a practical and effective alternative to managing their child’s online safety.
 
 This approach also avoids the need to collect and store sensitive identity data offshore. No tech company needs to be involved in the verification process, and the skills to build and maintain this system already exist within the Australian public service.
 
 Furthermore, the eSafety Commissioner could easily update the list of websites subject to verification, providing a flexible and responsive system. It wouldn’t cover the entire internet, of course, but it would provide a valuable safety net for those who need it.
 
+## Where to from here?
+
 Now that the government has acknowledged the shortcomings of its initial approach, it’s time to explore real solutions. A government-run, family-friendly DNS system that routes certain domain names to a verification process is a solid starting point for a genuinely effective technical solution to help families navigate the online world.

src/content/designing_and_building_an_ai_enhanced_cctv_system_at_home.md

@@ -0,0 +1,188 @@
+Title: Designing and Building an AI Enhanced CCTV System
+Date: 2026-02-02 20:00
+Modified: 2026-02-03 20:00
+Category: Homelab
+Tags: proxmox, hardware, self host, homelab
+Slug: ai-enhanced-cctv
+Authors: Andrew Ridgway
+Summary: Home CCTV Security has become a bastion cloud subscription awfulness. This blog describes the work involved in creating your own home grown AI enhanced CCTV system. Unfortunately what you save in subscription you lose in time but if you value privacy, it's worth it.
+
+
+### Why Build Your Own AI‑Enhanced CCTV?
+
+When you buy a consumer‑grade security camera, you’re not just paying for the lens and the plastic housing. You’re also paying for a subscription that ships every frame of your backyard to a cloud service you’ll never meet. That data can be used to train models, sold to advertisers, or handed over to authorities on a whim. For many, the convenience outweighs the privacy cost, but for anyone who values control over their own footage, the trade‑off feels unacceptable.
+
+The goal of this project was simple: **keep every byte of video on‑premises, add a layer of artificial intelligence that makes the footage searchable and actionable, and do it all on a budget that wouldn’t break the bank**. Over the past six months I’ve iterated on a design that satisfies those constraints, and the result is a fully local, AI‑enhanced CCTV system that can tell you when a “red SUV” pulls into the driveway, or when a “dog wearing a bandana” wanders across the garden, without ever leaving the house.
+
+---
+
+### The Core Software – Frigate
+
+At the heart of the system sits **Frigate**, an open‑source network video recorder (NVR) that runs in containers and is configured entirely via a single YAML file. The simplicity of the configuration is a breath of fresh air compared with the sprawling JSON or proprietary GUIs of many commercial solutions. A few key reasons Frigate became the obvious choice:
+
+| Feature | Why It Matters |
+|---------|----------------|
+| **Container‑native** | Deploys cleanly on Docker, Kubernetes, or a lightweight LXC. No host‑level dependencies to wrestle with. |
+| **YAML‑driven** | Human‑readable, version‑controlled, and easy to replicate across test environments. |
+| **Built‑in object detection** | Supports car, person, animal, and motorbike detection out of the box, with the ability to plug in custom models. |
+| **Extensible APIs** | Exposes detection events, snapshots, and stream metadata for downstream automation tools. |
+| **GenAI integration** | Recent addition that lets you forward snapshots to a local LLM (via Ollama) for semantic enrichment. |
+
+The documentation is thorough, and the community is active enough that most stumbling blocks are resolved within a few forum posts. Because the entire system is defined in a single YAML file, I can spin up a fresh test instance in minutes, tweak a camera’s FFmpeg options, and see the impact without rebuilding the whole stack.
+
+---
+
+### Choosing the Cameras – TP‑Link Vigi C540
+
+A surveillance system is only as good as the lenses feeding it. I needed cameras that could:
+
+1. Deliver a reliable RTSP stream (the lingua franca of NVRs).
+2. Offer pan‑and‑tilt so a single unit can cover a larger field of view.
+3. Provide on‑board human detection to reduce unnecessary bandwidth.
+4. Remain affordable enough to allow for future expansion.
+
+The **TP‑Link Vigi C540** checked all those boxes. Purchased during a Black Friday sale for roughly AUD 50 each, the three units I started with have proven surprisingly capable:
+
+- **Pan/Tilt** – Allows a single camera to sweep a driveway or front porch, reducing the number of physical devices needed.
+- **On‑board human detection** – The camera can flag a person locally, which helps keep the upstream bandwidth low when the NVR is busy processing other streams.
+- **RTSP output** – Perfectly compatible with Frigate’s ingest pipeline.
+- **No zoom** – A minor limitation, but the field of view is wide enough for my modest property.
+
+The cameras are wired via Ethernet, a decision driven by reliability concerns. Wireless links are prone to interference, especially when the cameras are placed near metal roofs or dense foliage. Running Ethernet required a bit of roof work (more on that later), but the resulting stable connection has paid dividends in stream consistency.
+
+---
+
+### The Host Machine – A Budget Dell Workstation
+
+All the AI magic lives on a modest **Dell OptiPlex 7050 SFF** that I rescued for $150. Its specifications are:
+
+- **CPU:** Intel i5‑7500 (4 cores, 3.4 GHz)
+- **RAM:** 16 GB DDR4
+- **Storage:** 256 GB SSD for the OS and containers, 2 TB HDD for video archives
+- **GPU:** Integrated Intel HD Graphics 630 (no dedicated accelerator)
+
+Despite lacking a powerful discrete GPU, the workstation runs Frigate’s **OpenVINO**‑based SSD‑Lite MobileNet V2 detector comfortably. The model is small enough to execute on the integrated graphics, keeping inference latency low enough for real‑time alerts. CPU utilization hovers around 70‑80 % under typical load, which is high but acceptable for a home lab. The system does run warm, so I’ve added a couple of case fans to keep temperatures in the safe zone.
+
+The storage layout is intentional: the SSD hosts the OS, Docker engine, and Frigate container, ensuring fast boot and container start times. The 2 TB HDD stores raw video, detection clips, and alert snapshots. With the current retention policy (7 days of full footage, 14 days of detection clips, 30 days of alerts) the drive is comfortably sized, though I plan to monitor usage as I add more cameras.
+
+---
+
+### Wiring It All Together – Proxmox and Docker LXC
+
+To keep the environment tidy and reproducible, I run the entire stack inside a **Proxmox VE** cluster. A dedicated node hosts a **Docker‑enabled LXC container** that isolates the NVR from the rest of the homelab. This approach offers several benefits:
+
+- **Resource isolation** – CPU and memory limits can be applied per container, preventing a runaway process from starving other services.
+- **Snapshot‑ready** – Proxmox can snapshot the whole VM, giving me a quick rollback point if a configuration change breaks something.
+- **Portability** – The LXC definition can be exported and re‑imported on any other Proxmox host, making disaster recovery straightforward.
+
+Inside the container, Docker orchestrates the Frigate service, an Ollama server (hosting the LLM models), and a lightweight reverse proxy for HTTPS termination. All traffic stays within the local network; the only external connections are occasional model downloads from Hugging Face and the occasional software update.
+
+---
+
+### From Detection to Context – The Ollama Integration
+
+Frigate’s native object detection tells you *what* it sees (e.g., “person”, “car”, “dog”). To turn that into *meaningful* information, I added a **GenAI** layer using **Ollama**, a self‑hosted LLM runtime that can serve vision‑capable models locally.
+
+The workflow is as follows:
+
+1. **Frigate detects an object** and captures a snapshot of the frame.
+2. The snapshot is sent to **Ollama** running the `qwen3‑vl‑4b` model, which performs **semantic analysis**. The model returns a textual description such as “a white ute with a surfboard on the roof”.
+3. Frigate stores this enriched metadata alongside the detection event.
+4. When a user searches the Frigate UI for “white ute”, the system can match the description generated by the LLM, dramatically narrowing the result set.
+5. For real‑time alerts, a smaller model (`qwen3‑vl‑2b`) is invoked to generate a concise, human‑readable sentence that is then forwarded to Home Assistant.
+
+Because the LLM runs locally, there is no latency penalty associated with round‑trip internet calls, and privacy is preserved. The only external dependency is the occasional model pull from Hugging Face during the initial setup or when a newer version is released.
+
+---
+
+### Home Assistant – The Glue That Binds
+
+While Frigate handles video ingestion and object detection, **Home Assistant** provides the automation backbone. By integrating Frigate’s webhook events into Home Assistant, I can:
+
+- **Trigger notifications** via Matrix when a detection meets certain criteria.
+- **Run conditional logic** to decide whether an alert is worth sending (e.g., ignore cars on the street but flag a delivery van stopping at the gate).
+- **Log events** into a time‑series database for later analysis.
+- **Expose the enriched metadata** to any other smart‑home component that might benefit from it (e.g., turning on porch lights when a person is detected after dark).
+
+The Home Assistant configuration lives in its own YAML file, mirroring the philosophy of “infrastructure as code”. This makes it easy to version‑control the automation logic alongside the NVR configuration.
+
+---
+
+### Semantic Search – Finding a Needle in a Haystack
+
+One of the most satisfying features of the system is the ability to **search footage using natural language**. Traditional NVRs only let you filter by timestamps or simple motion events. With the GenAI‑enhanced metadata, the search bar becomes a powerful query engine:
+
+- Typing “red SUV” returns all clips where the LLM described a vehicle as red and an SUV.
+- Searching “dog with a bandana” surfaces the few moments a neighbour’s pet decided to wear a fashion accessory.
+- Combining terms (“white ute with surfboard”) narrows the results to a single delivery that happened last weekend.
+
+Under the hood, the search is a straightforward text match against the stored descriptions, but the quality of those descriptions hinges on the LLM prompts. Fine‑tuning the prompts has been an ongoing task, as the initial attempts produced generic phrases like “a vehicle” that were not useful for filtering.
+
+---
+
+### Managing Storage and Retention
+
+Video data is notoriously storage‑hungry. To keep the system sustainable, I adopted a tiered retention policy:
+
+| Data Type | Retention | Approx. Size (4 cameras) |
+|------------|-----------|--------------------------|
+| Full video (raw RTSP) | 7 days | ~1.2 TB |
+| Detection clips (30 s each) | 14 days | ~300 GB |
+| Alert snapshots (high‑res) | 30 days | ~150 GB |
+
+The SSD holds the operating system and container images, while the HDD stores the bulk of the video. When the HDD approaches capacity, a simple cron job rotates out the oldest files, ensuring the system never runs out of space. In practice, the 2 TB drive has been more than sufficient for the current camera count, but I have a spare 4 TB drive on standby for future expansion.
+
+---
+
+### Lessons Learned – The Good, the Bad, and the Ugly
+
+#### 1. **Performance Is a Balancing Act**
+Running inference on an integrated GPU is feasible, but the CPU load remains high. Adding a modest NVIDIA GTX 1650 would drop CPU usage dramatically and free headroom for additional cameras or more complex models.
+
+#### 2. **Prompt Engineering Is Real Work**
+The LLM’s output quality is directly tied to the prompt. Early attempts used a single sentence like “Describe the scene,” which resulted in vague answers. Iterating on a multi‑step prompt that asks the model to list objects, colors, and actions has produced far richer metadata.
+
+#### 3. **Notification Fatigue Is Real**
+Initially, every detection triggered a push notification, flooding my phone with alerts for passing cars and stray cats. By adding a simple confidence threshold and a “time‑of‑day” filter in Home Assistant, I reduced noise by 80 %.
+
+#### 4. **Network Stability Matters**
+Wired Ethernet eliminated the jitter that plagued my early Wi‑Fi experiments. The only hiccup was a mis‑wired patch panel that caused occasional packet loss; a quick audit resolved the issue.
+
+#### 5. **Documentation Pays Off**
+Because Frigate’s configuration is YAML‑based, I could version‑control the entire stack in a Git repository. When a change broke the FFmpeg pipeline, a `git revert` restored the previous working state in minutes.
+
+---
+
+### Future Enhancements – Where to Go From Here
+
+- **GPU Upgrade** – Adding a dedicated inference accelerator (e.g., an Intel Arc or NVIDIA RTX) to improve detection speed and lower CPU load.
+- **Dynamic Prompt Generation** – Using a small LLM to craft context‑aware prompts based on the time of day, weather, or known events (e.g., “delivery” vs. “visitor”).
+- **Smart Notification Decision Engine** – Training a lightweight classifier that decides whether an alert is worth sending, based on historical user feedback.
+- **Edge‑Only Model Updates** – Caching Hugging Face models locally and scheduling updates during off‑peak hours to eliminate any internet dependency after the initial download.
+- **Multi‑Camera Correlation** – Linking detections across cameras to track a moving object through the property, enabling a “follow‑the‑intruder” view.
+
+---
+
+### A Personal Note – The Roof, the Cables, and My Dad
+
+All the technical wizardry would have been for naught if I hadn’t managed to get Ethernet cables from the house’s main distribution board up to the roof where the cameras sit. I’m decent with Docker, YAML, and LLM prompts, but I’m hopeless when it comes to climbing ladders and threading cables through roof joists.
+
+Enter my dad. He spent an entire Saturday hauling a coil of Cat‑6, pulling the cables into the roof space while I fumbled with the tools. He didn’t care that I’d rather be writing code than wielding a hammer; There were apparently 4 days of pain afterwards so please know the help was truly appreciated. The result is a rock‑solid wired backbone that keeps the cameras streaming without hiccups.
+
+Thank you, Dad. Your patience, muscle, and willingness to get your hands dirty made this whole system possible.
+
+---
+
+### Bringing It All Together – The Architecture
+
+<img alt="CCTV Architecture" height="auto" width="100%" src="{attach}/images/CCTV_ARCH.png">
+
+---
+
+### Closing Thoughts
+
+Building an AI‑enhanced CCTV system from the ground up has been a rewarding blend of hardware tinkering, software orchestration, and a dash of machine‑learning experimentation. The result is a **privacy‑first, locally owned surveillance platform** that does more than just record—it understands. It can answer natural‑language queries, send context‑rich alerts, and integrate seamlessly with a broader home‑automation ecosystem.
+
+If you’re a hobbyist, a small‑business owner, or anyone who values data sovereignty, the stack described here offers a solid foundation. Start with a single camera, get comfortable with Frigate’s YAML configuration, and gradually layer on the AI components. Remember that the most valuable part of the journey is the learning curve: each tweak teaches you something new about video streaming, inference workloads, and the quirks of your own network.
+
+So, roll up your sleeves, grab a ladder (or enlist a dad), and give your home the eyes it deserves—without handing the footage over to a faceless cloud. The future of home surveillance is local, intelligent, and, most importantly, under your control. Cheers!

src/content/google_ai_is_rising.md

@@ -0,0 +1,31 @@
+Title: Google AI is Rising
+Date: 2025-12-21 20:00
+Modified: 2025-12-23 10:00
+Category: AI
+Tags: AI, Google, Tech
+Slug: google-ai-is-rising
+Authors: Andrew Ridgway
+Summary: After a period of seeming hesitation, one tech giant is now a serious contender in the AI race. Leveraging its massive and uniquely personal datasets – gleaned from widely used services like search, email, and calendars – it’s releasing models that are quickly challenging existing benchmarks. This arrival is significant, creating a more competitive landscape and potentially pushing innovation forward. However, it also highlights crucial privacy concerns given the depth of data access. The company’s recent open-source contributions suggest a multifaceted approach, but users should be mindful of data control and consider diversifying their digital footprint.
+
+# Google AI is Rising
+
+The landscape of Artificial Intelligence is shifting, and a familiar name is finally asserting its dominance. For a while there, it felt like Google was… well, lagging. Given the sheer volume of data at its disposal, it was a surprise to many that they weren’t leading the charge in Large Language Models (LLMs). But the moment appears to have arrived. Google seems to have navigated its internal complexities and is now delivering models that are genuinely competitive, and in some cases, surpassing the current benchmarks.
+
+The key to understanding Google’s potential lies in the data they’ve accumulated. Consider the services we willingly integrate into our daily lives: email through Gmail, scheduling with Google Calendar, advertising interactions, and of course, the ubiquitous Google Search. Crucially, we provide this data willingly, often tied to a single Google account. This isn’t just a large dataset; it’s a *targeted* dataset, offering an unprecedented level of insight into individual behaviours and preferences. 
+
+This data advantage is now manifesting in the performance of Gemini, Google’s latest LLM. Recent discussions within the tech community – on platforms like [Hacker News](https://news.ycombinator.com/item?id=46301851) and [Reddit](https://www.reddit.com/r/singularity/comments/1p8sd2g/experiences_with_chatgpt51_vs_gemini_3_pro/) and [Reddit](https://www.reddit.com/r/GeminiAI/comments/1p953al/gemini_seems_to_officially_be_better_than_chatgpt/) – suggest Gemini is rapidly gaining ground, and in some instances, exceeding the capabilities of established models.
+
+Google’s history is one of immense scale and profitability, exceeding the GDP of many nations. This success, however, has inevitably led to the creation of large, protective bureaucracies. While necessary for safeguarding revenue streams, these structures can stifle innovation and slow down decision-making. Ideas often have to navigate multiple layers of management, sometimes overseen by individuals whose expertise lies in business administration rather than the intricacies of neural networks and algorithmic functions.
+
+The arrival of a truly competitive Google model is a significant development. OpenAI, previously considered the frontrunner, now faces a formidable challenge.  Furthermore, Anthropic is gaining traction amongst developers, with many preferring their models for coding assistance. This shift suggests a growing demand for tools tailored to specific professional needs.
+
+It’s important to acknowledge that neither Google nor OpenAI are inherently benevolent entities. However, with Google now fully engaged in the LLM race, the potential implications are considerable. Gemini’s access to deeply personal data – email content, calendar events, even metadata – raises legitimate privacy concerns.  It’s a sobering thought to consider the extent of data visibility Google possesses, particularly when we don’t directly own the services we use. This reality strengthens the argument for greater data control and the exploration of self-hosted alternatives.
+
+Google’s commitment to open-source initiatives, demonstrated through the release of the Gemma models (which, incidentally, powered the creation of this very blog), signals a broader strategy.  The technology is here, it’s evolving rapidly, and its influence will only continue to grow.  
+
+While complete resistance may be unrealistic, individuals can take steps to mitigate potential risks. Fragmenting your data across different services, diversifying email providers, and avoiding single sign-on (SSO) with Google are all proactive measures that can help reclaim a sense of control.  (Though, let’s be honest, anyone still using Chrome is already operating within a highly monitored ecosystem.)
+
+The future of AI is unfolding quickly, and Google is now a major player. It’s a development that warrants careful consideration, and a renewed focus on data privacy and digital autonomy.
+
+
+

src/content/how_legal_systems_interact_to_create_bad_outcomes_part_1.md

@@ -0,0 +1,154 @@
+Title: How Legal Systems Interact To Create Bad Outcomes Part 1  
+Date: 2026-04-29  
+Modified: 2026-04-29  
+Category: Policy  
+Tags: health, superannuation, tax, australia, bureaucracy, ai_content, not_human_content  
+Slug: how-legal-systems-interact-bad-outcomes-part-1  
+Authors: glm-5.1.ai, nemotron-3-nano.ai, gemma4.ai, deepseek-v4-flash.ai  
+Summary: A detailed timeline shows how Australia’s health, superannuation and human‑services systems collide, turning a routine injury into a costly, stressful ordeal.  
+
+---
+
+## Introduction  
+
+When a child tears a knee ligament on the school field, most parents expect a clear path to recovery: a doctor’s visit, a referral, surgery if needed, and a return to sport. In practice, the journey can become a maze of separate legal and administrative regimes that do not speak to each other. The result is a set of unintended consequences that make an already painful situation even harder to navigate.
+
+This post is the first installment of a three‑part series. It does not attempt to solve the problem; it simply lays out the facts, the dates, and the interactions between three distinct systems:
+
+1. **The health‑care system** – public and private pathways for diagnosis, surgery and rehabilitation.  
+2. **The superannuation and tax system** – the “compassionate release” of superannuation to fund medical expenses and the tax treatment of that release.  
+3. **The human‑services system** – child‑care subsidies and other income‑support payments that are affected by changes in taxable income.
+
+By the end of this article you will see how each system operates in isolation, why their rules clash, and how those clashes created a cascade of financial and administrative burdens for my family.
+
+---
+
+## The Context  
+
+My daughter had been playing rugby for several months and was thriving. The sport gave her confidence, fitness and a sense of belonging. In June 2024 she suffered a serious knee injury at school. The injury required surgical reconstruction – a procedure that, in a well‑functioning system, would be scheduled, performed, and followed by a structured rehabilitation program.
+
+Australia’s health‑care landscape offers two routes:
+
+* **Public (Medicare‑funded) care** – free at the point of service but subject to long waiting lists for elective orthopaedic surgery.  
+* **Private care** – faster access for those who can afford out‑of‑pocket costs and have private health insurance that covers part of the bill.
+
+The decision to go private was driven by the projected wait time in the public system. The public waiting period for a similar orthopaedic case, according to the Australian Institute of Health and Welfare, can be twelve to twenty‑four months for triage alone. That timeline would have added a year or more to my daughter’s recovery, risking loss of fitness, mental‑health strain and secondary health issues.
+
+---
+
+## Timeline of Events  
+
+### June 2024 – The Injury and Initial Medical Response  
+
+* **School incident** – My daughter fell during a rugby drill, sustaining a complex ligament injury.  
+* **Emergency department visit** – The local hospital splinted the knee, ruled out fractures, and advised follow‑up with our general practitioner (GP).  
+* **GP consultation** – The GP explained the public‑system waiting period (12‑24 months for triage) and asked which specialist we would prefer for a private referral.  
+
+**Key failure point:** The public system’s lack of proactive care meant the injury was treated as a routine case, ignoring the time‑sensitive nature of a young athlete’s rehabilitation. The delay would have turned a treatable injury into a chronic problem.
+
+### July 2024 – Specialist Assessment and Financial Planning  
+
+* **Referral to a private orthopaedic surgeon** – After researching local specialists, we booked an appointment with a well‑known surgeon who routinely treats sports‑related knee injuries.  
+* **Surgical recommendation** – The surgeon confirmed that reconstruction was necessary to restore stability and function.  
+* **Fee schedule** – The surgeon provided a detailed breakdown:  
+  * Surgeon’s fee: $8,000  
+  * Anaesthetist: $1,500  
+  * Hospital fees (covered by private health insurance): $0 for the stay, but a $1,000 Medicare rebate for the procedure.  
+* **Gap‑cover discussion** – We asked whether the surgeon participated in a gap‑cover arrangement that would reduce out‑of‑pocket costs. The surgeon declined, explaining that participating would reduce her fee to a level that would not cover indemnity insurance, hospital overheads and professional expenses.  
+
+**Key failure point:** The private system’s gap‑cover model leaves many patients exposed to high out‑of‑pocket costs, especially when specialists opt out for financial viability reasons.
+
+### August 2024 – Accessing Superannuation  
+
+* **Exploring financing options** – With a total out‑of‑pocket cost of roughly $8,500 after Medicare, we evaluated personal loans, credit cards and the “compassionate release” of superannuation.  
+* **Compassionate release research** – The Australian Taxation Office (ATO) provides a pathway to withdraw super early for serious medical conditions. The process requires extensive documentation: medical reports, invoices no older than six months, proof of identity and relationship, and a signed application.  
+* **Cost‑benefit analysis** – Although the released amount would be treated as taxable income, the tax liability (approximately 20 % after the 10 % tax offset for early release) was still lower than the interest that would accrue on a personal loan of $8,500.  
+* **Application preparation** – We spent several evenings gathering medical reports, invoices, and completing the online form via myGov. The ATO’s online portal limits attachments to 20 files, each under 10 MB, and does not accept screenshots of messages.  
+* **Approval** – Within two weeks the ATO approved the release. The super fund deducted the required tax and transferred the net amount to our bank account.  
+
+**Key failure point:** The compassionate release process is designed for emergencies, yet the administrative burden is comparable to a full tax return. The system treats a genuine medical need as a bureaucratic hurdle, and the tax treatment erodes the financial benefit.
+
+### September 2024 – Surgery and Immediate After‑care  
+
+* **Surgery date** – The operation was performed at a private hospital on 12 September 2024.  
+* **Payment** – We settled the surgeon’s invoice and the anaesthetist’s fee using the released super funds.  
+* **Hospital stay** – The stay was covered by private health insurance, avoiding additional charges.  
+
+### October 2024 – Rehabilitation Begins  
+
+* **Physiotherapy** – A structured physiotherapy program started two weeks post‑surgery, with sessions three times per week for the first month, then tapering to weekly.  
+* **Out‑of‑pocket physiotherapy costs** – Approximately $150 per session, partially covered by private health insurance after the first six sessions.  
+
+### November 2024 – Tax Return for the Prior Financial Year  
+
+* **2023/24 tax filing** – Our accountant prepared the return. The compassionate release of super occurred in the 2024/25 financial year, so it did not appear on the 2023/24 return.  
+* **Normal tax season** – No unusual adjustments were required for that year.  
+
+### April 2025 – Return to Rugby  
+
+* **2024 rugby season** – My daughter rejoined training in April 2025. She could not yet play competitively but was able to participate in drills and conditioning.  
+* **Contrast with public pathway** – Had we remained in the public system, the surgery would still have been pending, and she would have missed the entire season.  
+
+---
+
+## How the Three Systems Interact  
+
+### 1. Health‑Care System  
+
+* **Public side** – Provides universal access but suffers from chronic under‑funding, leading to long waiting lists for elective orthopaedic surgery.  
+* **Private side** – Offers speed at a price. The gap‑cover model, intended to bridge the cost gap, is optional for specialists. When specialists opt out, patients face the full fee.  
+
+### 2. Superannuation and Tax System  
+
+* **Compassionate release** – Allows early withdrawal of super for serious medical conditions, but the released amount is added to taxable income. The ATO withholds tax at the marginal rate, reducing the net benefit.  
+* **Administrative load** – The application requires multiple certified documents, strict file‑size limits and a separate process from the usual tax return. Errors (out‑of‑date invoices, missing medical reports) cause delays or rejections.  
+
+### 3. Human‑Services System  
+
+* **Child‑care subsidy** – Calculated on the basis of taxable income. When the compassionate release is added to income, the subsidy can be reduced or lost, even though the money was spent on a medical expense.  
+* **Other income‑support payments** – Similar rules apply to family tax benefits and low‑income health care cards. A temporary rise in assessable income can trigger a loss of eligibility for months after the medical expense has been paid.  
+
+### The Cascading Effect  
+
+1. **Medical need** triggers a decision to go private.  
+2. **Private cost** forces us to tap super, which **increases taxable income**.  
+3. **Higher taxable income** reduces eligibility for child‑care subsidies and other benefits.  
+4. **Reduced subsidies** increase out‑of‑pocket costs for future expenses (e.g., physiotherapy, school fees).  
+
+The systems operate in silos, each assuming the others will not interfere. In reality, a single event ripples through all three, creating a net loss far greater than the original medical expense.
+
+---
+
+## Reflections on the Experience  
+
+### The Emotional Toll  
+
+Navigating three bureaucracies while caring for a recovering child is exhausting. Each phone call, each form, each email adds to the stress. The process feels deliberately opaque; the language used by the ATO and health insurers assumes a level of legal literacy that most families do not possess.
+
+### Financial Reality  
+
+* **Total out‑of‑pocket cost** – Approximately $9,500 after Medicare and private health rebates.  
+* **Tax on super release** – Roughly $1,700 withheld, leaving a net cash flow of $7,800.  
+* **Lost child‑care subsidy** – An estimated $2,000 over the 2024/25 year due to the temporary income increase.  
+
+When all factors are added, the effective cost of the injury exceeds $12,000, far beyond the quoted surgical fees.
+
+### Systemic Implications  
+
+The case illustrates a broader problem: policies designed to protect individuals in isolation can combine to produce perverse outcomes. The compassionate release of super is meant to be a safety net, yet its tax treatment and interaction with income‑tested benefits erode that safety net. The private health gap‑cover model aims to reduce out‑of‑pocket expenses, but specialist opt‑out leaves many families exposed.
+
+---
+
+## What This Post Does Not Cover  
+
+This article stops at the end of the 2024/25 tax year. The next installment will trace how the tax return, the ATO’s assessment, and the subsequent adjustment of human‑services payments unfold, and will analyse why the term “compassionate” is misleading in this context.
+
+---
+
+## Conclusion  
+
+A single knee injury set off a chain reaction across three distinct legal frameworks. The public health system’s long waits, the private system’s fee structure, the superannuation release rules, and the income‑tested human‑services payments each functioned as intended when viewed alone. Together they produced a result that was far more costly, stressful and time‑consuming than any of the individual policies anticipated.
+
+Understanding this interaction is the first step toward reform. By exposing the hidden links, families, policymakers and advocates can begin to ask the right questions: How can we design a compassionate release that does not penalise taxable income? How can gap‑cover be made universally available without jeopardising specialist viability? How can public orthopaedic pathways be accelerated for young athletes?
+
+The answers will be explored in Part 2 and Part 3 of this series. For now, the timeline above serves as a record of what happened, why it happened, and what it cost – both in dollars and in peace of mind.