Category: Uncategorized

Nearly two million Australians just learned a lesson about data retention the hard way. Quest Apartment Hotels has confirmed that a breach through a third-party technology provider exposed records for roughly 1,991,613 customers — names and contact details mostly, but also passport and licence numbers, vehicle registrations, and hundreds of thousands of credit card numbers. The detail that should stop every small business owner cold is buried a few paragraphs down: all of the affected information relates to records from before June 2025. This was old data. It was still just sitting there.

Two failures, only one of them Quest’s

The attack came through a vulnerability in a third-party provider’s software, which is the part you can’t fully control. Vendors get breached; that’s the world we live in. But the blast radius of a vendor breach is entirely decided by what you kept. The forensic breakdown tells the story: 297,739 credit card numbers without CVV and another 46,727 with CVV, including expired cards. Passport numbers for guests who checked out years ago. The third-party software opened the door — the data hoard determined how much walked out of it.

As one security commentator put it in the coverage: audit your data holdings, know what you have and why, and remember that data you no longer hold cannot be stolen in a breach. That last sentence is the whole article, really. Everything else is implementation detail.

Storing CVV is not a retention oops — it is a rule violation

A quick word on those 46,727 cards with CVV, because it matters for anyone taking payments. PCI DSS has forbidden storing the card verification value after authorisation for as long as the standard has existed. There is no innocent retention-policy story where CVVs end up in a database; that data should never have been written in the first place. If your booking form, POS export, or “just in case” spreadsheet pipeline is writing full card details anywhere, that is not a cleanup task for next quarter. It is a today problem.

Retention is a security control, and Australian law now agrees

After the Optus breach, Australian privacy law was tightened to require organisations to destroy or de-identify personal information once it is no longer needed. Which sounds like compliance paperwork until you frame it the way an attacker would: every month you keep data past its useful life, you are holding inventory for someone else’s incident. Retention policy is not a records-management nicety. It is attack-surface reduction, and unlike most security spending, deletion is free.

A retention audit a small business can actually finish

Enterprise data governance frameworks are a waste of your time. Here is the version I would run for a ten-person business, doable in an afternoon:

• Inventory by category, not by system. Not “the booking database” but the categories inside it: names, contact details, payment identifiers, ID numbers. List where each category lives — including exports, shared drives, email archives, and that spreadsheet an contractor made in 2023.
• Give every category a TTL and a reason. If you cannot articulate why you still hold a category of data, that is your answer: it goes. Contact details for past customers? Fine, with a marketing-consent story. Passport numbers from a 2019 booking? There is no story.
• Automate the purge so it sticks. A retention rule that depends on someone remembering is not a rule. One cron job beats one heroic cleanup:

# monthly: remove guest exports older than 24 months
0 3 1 * * find /srv/exports/guests -type f -mtime +730 -print -delete >> /var/log/retention.log 2>&1

The -print before the -delete matters: you want an audit trail of what the policy removed, because “we delete old data” is also something you will need to demonstrate.

• Fix collection at the source. The cheapest record to retain is the one you never collected. Walk your forms and checkout flow with a hostile eye: is every field justified? Every optional ID field you delete from the form is a category that can never leak.
• Ask your vendors the same question. Quest’s path in was third-party software. Ask yours what they retain, for how long, and who has access. A vendor who cannot answer is telling you something.
• Remember that backups count. The awkward one. Your snapshots and offsite copies faithfully preserve every PII field you “deleted” in production. If you purge a category, note it and make sure the next backup cycle ages it out too, or your retention policy has an asterisk the size of a restore.

The cheapest breach response is no data to respond about

Quest is now doing what every breached company does: forensic analysis, regulator notifications, apology letters to two million people, a support line. Nearly all of that cost scales with how much data was sitting in the room when the door got kicked in. The records from before June 2025 should have been gone years before the attacker arrived. They were not, and two million people are dealing with the consequences.

You cannot prevent a vendor’s software from having a vulnerability. You can absolutely decide that when something gets into your systems, it finds a sparse target. Hoarding customer data past its useful life is unsecured debt — it accrues quietly, and it comes due at the worst possible moment. Stop keeping it.

Every few months someone writes a eulogy for the old click-in laptop docks, and How-To Geek’s recent piece is a good one: the proprietary dock that swallowed your whole laptop, charged it with a supply actually designed for it, and never once asked whether the cable was certified. It’s nostalgia with a point. But if you run desks for a small business or a homelab bench — and I do — the real lesson isn’t “old docks were nicer.” It’s this: universal docks didn’t eliminate the integration work, they transferred it to you.

What the old docks actually got right

The genuine advantages weren’t sentimental. A model-specific dock was sold as a tested appliance: the power supply was matched to the machine, the connector had enough parallel pins that peripherals weren’t fighting over one shared pipe, and the mechanical dock held the laptop like it was designed to — because it was. You plugged in and everything worked at full speed, every time, because the vendor had already done the compatibility testing on exactly one combination of hardware.

Why universal docks won anyway

None of that survives contact with reality, of course. Proprietary docks only made sense when a company bought one laptop model for everyone, and they died the moment laptops started outliving their dock generations. A single USB-C cable that drives two monitors, gigabit (or better) ethernet, audio, and charging on literally any modern laptop is a straight-up better deal for procurement. When the laptop fleet turns over and the docks stay, that’s money saved and e-waste avoided. Universal won on merit.

The catch: you’re the certification lab now

What disappeared was the tested part. USB-C’s famous mess means one connector shape hides half a dozen different capability levels. Take a random dock, a random cable, and a random laptop, and you genuinely cannot know what you’ll get — display bandwidth, charging speed, whether the 2.5GbE port runs at 2.5 or negotiates down — without checking spec sheets, and sometimes without benchmarking. The old vendor QA became a lottery, and the house always wins: you pay in flaky monitors, slow charging, and support tickets that say “the network is slow” when it’s actually a dock port.

So run it like infrastructure

Here’s the playbook I use. It’s less “throw out the universal dock” and more “do the QA the vendor stopped doing, once, properly.”

• Standardize one dock SKU and one cable SKU. Not “whatever was cheap on the day” — one certified Thunderbolt 4 or USB4 dock, bought in multiples. Buy a spare before you need it, because the replacement in two years will be a different compatibility gamble.
• Match the power budget to peak draw, not the sticker. If the laptop pulls 100W under load and the dock passes through 90, you’ll spend months blaming “battery problems.” Check the wattage at full tilt, not idle.
• Keep the heavy lifting off the dock where you can. All those ports share one uplink. Displays, the wired NIC, and an external SSD streaming backups can gang up in ugly ways. On the homelab bench, anything that moves real data gets a direct port or its own NIC; the dock earns its keep on monitors, keyboard, and charging.
• Burn in every new laptop-plus-dock combo once. Displays at target resolution and refresh, a sustained load while charging, and an iperf3 run through the dock’s ethernet port:

iperf3 -c 192.168.1.10 -t 30

Thirty seconds of that tells you more than any spec sheet. Do it on day one, not the day the new hire can’t figure out why their second monitor is 30Hz.

• Purge the cable drawer. Mystery USB-C cables are where dock setups go to die. Keep the certified ones, label them, and recycle the rest — the cost of debugging one bad cable exceeds the cost of every good cable you own.

Verdict

The How-To Geek piece is right that something was lost: the old dock was an appliance, and appliances are lovely. But I wouldn’t go back, and for a small business you probably can’t afford to. The modern dock isn’t an appliance — it’s infrastructure, and infrastructure that nobody manages is just an outage with a delay timer. Pick one model, buy the good cable, run the burn-in once, and the “universal” dock gets you 95% of the old certainty with none of the lock-in.

The weak link in local LLMs has never been the models — it’s the frontends. Ollama and vLLM run beautifully on homelab hardware, but the chat UIs range from serviceable to science project. Which is why an XDA piece this month caught my attention: the author has been running local models — Qwen, GLM-Flash — inside the ChatGPT desktop app, with OpenAI’s client none the wiser, using a free open-source proxy called opencodex. That’s a trick worth understanding even if you never run it.

A proxy, not a fork — and that’s the clever part

opencodex works because the ChatGPT desktop app’s coding side reads its API endpoint from a local config file. The tool edits ~/.codex/config.toml and points it at itself:

# Auto-injected by opencodex
openai_base_url = "http://127.0.0.1:10100/v1"

From then on, every request — listing models, sending a chat — hits the local proxy first. It aggregates your configured providers into one model list, so your local models appear in the official model picker alongside the real OpenAI ones, prefixed by backend (a vLLM-served model shows up as vllm/glm-5.3-flash, say). When you pick one and send a message, the proxy routes the request wherever it actually needs to go.

The reason this is implemented as a proxy rather than a patched app matters: app updates keep landing and the integration keeps working. It survives upgrades because it never touched the app binary, only the config it reads. Anyone who’s maintained a fork of anything will recognize how much grief that design decision saves.

Setup is genuinely short

It’s an npm install. Run ocx init for a guided setup that writes the config and offers to inject the base URL into the config file. Out of the box it auto-detects the three runtimes most homelab people already run on their default ports — Ollama, vLLM, and LM Studio — and anything speaking an OpenAI-compatible API or Anthropic’s Messages API can be added manually. There’s a web dashboard for wiring up providers and, usefully for anyone who bills or budgets by tokens, per-model usage and cost statistics.

The homelab version of this

The interesting move for us isn’t laptop-local models — it’s that the proxy doesn’t care where the provider lives. XDA routes to models on multiple machines over a private network, which maps exactly onto how a homelab wants to run: vLLM serving something big on the GPU box in the rack, a smaller model on the workstation, all surfaced as one model list in a polished desktop client on whatever machine you’re actually sitting at. The frontend problem solves itself, and your model-serving architecture stays exactly as distributed as it already was.

Two honest caveats

Before you point a paying client at this, know where the seams are.

Tool-calling is the real compatibility test. The app’s agent tooling uses its own calling conventions — freeform patch edits, shell access, namespaced tools — and models trained on different conventions can flounder badly. In the XDA testing, one model got completely lost while others handled it fine. The fix is empirical: test your model on the tasks you actually do before trusting it, and don’t conclude “local models are broken” when it’s really “this model wasn’t trained for this client’s dialect.”

Not every request stays local. This is the one that matters for the privacy-motivated. The built-in web search tool still executes through OpenAI’s servers under your ChatGPT login, and if your local model is text-only, image requests get described by an OpenAI model first, with the text handed back to your model. Plain chat and code stay on your wire; search and vision do not. If your rule is “nothing leaves the house,” either avoid those features or accept exactly which calls bypass the proxy — because they will.

Verdict

opencodex is the missing piece a lot of local-LLM setups have been waiting for: a first-party-quality client pointed at your own hardware, with a design (config-level proxying) that won’t fall over on every update. Test your model’s tool-calling, keep an eye on which features phone home, and the best chat frontend for your homelab models might just be one you already have installed.

Cloud storage killed the USB stick for most people, but there’s one flavour of thumb drive that deserves a revival: the pocket repair kit. An XDA piece recently made this case with four Windows-friendly picks, and it’s the right idea — it’s just aimed a bit too consumer for the homelab and small-business crowds. When a client site is half-down or your own rack is misbehaving, you don’t want to be downloading tools on the one connection you don’t trust. Here’s my version: what’s on the stick, and — the part everyone forgets — what’s in the pocket with it.

Carry it all with Ventoy

First, the container. The stick runs Ventoy, so it’s simultaneously a portable-apps drive and a multiboot installer: drop rescue ISOs (GParted Live, a Linux rescue image, memtest) next to the tools folders and boot any of them without re-flashing. One stick, every job. A 64GB drive is plenty; bigger just invites hoarding.

The software kit

Two of XDA’s picks make my cut unchanged, and I swap the rest for tools that answer the questions clients actually ask.

Wireshark Portable

Still the definitive answer to “what is this thing actually doing?” The classic move when a link feels slow: capture for sixty seconds, sort by bytes, and watch the backup job, the misbehaving smart TV, or the sync-happy app reveal itself. Portable runs without installing, which matters when you’re working on someone else’s machine and don’t want to leave footprints.

Nmap

The “is it even on the network?” tool. Two commands cover ninety percent of site visits:

nmap -sn 192.168.1.0/24

lists everything alive on the subnet — perfect for finding the smart plug that silently dropped off Wi-Fi — and

nmap -sV --top-ports 100 192.168.1.10

tells you what a mystery box is running and whether that IoT gadget is exposing more than it should. Before you pat yourself on the back for the closed ports, scan from outside too: the view from the LAN and the view from the internet are different audits.

iperf3

This is my first addition, and honestly the highest-value one. Clients don’t call saying “my TCP window scaling is suboptimal” — they say “it’s slow.” iperf3 splits that complaint in half in under a minute: run a server on the laptop, point the client at it from another device, and you learn whether the network is slow or the endpoint is. Wi-Fi that negotiates at 40Mbps, a flaky patch lead capping a gigabit run at 100 — iperf3 finds these while everyone’s still describing symptoms. Carry builds for Windows, macOS, and Linux; you’ll need all three.

mtr

Ping tells you a thing is down; mtr tells you where. It combines traceroute with continuous ping statistics, so instead of a single frozen path you get per-hop loss and latency over time. When the question is “us, the ISP, or them,” mtr answers it with evidence you can paste into a ticket. Run it for a few hundred cycles, not five.

dig

The XDA article suggests DNS Jumper for flipping between resolvers. It’s fine for consumer use, but dig gets you the truth without a GUI: query a specific server directly, chase the delegation chain, compare answers.

dig @1.1.1.1 example.com +trace

When “the internet is down” turns out to be one broken DNS record, this is the tool that finds it. It ships with BIND tools on Windows and everywhere else on Linux — no third-party download needed.

Where I differ from the original list

NetResView, the fourth pick, is a genuine throwback — SMB network browsing has been deprecated by Microsoft itself, and modern shares don’t announce themselves that way. If you need to inventory Windows shares and printers, nmap’s SMB scripts do it on any platform. A repair kit should be tools you trust on any box, not Windows XP-era utilities that half-work.

The hardware that rides in the same pocket

• A USB 3.0 ethernet adapter. Instant second NIC for laptop captures, and a known-good spare when a desktop’s onboard port is the suspect.
• A USB-serial console cable. The difference between a two-minute switch recovery and a drive to site. If you run any gear with a console port, this is non-negotiable.
• Two known-good patch leads and a coupler. Half of “the network is broken” is one bad lead in a wall of good ones. Yours are known-good because they’ve never left the bag.
• A phone with tethering. To download the driver you inevitably need, from a network that isn’t the patient.

Keep it honest

A repair kit rots quietly. Put a recurring calendar reminder to refresh it quarterly: update the tools, swap in current ISOs, and keep a plain-text manifest of what’s aboard. The worst time to discover your stick’s Wireshark is three years old is mid-outage, on a client’s machine, with no working internet.

Verdict

The XDA premise is right and the execution just needs a homelab accent: Ventoy for the container, Wireshark and Nmap as agreed, then iperf3, mtr, and dig — plus the physical bits that turn software into an actual repair kit. Old USB drives are free; a kit that saves one site visit pays for itself the first time you plug it in.

Every home automation enthusiast hits the same wall: the phone is in the other room, nobody else wants to install the app, and a wall-mounted tablet costs real money for a job that’s mostly “turn off the lights.” Tessera (formerly ESP Screens) takes a swing at that wall with small ESP32 touch panels — from a 2.8-inch CYD board to a 10.1-inch Guition — running firmware you flash once and then manage entirely from Home Assistant. No YAML. No MQTT. No tokens. I’ve been watching this category for a while, and this is the first approach that feels like it was designed by someone who actually lives with other people.

The problem it solves

The standard answers to “always-available home control” are all wrong in some way. A wall tablet is expensive, overpowered, needs a mount and a permanent power scheme, and half the time you end up babysitting its battery or its updates. A phone app is one unlock-gesture away from nothing. Cheap e-ink buttons handle exactly one thing. What most rooms actually need is a small, dumb, always-on surface with a handful of tiles: lights, heating, maybe the vacuum. That’s the whole spec, and Tessera nails it.

How it works

The project is two halves. The firmware side runs on the panel itself. The Home Assistant side is an app called ESP Screen Manager, which handles everything else: it flashes a new screen over USB, updates it over Wi-Fi afterwards, and pushes your tile layout to it. Layout is done in a drag-and-drop editor — pick a tile, drag it, hit Save & send. Changing a screen doesn’t mean reflashing it, and there’s no blueprint to wrangle.

Five panels are supported today: the 2.8-inch CYD, a 4-inch and a 10.1-inch Guition, and 4.3-inch and 7-inch Waveshare boards. The firmware measures its own canvas at boot and lays out pages to fit — around six tiles on the little CYD, twenty on the big Guition — while tiles stay roughly the same physical size in millimetres. The same home scales across all five glasses, which is a smart touch if you standardise on the ecosystem and then upgrade a room later.

What the tiles can do

• Lights, climate, blinds and curtains, the vacuum, and media controls
• Weather, clocks, timers, and history graphs
• Your alarm with a proper keypad, plus cameras on every screen except the 2.8-inch CYD
• A tile that fills a whole page as one big switch you can hit without looking, and tiles that navigate to another page

The detail that sold me: an automation can push an alert to every screen in the house at once. Someone rings the bell, every panel lights up, and any screen with room for a picture shows who’s standing there from the doorbell camera. That’s the difference between a control panel and something that genuinely earns wall space.

Brightness, night hours, and dark mode can all be driven by automations, and if you do hand-write YAML for one screen, it survives firmware updates. Little things, but they’re the little things that decide whether a family actually uses the panels or learns to ignore them.

My buying advice

Start with one mid-size panel — the 4.3-inch Waveshare or the 4-inch Guition — in the room where the “phone in the other room” problem bites hardest. Don’t begin with the 2.8-inch CYD: it’s the cheapest entry point and a fun toy, but six tiles is tight and no camera feed is a real limitation. The 10.1-inch Guition is the living-room showpiece; earn your way to it.

The honest caveats

These are ESP32 panels, not iPads. The screens are modest, the touch is functional, and you shouldn’t expect to mirror a full Home Assistant dashboard on them — this is deliberately a tiles-and-pages model, not a mini browser. It’s also very much a community project with a solo developer and a donation link: pin the version you install, expect the occasional rough edge, and maybe throw the author a coffee if it earns a spot on your wall.

Verdict

A tablet on the wall is a general-purpose computer doing a single-purpose job badly. Tessera flips that: single-purpose hardware doing a single-purpose job properly, at a fraction of the price, with an editor simple enough that non-technical household members won’t need you to change anything. For small-business fitouts — a reception panel for the alarm, a workshop panel for the roller door — the same logic applies double. This is how wall controls should have worked all along.

Most of the dashboards we build in this hobby stare inward. Grafana graphs the temperature of a rack, Uptime Kuma watches our own URLs, the odd ESP32 sensor feeds a gauge nobody outside the house will ever see. Every now and then, though, a project comes along that points all that homelab energy at the outside world. God’s Eye View is that project: a photorealistic 3D globe in your browser that renders live public data — aircraft, ships, satellites, earthquakes, weather, even public cameras — and, refreshingly for something this impressive, runs locally with source code you can actually read.

What it actually is

Built by Bilawal Sidhu (of the God’s Eye View YouTube series), the project describes itself as “a spy satellite simulator in your browser, except the data is real.” That’s accurate. The globe layers a stack of open signals onto one explorable earth:

• Live aircraft from flight transponders (ADS-B), with a cockpit view that can ride a tracked flight down to the ground
• Ship beacons (AIS), orbital elements for satellites, and seismograph feeds
• Weather on a scrub-able timeline: forecast winds, observed radar, satellite clouds, lightning, cyclone tracks — no API key needed
• Public camera locations mapped from OpenStreetMap, including tagged license-plate-reader sites
• Simulated traffic flowing along real roads, aggregated from location data

You can click-to-track anything, speak annotations onto the map as real polygons, reskin the whole thing with GLSL sensor looks (CRT, night vision, thermal), and serialise your exact view — camera, layers, even a live-tracked aircraft — into a shareable URL. It hit #1 on GitHub Trending in August 2026, and it earned it.

Why a homelab person should care

Two reasons. First, it’s the Grafana mindset applied to the planet. The skills that make you good at dashboards — choosing the right data source, filtering noise, composing a view that answers a question — are exactly the skills this thing rewards. Each data layer is a separate module, so extending it with your own feed (your station’s seismograph, your ADS-B receiver’s coverage, your farm’s soil moisture) is the obvious next step once you’ve played with it.

Second, it starts without API keys and runs locally. You install it via Pinokio in one click or clone it and run it from the terminal, and the base experience just works in your browser. Optional keys unlock extras inside the app when you want them. For a box that lives on your LAN serving a household, that’s the right default: no telemetry to a third party, no account to create, nothing phoning home that you didn’t configure.

Practical uses beyond the pretty factor

I’ll be honest: most evenings it’s a toy, and a very good one. But it has quietly useful moments:

• Satellite passes: ask by voice when a loaded satellite next rises over you, and get rise, peak, and set times with a yes/no on visibility. Handy before a planned pass or an ISS photo attempt.
• Weather events: replaying observed radar alongside cyclone tracks during a storm front is more informative than a static news map, and the timeline scrubbing makes the structure of a system obvious.
• Analyst queries: counting, filtering, and ranking things by voice — flights, ships, fires, quakes — with staleness flags on the answers. It’s a surprisingly decent situational-awareness terminal when something is happening somewhere.

Honest caveats

The README is admirably upfront about what’s real and what isn’t, and you should hold that line too: traffic is simulated along real roads, and camera positions and rocket trajectories are coarse estimates. If you find yourself treating it as ground truth during an actual emergency, you’ve drifted. It’s open-source spatial intelligence, not an emergency service.

Also note the voice agent means a microphone. Running locally is the right call, but if you’re the sort who tapes over laptop cameras, think about where this one runs and who’s near it.

Worth your disk space

Projects like this usually end up as a viral video and a dead repo. This one has the opposite shape: real engineering, modular layers, a local-first install, and documentation that admits its own fudges. Drop it on the homelab box, hand the globe to whoever wanders past, and see how long it takes before someone asks “wait, can we put our own data on it?” That question — not the globe — is the actual product.