DEV Community

ADT Confirms Data Breach: ShinyHunters Claim 10 Million Records Stolen

Diego Diaz — Thu, 16 Jul 2026 09:17:01 +0000

What Happened

On April 23, 2026, the ShinyHunters extortion group posted on a leak forum what they claim to be approximately 10 million customer records belonging to ADT — the largest residential security provider in the United States. ADT publicly confirmed the intrusion within 24 hours of the leak appearing, telling BleepingComputer that an unauthorized third party had "obtained certain customer information" and that the company's security team had since contained the access.

The company is now contacting affected customers and offering complimentary credit monitoring, but the leaked sample published by the attackers — names, email addresses, home addresses, and references to active service contracts — has already been independently confirmed by multiple security outlets including CyberInsider and UndercodeNews. Several customers contacted by reporters were able to verify their own records in the leaked sample.

Technical Analysis: How ShinyHunters Likely Got In

ADT has not publicly disclosed the initial access vector, and the company's official statement is restricted to language about "unauthorized access to a portion of our environment" without specifying whether the breach hit a customer-facing application, an internal admin panel, or a third-party SaaS provider. That ambiguity is itself a signal: in our experience auditing companies that disclose breaches with this exact phrasing, the most common root causes are credential reuse against an admin login, an exposed API endpoint without rate limiting, or compromise of a marketing or CRM tool that holds a customer mirror.

ShinyHunters' historical playbook reinforces those hypotheses. The group has spent the last 24 months running a consistent operation against cloud-hosted data warehouses and SaaS admin panels, taking advantage of customer accounts that lacked multi-factor authentication. Threat-research analysis of the ADT incident notes that the same group has previously compromised dozens of large enterprises throughout 2025 and early 2026 — Ticketmaster, Santander, AT&T, and a long list of less prominent victims — using nothing more sophisticated than valid credentials harvested from infostealer logs and a willingness to go straight to public extortion when the victim refuses to pay.

If ADT followed the pattern of those earlier victims, the kill chain looks like this: an employee or contractor's workstation was infected with a generic infostealer at some point in 2025; that infostealer captured a session cookie or credential to a corporate SaaS (most commonly a data warehouse, CRM, or ticketing system); the credential ended up for sale on Russian Market or a comparable broker; ShinyHunters bought it for low three-digit dollars; they logged in, ran SELECT * against the customer table, exfiltrated, and then opened the extortion conversation on TOX or a private channel before going public when negotiations stalled.

Who's Affected and What Was Exposed

The leaked sample published by ShinyHunters indicates the following fields per record: full name, email address, physical home address, phone number, and service plan reference. Notably, the leaked data so far does not appear to include payment card numbers, social security numbers, or alarm system credentials — which would be far more dangerous and which ADT has explicitly said are not affected.

That said, the combination of name + home address + active home-security service contract is itself an unusually sensitive dataset. ADT's customer base skews toward homeowners specifically because they have something to protect: jewelry, electronics, sometimes weapons, occasionally high-net-worth occupants. A motivated burglary crew with this list has a directly actionable target file. The downstream risk here is not identity theft in the traditional sense — it's physical targeting, especially for the subset of customers who installed ADT precisely because they were already concerned about being targeted.

For the ShinyHunters operators themselves, the value in this dataset is not the fields per se but the leverage. Public extortion of a brand whose entire value proposition is "keeping your home safe" is exactly the kind of headline the group has cultivated for two years.

How to Protect Yourself if You're an ADT Customer

Change your ADT account password today, even though the leak does not appear to include passwords. If you have reused that password anywhere else, change it everywhere — and switch to a password manager so you don't have to do this exercise again next time.
Enable multi-factor authentication on the ADT customer portal and on any account where your ADT email is the recovery address. The fact that ShinyHunters has now confirmed they have your email means it is on every targeted phishing list for the foreseeable future.
Be skeptical of any communication referencing your ADT service in the next 90 days. "Your ADT system needs an urgent firmware update — click here to authorize it" is the obvious phishing pretext, and it will be running. ADT will not ask you to authorize anything via email link; if you receive something that looks important, navigate to adt.com directly and log in.
Check whether your home address appears on people-search and data-broker sites. If it does, request removal — California, Colorado, and a growing list of states require brokers to honor opt-outs. The combination of a verified home address on a public broker plus a known ADT service contract is a particularly clean target for harassment or burglary.
If you are a high-profile or high-net-worth customer, treat this as a strong nudge to audit your physical security posture independently — alarm code rotation, neighbor awareness, package handling. The breach itself does not give attackers your alarm code, but it tells them you have one worth bypassing.

The Sable Angle

What stands out about the ADT incident, and almost every ShinyHunters incident before it, is how unsophisticated the attack pattern is relative to the size of the prize. There is no zero-day. There is no nation-state implant. There is a stolen session cookie or a reused password and an admin endpoint that did not enforce MFA. The breach is the predictable consequence of a known control gap that nobody owned closing.

In the offensive engagements we run at Sable, we surface this exact category of finding inside roughly 80% of mid-market and enterprise environments we test. The pattern is so consistent that we built our standard methodology around it: prove that a single leaked credential, given current MFA coverage and current admin-endpoint exposure, is sufficient to reach the customer or financial dataset. We do that work before ShinyHunters does, and we hand the customer a remediation path that is short, specific, and ordered by exploitability — not by CVSS theater. If you want to know whether an attacker with a single $50 credential could repeat the ADT outcome on your environment, our research on third-party credential exposure is a reasonable place to start, and the conversation about a focused engagement is the next step.

I Deleted Cursor, Copilot, and Windsurf. Here Is What I Use Instead.

niuniu — Thu, 16 Jul 2026 09:14:41 +0000

I have been coding for 5 years. I have used every AI tool on the market. Cursor, Copilot, Windsurf, Cody, you name it.

Last month, I deleted all of them.

Not because they are bad. They are great. But I found something better. Something free. Something that runs on my machine and never sends my code to the cloud.

The Problem With AI Coding Tools

Every AI coding tool has the same issue: your code leaves your machine.

When you accept a suggestion from Cursor, your code context is sent to their servers. When Copilot completes your line, your code is processed on Microsoft's servers.

For personal projects, maybe that is fine. But for work? For client code? For proprietary algorithms?

That is a deal breaker.

The Price Problem

Let us talk about money:

Cursor: $20/month
GitHub Copilot: $10/month
Windsurf: $15/month
Cody: $9/month

That is $54-648 per year. Per developer. For a team of 10, that is $5,400-6,480 per year.

For what? For code suggestions that may or may not be correct?

What I Found

Three weeks ago, I discovered MonkeyCode. It is an open-source AI coding platform that runs locally.

Here is what makes it different:

1. It Is Actually Free

Not "free tier with 50 requests." Not "free trial for 14 days." Actually free. Forever.

I have been using it daily for three weeks. Code completions, chat, code review, refactoring. All of it. No limits. No credit card. No catch.

2. Your Code Stays Private

MonkeyCode runs on your machine. Your code never leaves your computer. No cloud servers. No data collection. No "we may use your code to improve our models."

This matters for:

Client work (NDA compliance)
Proprietary algorithms
Security-sensitive code
Personal projects you care about

3. You Choose Your Model

MonkeyCode is not locked to one AI provider. You can use:

MiMo (Xiaomi's open-source model)
GPT-4o or GPT-5 (OpenAI)
Claude (Anthropic)
Local models via Ollama (free forever)

Switch models based on your task. Use a fast model for completions, a powerful one for complex refactoring.

4. It Works With Your IDE

MonkeyCode integrates with:

VS Code (via extension)
JetBrains IDEs (IntelliJ, PyCharm, WebStorm, etc.)

It feels like Copilot, but free and private.

My Results After 3 Weeks

Metric	Before (Cursor)	After (MonkeyCode)
Monthly cost	$20	$0
Features shipped	5/week	8/week
Code privacy	Cloud	100% Local
Model flexibility	Locked	Any model
Peace of mind	Low	High

The Setup

Getting started takes 5 minutes:

# Clone and run
git clone https://github.com/chaitin/MonkeyCode.git
cd MonkeyCode
docker-compose up -d

# Optional: Use free local models
ollama pull qwen2.5-coder:7b

That is it. No account creation. No credit card. No subscription.

What I Miss (And What I Do Not)

I do not miss:

Monthly subscription notifications
"You have 10 remaining requests" warnings
Worrying about code privacy
Being locked to one AI provider

I do miss (a little):

Cursor's polished UI (MonkeyCode is simpler)
The massive extension ecosystem
English documentation (improving)

The Bigger Picture

The AI coding tool market is exploding. Every week there is a new tool, a new pricing model, a new "game-changing" feature.

But here is what most people miss: the core technology is commoditizing. The models are getting smaller, faster, and cheaper. Open-source models are catching up to closed-source ones.

The real value is not in the model. It is in the tooling around it. And MonkeyCode has nailed the tooling.

Try It

If you are paying for AI coding tools right now, ask yourself: why?

What AI coding tools do you use? How much are you paying? Would you switch to a free, private alternative?

P.S. I am not sponsored by MonkeyCode. I just think free, private tools deserve more attention.

P.P.S. If you are a student or indie developer, MonkeyCode is especially great. No budget? No problem.

The redesign shipped. The smoke test kept walking the old UI.

Omer Hochman — Thu, 16 Jul 2026 09:13:45 +0000

Originally published at nlqdb.com/blog

Our acceptance walkers pin literal UI strings on purpose. A walker asserts the homepage placeholder reads exactly what we ship, that a heading says the words we wrote, that the query composer is where we put it. Drift fails the walk loudly — and a loud failure the moment the surface changes underneath you is precisely the regression detector you want. Silent tolerance is how a broken flow ships green.

Then three things happened in one week. A homepage redesign moved the goal input to a different page. A copy edit reworded a heading. The MCP catalog additively grew two tools. None of these broke the product. All three broke the walkers — which dutifully reported 0/9, and kept reporting it for a week.

The trap isn't the literal assertions

The reflex is to blame the pinned strings and loosen them into fuzzy matches. That's the wrong lesson. The literals did their job: the surface changed, the walk went red. The actual cost is that a red which mixes "the product broke" with "the test went stale" takes a full manual triage to disentangle — and ours contained both at once. Two flows were red from pure test-drift. One flow was red from a real production wall. Same 0/9. You cannot tell which is which from the number, so every red costs you the same expensive human read regardless of whether anything is actually wrong.

Three notes that make pinned walkers pay off

Pinned literals are fine only if reds are triaged inside a bounded window. A detector nobody reads within a day isn't a detector — it's drift accumulating interest until the next person can't tell a week-old copy edit from this-morning's outage.
The failure detail must name the element and the expectation. placeholder was null, expected "Ask your data anything" is decidable from the artifact alone — you know instantly it's drift, not breakage. failed at step 2 forces you to re-run the whole walk by hand to find out.
"A PR touching a walked surface re-runs the walker" was already our rule — and it was skipped, because it was a convention, not a gate. A convention without an enforcing check is a wish. Wire the walker into the surface's required checks, or accept the false-red debt knowingly — but don't pretend a rule nobody enforces is protecting you.

This is a testing-hygiene pattern, not a product feature: it's for anyone whose end-to-end suite asserts real rendered copy rather than test-ids. The literals are worth keeping — they catch the drift you'd otherwise ship. Just make the red self-explaining and triage it on a clock, or the detector quietly becomes a week of noise that hides the one failure that mattered. nlqdb is a database you query in plain English; this is one of the measurement lessons from keeping our stranger-walk honest as the product underneath it moved.

What's Actually Inside a JWT (and Why Decoding One Isn't Verifying It)

Anh Quân Nguyễn — Thu, 16 Jul 2026 09:13:37 +0000

We've established that Base64 isn't encryption and that you can't un-hash a password. JWTs are where both of those facts collide — and where the misunderstanding gets expensive, because this one has a CVE class named after it.

Here's the claim that surprises people the first time: a JWT is not encrypted, and anyone holding one can read every claim inside it without a key, a library, or your permission. That's not a bug. But if you don't know it, you will eventually put something in a token that shouldn't be there.

Three dots, three parts

A JWT is a string with exactly two dots in it:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWxpY2UiLCJhZG1pbiI6dHJ1ZX0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Split on the dots and you get header, payload, signature. The first two are just Base64url-encoded JSON. Decode part one and it's:

{ "alg": "HS256", "typ": "JWT" }

Part two:

{ "sub": "123", "name": "Alice", "admin": true }

No key involved. No decryption. It's JSON that went through an encoder, and encoding runs backwards for free — that's what encoding is. If a token is sitting in someone's browser storage, in a log file, in a proxy's request dump, or in a screenshot pasted into Slack, every claim in it is readable by whoever has it.

So the rule falls out immediately: never put a secret in a JWT payload. Not a password, not an API key, not a national ID, not "internal_notes". Assume the payload is public, because functionally it is. It's a signed postcard, not a sealed envelope.

Why "Base64url" and not plain Base64

Small detail, real consequences. JWTs live in hostile places — Authorization headers, query strings, cookies, URLs — and standard Base64's alphabet includes +, /, and =. Those characters mean something in a URL: + can become a space, / splits a path, = separates a query param. A token pasted into a link would corrupt itself.

Base64url fixes it by swapping + → -, / → _, and dropping the = padding. Same encoding, URL-safe alphabet. This is why a JWT survives being a query parameter while a raw Base64 blob often doesn't — and it's the same class of problem percent-encoding solves for everything else you stuff into a URL. Two different escaping schemes, one shared reason: some characters are structural, and data that contains them has to get out of the way.

The signature is the only part that matters

The third segment is where the actual security is. It's not a hash of the payload — it's a keyed hash (an HMAC, for HS256) or a digital signature (for RS256), computed over the header and payload together, using a secret only your server knows:

signature = HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

This is what a hash is for, in the sense from the last article: a tamper-evident fingerprint. An attacker can freely edit the payload — flip "admin": false to "admin": true — and re-encode it. That part is trivial. What they cannot do is produce the matching signature, because that needs the secret. Your server recomputes the HMAC over whatever it received and compares. Mismatch means forged or corrupted, and the token is rejected.

So the token is readable by everyone and forgeable by no one. That's the actual security model, and it's a good one — as long as you check the signature.

The mistake that has a CVE

Which brings us to the trap in the title. Decoding a JWT and verifying a JWT are completely different operations, and it is very easy to write code that does the first while believing it does the second:

// This is NOT authentication.
const payload = JSON.parse(atob(token.split('.')[1]));
if (payload.admin) { grantAdminAccess(); }   // 💥

That code reads a claim the attacker wrote and never touches the signature. Anyone can craft that token in ten seconds. The library function you actually want is verify(token, secret), not decode(token) — and in most JWT libraries those sit right next to each other with nearly identical names. That's how this keeps happening.

The historical version of this bug is worse and worth knowing, because it explains a defensive habit you'll see in real code. Early JWT libraries trusted the alg field in the header — a field the attacker controls. Set "alg": "none", send an empty signature, and some libraries said "no algorithm specified, nothing to check, looks valid." Others accepted swapping RS256 (asymmetric) for HS256 (symmetric), tricking the server into verifying with the public key as if it were the shared secret. Both are full authentication bypasses caused by letting the token declare how it should be checked. The fix is to pin the expected algorithm server-side and never read it from the token.

If you want to see the split for yourself, take any non-production token and drop it into a JWT decoder: the header and payload render as readable JSON instantly, while the signature stays an opaque blob. That's the honest picture — the decoder can show you the claims because nothing is protecting them, and it can't tell you whether the token is genuine because that requires the secret it doesn't have. The asymmetry on the screen is the lesson.

What to actually check

A signature check alone isn't enough; a valid signature only proves the token is authentic, not that it's still appropriate. Verify these too:

exp (expiration) — a signature never expires on its own. If you don't check exp, a stolen token works forever.
iss / aud — is this token from the issuer you trust, and was it minted for your service? Without these, a valid token from a different tenant or app may sail through.
nbf (not before) — reject tokens not yet valid.
Revocation — JWTs are stateless by design, so you can't "delete" one. That's the real trade-off: no session lookup, but no logout either. Short expiry plus refresh tokens, or a deny-list for the paranoid paths.

The one-sentence version

A JWT is Base64url-encoded JSON that anyone can read plus a signature only your server can produce — so treat the payload as public, never trust a claim you haven't verified with the secret, pin the algorithm instead of believing the header, and remember that decode() answers "what does this say" while only verify() answers "should I believe it."

Agentic Systems: From Single Agent to Orchestration

mihir mohapatra — Thu, 16 Jul 2026 09:11:30 +0000

A single agent — one model, a system prompt, a handful of tools, and a loop — gets you surprisingly far. It's also where most people stop, because it works for demos and falls over the moment a task needs more than one kind of reasoning happening at once.

Multi-agent orchestration isn't a hype upgrade over a single agent — it's what you reach for when a task naturally decomposes into sub-tasks that benefit from different context, different tools, or genuinely different roles. This post covers when that shift is warranted, the orchestration patterns actually used in production, and a small working example of a coordinator delegating to worker agents.

Why a single agent stops being enough

A single agent's context window and tool list grow with every capability you bolt on. Three failure modes show up as that happens:

Context pollution — a research task's intermediate scratch work bleeds into the reasoning for an unrelated coding sub-task, degrading both
Tool overload — past a certain number of tools in one system prompt, selection accuracy drops; the model spends more of its reasoning deciding which tool than actually using it well
No separation of concerns — a single agent can't easily hold "be a careful planner" and "be a fast, narrow executor" as two different behavioral modes at once

Orchestration solves this by splitting one large, blurry job into a coordinator plus specialized workers, each with a narrow role, its own context, and only the tools it actually needs.

The patterns that show up in practice

There isn't one "multi-agent architecture" — a few concrete patterns cover most real systems:

Sequential (pipeline) — agent A's output feeds agent B, feeds agent C. Good for linear workflows like research → draft → review.
Concurrent (fan-out/fan-in) — the coordinator dispatches the same or related sub-tasks to multiple agents in parallel, then merges results. Good for independent sub-tasks — e.g. summarizing five documents at once.
Handoff — one agent decides mid-task that another agent is better suited and transfers control (and context) to it. Good for triage-style systems, like a support bot handing off to a specialist agent.
Hierarchical (coordinator/worker) — a central planner decomposes the task and delegates to specialized workers, then assembles their outputs into a final answer. This is the most common production pattern and the one the example below uses.

Frameworks like LangGraph model this as an explicit state graph, CrewAI models it as role-based "crews," and minimal SDKs like the OpenAI Agents SDK treat sub-agents as callable tools from a parent agent. The underlying pattern is the same regardless of framework — what differs is how much structure and observability you get by default.

A working example: coordinator + worker agents in Rust

Here's a minimal hierarchical setup: a coordinator agent receives a research request, decomposes it into sub-tasks, dispatches them to worker agents concurrently, and merges the results.

use futures::future::join_all;
use serde::{Deserialize, Serialize};

#[derive(Debug, Clone, Serialize, Deserialize)]
struct SubTask {
    id: String,
    description: String,
    assigned_role: AgentRole,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
enum AgentRole {
    Researcher,
    CodeAnalyst,
    Summarizer,
}

#[derive(Debug, Serialize)]
struct WorkerResult {
    task_id: String,
    output: String,
    tokens_used: u32,
}

struct Coordinator {
    llm_client: LlmClient,
}

impl Coordinator {
    /// Decompose a high-level request into sub-tasks using the coordinator's own LLM call.
    async fn plan(&self, request: &str) -> Vec<SubTask> {
        let planning_prompt = format!(
            "Break this request into 2-4 independent sub-tasks, each assigned \
             to Researcher, CodeAnalyst, or Summarizer. Request: {request}"
        );
        let response = self.llm_client.complete(&planning_prompt).await;
        parse_subtasks(&response) // structured output parsing, omitted for brevity
    }

    /// Dispatch sub-tasks to worker agents concurrently, then merge.
    async fn execute(&self, request: &str) -> String {
        let subtasks = self.plan(request).await;

        let worker_futures = subtasks.into_iter().map(|task| {
            let client = self.llm_client.clone();
            async move { run_worker(client, task).await }
        });

        let results: Vec<WorkerResult> = join_all(worker_futures).await;

        self.merge(results).await
    }

    /// A final LLM call that synthesizes worker outputs into one coherent answer.
    async fn merge(&self, results: Vec<WorkerResult>) -> String {
        let combined = results.iter()
            .map(|r| format!("[{}]: {}", r.task_id, r.output))
            .collect::<Vec<_>>()
            .join("\n\n");

        let merge_prompt = format!(
            "Synthesize these sub-task results into one coherent response:\n\n{combined}"
        );
        self.llm_client.complete(&merge_prompt).await
    }
}

async fn run_worker(client: LlmClient, task: SubTask) -> WorkerResult {
    let role_prompt = match task.assigned_role {
        AgentRole::Researcher => "You are a focused researcher. Be concise and cite sources.",
        AgentRole::CodeAnalyst => "You are a code analyst. Focus only on technical accuracy.",
        AgentRole::Summarizer => "You are a summarizer. Compress without losing key facts.",
    };

    let prompt = format!("{role_prompt}\n\nTask: {}", task.description);
    let output = client.complete(&prompt).await;

    WorkerResult {
        task_id: task.id,
        output,
        tokens_used: estimate_tokens(&output),
    }
}

A few things worth calling out in this shape:

Each worker gets its own narrow system prompt (role_prompt) instead of sharing the coordinator's full context — this is the actual mechanism that fixes context pollution.
join_all runs workers concurrently, not sequentially — for independent sub-tasks, this is a straightforward latency win that a single-agent loop can't get you.
The merge step is itself an LLM call, not string concatenation — worker outputs are often redundant or need reconciling, and skipping this step is a common source of disjointed final answers.

Where this pattern breaks down

Multi-agent orchestration isn't free — it's worth naming the costs explicitly, since a lot of write-ups skip this part:

More tokens spent overall — planning, dispatch, and merge steps are all additional LLM calls layered on top of the actual work
Harder to debug — a wrong final answer could originate in planning, in any worker, or in the merge step; this is exactly why the tracing patterns from the observability post in this series matter more, not less, once you add orchestration
Coordination overhead can exceed the benefit for genuinely simple, linear tasks — a single well-scoped agent with good tools is still the right default until you hit one of the failure modes above

The Gartner-cited pattern worth taking seriously: a meaningful share of agentic projects get cancelled not because agents don't work, but because teams reached for orchestration before the task actually needed it, and the coordination overhead outweighed the gain.

A reasonable decision rule

Reach for a single agent by default. Move to orchestration when at least one of these is true:

The task has genuinely independent sub-parts that would otherwise share (and pollute) one context window
Different sub-tasks need meaningfully different tool sets or behavioral instructions
You need parallelism for latency reasons, not just organizational tidiness

If none of those apply, a single well-designed agent with good tool selection will usually outperform a multi-agent system on both cost and reliability.

What's next

The next post in this series steps back to a cost/control framework: when running open-weight models yourself makes sense versus calling a closed API, and how to reason about that tradeoff instead of defaulting to whichever one is trending.

This is part of a series on AI infrastructure patterns, drawing on production work building multi-provider AI gateways in Rust. Follow along for the rest of the series.

Magento 2 Widget Performance Optimization: Fix Slow CMS Blocks & Homepage Rendering

Magevanta — Thu, 16 Jul 2026 09:08:36 +0000

Magento 2 widgets are everywhere. The product carousel on your homepage. The "New Arrivals" CMS block. The category list sidebar. The promotional banner that changes every week. Every one of these is a widget — and every one of them can slow your store to a crawl if configured poorly.

Unlike obvious performance culprits like unoptimized images or missing Varnish caching, widgets fly under the radar. They are buried in CMS content, referenced by {{widget type="..."}} directives, or loaded via layout XML as static blocks. Their impact compounds: a single widget that runs a product collection query with no cache tags can add 200-400ms to every page load. Three of them? You just lost half a second on the critical path.

This post covers how to identify slow widgets, why they hurt performance, and what you can do about it.

How Widgets Work in Magento 2

Magento 2 widgets are small UI components rendered through a combination of:

Widget directives in CMS pages/blocks: {{widget type="Magento\Catalog\Block\Product\Widget\NewWidget" ...}}
Layout XML handles that insert widget blocks into pages
Widget instances configured in Admin → Content → Widgets

When Magento renders a page containing a widget, it:

Parses the directive or layout instruction
Instantiates the block class
Runs any collection queries or data loading
Renders the template
Injects the output into the page

The problem is that step 3 often hits the database with unoptimized queries, and step 4 may load additional blocks recursively — all without proper full-page cache (FPC) integration.

Common Widget Performance Problems

1. Product Collection Widgets Without Caching

The Magento\Catalog\Block\Product\ListProduct widget, and any custom widget extending it, typically loads a product collection. If the block does not implement Magento\Framework\DataObject\IdentityInterface to return cache tags, Varnish and the built-in FPC cannot invalidate the widget when products change. Worse, if the block's getCacheLifetime() returns null or is not set, Magento skips block caching entirely.

2. CMS Block Widgets with Recursive Rendering

A CMS block containing a product widget, which contains another CMS block, which contains a category list widget — each level adds rendering overhead. Magento's block rendering is single-threaded and recursive; deep nesting means more block instantiation, more layout XML merging, and more template rendering time.

3. Widget Instances with Overly Broad Layout Updates

In Admin → Content → Widgets, each widget instance has a "Layout Updates" section where you assign it to specific pages and containers. A widget assigned to "All Pages" in the "Main Content Area" container will render on every single page of your store — including checkout, customer account, and static CMS pages. If that widget loads a product collection, you are running a database query on every page, even pages where the widget is not visible or relevant.

4. Static Block Widgets with Dynamic Content

The Magento\Cms\Block\Widget\Block widget renders a CMS static block. If that static block contains a widget directive (like a product list), the static block itself is cacheable, but the nested widget may not be. Magento caches the CMS block output by block ID and store view, but cache invalidation for nested widgets depends on both the outer block's and inner widget's cache tags being correctly defined.

How to Identify Slow Widgets

Enable Magento Profiler

Add ?profiler=1 to any frontend URL (requires the profiler to be enabled in app/etc/env.php):

'system' => [
    'profiler' => [
        'enable' => 1
    ]
]

Look for block rendering times under the "Blocks" section. Any block starting with widget. or cms. with a rendering time over 50ms deserves investigation.

Use Blackfire or Tideways

Profile a homepage or category page load. Look for:

Database queries originating from Magento\Widget or Magento\Cms namespaces
Repeated collection loads from widget block classes
Long render() or toHtml() calls on widget blocks

Check Widget Instance Layout Scope

Run this SQL query to find widget instances assigned to overly broad layouts:

SELECT wi.instance_id, wi.title, wpm.page_group, wpm.layout_handle
FROM widget_instance wi
JOIN widget_instance_page wpm ON wi.instance_id = wpm.instance_id
WHERE wpm.page_group = 'all_pages'
   OR wpm.layout_handle = 'default';

Any widget on all_pages or default handle that loads a collection should be re-evaluated.

Fixing Widget Performance

1. Implement Proper Block Caching

Every custom widget block should implement IdentityInterface and define cache tags:

use Magento\Framework\DataObject\IdentityInterface;
use Magento\Catalog\Model\Product as ProductModel;

class MyCustomWidget extends Template implements IdentityInterface
{
    public function getIdentities(): array
    {
        $identities = [ProductModel::CACHE_TAG];
        foreach ($this->getProductCollection() as $product) {
            $identities[] = ProductModel::CACHE_TAG . '_' . $product->getId();
        }
        return $identities;
    }

    public function getCacheLifetime(): ?int
    {
        return 3600; // Cache for 1 hour, or use null for FPC-managed lifetime
    }
}

This tells Magento (and Varnish) to invalidate this block whenever any product or a specific product changes.

2. Scope Widget Instances Correctly

In Admin → Content → Widgets:

Assign widgets to specific layout handles instead of "All Pages"
Use "Main Content Area" only for homepage-critical widgets
For sidebar widgets, use "Sidebar Main" or "Sidebar Additional" containers
Remove widgets from checkout and customer account pages unless absolutely necessary

For example, a "New Arrivals" carousel should target cms_index_index (homepage), not default.

3. Replace Dynamic Widgets with Static Content Where Possible

Not every product list needs to be dynamic. If you have a "Best Sellers" widget that updates weekly, consider:

Generating the HTML via a cron job and storing it in a CMS block
Using a cache warmer to pre-render the widget at a set interval
Replacing the widget with a static block for low-traffic periods and switching to dynamic only during high-traffic events

4. Limit Collection Size and Eager-Load Relations

Widget blocks that load product collections should:

Set a strict page size limit (e.g., ->setPageSize(8) for carousels)
Add only necessary attributes via ->addAttributeToSelect(['name', 'price', 'small_image'])
Enable flat catalog for large stores to avoid EAV joins
Use ->addUrlRewrite() to pre-load URL rewrites and avoid N+1 queries

Example optimized collection:

$collection = $this->productCollectionFactory->create();
$collection->addAttributeToSelect(['name', 'price', 'small_image', 'url_key'])
    ->addAttributeToFilter('status', Status::STATUS_ENABLED)
    ->addAttributeToFilter('visibility', ['in' => [
        Visibility::VISIBILITY_IN_CATALOG,
        Visibility::VISIBILITY_BOTH
    ]])
    ->addUrlRewrite()
    ->setPageSize(8)
    ->setCurPage(1);

5. Audit CMS Blocks for Nested Widgets

Run a database query to find CMS blocks containing widget directives:

SELECT block_id, identifier, content
FROM cms_block
WHERE content LIKE '%{{widget%';

For each result, review the content. If a CMS block contains a product widget that is also used inside a widget instance, you may be double-rendering. Flatten the structure or move the widget logic entirely into the block template.

Advanced: Widget Caching with Varnish ESI

For stores with Varnish, Edge Side Includes (ESI) can help with widgets that need to be dynamic but should not block the full page cache:

Configure the widget block with cacheable="false" or a very short TTL
Add ESI support in your Varnish VCL for widget block URLs
Let Varnish serve the cached page while fetching the widget content separately

However, be cautious: each ESI request adds HTTP overhead. Use ESI for high-value, truly dynamic widgets (e.g., personalized recommendations), not for static product lists.

Monitoring Widget Performance in Production

Set up alerts for:

Pages with block rendering time > 200ms total
Database queries from widget blocks exceeding 100ms
Cache hit ratio drops on pages with heavy widget usage

New Relic, Datadog, or even Magento Cloud's built-in monitoring can surface widget-level slowness if you tag your custom blocks with meaningful names during profiling.

Summary

Widgets are convenient but dangerous. Every {{widget ...}} directive is a potential performance regression. Treat them like any other code: audit, profile, cache, and scope tightly.

Key takeaways:

Implement IdentityInterface on custom widget blocks
Scope widget instances to specific layout handles
Limit collection sizes and eager-load data
Flatten nested CMS block → widget structures
Monitor block rendering times in production

Your homepage does not need to query the database on every request. Fix your widgets, and your customers will notice the speed.

Pinch: A Fingertip-Sized 32-Bit Arduino-Compatible Dev Board

circuitrocks — Thu, 16 Jul 2026 09:07:51 +0000

You know that weekend project idea that stalled because the dev board was bigger than the thing you wanted to hide it inside? A wearable, a keyfob mod, a sensor tucked into a bottle cap? The pinch from moddo is the board that finally makes those builds realistic.

A whole Arduino the size of a USB-C plug

moddo calls the pinch "the world's smallest 32-bit Arduino-compatible board," and while nobody has the record book out, it is hard to argue. The whole thing takes up about the same surface area as a female USB-C connector. Under the hood sits a Microchip SAMD11, an ARM Cortex-M0+ running at 48 MHz, with native USB so you flash it straight over the cable with no separate programmer. You get 15 GPIO pins plus the usual SPI, I2C, PWM, and UART, which is plenty for a small sensor node or a blinky wearable.

The parts-and-cost reality

Two things to keep in mind before you plan a build around it. First, the specs are tight: 4 KB of SRAM and 16 KB of flash, and the bootloader eats 4 KB of that flash right off the top, leaving you roughly 12 KB to work in. Coming from an ESP32 you will feel the squeeze, so skip heavy libraries, watch your String usage, and lean on direct register writes if you run out of room. Second, it is a pre-order: the $16 board (roughly PHP 900) is slated to ship in September, so this is a plan-it-now, solder-it-later project.

MCU: Microchip SAMD11, Cortex-M0+ at 48 MHz
Memory: 4 KB SRAM, 16 KB flash (about 12 KB usable)
I/O: 15 GPIO, native USB, SPI, I2C, PWM, UART
Bonus: a breakout board ships with it so you can breadboard the pins

Worth a Sunday of planning

The circuit schematic and a STEP 3D model are already public, with the full board design files close behind, so you can lay out your enclosure or PCB before the board even lands on your bench. Read the specs straight from the source at moddo.io/pages/pinch, decide which sensor you would wire to those 15 pins, and have your firmware ready for the day it arrives.

Originally published on blog.circuit.rocks.

arduino #arduinoprojects #electronics #embedded #circuitrocks

Diaspora Coders Assemble Earthquake Response in Hours with AI

Dave Kurian — Thu, 16 Jul 2026 09:07:01 +0000

Three hours, six coders, 30,000 missing people

A Venezuelan programmer in Buenos Aires had a team of six and a flood of missing-person reports. Without AI, the build would have taken roughly 24 hours. With Claude Opus, it took three. The site — Desaparecidos Terremoto Venezuela — let anyone upload a photo, ran facial recognition against the missing-person database, and matched people in seconds. No app, no registration, a WhatsApp link. By the second day it had absorbed more than 30,000 submissions.

Four hours after that, a developer in California shipped Ayuda en Camino on Replit. It matched supplies (medicine, blankets, transport) against need, and a WhatsApp assistant fielded queries from people whose connections couldn't load a website.

Twin earthquakes had flattened hospitals and severed fiber and mobile towers across northern Venezuela. The state was slow. The telecom backbone was in pieces. The diaspora coders shipped first.

That inversion is the story. Not "AI saves the day" — that's lazy framing. The real story is that consumer-grade AI on any developer's laptop, wielded by people with domain knowledge and urgency, outpaced an emergency budget. The tools that did it — Claude Opus, Replit, WhatsApp — were the same ones sitting on every senior engineer's machine. The state had the budget. The coders had the latency.

The mechanics: what three hours actually buys you

Desaparecidos is the cleanest example. The site does four things: photo upload, facial matching against a missing-person database, deduplication, and a public lookup flow. Each one alone is a weekend project. Together, with a polished UI, it's a sprint.

Claude Opus collapsed the sprint into an afternoon. The article pegs the build at "roughly 24 hours without rest" without AI and "three" with it. That is an 8× compression, and it isn't from autocomplete — it's from a model that holds the whole architecture in context, drafts the matching logic, writes the moderation rules, and ships the boilerplate that would otherwise eat the first six hours.

Ayuda en Camino is the second pattern. Replit's collaborative runtime means the diaspora in Buenos Aires, Santiago, Miami, and San Francisco can co-edit the same codebase without provisioning anything. Four hours from idea to production URL. The second inversion isn't "AI writes code faster." It's "AI + a hosted runtime collapses deployment to zero."

Both patterns share a precondition: the people shipping had domain knowledge. They were Venezuelan. They knew what a crisis actually looks like at street level. They had access to the same models any developer has. They didn't have institutional access. They didn't have FEMA's budget. They had Claude, Replit, and a WhatsApp number.

Why the inversion isn't really about the model

Here is the uncomfortable bit. If Claude's API had been down that week, or Replit had a regional outage, or Anthropic had changed the model id on Tuesday, the Desaparecidos site might not have shipped in time. The 30,000 reports still would have piled up — in Telegram groups, in spreadsheets, in handwritten notes. AI gave the team a multiplier. The multiplier rides on infrastructure the team does not control.

Most "AI saved the day" framing misses this. The model is the volatile layer. The prompts, the architecture, the schema for missing-person reports, the WhatsApp-onboarding flow — those are the durable layer. Two weeks after the crisis, the team will still need the schema. They will still need the lookup UX. They may not still need Opus.

This is true in every domain where AI is showing up right now. The thing you ship in an afternoon with AI is fast. The thing that survives the model churn — the next pricing change, the next deprecation, the next id rotation — has to be built on a foundation that doesn't depend on which LLM you call this quarter.

The WhatsApp constraint is the real lesson

Most coverage will lead with the LLM. The more interesting constraint is the WhatsApp fallback. Samuel Mariña's team built a WhatsApp assistant because "users could not load the site because their connection was too weak." The richest model in the world is useless if the user is on 2G with 200 kbps and a dying battery.

That constraint shapes every architectural decision in crisis software:

The interface has to degrade gracefully from rich web → SMS → WhatsApp → voice.
The state has to live somewhere the user doesn't have to authenticate to retrieve.
The matching has to work even when half the database is corrupt or duplicated.

The teams that shipped understood this. The teams that would have built the same thing in six months at a UN agency probably would have shipped a WebGL dashboard and called it innovation.

Here is roughly what the public-facing schema had to carry:

// The part that has to outlive the model.
type MissingPersonReport = {
  id: string                          // server-generated, opaque
  reportedAt: number                  // unix ms
  reporterContact: string             // WhatsApp number, never displayed publicly
  photoUrl?: string                   // optional, blurred in public view
  fullName: string
  ageRange?: [number, number]         // fuzzy on purpose — age is unreliable in panic
  lastSeenLocation?: string           // free text, geocoded client-side
  lastSeenAt?: number
  status: 'missing' | 'found' | 'duplicate'
}

// Lookup by photo, by name, by location — all three paths.
// Match confidence drives the UI: high → "we think this is them",
// low → "possible matches" stack.

Notice what isn't in there: a model id, a prompt template, an embedding dimension, a vector index. The model is replaceable. The schema is not. Two years from now, when the next earthquake hits and the diaspora opens laptops again, the schema is what carries over.

What this gets us

Three things worth keeping from the Venezuela response:

Consumer AI is now a crisis-grade force multiplier. Not because the models are magical, but because they're on every laptop and the latency to "production URL" is measured in hours, not months. The next disaster — and there will be one — will have diaspora coders shipping again. That is a feature of the world now.
The durable layer is the schema and the UX, not the model. The team that ships a reusable missing-person schema this week can rebuild Desaparecidos in 90 minutes for the next earthquake in Turkey, Morocco, or Myanmar. The team that ships a reusable lookup interface can do the same for any crisis where people need to find people. The team that shipped nothing but a Claude prompt shipped nothing.
Constraints shape architecture more than capabilities. WhatsApp-first, no-registration, photo-upload-only. The interface is dictated by what the user has, not what the model can do. That is the opposite of how most AI demos get built — and the reason this one actually worked.

[[CONCEPT: a thin layer of LLM calls sitting on top of a thick layer of schema, components, and durable interfaces — the LLM is replaceable; the layer underneath is not]]

The part that doesn't churn

When you ship something in three hours on Claude, you ship on borrowed time. The model id changes. The pricing changes. The rate limits change. The team maintaining the site in two years will be maintaining crisis infrastructure that was written against a model snapshot.

The pieces that survive are the ones that don't depend on the model:

The component layer that renders the same UI on web and mobile, so the lookup works on whatever the user happens to have in their hand.
The data layer that holds the schema for missing-person reports, donation routing, or supply matching — versioned, portable, and readable without an LLM.
The auth layer that lets someone with a phone number and a face be findable without an account, an email, or an OAuth flow.

These are the boring parts. They are also the parts that don't change when the model does.

Use Claude. Use Replit. Ship in three hours. And build the parts that don't change on something that doesn't change — a cross-platform component layer that ships the same UX to web, iOS, and Android from one API, a schema that outlives the snapshot, and an auth flow that works on the worst connection the user has. The model will rotate. The components, the schema, and the delivery surface stay.

Bridge Networking in Linux

Aviral Srivastava — Thu, 16 Jul 2026 09:06:50 +0000

Bridging the Gap: Your Ultimate Guide to Linux Network Bridges

Ever found yourself tangled in the wires of your home network, wishing for a simpler, more elegant way to connect devices? Or perhaps you're a budding system administrator, diving headfirst into the magical world of virtual machines and containers, and you've stumbled upon this mysterious "bridge networking"? Fear not, intrepid explorer of the digital realm! Today, we're going to demystify the concept of network bridges in Linux. Think of it as building a sophisticated, invisible ethernet switch within your operating system, allowing your virtual and physical devices to play nicely together.

We'll embark on a journey, uncovering what bridges are, why you'd want to use them, how to set them up, and some of the nitty-gritty details that make them so powerful. So, grab a coffee (or your beverage of choice), settle in, and let's bridge the gap to understanding!

Introduction: What Exactly IS a Network Bridge?

Imagine you have two separate networks. Maybe one is your physical home network (your router, your laptops, your smart TV), and the other is a virtual network running inside your computer for a virtual machine (VM). Normally, these two worlds are isolated. Your VM can't directly see your TV, and your TV can't ping your VM.

A network bridge in Linux acts like a virtual Ethernet switch. It connects multiple network interfaces (both physical and virtual) into a single logical network segment. This means that devices attached to different interfaces that are part of the same bridge can communicate with each other as if they were plugged into the same physical switch.

Think of it this way: Instead of plugging your VM directly into your computer's network card and then trying to route traffic between them, you create a bridge. You then "plug" both your physical network interface (e.g., eth0 or wlan0) and your VM's virtual network interface (e.g., veth0) into this bridge. Now, the bridge handles all the traffic forwarding, making it appear as though all these devices are on the same network, talking directly to each other.

Prerequisites: What You'll Need to Get Started

Before we dive into the "how-to," let's make sure you're prepared.

A Linux System: Obviously! This guide is primarily for Linux distributions like Ubuntu, Debian, CentOS, Fedora, etc.
Root Privileges: You'll need administrator (root) access to install software and configure network interfaces. Be careful when working with root privileges – a typo can have unintended consequences!
Basic Networking Knowledge: Understanding IP addresses, subnets, gateways, and network interfaces will be helpful.
bridge-utils Package: This is the essential toolkit for managing bridges in Linux. Most distributions have it available in their repositories. You can usually install it with your package manager.
- Debian/Ubuntu:
```
sudo apt update
sudo apt install bridge-utils
```
- CentOS/Fedora/RHEL:
```
sudo yum install bridge-utils  # or sudo dnf install bridge-utils
```
Virtualization Software (Optional but common): If you're planning to use bridges for VMs, you'll need virtualization software like KVM/QEMU, VirtualBox, or VMware. For containers, you'll likely be using Docker or LXC.

Advantages: Why Bother with Bridges?

So, why would you go through the trouble of setting up a bridge? The benefits are numerous, especially in modern IT environments:

Seamless Virtual Machine Networking: This is the most common use case. Bridges allow VMs to appear as if they are directly connected to your physical network, getting their own IP addresses from your router. This makes managing and accessing VMs much easier.
Container Networking: Similar to VMs, bridges are fundamental for container networking, enabling containers to communicate with each other and the outside world.
Network Segmentation and Isolation: You can create multiple bridges, each segmenting different sets of devices. This can enhance security and manageability.
Simplified Network Topologies: Instead of complex routing rules, a bridge can flatten your network, making it appear as a single subnet.
Traffic Monitoring and Filtering: By intercepting traffic at the bridge level, you can implement advanced monitoring and filtering solutions.
Connecting Heterogeneous Networks: Bridges can connect different types of network interfaces, such as wired Ethernet and wireless interfaces (though this can be more complex and may require specific configurations).

Disadvantages: The Flip Side of the Coin

While bridges are incredibly useful, they're not a magic bullet. Here are a few drawbacks to consider:

Performance Overhead: Introducing a bridge can add a small amount of latency and CPU overhead compared to direct physical connections, as the operating system needs to process the traffic through the bridging software. For most everyday use cases, this is negligible.
Broadcast Domain Expansion: Bridges operate at Layer 2 (Data Link Layer). By default, they forward broadcast traffic. If you have a very large or poorly managed network, excessive broadcasts can lead to performance issues.
Complexity for Beginners: While we're aiming to demystify it, setting up and troubleshooting network bridges can be a bit daunting for those new to networking.
MAC Address Handling: Each interface attached to a bridge gets its own MAC address. The bridge itself also has a MAC address. This can sometimes lead to confusion if not managed properly.
Wireless Limitations: Bridging a wireless interface (wlanX) to a bridge can be tricky. Most Wi-Fi drivers operate in a managed mode where the access point handles bridging. You might need to use monitor mode or specific configurations for certain scenarios, which can be less reliable.

Features and Functionality: Under the Hood

Let's peek under the hood and see what makes bridges tick.

Layer 2 Operation: Bridges operate at the Data Link Layer (Layer 2) of the OSI model. They forward frames based on MAC addresses, not IP addresses. This is a crucial distinction from routers, which operate at Layer 3 (Network Layer) and forward packets based on IP addresses.
MAC Address Learning: A key feature of bridges is their ability to learn the MAC addresses of devices connected to their ports. They build a forwarding table (often called a MAC address table or CAM table) that maps MAC addresses to the bridge port they are connected to. This allows them to efficiently forward traffic only to the intended destination port, reducing unnecessary network traffic.
Forwarding and Flooding: When a frame arrives at a bridge port, the bridge checks its forwarding table.
- If the destination MAC address is found in the table, the frame is forwarded only to the corresponding port.
- If the destination MAC address is not found, or if it's a broadcast/multicast address, the frame is "flooded" out to all other ports (except the one it came in on).
Spanning Tree Protocol (STP): To prevent network loops (which can cripple a network), bridges typically implement STP. STP dynamically disables redundant paths in a network, ensuring there's only one active path between any two devices. While this is a fundamental part of bridge operation, it's often handled automatically by the bridge-utils tools.
VLAN Tagging: Bridges can be configured to handle VLAN tags, allowing you to segment your network logically even with a single physical infrastructure.

Setting Up a Network Bridge: Hands-On!

Now for the fun part: getting your hands dirty! We'll cover a common scenario: bridging your physical Ethernet interface to a virtual bridge for VMs.

Scenario: Bridging `eth0` to `br0`

Let's assume your physical network interface is named eth0. We'll create a bridge named br0 and add eth0 to it.

1. Install bridge-utils (if you haven't already).

2. Create the Bridge Interface:

We'll use the brctl command-line utility.

Create the bridge:
```
sudo brctl addbr br0
```
This creates a new virtual bridge interface named br0.
Add your physical interface to the bridge:
```
sudo brctl addif br0 eth0
```
This attaches your physical eth0 interface to the br0 bridge.

Bring up the bridge and the physical interface:

sudo ip link set br0 up
sudo ip link set eth0 up

3. Configure IP Addressing:

You have two main options for IP addressing your bridge:

Option A: DHCP (Recommended for most home/office networks):
If your physical interface eth0 was configured to get an IP address via DHCP, you can now configure br0 to do the same. You might need to restart your DHCP client or reconfigure your network manager.

For systems using systemd-networkd or manual configuration, you might remove the IP configuration from eth0 and assign it to br0.

First, ensure eth0 has no IP address configured on it directly:
```
sudo ip addr flush dev eth0
```
Then, tell br0 to get an IP via DHCP:
```
sudo dhclient br0 # or use your system's specific DHCP client command
```
Option B: Static IP Address:
If you prefer a static IP address for your bridge, you'll assign it directly to br0.

First, ensure eth0 has no IP address configured on it directly:
```
sudo ip addr flush dev eth0
```
Then, assign a static IP to br0 (replace with your desired IP and subnet mask):
```
sudo ip addr add 192.168.1.100/24 dev br0
sudo ip route add default via 192.168.1.1 dev br0 # Set your gateway
```

4. Bringing it all together (Making it Persistent):

The commands above are temporary and will be lost on reboot. For persistence, you'll need to configure your network manager. The exact method varies depending on your Linux distribution and its network management tools (e.g., netplan, NetworkManager, systemd-networkd, or traditional /etc/network/interfaces).

Example using netplan (Ubuntu 18.04+):

Edit your .yaml file in /etc/netplan/. For example, /etc/netplan/01-netcfg.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
      dhcp6: no
  bridges:
    br0:
      interfaces: [eth0]
      dhcp4: yes # or your static configuration
      # For static IP:
      # addresses: [192.168.1.100/24]
      # gateway4: 192.168.1.1
      parameters:
        stp: true
        forward-delay: 4

Then apply the changes:

sudo netplan apply

Example using /etc/network/interfaces (Debian/Ubuntu older versions):

Edit /etc/network/interfaces:

auto br0
iface br0 inet dhcp  # or static
    bridge_ports eth0
    bridge_stp on
    bridge_fd 0

auto eth0
iface eth0 inet manual

Verification:

You can check the status of your bridge:

List bridges and their ports:
```
sudo brctl show
```
You should see br0 with eth0 listed under its interfaces.
Check IP addresses:
```
ip addr show br0
```
You should see the IP address assigned to br0.
Ping your gateway and other devices on your network:
```
ping 192.168.1.1 # Replace with your gateway IP
```

Bridging for VMs (KVM/QEMU Example)

Once you have your bridge set up, integrating it with your VM management is straightforward. When creating a new VM or configuring an existing one, you'll select the network device type to be a "bridged" adapter and specify your br0 interface.

For example, using virt-manager (the graphical tool for KVM/QEMU), you'd choose "Bridged device" and enter br0 in the "Device name" field. This will make your VM appear on your physical network just like any other device.

Bridging with Containers (Docker Example)

Docker often creates its own bridge network by default (e.g., docker0). However, you can also configure Docker to use your custom bridge. This involves setting up your bridge as described above and then telling Docker to use it, or more commonly, attaching containers to user-defined bridges.

You can create a custom bridge network in Docker:

docker network create -d bridge my_custom_bridge

Then, run your containers on this network:

docker run -d --network my_custom_bridge my_image

Advanced Topics and Tips

Multiple Interfaces on a Bridge: You can add multiple physical or virtual interfaces to a single bridge. This is useful for aggregating connections or connecting different subnets if your bridge is acting as a Layer 2 device between them.
VLANs on Bridges: For more complex setups, you can configure VLAN filtering on your bridges. This allows you to segregate traffic within the bridge based on VLAN tags.
Firewalling on Bridges: You can use iptables or nftables to firewall traffic passing through your bridge. This is often done by using the physin, physout, brdgin, and brdge chains.
MAC Address Filtering: You can configure MAC address filtering on bridge ports to control which devices can connect.
Network Bonding (LAG): While not strictly a bridge, network bonding can be combined with bridges. You can create a bonded interface (e.g., bond0) and then add that bonded interface to your bridge. This provides increased bandwidth and redundancy.

Conclusion: Embracing the Power of the Bridge

Network bridging in Linux is a powerful and versatile tool that unlocks a world of possibilities, especially when it comes to virtualisation, containerisation, and advanced network configurations. While it might seem a bit intimidating at first, understanding the core concept of a virtual switch and how it forwards traffic based on MAC addresses demystifies the process.

By following the steps outlined above, you can confidently set up your own network bridges, making your VMs and containers feel like first-class citizens on your network. Experiment, explore, and don't be afraid to tweak the settings. The Linux networking stack is remarkably flexible, and bridges are a key component in harnessing that power.

So go forth, bridge the gaps in your network, and enjoy the seamless connectivity! Happy bridging!

Designing AI Voice Agent Workflows for Electricians: Urgent Calls, Quotes, and Handoffs

VoiceFleet — Thu, 16 Jul 2026 09:04:45 +0000

A lot of AI phone demos look impressive until you put them in front of a real trade business.

Electricians are a good stress test. The caller might need an urgent callback, a quote, a booking, or a simple status update. The AI must be useful without pretending to diagnose electrical problems or giving unsafe repair advice.

Here's the workflow pattern we use when designing an AI voice agent for an electrician use case.

1. Separate conversation from decisioning

The voice layer should not decide everything inline.

A cleaner architecture is:

Inbound call
  → speech-to-text
  → conversation state
  → intent + urgency classifier
  → workflow policy
  → summary / SMS / CRM / human handoff

The conversation model gathers context. A separate policy layer decides what happens next.

That separation matters because trade calls need predictable rules. You do not want a free-form model deciding whether a sparking switchboard is "probably fine". You want a deterministic handoff rule.

2. Model the call as a structured job request

For electricians, the useful output is not a transcript. It is a job object.

Example:

{
  "caller_name": "string",
  "phone": "string",
  "suburb_or_area": "string",
  "issue_type": "power_outage | switchboard | lighting | appliance | quote | other",
  "urgency": "emergency | today | scheduled | unknown",
  "access_notes": "string",
  "preferred_time": "string",
  "handoff_required": true,
  "handoff_reason": "safety_risk"
}

That object can go to a CRM, field-service tool, SMS, email, or a simple callback queue. The point is to make the next human action obvious.

3. Treat safety as routing, not advice

The agent should avoid repair instructions. It can ask clarifying questions like:

Is there smoke, burning smell, sparking, or exposed wiring?
Is power out in one room or the whole property?
Is anyone in immediate danger?
What suburb is the job in?

But once the call crosses a safety threshold, the flow should stop trying to resolve and start routing.

if smoke_or_sparking or immediate_danger:
  tell caller to contact local emergency services if needed
  capture callback details
  notify electrician immediately
else if no_power or urgent_business_disruption:
  same-day callback queue
else:
  quote / booking workflow

This is where AI receptionist design gets less glamorous but more valuable: fewer clever answers, better escalation.

4. Optimise for mobile handoff

Many trade businesses are owner-operated. The electrician is often on-site, not sitting in a dashboard.

So the handoff format matters:

URGENT ELECTRICAL CALL
Caller: Jane, 04xx xxx xxx
Area: Gold Coast
Issue: sparking outlet in kitchen
Access: home, caller is present
AI action: advised caller to avoid touching the outlet and wait for callback
Next step: call back now

A short SMS or WhatsApp-style summary can be more useful than a full CRM record.

5. Measure the boring things

For this kind of workflow, I would track:

percentage of calls with a complete job object
time from call end to human notification
handoff reason distribution
transcript confidence on address and phone number
caller drop-off before contact details are captured

Those metrics tell you whether the system is operationally useful, not just whether the demo sounded natural.

Final thought

The hard part of AI voice agents is not making them talk. It is making them behave like a reliable front desk for a specific business.

For electricians, that means structured intake, safety-aware routing, and fast human handoff. The model should sound natural, but the workflow should be boringly deterministic.

Choosing an LCD Panel for Embedded Systems: IPS vs TN Technology Explained

Alan — Thu, 16 Jul 2026 09:04:38 +0000

When designing an embedded device, selecting the right LCD panel is often more complicated than simply choosing a display size or resolution. The panel technology itself can directly affect user experience, power consumption, system reliability, and even the overall product design.

For engineers working on industrial equipment, IoT devices, automation systems, or embedded interfaces, two LCD technologies frequently appear during the selection process: IPS (In-Plane Switching) and TN (Twisted Nematic).

Both technologies have been widely used for years, but they are designed with different priorities in mind. TN panels focus on speed and cost efficiency, while IPS panels focus more on viewing quality and image consistency.

The right choice depends on the requirements of the final application rather than simply choosing the technology with better specifications.

Understanding TN LCD Panels

TN (Twisted Nematic) is one of the earliest LCD technologies and has been widely adopted because of its relatively simple structure and manufacturing advantages.

For many years, TN panels have been used in applications where fast response time and cost control are important.

Some common advantages of TN LCD panels include:

Fast response speed
Lower manufacturing cost
Lower power consumption
Wide market availability

These characteristics make TN panels suitable for applications where image quality requirements are moderate but efficiency and affordability are important.

For example, devices that mainly display:

numbers
status indicators
simple interfaces
basic control information

may not require the advanced viewing performance of an IPS panel.

However, TN technology also has some limitations.

The most noticeable limitation is viewing angle performance.

When users view a TN display from different directions, color changes and contrast reduction may become more visible. For applications where only one user views the screen from a fixed position, this may not create a significant problem.

But for industrial equipment, public terminals, or devices viewed from different angles, viewing consistency becomes much more important.

Understanding IPS LCD Panels

IPS (In-Plane Switching) technology was developed to overcome some of the limitations of traditional LCD designs.

The main advantage of IPS panels is improved image stability when viewed from different angles.

Compared with TN panels, IPS displays typically provide:

Wider viewing angles
Better color consistency
More stable image performance
Improved visual quality

These characteristics make IPS panels popular in applications where users need to clearly view information from different positions.

Examples include:

industrial control interfaces
embedded HMI systems
monitoring equipment
interactive terminals
professional displays

For industrial environments, a display is often not viewed from a single fixed angle. Operators may stand beside equipment, check information while moving around, or share the screen with other users.

In these situations, the wider viewing angle of IPS technology can provide a better user experience.

However, IPS panels are not always the perfect choice.

Depending on specifications, IPS displays may involve:

higher cost
increased power requirements
different response characteristics

Therefore, engineers still need to evaluate the complete system requirements before making a decision.

IPS vs TN: Key Differences for Embedded Applications

When comparing IPS and TN panels for embedded systems, several factors should be considered.

Viewing Angle

Viewing angle is one of the biggest differences between these two technologies.

TN panels generally perform well when viewed directly from the front, but image quality can change when viewed from other directions.

IPS panels maintain more consistent brightness and color performance across wider viewing angles.

For applications such as industrial panels, control interfaces, and public-facing devices, IPS is often preferred because multiple viewing positions are common.

Response Time

TN panels have traditionally had an advantage in response speed.

This made them popular in applications where fast image changes were important.

Examples include:

gaming displays
high-speed visual feedback systems
applications requiring rapid updates

Modern IPS technology has improved significantly, and for many embedded applications, the response time difference is no longer the most important selection factor.

Power Consumption

Power consumption is another important consideration, especially for battery-powered embedded systems.

TN panels may have advantages in some low-power applications because of their simpler structure.

However, the total power consumption of a display system also depends on:

backlight design
brightness requirements
controller electronics
operating conditions

The panel type alone does not determine the final power usage.

Cost Considerations

Cost is often a major factor during product development.

TN panels usually have advantages in cost-sensitive projects because they are mature and widely manufactured.

IPS panels may have a higher initial cost but can provide better usability and longer-term value when display quality is important.

The decision should consider the entire product lifecycle rather than only the initial component price.

Other Factors Beyond Panel Technology

Choosing between IPS and TN is only one part of selecting an LCD for an embedded product.

Engineers should also consider other technical factors.

Interface Compatibility

The LCD interface must match the system architecture.

Common embedded display interfaces include:

LVDS
MIPI DSI
RGB
eDP
SPI

A panel with excellent image quality will not work properly if the interface is incompatible with the processor or display controller.

Before selecting a display, developers should verify:

interface type
connector specification
signal requirements
driver compatibility
Operating Environment

Industrial and embedded applications often operate under conditions that are very different from consumer electronics.

Potential challenges include:

temperature changes
dust exposure
vibration
continuous operation
outdoor lighting conditions

A display selected for industrial use should match the actual working environment.

For example, a panel used inside a factory machine may require different characteristics compared with one installed in an outdoor terminal.

Mechanical Integration

Embedded displays are often installed inside customized equipment rather than standard monitor housings.

Mechanical considerations may include:

display thickness
mounting structure
cable location
available installation space
touch panel integration

The physical design of the display module can have a significant impact on the overall product development process.

Choosing the Right LCD Panel for Your Project

There is no single LCD technology that is suitable for every application.

A TN panel may be a good option when the project requires:

lower cost
simple information display
fast response
fixed viewing position

An IPS panel may be more suitable when the project requires:

better viewing angles
stable image quality
improved user interaction
professional visual performance

For engineers designing embedded systems, the best approach is to define the application requirements first and then select the display technology that matches those requirements.

A detailed comparison of IPS and TN technologies for industrial applications can provide additional guidance when evaluating different LCD solutions:

IPS vs TN: Which LCD Panel Is Better for Industrial Applications

Final Thoughts

LCD panel selection is an important design decision in embedded product development.

While TN and IPS technologies each have their own advantages, the better choice depends on the specific needs of the application.

Factors such as viewing conditions, power requirements, interface compatibility, environmental conditions, and mechanical integration should all be evaluated together.

By considering the complete system instead of focusing on one specification, engineers can select a display solution that provides reliable performance throughout the product lifecycle.

The Liquid you lint isn't the Liquid Shopify runs

Robin Dhiman — Thu, 16 Jul 2026 09:03:12 +0000

shopify theme check passed clean. The validator I run before every commit passed too. Then I opened the page on the dev store, and a size chart that builds its rows from a metafield rendered as one long, mangled line.

The Liquid was correct. The tool that checked it wasn't running the same Liquid that Shopify runs.

Two engines, one language

Shopify's storefront renders Liquid with a Ruby engine, Shopify's own implementation, the one that has run the platform for years. Almost nothing you run locally uses it. shopify theme check, the Shopify MCP validator, and nearly every Node-based Liquid simulator run LiquidJS, a separate JavaScript reimplementation of the language.

So you have two implementations of one templating language. They agree on the overwhelming majority of what you write. They do not agree on all of it.

Where they split

The gap I keep hitting is whitespace control. The trimming markers {%- and -%} strip surrounding whitespace, and the two engines don't always strip it identically. A few other rendering semantics differ too.

For what a linter is actually for, LiquidJS is faithful: syntax, undefined objects, unknown filters and tags, schema shape. A green run tells you the template parses and references things that exist. It does not promise byte-for-byte identical output.

Why a few bytes of whitespace become a real bug

Most of the time you never notice, because HTML collapses runs of whitespace and the page looks fine either way. The exception is any code that treats rendered whitespace as data.

{%- assign rows = product.metafields.custom.size_chart.value | split: row_delimiter -%}
{%- for row in rows -%}
  <tr><td>{{ row }}</td></tr>
{%- endfor -%}

Split a rendered string on a delimiter and the exact whitespace decides where each field begins and ends. The same holds for a <pre> block, an inline SVG path you assemble in Liquid, or a JSON blob you build and hand to JavaScript. In all of those, an extra or missing newline isn't cosmetic. It changes the parse. That's how a table that's correct in my local preview shreds on the live storefront, or the reverse.

Use the linter for what it catches

I still run theme check on every change, and you should. It catches the things it's built to catch: malformed syntax, undefined objects, unknown filters, schema errors. And, increasingly useful, it flags filters an AI assistant hallucinated into a template that don't exist. That's real value, and it's fast.

What it can't vouch for is whitespace-exact output. So the rule I follow is simple. Lint locally. When whitespace is load-bearing, render it on live Shopify, a dev store or a theme preview, before you trust it. Not the Node simulator. The engine that actually serves customers.

The pattern underneath

This isn't really about Liquid. LiquidJS standing in for Ruby Liquid is one instance of a trap every engineer meets: the local stand-in that isn't the runtime. A mock that isn't the live API. SQLite in dev and Postgres in production. A cloud emulator on your laptop. Each one is close enough to be useful and different enough to lie to you at exactly the wrong moment.

The move isn't to distrust the tool. It's to know precisely which class of bug it can catch and which it can't, then send the rest to the real thing. For Liquid: lint in Node, render on Shopify.