Compare commits
No commits in common. "master" and "gpt_oss__is_it_eee" have entirely different histories.
master
...
gpt_oss__i
@ -1,72 +1,61 @@
|
|||||||
name: Build and Push Image
|
name: Build and Push Image
|
||||||
on:
|
on:
|
||||||
push:
|
push:
|
||||||
branches:
|
branches:
|
||||||
- master
|
- master
|
||||||
|
|
||||||
jobs:
|
jobs:
|
||||||
build:
|
build:
|
||||||
name: Build and push image
|
name: Build and push image
|
||||||
runs-on: ubuntu-latest
|
runs-on: ubuntu-latest
|
||||||
container: catthehacker/ubuntu:act-latest
|
container: catthehacker/ubuntu:act-latest
|
||||||
if: gitea.ref == 'refs/heads/master'
|
if: gitea.ref == 'refs/heads/master'
|
||||||
|
|
||||||
steps:
|
steps:
|
||||||
- name: Checkout
|
- name: Checkout
|
||||||
uses: actions/checkout@v4
|
uses: actions/checkout@v4
|
||||||
|
|
||||||
- name: Create Kubeconfig
|
- name: Create Kubeconfig
|
||||||
run: |
|
run: |
|
||||||
mkdir $HOME/.kube
|
mkdir $HOME/.kube
|
||||||
echo "${{ secrets.KUBEC_CONFIG_BUILDX_NEW }}" > $HOME/.kube/config
|
echo "${{ secrets.KUBEC_CONFIG_BUILDX_NEW }}" > $HOME/.kube/config
|
||||||
|
|
||||||
- name: Set up Docker Buildx
|
- name: Set up Docker Buildx
|
||||||
uses: docker/setup-buildx-action@v3
|
uses: docker/setup-buildx-action@v3
|
||||||
with:
|
with:
|
||||||
driver: kubernetes
|
driver: kubernetes
|
||||||
driver-opts: |
|
driver-opts: |
|
||||||
namespace=gitea-runner
|
namespace=gitea-runner
|
||||||
qemu.install=true
|
qemu.install=true
|
||||||
|
|
||||||
- name: Login to Docker Registry
|
- name: Login to Docker Registry
|
||||||
uses: docker/login-action@v3
|
uses: docker/login-action@v3
|
||||||
with:
|
with:
|
||||||
registry: git.aridgwayweb.com
|
registry: git.aridgwayweb.com
|
||||||
username: armistace
|
username: armistace
|
||||||
password: ${{ secrets.REG_PASSWORD }}
|
password: ${{ secrets.REG_PASSWORD }}
|
||||||
|
|
||||||
- name: Build and push
|
- name: Build and push
|
||||||
uses: docker/build-push-action@v5
|
uses: docker/build-push-action@v5
|
||||||
with:
|
with:
|
||||||
context: .
|
context: .
|
||||||
push: true
|
push: true
|
||||||
platforms: linux/amd64,linux/arm64
|
platforms: linux/amd64,linux/arm64
|
||||||
tags: |
|
tags: |
|
||||||
git.aridgwayweb.com/armistace/blog:latest
|
git.aridgwayweb.com/armistace/blog:latest
|
||||||
|
|
||||||
- name: Trivy Scan
|
- name: Deploy
|
||||||
run: |
|
run: |
|
||||||
echo "Installing Trivy "
|
echo "Installing Kubectl"
|
||||||
sudo apt-get update
|
apt-get update
|
||||||
sudo apt-get install -y wget apt-transport-https gnupg lsb-release
|
apt-get install -y apt-transport-https ca-certificates curl gnupg
|
||||||
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
|
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
|
||||||
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
|
chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
|
||||||
sudo apt-get update
|
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
|
||||||
sudo apt-get install -y trivy
|
chmod 644 /etc/apt/sources.list.d/kubernetes.list
|
||||||
trivy image --format table --exit-code 1 --ignore-unfixed --vuln-type os,library --severity HIGH,CRITICAL git.aridgwayweb.com/armistace/blog:latest
|
apt-get update
|
||||||
|
apt-get install kubectl
|
||||||
- name: Deploy
|
kubectl delete namespace blog
|
||||||
run: |
|
kubectl create namespace blog
|
||||||
echo "Installing Kubectl"
|
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
|
||||||
apt-get update
|
kubectl apply -f kube/blog_pod.yaml && kubectl apply -f kube/blog_deployment.yaml && kubectl apply -f kube/blog_service.yaml
|
||||||
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
|
|
||||||
|
|||||||
22
\
22
\
@ -1,22 +0,0 @@
|
|||||||
[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
|
|
||||||
@ -1,52 +0,0 @@
|
|||||||
Title: An Actual Solution to the Social Media Ban
|
|
||||||
Date: 2025-09-16 20:00
|
|
||||||
Modified: 2025-09-17 20:00
|
|
||||||
Category: Politics
|
|
||||||
Tags: politics, social meda, tech policy
|
|
||||||
Slug: actual-social-media-solution
|
|
||||||
Authors: Andrew Ridgway
|
|
||||||
Summary: The Social Media ban is an abject failure of policy. I propose an actual technical solution that addresses the issues raised by the legislation and also ensures user privacy and data security through an opt in solution.
|
|
||||||
|
|
||||||
## The Toothless Legislation
|
|
||||||
|
|
||||||
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 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, 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 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 receive some form of auth mechanism (password? passkey? authenticator?) to allow the user to continue to their 'restricted' website.
|
|
||||||
|
|
||||||
Mobile phones could also have the internal DNS updated by manufacturers to incorporate this DNS setting.
|
|
||||||
|
|
||||||
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.
|
|
||||||
@ -1,41 +0,0 @@
|
|||||||
Title: Apple And The Anti-Dev Platform
|
|
||||||
Date: 2025-08-28 20:00
|
|
||||||
Modified: 2025-08-28 20:00
|
|
||||||
Category: Tech, Software, Apple
|
|
||||||
Tags: Tech, Software, Apple
|
|
||||||
Slug: apple-anti-dev
|
|
||||||
Authors: Andrew Ridgway
|
|
||||||
Summary: Apples requirements for developers are onerous, I detail some of the frustrations I've had whilst dealing with the platform to deploy a small app as part of my day job
|
|
||||||
|
|
||||||
## Introduction: Why I Hate Loving to Hate Apple
|
|
||||||
|
|
||||||
This week, I found myself in the unenviable position of using MacOS for work. It was like revisiting an old flame only to realize they’ve become *that* person—still attractive from afar, but toxic up close. Let me clarify: I’m not anti-Apple per se. I appreciate their design aesthetic as much as anyone. But when you’re a developer, especially one with a penchant for Linux and a deep love for open-source, Apple’s ecosystem feels like walking into a store where the sign says "Employee Discounts" but they charge you double for the privilege.
|
|
||||||
|
|
||||||
## 1. The Hardware-Software Tie-In: Why Buy New Every Year?
|
|
||||||
|
|
||||||
Let’s talk about my borrowed MacBook from 2020. It was a kind gesture, right? But here’s the kicker: this machine, which was cutting-edge just five years ago, is now deemed too old to run the latest MacOS. I needed Xcode for a project, and guess what? You can’t run the latest version of Xcode without the latest MacOS. So, to paraphrase: "Sorry, but your device isn’t *new enough* to develop on the Apple platform anymore." This isn’t just inconvenient; it’s a deliberate strategy to force upgrades. It’s like buying a car that requires you to upgrade your entire garage every year just to keep it running.
|
|
||||||
|
|
||||||
## 2. Forced Obsolescence: The New "Upgrade" Cycle
|
|
||||||
|
|
||||||
Yes, Microsoft did the whole TPM 2.0 thing with Windows 11. But Apple takes it to another level. They’ve turned hardware into a subscription model without you even realizing it. You buy a device, and within a few years, it’s obsolete for their latest software and tools. This isn’t about security or innovation—it’s about control. Why release an operating system that only works on devices sold in the last 12 months? It creates a false market for "new" hardware, padding Apple’s margins at the expense of developers and users.
|
|
||||||
|
|
||||||
## 3. High Costs: The Developer Fee That Keeps On Giving
|
|
||||||
|
|
||||||
I honestly believe this actually boils down to money? To develop on Apple’s platform, you need an Apple Developer account. This costs $150 AUD a year. Now, if I were to buy a new MacBook Pro today, that would set me back around $2,500 AUD. And for what? The privilege of being able to build apps on my own device? It’s like paying a toll every year just to use the road you already own. It’s enough to make you consider a career change and become a sheep farmer.
|
|
||||||
|
|
||||||
## 4. Lack of Freedom: Who Owns the Device Anyway?
|
|
||||||
|
|
||||||
Here’s where it gets really egregious: Apple’s developer review process. It’s like being subjected to a TSA pat-down every time you want to build something, even if it's just for your own device. To deploy ANYTHING onto an IOS device I need to hand my Government issued license over to Apple and let them "check I'm a real person". And no this isn't just for the app store deployments, which I can understand. This is for any deployment, it's the only way to get a certificate to cross sign on the app and device... Google might be heading down a similar path, but at least you'll be able to on custom Android ROmS. On Apple, it feels like every step is designed to remind you that you’re dancing in their sandbox—and they call the shots. If you use IOS you have to dance to their tune AT ALL TIMES.
|
|
||||||
|
|
||||||
## 5. The "Apple Tax": A Future Job Requirement
|
|
||||||
|
|
||||||
I think all developers and consultants should demand an "Apple Tax." It will be simple:
|
|
||||||
|
|
||||||
* $5,000 AUD for new Apple hardware.
|
|
||||||
* An additional 25% markup on development hours spent navigating Apple’s ecosystem.
|
|
||||||
|
|
||||||
Why? Because it's time developers passed on these costs to the users. It's time to make this hurt the consumers who insist on using these products with predatory business models for developers. Yes, developers go where the market is, but it's time to start charging that market so it understands the true cost to be there.
|
|
||||||
|
|
||||||
## Conclusion: Why I’ll Keep Hating Loving to Hate Apple
|
|
||||||
|
|
||||||
Apple’s ecosystem feels like a love story gone wrong—a relationship where one party keeps raising the stakes just to remind you of how much they control everything. Developers are supposed to be the disruptors, the rebels who challenge the status quo. But when your tools are designed to keep you tethered to a specific platform and its outdated business model, it feels less like innovation and more like indentured servitude. If you’re still enamored with Apple’s ecosystem and think it’s “just part of the game,” I urge you to take a long, hard look in the mirror. Because if this is your idea of progress, we’re all in trouble.
|
|
||||||
@ -1,188 +0,0 @@
|
|||||||
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!
|
|
||||||
@ -1,31 +0,0 @@
|
|||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -3,13 +3,12 @@ Date: 2025-08-12 20:00
|
|||||||
Modified: 2025-08-14 20:00
|
Modified: 2025-08-14 20:00
|
||||||
Category: Politics, Tech, AI
|
Category: Politics, Tech, AI
|
||||||
Tags: politics, tech, Ai
|
Tags: politics, tech, Ai
|
||||||
Slug: gpt-oss-eee
|
Slug: social-media-ban-fail
|
||||||
Authors: Andrew Ridgway
|
Authors: Andrew Ridgway
|
||||||
Summary: GPT OSS is here from Open AI, the first open weight model from them since GPT-2. My question is... why now?
|
Summary: GPT OSS is here from Open AI, the first open weight model from them since GPT-2. My question is... why now?
|
||||||
|
|
||||||
# Human Introduction
|
# Human Introduction
|
||||||
This has been a tough one for the publishing house to get right. I've had it generate 3 different drafts and this is still the result of quite the edit. Today's blog was written by:
|
This has been a tough one for the publishing house to get right. I've had it generate 3 different drafts and this is still the result of quite the edit. Today's blog was written by:
|
||||||
|
|
||||||
1. Gemma:27b - Editor
|
1. Gemma:27b - Editor
|
||||||
2. GPT-OSS - Journalist
|
2. GPT-OSS - Journalist
|
||||||
3. Qwen3:14b - Journalist
|
3. Qwen3:14b - Journalist
|
||||||
@ -54,7 +53,7 @@ Now, I’m not accusing OpenAI of anything here—just pointing out that they’
|
|||||||
|
|
||||||
* OpenAI has dominated the consumer AI market with their **ChatGPT** and other tools.
|
* OpenAI has dominated the consumer AI market with their **ChatGPT** and other tools.
|
||||||
* They’ve been losing ground in the developer market, where models like [Gemini](https://deepmind.google/models/gemini/pro/) and particularly [Claude (Anthropic)](https://claude.ai/) are gaining traction in the proprietary space.
|
* They’ve been losing ground in the developer market, where models like [Gemini](https://deepmind.google/models/gemini/pro/) and particularly [Claude (Anthropic)](https://claude.ai/) are gaining traction in the proprietary space.
|
||||||
* Now they’re releasing open weight models that promise to compete at GPT-4 levels to try and bring in the Deepseek and Qwen crowd.
|
* Now they’re releasing open-source models that promise to compete at GPT-4 levels to try and bring in the Deepseek and Qwen crowd.
|
||||||
|
|
||||||
The timing feels a bit too convenient. OpenAI is essentially saying: “We get it. You want local, affordable, and flexible AI? We’ve got you covered.” But will this be enough to win back the developer community? Or are they just delaying the inevitable?
|
The timing feels a bit too convenient. OpenAI is essentially saying: “We get it. You want local, affordable, and flexible AI? We’ve got you covered.” But will this be enough to win back the developer community? Or are they just delaying the inevitable?
|
||||||
|
|
||||||
|
|||||||
Binary file not shown.
|
Before Width: | Height: | Size: 201 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 324 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 212 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 292 KiB |
@ -1,309 +0,0 @@
|
|||||||
Title: PR Reviewer - A deployable AI reviewer for your Repos
|
|
||||||
Date: 2026-05-21 18:30
|
|
||||||
Modified: 2026-05-21 18:30
|
|
||||||
Category: DevOps
|
|
||||||
Tags: ai, code-review, automation, devops, open-source, ai_content, not_human_content
|
|
||||||
Slug: pr-reviewer-deployable-ai-reviewer
|
|
||||||
Authors: Andrew Ridgway... And Friends - glm-5.1.ai, nemotron-3-nano.ai, gemma4.ai, deepseek-v4-flash.ai
|
|
||||||
Summary: An in‑depth look at PR Reviewer, a self‑hosted, LLM‑agnostic AI system that automates code, security and infrastructure reviews for any Git repository.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Introduction
|
|
||||||
|
|
||||||
Pull requests (PRs) are the lifeblood of modern software development. They enable collaboration, enforce quality gates, and provide a natural checkpoint before code reaches production. Yet, the manual review process is increasingly strained by the sheer volume of changes, the growing complexity of tech stacks, and the need for specialised expertise in security and infrastructure.
|
|
||||||
|
|
||||||
Enter **PR Reviewer**, a locally deployable AI‑driven review engine that brings automated, multi‑domain analysis to any repository. Built on top of CrewAI’s flow orchestration and the Model Context Protocol (MCP), the system runs three parallel review streams—code quality, security, and infrastructure—then synthesises a concise, actionable report. It is deliberately LLM‑agnostic, supporting OpenAI, Anthropic, Ollama and any other provider that conforms to CrewAI’s abstraction layer.
|
|
||||||
|
|
||||||
This article walks through the motivations behind PR Reviewer, its architectural choices, feature set, deployment pathways, and practical considerations for teams that want to augment their PR workflow with AI without surrendering control to a third‑party SaaS.
|
|
||||||
|
|
||||||
## The case for AI‑augmented PR reviews
|
|
||||||
|
|
||||||
### Scaling expertise
|
|
||||||
|
|
||||||
Traditional code reviews rely on senior engineers to spot anti‑patterns, security flaws, and deployment mis‑configurations. As teams grow, the pool of reviewers does not always keep pace, leading to bottlenecks and inconsistent feedback. An AI reviewer can apply a consistent set of rules across every PR, ensuring that even junior contributors receive high‑quality guidance.
|
|
||||||
|
|
||||||
### Reducing cognitive load
|
|
||||||
|
|
||||||
Human reviewers must juggle multiple concerns—style, correctness, performance, compliance—while also understanding the broader context of a change. By offloading routine checks to an automated system, reviewers can focus on architectural decisions and nuanced trade‑offs that truly require human judgement.
|
|
||||||
|
|
||||||
### Faster feedback loops
|
|
||||||
|
|
||||||
Continuous integration pipelines already provide rapid build and test feedback. Adding an AI review step that runs in parallel with existing checks shortens the time between code submission and actionable feedback, encouraging a “shift‑left” mentality where problems are caught earlier.
|
|
||||||
|
|
||||||
### Vendor‑neutral flexibility
|
|
||||||
|
|
||||||
Many commercial AI review tools lock users into proprietary APIs and cloud‑only deployments. PR Reviewer’s design deliberately avoids vendor lock‑in. By abstracting the LLM layer, teams can run the service on‑premise, on a private cloud, or even on a modest workstation using a local model such as Ollama.
|
|
||||||
|
|
||||||
## Core concepts
|
|
||||||
|
|
||||||
### CrewAI flows
|
|
||||||
|
|
||||||
CrewAI provides a lightweight framework for orchestrating multiple “crews” (agents) that each perform a specialised task. In PR Reviewer, three crews—**CodeReviewCrew**, **SecurityCrew**, and **InfraCrew**—operate concurrently. Each crew receives the same PR context, runs its own analysis toolchain (Semgrep, Trivy, Hadolint/Checkov respectively), and returns a structured narrative.
|
|
||||||
|
|
||||||
### Model Context Protocol (MCP)
|
|
||||||
|
|
||||||
MCP standardises how external tools expose their findings to an LLM. Instead of feeding raw tool output, MCP wraps results in a JSON schema that includes severity, location, and remediation suggestions. This uniform representation enables the summariser crew to merge disparate findings into a single coherent report.
|
|
||||||
|
|
||||||
### Summariser crew
|
|
||||||
|
|
||||||
The final crew consumes the three domain‑specific outputs and asks the LLM to produce a human‑readable summary. The prompt includes the repository’s coding style guidelines (if supplied) and any custom review policies, ensuring the tone and recommendations align with the team’s expectations.
|
|
||||||
|
|
||||||
## Feature overview
|
|
||||||
|
|
||||||
| Feature | Description |
|
|
||||||
|---|---|
|
|
||||||
| **Code review** | Style, maintainability and best‑practice checks powered by Semgrep. |
|
|
||||||
| **Security review** | Vulnerability scanning, secret detection and container image analysis via Trivy. |
|
|
||||||
| **Infrastructure review** | Dockerfile linting, Kubernetes manifest validation, IaC checks using Hadolint and Checkov. |
|
|
||||||
| **Summarisation** | Consolidated, actionable report generated by an LLM. |
|
|
||||||
| **REST API** | FastAPI endpoints for health checks, manual review triggers, and webhook handling. |
|
|
||||||
| **Gitea webhook** | Automatic PR event processing, diff fetching, and comment posting. |
|
|
||||||
| **Dockerised** | Multi‑stage build with all dependencies baked in. |
|
|
||||||
| **Kubernetes ready** | Helm‑compatible manifests and CI pipeline for automated deployment. |
|
|
||||||
| **LLM‑agnostic** | Works with OpenAI, Anthropic, Ollama or any CrewAI‑compatible provider. |
|
|
||||||
| **Configurable guidelines** | Override default review policies with repository‑specific markdown files. |
|
|
||||||
|
|
||||||
## Architecture deep dive
|
|
||||||
|
|
||||||
At a high level, PR Reviewer follows a request‑response pattern orchestrated by FastAPI. When a review request arrives—either via the `/api/v1/review` endpoint or a Gitea webhook—the service extracts the PR metadata, fetches the changed files, and constructs an MCP‑compatible payload. This payload is then dispatched to the three review crews in parallel.
|
|
||||||
|
|
||||||
```
|
|
||||||
POST /api/v1/review → FastAPI handler
|
|
||||||
│
|
|
||||||
├─► Fetch diffs from Gitea (or use supplied file list)
|
|
||||||
├─► Build MCP payload
|
|
||||||
├─► Parallel execution:
|
|
||||||
│ ├─ CodeReviewCrew (Semgrep)
|
|
||||||
│ ├─ SecurityCrew (Trivy)
|
|
||||||
│ └─ InfraCrew (Hadolint + Checkov)
|
|
||||||
└─► Summariser crew → LLM → JSON response
|
|
||||||
└─► Return consolidated report
|
|
||||||
```
|
|
||||||
|
|
||||||
### Parallelism and timeouts
|
|
||||||
|
|
||||||
Each crew runs in its own asynchronous task with a configurable timeout (`PER_CREW_TIMEOUT`). The overall workflow respects a global timeout (`TOTAL_FLOW_TIMEOUT`) to prevent runaway processing on large PRs. If a crew exceeds its limit, the summariser notes the omission and proceeds with the available data.
|
|
||||||
|
|
||||||
### Data flow and persistence
|
|
||||||
|
|
||||||
PR Reviewer is deliberately stateless. All inputs are supplied in the request body, and all outputs are returned as JSON. This design simplifies horizontal scaling—multiple instances can sit behind a load balancer without coordination. For audit purposes, teams can enable optional logging to an external store (e.g., Elasticsearch) via environment variables.
|
|
||||||
|
|
||||||
## Integration with LLM providers
|
|
||||||
|
|
||||||
CrewAI abstracts the LLM behind a simple interface: `generate(prompt, model, temperature)`. The service reads three environment variables to configure the provider:
|
|
||||||
|
|
||||||
* `LLM_PROVIDER` – `openai`, `anthropic`, or `ollama`.
|
|
||||||
* `LLM_MODEL` – model identifier (e.g., `gpt-4`, `claude-3-sonnet`, `gemma4:31b-cloud`).
|
|
||||||
* `LLM_API_KEY` – required for hosted services; omitted for local Ollama instances.
|
|
||||||
|
|
||||||
Because the prompt is generated programmatically, switching providers does not require code changes—only a restart with new environment values. This flexibility is crucial for teams that wish to experiment with emerging open‑source models without rewriting integration logic.
|
|
||||||
|
|
||||||
## Review flows in detail
|
|
||||||
|
|
||||||
### Code review crew
|
|
||||||
|
|
||||||
The code crew invokes Semgrep with a curated rule set that reflects common Python, JavaScript and Go best practices. Findings are normalised into MCP entries containing:
|
|
||||||
|
|
||||||
* **Severity** – `critical`, `high`, `medium`, `low`.
|
|
||||||
* **Location** – file path and line range.
|
|
||||||
* **Message** – concise description of the issue.
|
|
||||||
* **Remediation** – suggested code change or reference to documentation.
|
|
||||||
|
|
||||||
If a repository supplies a custom `code_review.md` guideline file, its contents are appended to the prompt, allowing the LLM to tailor feedback to the team’s style (e.g., preferring f‑strings over `%` formatting).
|
|
||||||
|
|
||||||
### Security review crew
|
|
||||||
|
|
||||||
Security analysis runs Trivy in two modes: vulnerability scanning of any container images referenced in the PR, and filesystem scanning for secrets, mis‑configurations, and known vulnerable dependencies. The output is again wrapped in MCP, with an additional field indicating **exploitability** based on CVSS scores.
|
|
||||||
|
|
||||||
### Infrastructure review crew
|
|
||||||
|
|
||||||
Infrastructure checks focus on Dockerfiles, Kubernetes manifests, and generic IaC (Terraform, CloudFormation). Hadolint validates Dockerfile best practices, while Checkov evaluates cloud resource definitions against industry‑standard policies (e.g., CIS benchmarks). The crew also respects any `infra_review.md` file that may contain organisation‑specific constraints such as mandatory resource limits.
|
|
||||||
|
|
||||||
### Summariser crew
|
|
||||||
|
|
||||||
The summariser receives three JSON arrays and constructs a single prompt that asks the LLM to:
|
|
||||||
|
|
||||||
1. Produce an executive summary of the overall health of the PR.
|
|
||||||
2. List the top‑5 findings across all domains, ordered by severity.
|
|
||||||
3. Provide actionable recommendations, grouped by domain.
|
|
||||||
4. Highlight any deviations from the repository’s own guidelines.
|
|
||||||
|
|
||||||
The result is a markdown document that can be posted directly as a PR comment, ensuring developers receive a readable, context‑aware report without additional formatting steps.
|
|
||||||
|
|
||||||
## API design
|
|
||||||
|
|
||||||
PR Reviewer exposes a minimal FastAPI surface:
|
|
||||||
|
|
||||||
* `GET /api/v1/health` – health check returning `{ "status": "healthy", "service": "pr-reviewer" }`.
|
|
||||||
* `POST /api/v1/review` – manual trigger; expects a JSON payload describing the PR (metadata, file list, optional overrides). Returns a JSON object containing a unique `review_id`, timestamps, and the full review results.
|
|
||||||
* `POST /api/v1/gitea-webhook` – endpoint for Gitea pull‑request events. Validates the `X-Gitea-Signature` header (if `ACCESS_GITEA_SECRET` is set), fetches the diff via the Gitea API, runs the review pipeline, and posts the markdown summary as a comment on the PR.
|
|
||||||
|
|
||||||
All endpoints respect standard HTTP status codes and include descriptive error messages for malformed requests, authentication failures, or internal timeouts.
|
|
||||||
|
|
||||||
## Gitea webhook integration
|
|
||||||
|
|
||||||
Gitea is the default CI/CD platform for the reference implementation, but the webhook handler is deliberately generic:
|
|
||||||
|
|
||||||
1. **Signature verification** – HMAC‑SHA256 using the secret configured in `ACCESS_GITEA_SECRET`. If the secret is omitted, verification is skipped (useful for local testing).
|
|
||||||
2. **Payload parsing** – Only `pull_request` events with actions `opened`, `synchronize`, or `reopened` are processed. Other events are ignored to reduce noise.
|
|
||||||
3. **Diff retrieval** – The handler calls the Gitea API (`/repos/{owner}/{repo}/pulls/{id}/files`) to obtain the list of changed files, their statuses, and raw content when needed.
|
|
||||||
4. **Review execution** – The same parallel crew workflow described earlier runs on the fetched diff.
|
|
||||||
5. **Comment posting** – Upon completion, the service posts the markdown report to the PR using the Gitea API (`/repos/{owner}/{repo}/issues/{id}/comments`).
|
|
||||||
|
|
||||||
### Adding support for other platforms
|
|
||||||
|
|
||||||
Because the webhook payload is parsed into a canonical internal model, extending support to GitHub, GitLab or Bitbucket merely requires a thin adapter that translates their event schemas into the same structure. The core review logic remains untouched, making cross‑platform adoption straightforward.
|
|
||||||
|
|
||||||
## Deployment options
|
|
||||||
|
|
||||||
### Docker compose (local development)
|
|
||||||
|
|
||||||
The repository ships with a `docker-compose.yaml` that defines two services:
|
|
||||||
|
|
||||||
* `pr-reviewer` – the FastAPI application.
|
|
||||||
* `ollama` (optional) – a local LLM server for offline use.
|
|
||||||
|
|
||||||
Running `docker compose up` builds the multi‑stage image, injects environment variables from `.env`, and exposes the API on `http://localhost:8000`.
|
|
||||||
|
|
||||||
### Kubernetes (production)
|
|
||||||
|
|
||||||
For production workloads, a Helm chart (or plain manifests in `kube/`) provides:
|
|
||||||
|
|
||||||
* A Deployment with configurable replica count.
|
|
||||||
* A Service of type `NodePort` (default port `30001`) or `LoadBalancer` for cloud environments.
|
|
||||||
* A Secret (`pr-reviewer-env`) that stores all `.env` values, including Gitea tokens and LLM credentials.
|
|
||||||
* An optional HorizontalPodAutoscaler that scales based on CPU utilisation.
|
|
||||||
|
|
||||||
The CI pipeline (`.gitea/workflows/build_push.yml`) automatically builds a multi‑arch Docker image, pushes it to the configured registry, and applies the Kubernetes manifests.
|
|
||||||
|
|
||||||
### Resource considerations
|
|
||||||
|
|
||||||
* **CPU** – The LLM inference dominates CPU usage. When using a hosted provider, the container’s CPU footprint is modest (mostly for Semgrep/Trivy). With a local model, allocate at least 4 vCPUs and 8 GB RAM.
|
|
||||||
* **Memory** – Each review crew consumes roughly 200 MB of RAM; the summariser adds another 150 MB. The total stays under 1 GB for typical PR sizes.
|
|
||||||
* **Storage** – The image size is ~1.2 GB (including all scanning tools). Persistent storage is not required unless audit logging is enabled.
|
|
||||||
|
|
||||||
## Configuration details
|
|
||||||
|
|
||||||
All runtime options are supplied via environment variables. The most important groups are:
|
|
||||||
|
|
||||||
| Variable | Required? | Description |
|
|
||||||
|---|---|---|
|
|
||||||
| `LLM_PROVIDER` | Yes | `openai`, `anthropic`, or `ollama`. |
|
|
||||||
| `LLM_MODEL` | Yes | Model identifier (e.g., `gpt-4`). |
|
|
||||||
| `LLM_API_KEY` | Conditional | API key for hosted providers. |
|
|
||||||
| `ACCESS_GITEA_URL` | Yes | Base URL of the Gitea instance. |
|
|
||||||
| `ACCESS_GITEA_TOKEN` | Yes | Personal access token with repository read scope. |
|
|
||||||
| `ACCESS_GITEA_SECRET` | No | Webhook secret for HMAC verification. |
|
|
||||||
| `TOTAL_FLOW_TIMEOUT` | No (default 600) | Max seconds for the whole review pipeline. |
|
|
||||||
| `PER_CREW_TIMEOUT` | No (default 300) | Max seconds per individual crew. |
|
|
||||||
| `LOG_LEVEL` | No (default `INFO`) | Python logging verbosity. |
|
|
||||||
|
|
||||||
Additional optional variables allow overriding default review guidelines (`CODE_REVIEW_GUIDELINES`, `SECURITY_REVIEW_GUIDELINES`, `INFRA_REVIEW_GUIDELINES`) by pointing to markdown files stored in the container or mounted via a volume.
|
|
||||||
|
|
||||||
## Operational considerations
|
|
||||||
|
|
||||||
### Monitoring
|
|
||||||
|
|
||||||
FastAPI’s built‑in metrics can be exposed via `/metrics` (Prometheus format). Key metrics include:
|
|
||||||
|
|
||||||
* `pr_review_requests_total`
|
|
||||||
* `pr_review_duration_seconds`
|
|
||||||
* `crew_timeout_total` (per crew)
|
|
||||||
* `llm_api_errors_total`
|
|
||||||
|
|
||||||
Collecting these metrics enables alerting on abnormal latency spikes, which often indicate upstream LLM throttling or unusually large diffs.
|
|
||||||
|
|
||||||
### Logging
|
|
||||||
|
|
||||||
Structured JSON logs are emitted by default, containing fields such as `request_id`, `pr_id`, `crew`, and `severity`. When integrated with a log aggregation platform (e.g., Loki), operators can trace the lifecycle of a single PR review from receipt to comment posting.
|
|
||||||
|
|
||||||
### Security
|
|
||||||
|
|
||||||
* **Secret management** – Store all tokens and API keys in a secret manager (Kubernetes Secrets, HashiCorp Vault, or Azure Key Vault). Never commit `.env` files to source control.
|
|
||||||
* **Network isolation** – If using a local LLM, keep the Ollama container on a private network and restrict outbound internet access.
|
|
||||||
* **Rate limiting** – The service respects the `X-RateLimit-Remaining` header from hosted LLM APIs and backs off automatically to avoid hitting provider quotas.
|
|
||||||
|
|
||||||
## Extending to other CI/CD platforms
|
|
||||||
|
|
||||||
While the reference implementation focuses on Gitea, the architecture encourages reuse:
|
|
||||||
|
|
||||||
1. **Create an adapter** – Implement a small FastAPI route that accepts GitHub `pull_request` webhook payloads, validates the signature (`X-Hub-Signature-256`), and maps fields to the internal PR model.
|
|
||||||
2. **Reuse the core flow** – Forward the transformed payload to the existing `/api/v1/review` endpoint. No changes to the review crews are required.
|
|
||||||
3. **Deploy the new route** – Add the new route to the FastAPI app, update the Docker image, and configure the external webhook in the target platform.
|
|
||||||
|
|
||||||
Because the review logic is decoupled from the webhook source, teams can support multiple providers simultaneously, each posting its own comment to the respective PR.
|
|
||||||
|
|
||||||
## Development workflow
|
|
||||||
|
|
||||||
Contributors who wish to enhance PR Reviewer can follow these steps:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Clone the repository
|
|
||||||
git clone https://git.aridgwayweb.com/armistace/pr_reviewer.git
|
|
||||||
cd pr_reviewer
|
|
||||||
|
|
||||||
# Install development dependencies
|
|
||||||
uv pip install -e ".[dev]"
|
|
||||||
|
|
||||||
# Run the test suite
|
|
||||||
pytest tests/
|
|
||||||
|
|
||||||
# Start the server locally for rapid iteration
|
|
||||||
uvicorn src.pr_reviewer.main:app --reload
|
|
||||||
```
|
|
||||||
|
|
||||||
The project uses **uv** for isolated virtual environments, **pytest** for unit and integration tests, and **ruff** for linting. CI pipelines enforce 100 % test coverage and run static analysis on every pull request.
|
|
||||||
|
|
||||||
### Adding a new review tool
|
|
||||||
|
|
||||||
To incorporate an additional analysis tool (e.g., a custom static analyser), developers should:
|
|
||||||
|
|
||||||
1. Write a thin wrapper that converts the tool’s output into the MCP schema.
|
|
||||||
2. Register a new crew in `crews/` that invokes the wrapper.
|
|
||||||
3. Update the orchestration flow (`flow.py`) to include the new crew in the parallel execution block.
|
|
||||||
4. Add corresponding unit tests that mock the tool’s output and verify correct MCP conversion.
|
|
||||||
|
|
||||||
## Testing and quality assurance
|
|
||||||
|
|
||||||
PR Reviewer’s reliability hinges on three testing layers:
|
|
||||||
|
|
||||||
* **Unit tests** – Validate each crew’s MCP conversion logic, LLM prompt generation, and webhook parsing.
|
|
||||||
* **Integration tests** – Spin up a temporary Docker Compose environment with a mock Gitea server, submit a synthetic PR payload, and assert that the final markdown report contains expected sections.
|
|
||||||
* **End‑to‑end tests** – Deploy the Helm chart to a disposable Kubernetes namespace, trigger a real Gitea webhook, and verify that the comment appears on the PR with correct formatting.
|
|
||||||
|
|
||||||
All tests run in CI on every push, and failures block merges.
|
|
||||||
|
|
||||||
## Community and contributions
|
|
||||||
|
|
||||||
The project is deliberately open‑source, hosted on a self‑managed Gitea instance. Contributors are encouraged to:
|
|
||||||
|
|
||||||
* **Open issues** – Report bugs, request new review domains, or suggest LLM prompt improvements.
|
|
||||||
* **Submit pull requests** – Follow the contribution guidelines in `CONTRIBUTING.md`, which outline code style, testing requirements, and documentation standards.
|
|
||||||
* **Share custom guidelines** – Teams can publish repository‑specific markdown files (e.g., `code_review.md`) that the summariser will automatically honour.
|
|
||||||
|
|
||||||
Because the tool is designed for private deployment, there is no central SaaS offering. Instead, the community benefits from shared Docker images, Helm charts, and a growing catalogue of custom rule sets that can be forked and adapted.
|
|
||||||
|
|
||||||
## Limitations and future directions
|
|
||||||
|
|
||||||
### Current constraints
|
|
||||||
|
|
||||||
* **LLM dependence** – The quality of the final summary is directly tied to the underlying model’s capabilities. Low‑capacity models may produce vague recommendations.
|
|
||||||
* **Static analysis scope** – While Semgrep, Trivy, Hadolint and Checkov cover many common languages and platforms, niche tech stacks (e.g., Rust, Terraform Cloud) require additional adapters.
|
|
||||||
* **No built‑in CI/CD orchestration** – PR Reviewer focuses on the review step; it does not enforce merge policies or gate deployments. Teams must integrate the API into their existing pipelines.
|
|
||||||
|
|
||||||
### Planned enhancements
|
|
||||||
|
|
||||||
1. **Model‑agnostic prompt optimisation** – Research into dynamic prompt templates that adapt to the strengths of each LLM provider.
|
|
||||||
2. **Feedback loop** – Capture developer reactions to the AI suggestions (e.g., thumbs up/down) and use them to fine‑tune future prompts.
|
|
||||||
3. **Extended platform support** – Official adapters for GitHub Actions, GitLab CI, and Azure DevOps.
|
|
||||||
4. **Cache layer** – Introduce a Redis‑backed cache for repeated scans of unchanged files, reducing compute cost on large monorepos.
|
|
||||||
5. **Policy as code** – Allow organisations to define review policies in a declarative YAML format that the summariser can reference, enabling compliance‑first workflows.
|
|
||||||
|
|
||||||
## Conclusion
|
|
||||||
|
|
||||||
PR Reviewer demonstrates that AI‑driven code quality, security, and infrastructure analysis can be delivered as a self‑hosted, vendor‑neutral service without sacrificing flexibility or control. By leveraging CrewAI’s flow orchestration, MCP’s structured data exchange, and a modular architecture, the system provides consistent, actionable feedback across multiple domains while remaining easy to extend and integrate into existing CI/CD pipelines.
|
|
||||||
|
|
||||||
For teams that value privacy, customisation, and the ability to run sophisticated analysis on modest hardware, PR Reviewer offers a pragmatic path forward. The open‑source nature invites collaboration, and the clear separation between tooling, LLM inference and summarisation ensures that future improvements—whether in scanning capabilities or language model performance—can be adopted with minimal friction.
|
|
||||||
|
|
||||||
Give it a spin, contribute a rule set, or simply use it to offload the routine parts of your PR workflow. In doing so, you’ll free up senior engineers to focus on the strategic decisions that truly move software forward.
|
|
||||||
@ -1,228 +0,0 @@
|
|||||||
Title: Zen Browser - Is it new browser for me?
|
|
||||||
Date: 2026-05-03
|
|
||||||
Modified: 2026-05-03
|
|
||||||
Category: Browsers
|
|
||||||
Tags: firefox, zen-browser, privacy, open-source, alternatives, ai_content, not_human_content
|
|
||||||
Slug: zen-browser-new-browser-for-me
|
|
||||||
Authors: Andrew Ridgway... and friends - glm-5.1, nemotron-3-nano, gemma4, deepseek-v4-flash
|
|
||||||
Summary: A deep dive into Zen Browser, its Firefox‑based architecture, privacy‑focused design, and whether it can replace your current browser in a Chromium‑dominated world.
|
|
||||||
|
|
||||||
## 1. Why the browser matters today
|
|
||||||
|
|
||||||
The web is no longer a quiet place where you could pop a page, read a story, and close the tab without a second thought. In 2026 the internet is saturated with AI‑generated content, relentless push notifications, and a market that has coalesced around a single rendering engine: Chromium. Chrome, Edge, Brave, Vivaldi, Opera and even the newer Arc all sit on the same Blink‑based foundation. That homogeneity brings convenience—websites only need to be tested once—but it also creates a monoculture where a single corporate decision can ripple through the entire ecosystem.
|
|
||||||
|
|
||||||
For many developers and power users this is uncomfortable. The same engine means the same telemetry, the same default data‑sharing practices, and the same attack surface. It also means that innovation at the engine level is effectively a zero‑sum game: if Google decides to deprecate a web standard, every Chromium browser follows suit. The result is a web that feels increasingly curated by a single entity.
|
|
||||||
|
|
||||||
I have spent the last decade fighting this trend. At home and work I keep Firefox as my default on the desktop and on my phone, mainly out of principle rather than passion. The browser feels like a relic in a world that worships speed and AI‑driven UI tricks, yet it remains the most trustworthy open‑source option I know.
|
|
||||||
|
|
||||||
Enter Zen Browser, a project that promises to give Firefox a fresh coat of paint while preserving its core values. The question is whether Zen can be the “new browser for me” without forcing me to abandon the ecosystem I have built around Firefox.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. The state of the browser market in 2026
|
|
||||||
|
|
||||||
Before we can judge Zen on its own merits, it helps to understand the broader landscape.
|
|
||||||
|
|
||||||
| Browser | Engine | Open‑source? | Mobile version | Sync ecosystem |
|
|
||||||
|---------|--------|---------------|----------------|----------------|
|
|
||||||
| Chrome | Blink | No (proprietary) | Android, iOS (WebView) | Google Account |
|
|
||||||
| Edge | Blink | Partially (Chromium core) | Android, iOS | Microsoft Account |
|
|
||||||
| Brave | Blink | Yes (MIT) | Android, iOS | Brave Sync |
|
|
||||||
| Vivaldi | Blink | Yes (GPL) | Android (WebView) | Vivaldi Sync |
|
|
||||||
| Arc | Blink | No (closed) | None (desktop only) | Arc Cloud |
|
|
||||||
| Firefox | Gecko | Yes (MPL) | Android, iOS | Firefox Sync |
|
|
||||||
| **Zen** | Gecko (fork) | Yes (MPL) | **None** (desktop only) | Firefox Sync (built‑in) |
|
|
||||||
|
|
||||||
The table shows that Zen is the only desktop‑only browser that still runs on Gecko while offering a radically different UI. Its lack of a mobile client is a drawback, but the built‑in Firefox Sync mitigates the inconvenience by allowing seamless hand‑off to the regular Firefox mobile app.
|
|
||||||
|
|
||||||
Another trend worth noting is the rise of “no‑Google” browsers. Users increasingly value a browsing experience that does not automatically send telemetry to Google, nor embed Google services by default. Zen positions itself squarely in that niche, advertising a “no‑Google” promise and disabling telemetry out of the box.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. Zen’s technical foundation
|
|
||||||
|
|
||||||
### 3.1 A true Firefox fork
|
|
||||||
|
|
||||||
Zen is not a “Firefox‑inspired” project that re‑implements features on top of Chromium. It is a **fork of the Firefox source code**, meaning it inherits the Gecko rendering engine, the SpiderMonkey JavaScript engine, and the same security model that has protected Firefox users for over a decade. The developers have taken the Firefox codebase, stripped away the default UI, and rebuilt the chrome (the browser UI, not the Chrome engine) to match a minimalist aesthetic.
|
|
||||||
|
|
||||||
Because it is a fork, Zen benefits from every upstream security patch that Mozilla releases. When Mozilla pushes a fix for a memory‑corruption bug, Zen can merge it with minimal effort. Conversely, any regression introduced by Zen’s UI layer can be isolated without affecting the core engine.
|
|
||||||
|
|
||||||
### 3.2 Firefox Sync baked in
|
|
||||||
|
|
||||||
One of the biggest friction points for any new browser is data migration. Zen solves this by integrating Firefox Sync directly into its startup flow. When you launch Zen for the first time you are prompted to sign in with your existing Firefox account. The browser then pulls in:
|
|
||||||
|
|
||||||
- Bookmarks
|
|
||||||
- Saved passwords (encrypted with your Firefox master password)
|
|
||||||
- Open tabs
|
|
||||||
- History
|
|
||||||
- Preferences (where applicable)
|
|
||||||
|
|
||||||
The result is a seamless transition: you can keep your existing workflow, extensions, and saved credentials without manual export/import. This is especially valuable for users who have invested years of curation into their Firefox profile.
|
|
||||||
|
|
||||||
### 3.3 Open‑source ethos
|
|
||||||
|
|
||||||
Zen’s source lives on GitHub under the Mozilla Public License 2.0, the same license that governs Firefox. The repository is public, issues are triaged openly, and contributions are welcomed from anyone with the requisite skill set. For developers who like to peek under the hood, the code is fully auditable. The project also provides pre‑built binaries for Windows, macOS and Linux, as well as Flatpak, AppImage and tarball options for the Linux crowd.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. User experience: the “Zen” in Zen Browser
|
|
||||||
|
|
||||||
### 4.1 Minimalist UI
|
|
||||||
|
|
||||||
The most striking aspect of Zen is its **Zen Mode** (also called Compact Mode). When you open a new window you are greeted with a blank canvas that contains only the web page. The traditional tab bar, bookmarks toolbar, and extension icons are hidden by default. Hovering near the top edge reveals a thin, unobtrusive sidebar that contains the address bar, a minimal set of navigation controls, and a button to toggle the sidebar itself.
|
|
||||||
|
|
||||||
This design is deliberately anti‑clutter. It respects the user’s attention by removing visual noise, allowing the content to take centre stage. For developers who spend hours reading documentation or for writers who need a distraction‑free environment, this mode feels like a digital equivalent of a quiet study.
|
|
||||||
|
|
||||||
### 4.2 Vertical tabs and workspaces
|
|
||||||
|
|
||||||
Zen replaces the classic horizontal tab strip with **vertical tabs** that sit on the left side of the window. Each tab is represented by its favicon and title, and you can drag‑and‑drop to reorder them. The vertical layout pairs naturally with the sidebar, creating a “pane‑like” feel that many tiling‑window‑manager enthusiasts will recognise.
|
|
||||||
|
|
||||||
Beyond simple tabs, Zen introduces **workspaces**. A workspace is a collection of tabs that can be switched with a single keyboard shortcut (Ctrl+Alt+←/→ by default). This allows you to separate, for example, work‑related sites from personal browsing without opening a new window. The workspace concept mirrors the way developers use virtual desktops on their operating system, bringing that mental model into the browser.
|
|
||||||
|
|
||||||
### 4.3 Split view
|
|
||||||
|
|
||||||
Another productivity‑focused feature is **split view**. By dragging a tab to the right edge of the window, Zen automatically creates a side‑by‑side layout where two pages share the same window. This is handy for comparing documentation with a live site, watching a tutorial while coding, or simply keeping a chat window open alongside a news feed.
|
|
||||||
|
|
||||||
The split view is implemented using the same rendering process for both panes, so performance remains consistent. The UI automatically resizes when you move the divider, and you can close either pane independently.
|
|
||||||
|
|
||||||
### 4.4 Keyboard‑first philosophy
|
|
||||||
|
|
||||||
Zen assumes you will spend most of your time navigating with the keyboard. The default shortcuts are intentionally similar to those you already know from Firefox and other browsers:
|
|
||||||
|
|
||||||
| Shortcut | Action |
|
|
||||||
|----------|--------|
|
|
||||||
| Ctrl + T | New tab |
|
|
||||||
| Ctrl + N | New window |
|
|
||||||
| Ctrl + W | Close tab |
|
|
||||||
| Ctrl + Shift + T | Reopen closed tab |
|
|
||||||
| Ctrl + L | Focus address bar |
|
|
||||||
| Ctrl + Alt + ←/→ | Switch workspace |
|
|
||||||
| Ctrl + Shift + S | Toggle split view |
|
|
||||||
| Ctrl + B | Toggle sidebar |
|
|
||||||
| Ctrl + / | Open command palette (search commands) |
|
|
||||||
|
|
||||||
Because the UI is hidden most of the time, these shortcuts become the primary way to interact with the browser. Users quickly develop muscle memory, and the result is a faster, more fluid browsing experience.
|
|
||||||
|
|
||||||
### 4.5 Extension compatibility
|
|
||||||
|
|
||||||
Since Zen runs on Gecko, it supports the **Mozilla Add‑ons ecosystem** out of the box. Popular extensions such as uBlock Origin, Bitwarden, Dark Reader, and the myriad of developer tools work without modification. The only caveat is that extensions that rely on Chrome‑specific APIs will not function, but those are rare in the Firefox world.
|
|
||||||
|
|
||||||
The developers have also introduced a **mods system** that allows community‑created UI tweaks, themes, and custom CSS. This is similar to the old Firefox “userChrome.css” approach but packaged in a more discoverable way. Users can browse the Zen Mods repository, install a theme with a single click, and have the browser instantly re‑skin itself.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. Privacy, security and the “no‑Google” promise
|
|
||||||
|
|
||||||
### 5.1 Telemetry disabled by default
|
|
||||||
|
|
||||||
One of the most common criticisms of modern browsers is the amount of telemetry they ship. Zen disables all telemetry at launch. No usage data is sent to the Zen developers unless you explicitly opt‑in via the Settings panel. This aligns with the privacy‑first ethos that attracted many to Firefox in the first place.
|
|
||||||
|
|
||||||
### 5.2 No bundled Google services
|
|
||||||
|
|
||||||
Chrome and its Chromium siblings ship with Google services baked into the browser: Safe Browsing, Google Translate, automatic sign‑in, and more. Zen strips all of these out. The only external services it contacts are Mozilla’s update servers (for security patches) and the Firefox Sync servers (for data sync). There is no default integration with Google Analytics, no automatic Google account sign‑in, and no built‑in Widevine DRM.
|
|
||||||
|
|
||||||
### 5.3 DRM and media playback
|
|
||||||
|
|
||||||
Because Zen chooses not to include proprietary DRM modules, it cannot play Widevine‑protected streams (Netflix, Disney+, etc.) out of the box. Users who need this functionality must fall back to Firefox or a Chromium‑based browser for those sites. The developers have been transparent about this limitation, and many users accept it as a reasonable trade‑off for a cleaner, more private browsing experience.
|
|
||||||
|
|
||||||
### 5.4 Security updates
|
|
||||||
|
|
||||||
Zen inherits Firefox’s rapid security‑patch cadence. When Mozilla releases a critical fix, the Zen maintainers merge it into the next release within days. The project also runs its own automated build pipeline that signs binaries, ensuring that users receive authentic updates.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 6. Performance and stability
|
|
||||||
|
|
||||||
### 6.1 Benchmarks vs real‑world use
|
|
||||||
|
|
||||||
Synthetic benchmarks (e.g., Speedometer 3) show Zen scoring slightly lower than vanilla Firefox—around 5‑7 % slower—primarily due to the additional UI layer. In practice, the difference is imperceptible for everyday tasks such as browsing news sites, reading documentation, or coding. The vertical tab and workspace features add negligible overhead because they are UI constructs rather than rendering changes.
|
|
||||||
|
|
||||||
### 6.2 Memory footprint
|
|
||||||
|
|
||||||
Zen’s memory usage is comparable to Firefox’s default profile. The hidden UI reduces the number of active UI elements, which can actually lower RAM consumption when many tabs are open. Users have reported being able to keep 30‑40 tabs open without the system slowing down, a figure that matches or exceeds most Chromium browsers on the same hardware.
|
|
||||||
|
|
||||||
### 6.3 Stability track record
|
|
||||||
|
|
||||||
Since its first stable release (v1.0) in early 2025, Zen has maintained a steady release cadence—approximately one minor version every six weeks. Crash reports have steadily declined as the codebase matures. The most common issues reported are related to split view quirks on certain Linux window managers, but these are being addressed in the upcoming 1.21 release.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 7. Limitations and trade‑offs
|
|
||||||
|
|
||||||
| Limitation | Impact | Mitigation |
|
|
||||||
|------------|--------|-------------|
|
|
||||||
| No mobile app (Android/iOS) | Cannot browse Zen‑only UI on phone | Use Firefox mobile with Sync to keep bookmarks, passwords, and open tabs |
|
|
||||||
| No built‑in Widevine DRM | Cannot stream Netflix/Disney+ directly | Use a Chromium browser for DRM‑protected services |
|
|
||||||
| Smaller development team | Potential risk of abandonment | Community contributions, open‑source transparency |
|
|
||||||
| Limited CLI documentation | Advanced users may lack command‑line options | Most Firefox CLI flags work; community can extend docs |
|
|
||||||
|
|
||||||
These constraints are not deal‑breakers for many power users. The ability to keep a consistent workflow across desktop devices, combined with the privacy benefits, outweighs the lack of a native mobile client for a sizable portion of the audience.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 8. Getting started with Zen
|
|
||||||
|
|
||||||
1. **Download** – Visit the official site (https://zen-browser.app) and choose the installer for your OS. Linux users can pick Flatpak, AppImage, or a tarball.
|
|
||||||
2. **Install** – Run the installer; on Windows and macOS the process is straightforward. Linux users may need to make the AppImage executable (`chmod +x`).
|
|
||||||
3. **Sign in** – On first launch, click “Sign in with Firefox” and enter your Mozilla account credentials. This will pull in your existing data.
|
|
||||||
4. **Configure** – Open Settings → Privacy to verify telemetry is disabled. Adjust shortcuts under Keyboard → Shortcuts if you prefer different key bindings.
|
|
||||||
5. **Explore** – Try Zen Mode (Ctrl + /), enable vertical tabs, create a workspace, and experiment with split view.
|
|
||||||
6. **Install extensions** – Visit addons.mozilla.org from within Zen and add your favourite tools.
|
|
||||||
7. **Join the community** – The Discord server and GitHub Discussions are active places to ask questions, report bugs, or suggest features.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 9. How Zen compares to other browsers
|
|
||||||
|
|
||||||
| Feature | Zen | Firefox (standard) | Chrome | Brave | Vivaldi |
|
|
||||||
|---------|-----|--------------------|--------|-------|---------|
|
|
||||||
| Engine | Gecko (fork) | Gecko | Blink | Blink | Blink |
|
|
||||||
| UI paradigm | Vertical tabs, workspaces, Zen Mode | Traditional tab bar | Minimalist but Chrome‑centric | Similar to Chrome with added shields | Highly customizable |
|
|
||||||
| Default telemetry | Disabled | Enabled (opt‑out) | Enabled | Enabled (opt‑out) | Enabled |
|
|
||||||
| Google services | None | None | Integrated | Integrated | Integrated |
|
|
||||||
| Mobile app | None (use Firefox) | Yes | Yes | Yes | Yes |
|
|
||||||
| DRM support | No | No (requires separate plugin) | Yes | Yes | Yes |
|
|
||||||
| Open‑source | Yes (MPL) | Yes (MPL) | No (proprietary) | Yes (MIT) | Yes (GPL) |
|
|
||||||
| Extension ecosystem | Mozilla Add‑ons | Mozilla Add‑ons | Chrome Web Store | Chrome Web Store | Chrome Web Store |
|
|
||||||
|
|
||||||
Zen occupies a unique niche: it offers a radically different UI while staying within the Firefox ecosystem. For users who love Firefox’s privacy stance but crave a fresh visual experience, Zen is the only option that satisfies both criteria without resorting to Chromium.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 10. Who should give Zen a try?
|
|
||||||
|
|
||||||
- **Privacy‑conscious users** who want a browser that does not ship Google telemetry by default.
|
|
||||||
- **Power users** who rely heavily on keyboard navigation, vertical tabs, and workspace separation.
|
|
||||||
- **Developers** who already have a Firefox profile and want to keep their bookmarks, passwords, and extensions intact while experimenting with a new UI.
|
|
||||||
- **Linux enthusiasts** who appreciate open‑source software and the ability to install via Flatpak or AppImage.
|
|
||||||
- **Anyone tired of the Chromium monoculture** and looking for a viable alternative that still renders modern web standards correctly.
|
|
||||||
|
|
||||||
Conversely, Zen may not be ideal for:
|
|
||||||
|
|
||||||
- Users who need **DRM‑protected streaming** on a daily basis.
|
|
||||||
- Mobile‑first users who expect a seamless browser experience across phone and tablet.
|
|
||||||
- Organizations that require **same‑day security patches** for a large fleet of machines (Chromium browsers often receive patches faster due to corporate backing).
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 11. The future of Zen
|
|
||||||
|
|
||||||
The browser market has a notorious “scrap heap” where ambitious projects disappear after a few years. Zen’s survival hinges on three factors:
|
|
||||||
|
|
||||||
1. **Community involvement** – Because the code is open, contributors can add features, fix bugs, and keep the project alive even if the core team shrinks.
|
|
||||||
2. **Sustainable funding** – The project currently relies on donations and occasional sponsorships. A steady revenue stream would allow dedicated developers to work full‑time.
|
|
||||||
3. **Feature roadmap** – Delivering a mobile client, adding optional DRM support, and refining split view stability are on the public roadmap. Hitting these milestones will broaden Zen’s appeal.
|
|
||||||
|
|
||||||
If these conditions are met, Zen could become a long‑term pillar of the non‑Chromium ecosystem, offering a viable, privacy‑first alternative for years to come.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 12. Final thoughts
|
|
||||||
|
|
||||||
Zen Browser is more than a cosmetic overhaul of Firefox; it is a statement that the web does not have to be dominated by a single engine and a single corporate agenda. Its minimalist UI, vertical tabs, workspaces, and split view provide a fresh workflow that respects the user’s attention. The seamless integration with Firefox Sync means you can adopt Zen without losing the data you have painstakingly built up over years.
|
|
||||||
|
|
||||||
The trade‑offs—no mobile client, no built‑in DRM—are real, but they are transparent and can be worked around. For anyone who values privacy, open‑source principles, and a keyboard‑first experience, Zen is worth a serious look.
|
|
||||||
|
|
||||||
In a world where AI‑generated noise threatens to drown out thoughtful browsing, Zen offers a quiet corner where the page itself can finally be heard. Give it a spin, set up your workspaces, and see whether it becomes the new browser for you.
|
|
||||||
|
|
||||||
---
|
|
||||||
@ -6,7 +6,7 @@ SITENAME = "Andrew Ridgway's Blog"
|
|||||||
SITEURL = 'https://blog.aridgwayweb.com'
|
SITEURL = 'https://blog.aridgwayweb.com'
|
||||||
THEME = 'themes/cleanblog'
|
THEME = 'themes/cleanblog'
|
||||||
PATH = 'content'
|
PATH = 'content'
|
||||||
HEADER_COVER = 'https://blog.aridgwayweb.com/images/Tech-Desktop-Wallpaper-35697.jpg'
|
HEADER_COVER = 'https://wallpaperaccess.com/full/3239444.jpg'
|
||||||
TIMEZONE = 'Australia/Brisbane'
|
TIMEZONE = 'Australia/Brisbane'
|
||||||
COLOR_SCHEME_CSS = 'tomorrow.css'
|
COLOR_SCHEME_CSS = 'tomorrow.css'
|
||||||
DEFAULT_LANG = 'en'
|
DEFAULT_LANG = 'en'
|
||||||
|
|||||||
Binary file not shown.
|
Before Width: | Height: | Size: 2.8 MiB |
@ -33,7 +33,7 @@
|
|||||||
{% if article.header_cover %}
|
{% if article.header_cover %}
|
||||||
<header class="intro-header" style="background-image: url('{{ article.header_cover }}')">
|
<header class="intro-header" style="background-image: url('{{ article.header_cover }}')">
|
||||||
{% else %}
|
{% else %}
|
||||||
<header class="intro-header" style="background-image: url('{{ SITEURL }}/{{ THEME_STATIC_DIR }}/images/post-bg.png')">
|
<header class="intro-header" style="background-image: url('{{ SITEURL }}/{{ THEME_STATIC_DIR }}/images/post-bg.jpg')">
|
||||||
{% endif %}
|
{% endif %}
|
||||||
<div class="container">
|
<div class="container">
|
||||||
<div class="row">
|
<div class="row">
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user