Devs Brasileiros

¿Cuánta energía, agua, dinero e infraestructura estamos dispuestos a gastar para sostenerla?

Miguel Angel Mendoza Cardenas — Sun, 03 May 2026 22:40:08 +0000

La conversación sobre IA no debería quedarse solo en lo que la tecnología puede hacer.
También deberíamos preguntarnos:

¿Cuánta energía, agua, dinero e infraestructura estamos dispuestos a gastar para sostenerla?

Hoy vemos una carrera acelerada por construir modelos más grandes, más centros de datos, más GPUs y más automatización. Las grandes empresas están invirtiendo miles de millones como si el retorno económico estuviera garantizado, pero todavía no existe suficiente claridad sobre el costo real por usuario, el margen neto de muchos productos de IA y el impacto energético a largo plazo.

Y aquí aparece un punto crítico:

Aunque los modelos se optimicen, el consumo total puede seguir creciendo.
Si una tecnología se vuelve más eficiente y barata de usar, normalmente se usa más. Esto se conoce como efecto rebote. En IA puede pasar lo mismo: modelos más rápidos y económicos podrían llevar a integrar IA en todo: programación, marketing, soporte, publicidad, CRM, ERP, educación, salud, finanzas, agricultura, logística y agentes autónomos trabajando en segundo plano.

El problema no es que la IA exista.

El problema es una IA sin límites, sin medición clara y sin responsabilidad ambiental, económica y social.

La IA puede ser una gran herramienta para mejorar productividad, ciencia, educación, salud y acceso al conocimiento. Pero si se usa principalmente para reemplazar personas, producir contenido basura, automatizar publicidad infinita y aumentar consumo sin medir impacto, deja de ser progreso y empieza a parecer extracción de recursos.
No estamos listos para darle control completo de nuestros recursos a sistemas de IA.

No estamos listos para una IA que crezca más rápido que la infraestructura eléctrica, las regulaciones y la capacidad ambiental del planeta.
Por eso creo que necesitamos una conversación más seria sobre:

Medición obligatoria de energía, agua y emisiones por data center.
Modelos grandes solo cuando realmente sean necesarios.
Modelos pequeños y especializados para tareas concretas.
Reportes claros de costos e ingresos reales de productos de IA.
Límites regionales donde la red eléctrica o el agua no alcancen.
Auditorías externas de impacto ambiental y económico.
Regulación antes de aprobar nuevas cargas gigantes de infraestructura. La pregunta no debería ser solo:

“¿Qué puede hacer la IA?”

La pregunta más importante debería ser:

“¿Qué costo estamos dispuestos a pagar como sociedad para usarla sin límites?”

La IA puede ser parte del futuro, sí.

Pero no debería convertirse en una excusa para consumir energía, agua, talento, dinero e infraestructura sin control.

IA sí, pero con límites.
IA útil, no IA desbordada.
IA supervisada, no IA dueña de nuestros recursos.

Mythos Found a 27-Year-Old Bug in OpenBSD. Your Code Is Next.

Michelle Jones — Sun, 03 May 2026 22:37:32 +0000

Anthropic's new Mythos Preview surfaced a 27-year-old vulnerability in OpenBSD — the most-audited operating system in commercial software — and generated 181 working Firefox exploits in a benchmark where Claude Opus 4.6 managed two. Eleven organizations are inside the launch cohort. The rest of us aren't, and the next Mythos won't be gated.

What Mythos is, in hard numbers

On April 7, Anthropic announced Claude Mythos Preview, a frontier general-purpose model with a step-change in computer security capability. The numbers are the story:

A 27-year-old vulnerability in OpenBSD, surfaced by Mythos in the TCP SACK implementation. OpenBSD's audit posture is the high bar in the industry.
A 16-year-old vulnerability in FFmpeg's H.264 codec — the media component shipped in nearly every modern browser and video pipeline.
A 17-year-old remote code execution vulnerability in FreeBSD's NFS implementation (CVE-2026-4747).
Linux kernel vulnerabilities autonomously chained by the model into a complete privilege escalation to root.
181 working Firefox exploits in a benchmark where Claude Opus 4.6 produced two — an order-of-magnitude leap in a single model generation.
271 vulnerabilities patched in Firefox 150 after Mozilla used an early version of Mythos Preview to scan its codebase. Mozilla described the model as "every bit as capable" as the best human security researchers.
Thousands of zero-days identified in operating systems, browsers, and infrastructure software in the weeks before announcement.

Anthropic was clear about something else worth dwelling on: the company did not explicitly train Mythos for these capabilities. They emerged as a downstream consequence of general improvements in code, reasoning, and autonomy. The same improvements that make the model a better defender make it a better attacker. That equivalence is the whole story.

Mythos isn't a security tool. It's a frontier model that happens to be very good at a security task that turns out to require general intelligence. The distinction matters: capability of this kind doesn't stay siloed.

The asymmetry just collapsed

For thirty years, the offensive-defensive asymmetry in software security was: attackers needed to find one bug, defenders needed to find all of them. The economics favored attackers — but only because finding bugs was hard, slow, and required deep human expertise.

Mythos didn't flip the asymmetry. It collapsed the cost difference between the two activities. The same model that can find thousands of zero-days for a defender can find thousands of zero-days for an attacker. There is no "attacker mode" and "defender mode." There is one capability with two uses, and the user picks.

For the launch cohort inside Project Glasswing — including Microsoft, Google, Apple, AWS, JPMorganChase, Nvidia, the Linux Foundation, and major security vendors — this is a defensive windfall. They get to find and patch their own bugs before anyone else can. For everyone else, the math is uglier. When this class of capability becomes broadly available (and it will), the same scan that takes Apple a quiet weekend will take a determined adversary the same quiet weekend.

What this changes about threat modeling

Pre-Mythos, the assumption underlying most enterprise risk frameworks was that vulnerabilities cost time to discover. Post-Mythos, that assumption no longer holds for sophisticated actors. The vulnerabilities are already there, in code that's already deployed. The only question is who finds them first.

Project Glasswing's narrow gate

Anthropic's response to the dual-use problem is Project Glasswing: instead of releasing Mythos publicly, the model is gated to vetted partners doing defensive security work on critical infrastructure. The launch cohort is eleven outside organizations — AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks — with another forty-plus organizations given extended access. Anthropic has committed $100M in Mythos usage credits and additional funding to upstream open-source security ($2.5M to Alpha-Omega and OpenSSF, $1.5M to the Apache Software Foundation). On April 21, Bloomberg and TechCrunch reported that a small group of unauthorized users — reportedly a third-party Anthropic contractor who guessed the model's online location — had accessed Mythos on the same day Anthropic announced the limited release.

The Glasswing structure is a reasonable response to a hard problem. The cohort is a serious set of defenders, the Linux Foundation's inclusion broadens the open-source impact, and the upstream funding commitments are not trivial. But the structure has implications worth thinking through:

The launch cohort is well-resourced and concentrated. Megacaps, major security vendors, and one open-source foundation. Most enterprises, healthcare systems, utilities, and government agencies are not in the launch cohort.
The cohort is the world's biggest target. Concentrating frontier offensive capability inside a known list of well-resourced firms makes those firms exponentially more valuable to compromise. The April 21 unauthorized-access incident is the canary, not the bird.
The gate is temporary. The capability emerged from general intelligence improvements. Other labs are on the same trajectory. Within twelve to twenty-four months, equivalent capability will be available somewhere — through a competitor, an open-weights model, or a leak. Anthropic's caution buys the industry time. It does not buy the industry safety.
The defenders inside the gate have a head start. The defenders outside the gate don't. By the time Mythos-class capability is broadly available, the cohort will have spent a year hardening their stacks. Everyone else will be starting cold.

None of this is criticism of Glasswing. It's a description of where the rest of the industry sits: outside the gate, on the clock, with a year-or-so head start to spend on infrastructure that doesn't assume bug discovery is expensive.

Why your legacy stack is the easy target

If Mythos found a bug in OpenBSD that survived twenty-seven years of obsessive auditing, what does it find in code that's been quietly running in production since 1998 with no audit at all?

Legacy systems are uniquely exposed to this class of capability for reasons that have nothing to do with their original quality:

The code was written in a different threat model. COBOL batch jobs, C-based middleware, and FORTRAN scientific computing were written assuming network isolation, trusted operators, and small adversary budgets. None of those assumptions hold today.
The maintainers are gone. The engineers who wrote the original code retired a decade ago. The people who maintain it now read it; they don't reason about it. A capable adversary scanning the same code reasons about it just fine.
The scale is enormous. A typical Fortune 100 enterprise runs millions of lines of legacy code. Manual audit is impossible at this volume; automated tools were built for the threat model where bug discovery was expensive. Mythos-class capability inverts that economics.
The code is statistically interesting. Old code has been running long enough that bugs which never triggered in production are still latent. The defects are there. They just haven't been found yet.
The patch path is brittle. Even when a bug is found in a legacy system, the cost of patching is often catastrophic — recompiling a forty-year-old build chain, validating against a forty-year-old behavior contract, regression-testing dependencies that may no longer have maintainers. "We can't patch this" is a common honest answer for legacy systems, and adversaries know it.

The 27-year-old OpenBSD bug is the canary. OpenBSD is among the most-audited code in the world. Your COBOL payroll system, your FORTRAN actuarial engine, your C-based supply chain ETL — they have not had that audit. They have the same age. They do not have the same hardening.

The honest framing is this: Mythos-class capability does not introduce new vulnerabilities. It surfaces vulnerabilities that have been latent in your systems for years or decades. The defects are already there. The economics of finding them just changed.

The defender's playbook for the next 90 days

If we accept that Mythos-class capability will be broadly available within twenty-four months and that legacy systems are the most exposed surface, the defensive question is what to do this quarter that materially reduces risk. Five things worth prioritizing.

1. Get an honest inventory of your legacy attack surface

Most enterprises do not have an accurate inventory of what legacy code they actually run, what it touches, and what depends on it. The first step is unglamorous: catalog the legacy systems, their network exposure, the data they process, and the dependencies that would break if they went down. You cannot defend what you cannot see.

2. Build the SBOM you should already have

A Software Bill of Materials isn't a compliance artifact; it's the data structure you need to answer the question "is the new zero-day in our stack?" in minutes instead of weeks. Federal contractors will need one for compliance under recent OMB guidance. Build it now, before the next Mythos disclosure forces the question.

3. Modernize the highest-exposure legacy primitives first

Total legacy modernization is a multi-year program. Prioritized modernization isn't. Identify the legacy components with (a) network exposure, (b) sensitive data flow, and (c) no maintainer — and modernize those first. Pull the C-based parser out of the perimeter. Replace the COBOL service that processes external data with a memory-safe equivalent. Leave the back-office batch job for next year.

4. Assume the patch tsunami is coming

If Mythos-class scanning produces ten thousand findings against your stack, your security team cannot triage ten thousand findings by hand. Invest in automated patch prioritization, exploit-prediction scoring (EPSS), and patch-deployment automation now — before you need it under pressure. The bottleneck of the next two years is not finding bugs. It's deciding which ones to patch first and shipping the patches without breaking production.

5. Threat-model with AI-assisted attackers in scope

Update your threat models to assume adversaries have Mythos-class capability. The questions change. "What's our mean-time-to-detect?" matters more than "Is this code vulnerable?" (it almost certainly is). "What's the blast radius if a single legacy primitive is fully compromised?" matters more than "Is this primitive likely to be compromised?" (it is more likely than it was). Defense in depth, network segmentation, and rapid containment become first-class controls, not best-practice nice-to-haves.

The shift in posture

Pre-Mythos: defenders optimize for bug-finding cost. Post-Mythos: defenders optimize for time-to-patch and blast-radius containment, because bugs will be found whether you find them first or someone else does.

A note for federal contractors

Federal contractors and agencies have an extra layer of implications: the procurement and compliance machinery that governs federal software is going to reckon with this — slowly, but inexorably. Expect SBOM and provenance requirements (already mandated under EO 14028) to get enforced in earnest. Expect NIST SSDF / SP 800-218 to shift from documentation to continuous attestation. Expect legacy waivers to become harder to defend, with risk-acceptance memos required to explicitly acknowledge Mythos-class threat. Expect patch SLAs to compress — sub-week response on high-severity findings against widely-deployed primitives is the realistic floor, not the ceiling. Vendor due-diligence will move from annual questionnaires to continuous attestation.

The realistic posture for the next twenty-four months is not "modernize everything." It is "modernize the exposed surface, instrument the rest, and assume the rest will eventually be reached." The agencies and primes that prepare for that reality now will not be the ones writing breach-notification letters in 2027.

The honest read

Mythos is not a doomsday model. It is a step on a curve that the entire industry has been on for several years, and Anthropic's decision to gate it through Glasswing is, in our view, the responsible move. We don't think the right reaction is panic, and we don't think the right reaction is dismissal.

The right reaction is to use the Glasswing window — the twelve to twenty-four months where this capability is concentrated in twelve hands and a national-security agency — to do the unglamorous defensive work that everyone has been deferring. Inventory the legacy. Build the SBOM. Modernize the exposed primitives. Automate the patch path. Threat-model with AI-assisted attackers in scope.

We don't know exactly when the next Mythos lands or who ships it. We do know it will not be gated like this one. The defenders who used the window will be fine. The defenders who didn't will be writing the postmortem.

Codavyn helps enterprise and federal teams modernize the exposed surface of legacy stacks before AI-assisted scanning catches up. Custom software, modernization, and a threat model that assumes the attacker is reading your code as fast as you are. See our modernization services or book a 30-minute risk review.

Logic Apps Agent Loop + MCP: Two Bugs Worth Knowing About

Daniel Jonathan — Sun, 03 May 2026 22:35:02 +0000

I spent the long weekend pushing Logic Apps MCP server capabilities further than I had before — and hit two bugs worth documenting. Both are filed. If you're building in this space, save yourself the debugging time.

Context

If you've been following along, the MCP server and BODMAS Agent are covered in the previous posts. This post is just about what broke when I wired them together.

Bug 1 — Intermittent duplicate key error at tool registration

What happens

The Agent Loop fails with a BadRequest before making a single MCP call:

HTTP request failed: 'An item with the same key has already been added. Key: {tool_name}'.

The key referenced in the error — BasicArithmeticMCP, ExtendedArithmeticMCP, whatever you name it — appears exactly once in the workflow definition. There is no actual duplicate in the JSON.

What makes it particularly frustrating to diagnose

It is intermittent. Some runs fail, others succeed with identical configuration and identical input. No changes between a failing and a succeeding run — same workflow, same expression, same everything.

Load test

I fired 5 to 10 parallel requests at the Agent Loop as a mini stress test. It failed — the duplicate key error appeared across multiple runs in the batch.

Sequential calls with proper spacing between them worked fine.

What you can't do

The Agent action has a default retry policy, but it does not help here. A BadRequest (400) is not treated as a transient error — the retry policy targets server-side failures (5xx), not client errors. So even with retries configured, the duplicate key error causes an immediate terminal failure. There is no clean in-workflow workaround.

Bug 2 — MCP Connector does not support OAuth

What happens

Both the MCP server and the MCP client are Logic Apps Standard. When OAuth is configured on the MCP server side, the workflow doesn't trigger at all — it never reaches the Logic App. The connection gets corrupted at design time with the OAuth setup, and no run is created.

Tools don't load but you can save the workflow.

You get a 502 bad gateway error when you push a request.

The same endpoint called directly from Postman with a valid bearer token works fine.

Why it matters

To get the Agent Loop working, the MCP server has to run with either anonymous authentication or key-based authentication. OAuth simply does not work with the built-in MCP client connector.

Current state

Both issues are filed on the Logic Apps GitHub repo:

Agent Loop: "An item with the same key has already been added" when using McpClientTool

The issue covers both bugs with full workflow JSON, reproduction steps, and screenshots. If you've hit either of these, add a reaction or comment — the more signal on the issue, the better.

What works in the meantime

Set "type": "anonymous" in the McpServerEndpoints authentication block in host.json — removes the OAuth blocker for dev and demo use
Accept the intermittent failure rate on the Agent Loop and re-trigger manually when it hits — not a fix, but the success rate is high enough to keep building and testing

Both issues are filed. If you hit either of them, the GitHub issue is the right place to add signal.

Feature Flags That Actually Ship: Lessons From the Trenches

Pravin Khandke — Sun, 03 May 2026 22:22:26 +0000

It was 2:47 AM when the alerts started. A seemingly straightforward database migration had triggered a cascading failure across three downstream services, and our payment processing pipeline was dropping roughly 12% of transactions. The on-call engineer didn't need to wake anyone, locate a rollback script, or wait for a CI pipeline to churn through another deploy. She opened the LaunchDarkly dashboard, toggled one kill switch, and the system reverted to the stable path within seconds. The migration was still there, still deployed — just no longer live.

That moment crystallized something I'd been learning across two and a half decades of building software: separating deployment from release isn't a nice-to-have. It's the difference between a system you trust and one you fear touching on a Friday afternoon.

This article captures what I've learned using feature flags in production — the patterns that held up under pressure, the mistakes I've watched teams repeat (and made myself), and the practical steps you can take whether you're evaluating LaunchDarkly or already deep into your feature flag journey. I'm publishing this here first because the developer community gives the most honest feedback, and I'd rather refine these ideas with you before they land on LeadDev and DZone.

The Patterns That Actually Matter

When you first start with feature flags, everything looks like a toggle. The key consideration here is understanding that not all flags serve the same purpose, and conflating them creates the very fragility you're trying to avoid.

Release Flags

These gate unfinished features. They're temporary by design — the flag exists while the feature stabilizes, then gets removed. The mistake I see most often is teams treating release flags as permanent configuration knobs. When a flag has been at 100% for three months, nobody remembers which code path is the "real" one, and your test matrix silently doubles.

In practice, this means setting a removal date the moment you create the flag. Our team attaches an expiration tag to every release flag and runs a weekly script that surfaces anything past its removal window. We borrowed from the FlagShark playbook here: flags older than 90 days that aren't operational kill switches get an automatic ticket filed.

Centralize your flag keys in a single file, it gives you a one-glance inventory and prevents the typo-driven debugging sessions that scattered string literals create:

// code/src/flags.js — single source of truth for all flag keys
// See companion project: code/src/flags.js

const FLAGS = {
  // Kill switch: wraps the payment provider integration.
  // Defaults to FALSE (safe path) if SDK is unreachable.
  PAYMENT_PROVIDER_KILL_SWITCH: "ops_payments_new_provider",

  // Release flag: gates the new checkout UI.
  // Temporary — remove after 100% rollout + 14 days stable.
  NEW_CHECKOUT_UI: "release_checkout_redesigned_ui",

  // Experiment flag: percentage rollout of recommendation engine.
  RECOMMENDATION_ENGINE: "experiment_recommendations_v2",

  // Permission flag: enterprise-only feature.
  ENTERPRISE_ANALYTICS: "permission_enterprise_analytics",
};

The naming convention follows a pattern: {type}_{team/domain}_{feature}_{detail}. This tells you at a glance what a flag does, who owns it, and when it should be removed. Release flags should be short-lived. Ops flags (kill switches) should be reviewed annually. Experiment flags expire when the experiment ends.

Here's the LaunchDarkly client initialization — a singleton that streams flag rules and caches them locally so evaluations work even during network interruptions:

// code/src/launchdarkly.js — LD client singleton
// See companion project: code/src/launchdarkly.js

const LaunchDarkly = require("@launchdarkly/node-server-sdk");

async function initLaunchDarkly(sdkKey) {
  const ldClient = LaunchDarkly.init(sdkKey);

  try {
    await ldClient.waitForInitialization({ timeout: 5 });
    console.log("[LaunchDarkly] Client initialized successfully");
  } catch (err) {
    console.warn(
      "[LaunchDarkly] Initialization timed out — operating from cache or defaults"
    );
  }

  return ldClient;
}

Kill Switches

A kill switch is a different animal entirely. It's not about shipping features — it's about operational safety. Every integration point with an external system, every experimental code path, every performance-sensitive refactor gets wrapped in one.

The pattern that saved us at 2:47 AM looked like this:

// code/src/server.js — Kill Switch pattern
// See companion project: code/src/server.js, GET /api/payment/status

app.get("/api/payment/status", async (req, res) => {
  const context = { kind: "user", key: req.query.user || req.ip };

  // Default: false = use safe fallback path.
  // If LaunchDarkly is unreachable, the SDK returns the default.
  const useNewProvider = await client.boolVariation(
    FLAGS.PAYMENT_PROVIDER_KILL_SWITCH,
    context,
    false   // <-- THE CRITICAL DEFAULT: safe path
  );

  if (useNewProvider) {
    return res.json({ provider: "new-payment-provider", status: "ok" });
  }

  // Safe fallback: the existing, battle-tested provider.
  res.json({ provider: "existing-payment-provider", status: "ok" });
});

The critical design requirement: the fallback path must be the one that works. If your kill switch guards a new payment provider integration, the fallback routes through the existing, battle-tested provider. If the flag evaluation itself fails due to a network issue, LaunchDarkly's SDK returns the default value you specify — which should always trigger the safe path.

Percentage Rollouts

Deterministic hashing based on a stable user attribute means the same user sees the same experience across sessions. This matters more than you'd think — users notice inconsistency, and your metrics become meaningless if a single user bounces between variants.

Our rollout cadence settled into a rhythm: internal team for one day, 1% of external users for a day, then 5%, 25%, and full release if all guardrails stay green. At each stage, we watch application error rates, API latency, and business metrics. LaunchDarkly's Guarded Releases can automate the pause-or-rollback decision if a threshold breaches, which removes the 3 AM judgment call from the equation.

// code/src/server.js — Percentage rollout with string variation
// See companion project: code/src/server.js, GET /api/recommendations

app.get("/api/recommendations", async (req, res) => {
  const context = { kind: "user", key: req.query.user || "anonymous" };

  // stringVariation for multi-variant experiments.
  // Deterministic hashing on user key ensures the same user
  // consistently sees the same variant.
  const variant = await client.stringVariation(
    FLAGS.RECOMMENDATION_ENGINE,
    context,
    "v1"   // default: existing recommendation engine
  );

  if (variant === "v2") {
    return res.json({
      engine: "collaborative-filtering-v2",
      recommendations: ["Item-A", "Item-B", "Item-C"],
    });
  }

  res.json({
    engine: "popularity-based-v1",
    recommendations: ["Item-X", "Item-Y", "Item-Z"],
  });
});

And here's user targeting in action — enterprise features gated by a custom attribute:

// code/src/server.js — Targeting with custom attributes
// See companion project: code/src/server.js, GET /api/analytics/dashboard

app.get("/api/analytics/dashboard", async (req, res) => {
  const context = {
    kind: "user",
    key: req.query.user || "anonymous",
    plan: req.query.plan || "free",  // custom attribute for targeting rules
  };

  const canAccess = await client.boolVariation(
    FLAGS.ENTERPRISE_ANALYTICS,
    context,
    false
  );

  if (!canAccess) {
    return res.status(403).json({
      error: "Enterprise analytics require the Enterprise plan.",
    });
  }

  res.json({
    dashboard: "advanced-analytics",
    metrics: ["revenue-per-user", "churn-prediction", "cohort-retention"],
  });
});

All the code above comes from the companion project — a fully runnable Express app in code/src/server.js. Clone it, set your SDK key, and you'll see every pattern respond to flag toggles in real time without a server restart.

The Questions Your Team Will Ask (And How to Answer Them)

When you introduce feature flags at scale, you'll hear the same objections. I've had these conversations enough times to recognize the patterns.

"Doesn't this just create more code to maintain?"

Yes, if you treat flags as permanent. The entire discipline of flag lifecycle management exists because flags without expiration dates become technical debt with a feature flag logo. The countermeasure is mechanical, not cultural: automation that flags stale toggles, creates cleanup tasks, and blocks new flags when the ratio of creation to removal tips past 2:1.

We enforce a simple rule: every flag has an owner, an expiration date, and a ticket filed at creation time for its eventual removal. When a release flag hits 100% rollout for two weeks, the cleanup PR gets auto-generated. This isn't optional — it's how you prevent the flag graveyard.

"What if the flag service goes down?"

LaunchDarkly SDKs maintain a streaming connection and cache flag rules locally. If the connection drops, evaluations continue against the cached ruleset. The boolVariation call includes a default value parameter precisely for this scenario — and every code path I write defaults to the safe, existing behavior.

In the 2:47 AM scenario, the kill switch worked because the SDK had already cached the flag state. Even if LaunchDarkly's service had been unavailable at that exact moment, the toggle would have still evaluated correctly against the local cache.

"Can't we just build this ourselves?"

Technically, yes. I've seen teams build internal feature flag systems. I've also seen those same teams spend sprint after sprint maintaining edge-case evaluation logic, building dashboards, and debugging deterministic hashing when they could have been building their actual product. The key consideration here isn't whether you can build it — it's whether maintaining a feature flag platform is where your team's time creates the most value.

Where We Go From Here

If you're starting with feature flags, begin with one operational kill switch on a high-risk integration. Get comfortable with the pattern, build the muscle memory for flag cleanup, then expand to release flags and progressive rollouts. The most successful adoptions I've seen started small and grew organically, rather than attempting a company-wide flag-everything initiative overnight.

For deeper dives, the LaunchDarkly documentation on guarded rollouts and kill switch flags is excellent. The FlagShark best practices guide informed much of our internal naming and lifecycle discipline. And if you want to understand why stale flags genuinely keep me up at night, read about the $460M Knight Capital incident — a stark reminder that unreachable code paths aren't harmless.

The original version of this article, along with a companion project demonstrating every pattern discussed here, lives on this blog. I'll be expanding it based on your questions and feedback before it goes to LeadDev and DZone — so if something here sparks a thought or a disagreement, I'd genuinely like to hear it in the comments.

Key Takeaways

Separate deployment from release. A deployed change that isn't live yet is a safety net. A deployed change that's fully live with no way to turn it off is a liability.

Treat flag cleanup as a first-class engineering practice. Naming conventions, expiration dates, and automated removal aren't overhead — they're what keep your codebase comprehensible six months from now.

Default to safety. Every flag evaluation should fall back to the known-good path. The time to verify your kill switch works isn't during an incident at 2:47 AM.

Start small, automate early, and build the habits before you build the flag count. The teams I've watched succeed with feature flags aren't the ones with the most sophisticated tooling — they're the ones with the most disciplined lifecycle management.

How to Prevent IDOR Vulnerabilities in Django REST APIs

Stefan — Sun, 03 May 2026 22:21:49 +0000

How to Prevent IDOR Vulnerabilities in Django REST APIs

An authenticated user changes /api/orders/42/ to /api/orders/43/ and reads someone else's order. No privilege escalation needed — the endpoint just returns it. This is IDOR in its simplest form, and it's endemic in Django REST Framework code because DRF makes it trivially easy to wire up a ModelViewSet that exposes every object in a table. The authentication layer does its job; the authorization layer was never written.

How IDOR Attacks Work Against Django REST APIs

IDOR (Insecure Direct Object Reference) happens when an API accepts a user-controlled identifier — a URL path segment, query param, or request body field — and retrieves the corresponding object without verifying that the requesting user has any right to it. Authentication proves who you are. Authorization proves what you can touch. Most IDOR bugs exist because the first check was implemented and the second was skipped.

A typical attack against a vulnerable DRF app:

Attacker authenticates as alice@example.com and creates an order. The response contains {"id": 101, ...}.
Attacker sends GET /api/orders/100/. The API returns Bob's order because nothing checks ownership.
Attacker scripts a loop from ID 1 to 10000, dumps every order in the database. Sequential integer PKs make enumeration take seconds.

Here is the vulnerable ViewSet pattern we see most often in real codebases:

# views.py — VULNERABLE
from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated
from .models import Order
from .serializers import OrderSerializer

class OrderViewSet(viewsets.ModelViewSet):
    serializer_class = OrderSerializer
    permission_classes = [IsAuthenticated]  # proves identity, not ownership

    def get_queryset(self):
        # Returns every order in the database — any authenticated user
        # can retrieve, update, or delete any order by guessing its PK.
        return Order.objects.all()

IsAuthenticated blocks anonymous requests, which makes it look like the endpoint is secured. But any valid session token — including one the attacker registered themselves — bypasses it. The retrieve(), update(), and destroy() actions in ModelViewSet all call get_object(), which calls get_queryset() and then filters by the URL pk. Since get_queryset() returns everything, get_object() happily resolves any ID.

Fixing IDOR by Scoping Querysets to the Authenticated User

The correct fix is to scope get_queryset() to the authenticated user so that the object simply doesn't exist from the API's perspective if it doesn't belong to the requester. This gives you a 404 instead of a 403, which is almost always the right behavior — a 403 confirms the resource exists and leaks information about the ID space.

Add a second layer with a custom BasePermission that implements has_object_permission. The queryset filter handles list and retrieve; the object permission handles mutating actions where DRF calls check_object_permissions explicitly.

# permissions.py
from rest_framework.permissions import BasePermission

class IsOwner(BasePermission):
    def has_object_permission(self, request, view, obj):
        # Explicit ownership check — queryset scoping is the first line,
        # but we defend in depth for any path that bypasses get_queryset.
        return obj.owner == request.user

# views.py — FIXED
from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated
from .models import Order
from .serializers import OrderSerializer
from .permissions import IsOwner

class OrderViewSet(viewsets.ModelViewSet):
    serializer_class = OrderSerializer
    permission_classes = [IsAuthenticated, IsOwner]

    def get_queryset(self):
        # Scope to the requesting user at the ORM layer — objects that don't
        # belong to this user never enter the retrieval pipeline at all.
        return Order.objects.filter(owner=self.request.user).select_related("owner")

    def perform_create(self, serializer):
        # Bind the new object to the authenticated user so the POST path
        # can't accept a user-controlled owner field.
        serializer.save(owner=self.request.user)

Filtering at the queryset layer beats checking IDs inside the view body for two reasons. First, it's impossible to forget: every action — list, retrieve, update, partial update, destroy — goes through get_queryset(). Second, it eliminates a whole class of time-of-check / time-of-use bugs where you check ownership in get but forget to re-check in patch.

The same defense-in-depth principle applies to object-level auth in gRPC services and any RPC-style API where the framework doesn't give you a queryset abstraction: filter first, check permissions on the resolved object second.

Use Unguessable Identifiers Instead of Sequential IDs

Sequential integer PKs are an enumeration gift. Once an attacker has one valid ID, they have a roadmap to every other record. Replacing exposed identifiers with UUIDs or opaque slugs doesn't fix the authorization hole — that requires the fixes above — but it raises the cost of bulk enumeration from "write a loop" to "brute-force a 128-bit space."

# models.py
import uuid
from django.db import models

class Order(models.Model):
    # Use UUIDField as the primary key to prevent sequential enumeration.
    # This is defense in depth — queryset scoping is still mandatory.
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    owner = models.ForeignKey(
        "auth.User", on_delete=models.CASCADE, related_name="orders"
    )
    total = models.DecimalField(max_digits=10, decimal_places=2)
    created_at = models.DateTimeField(auto_now_add=True)

# urls.py — router uses the UUID field as the lookup
from rest_framework.routers import DefaultRouter
from .views import OrderViewSet

router = DefaultRouter()
router.register(r"orders", OrderViewSet, basename="order")

# Override lookup_field on the ViewSet to match the UUID primary key
# so DRF resolves /api/orders/<uuid>/ instead of /api/orders/<int>/

# views.py addition
class OrderViewSet(viewsets.ModelViewSet):
    lookup_field = "id"  # matches the UUIDField name on the model
    # ... rest of ViewSet unchanged from the fix above

One tradeoff: UUIDs inflate index size and can slow joins on large tables. If that matters, use a separately-stored public_id = models.UUIDField(default=uuid.uuid4, editable=False, unique=True) alongside an integer PK, and expose only public_id in serializers and URLs. The internal integer PK never appears in any HTTP response.

Never treat opaque IDs as a substitute for proper authorization. We've reviewed APIs that switched to UUIDs, removed the queryset scoping because "users can't guess them now," and then leaked UUIDs in webhook payloads, browser history, or third-party analytics — instantly making every ID known to an attacker.

Enforce Authorization at the Serializer and Nested Resource Level

Queryset scoping protects URL-path-based access. IDOR also hides in writable foreign key fields where a user submits a payload referencing another tenant's object. A user who owns projects 10 and 11 might try {"project": 99} on a task creation endpoint to attach their task to someone else's project.

This is especially common in multi-tenant SaaS applications where related resources belong to different organizational boundaries.

# serializers.py
from rest_framework import serializers
from .models import Task, Project

class TaskSerializer(serializers.ModelSerializer):
    class Meta:
        model = Task
        fields = ["id", "title", "project", "due_date"]

    def validate_project(self, value):
        request = self.context.get("request")
        if request is None:
            raise serializers.ValidationError("No request context available.")

        # Reject foreign keys that don't belong to the authenticated user —
        # without this check, any user can write into any project by ID.
        if not Project.objects.filter(id=value.id, owner=request.user).exists():
            raise serializers.ValidationError(
                "Project not found."  # Deliberately vague — don't confirm existence
            )
        return value

Always pass request in serializer context. DRF does this automatically when you use get_serializer() inside a view, but if you instantiate serializers directly (in management commands, signals, or background tasks), you must pass context={"request": request} manually. When there's no request context at all — background jobs, for example — you need a different mechanism to establish the authorization boundary, typically passing the owner explicitly.

The same class of bug appears in writable nested serializers. If a LineItem serializer accepts a nested order object with an id field, a user can point that id at any order. Validate every inbound relation. For more on how this nesting problem scales, the same concepts appear in authorization patterns in GraphQL APIs, where every resolver is effectively a relation that needs its own ownership check.

Test for IDOR with Automated Authorization Checks

The only reliable way to prevent IDOR regressions is to write tests that explicitly attempt cross-user access and assert they fail. Code reviews miss it. Manual QA misses it. Tests that authenticate as user B and try to touch user A's resources catch it every time — if you write them.

# tests/test_order_idor.py
import pytest
from django.contrib.auth import get_user_model
from rest_framework.test import APIClient
from orders.models import Order

User = get_user_model()

@pytest.fixture
def alice(db):
    return User.objects.create_user(username="alice", password="testpass123")  # noqa: S106

@pytest.fixture
def bob(db):
    return User.objects.create_user(username="bob", password="testpass123")  # noqa: S106

@pytest.fixture
def alice_order(alice):
    return Order.objects.create(owner=alice, total="99.99")

@pytest.mark.django_db
class TestOrderIDOR:
    def _client_for(self, user):
        client = APIClient()
        client.force_authenticate(user=user)
        return client

    def test_bob_cannot_retrieve_alice_order(self, alice_order, bob):
        # 404, not 403 — we don't confirm the resource exists to unauthorized users.
        response = self._client_for(bob).get(f"/api/orders/{alice_order.id}/")
        assert response.status_code == 404

    def test_bob_cannot_update_alice_order(self, alice_order, bob):
        response = self._client_for(bob).patch(
            f"/api/orders/{alice_order.id}/", {"total": "0.01"}, format="json"
        )
        assert response.status_code == 404

    def test_bob_cannot_delete_alice_order(self, alice_order, bob):
        response = self._client_for(bob).delete(f"/api/orders/{alice_order.id}/")
        assert response.status_code == 404

    def test_bob_list_does_not_include_alice_order(self, alice_order, bob):
        # List endpoint must not leak cross-user data even if IDs are unknown.
        response = self._client_for(bob).get("/api/orders/")
        assert response.status_code == 200
        ids = [item["id"] for item in response.data["results"]]
        assert str(alice_order.id) not in ids

The list-endpoint test is easy to forget and catches a different bug: get_queryset() returning everything on list() but correctly filtering on retrieve(). Write both.

Wire these into CI as required checks. A failing IDOR test should block a merge the same way a failing unit test does. This is not optional — the whole point is that a developer adding a new ModelViewSet in a Friday pull request doesn't ship a data leak to production by Monday.

Catch IDOR in Code Review and CI

Human review of pull requests should pattern-match on a short list of high-risk constructs. Any Model.objects.get(pk=...) or Model.objects.filter(id=...) call that doesn't chain a user-scoping filter is a candidate IDOR. Any ViewSet missing permission_classes is an unauthenticated endpoint or is inheriting from a base class that may not have adequate defaults. Any serializer field of type PrimaryKeyRelatedField with a broad queryset is a potential cross-tenant write.

Automate this with Semgrep. Here is a rule that flags the most common pattern: a DRF view calling .objects.get() without an owner filter anywhere in the same expression:

# semgrep/rules/drf-idor.yml
rules:
  - id: drf-unscoped-objects-get
    patterns:
      - pattern: $MODEL.objects.get(pk=...)
      - pattern-not: $MODEL.objects.get(pk=..., owner=...)
      - pattern-not: $MODEL.objects.get(pk=..., owner__in=...)
    message: >
      Unscoped .objects.get(pk=...) in a view — add an owner filter or replace with
      a queryset scoped in get_queryset(). Risk: IDOR.
    languages: [python]
    severity: ERROR
    metadata:
      cwe: CWE-639

Run this rule in your CI pipeline on every pull request. To shift IDOR checks left in your CI/CD pipeline, add it as a required status check alongside your test suite — not a separate "security scan" that developers learn to ignore.

Code review checklist for IDOR-prone patterns:

ModelViewSet or GenericAPIView subclass with no explicit get_queryset override — check what the default queryset returns.
permission_classes = [] or a ViewSet that inherits permission_classes from a base class you don't control.
PrimaryKeyRelatedField(queryset=Model.objects.all()) in any writable serializer — this gives any user access to the full table.
perform_create or perform_update that doesn't pin the owner field, leaving it open to user-supplied values.
Tests that only assert status_code == 200 for the happy path, with no cross-user negative test.

SAST tools like Semgrep will catch structural patterns; they won't catch logic bugs where the filter is present but uses the wrong field. Code review has to cover that gap. The combination — automated rules catching the obvious omissions, human review focused on logic — is more effective than either alone.

Hardening Checklist and Next Steps

The layered controls, in priority order:

Queryset scoping (required): get_queryset() filters by request.user. No exceptions for convenience. If an admin view needs to return all objects, it lives in a separate ViewSet with explicit admin permission checks.

Object-level permissions (required): IsOwner or equivalent BasePermission with has_object_permission as a second line of defense. Attach it to every mutating ViewSet.

Serializer-level FK validation (required for relational writes): Every PrimaryKeyRelatedField or nested writable serializer validates that the referenced object belongs to request.user.

perform_create owner binding (required): Never accept owner from request data. Always call serializer.save(owner=self.request.user).

Opaque identifiers (defense in depth): UUIDs or opaque public IDs in all URLs and serializer output. Still mandatory to have the above controls in place.

Automated cross-user tests (required for CI gates): One test class per resource that authenticates as User B and asserts 404 on User A's list, retrieve, update, and delete endpoints.

SAST rules in CI (defense in depth): Semgrep rules flagging unscoped .objects.get() and missing permission_classes, run as required checks on pull requests.

These controls address the majority of IDOR patterns in DRF, but authorization bugs extend well beyond the patterns covered here. If you want to build systematic habits around authorization review — across frameworks, auth protocols, and API types — the Application Security Engineer learning path on Code Review Lab covers the full scope, including scenarios more complex than single-tenant ownership checks.

The part most teams skip is the test suite. You can write perfect queryset scoping today and watch a future contributor add a get_object_or_404(Order, pk=pk) shortcut that bypasses it entirely. Tests that authenticate as the wrong user and assert 404 are the only automated check that catches that regression. Write them now, gate CI on them, and review them alongside any new ViewSet. If you want a reference for how IDOR shows up in security interviews and assessments, common IDOR interview questions are a useful signal for the gaps engineers typically leave in production systems.

How I stopped my README.md and README.zh.md from drifting apart

Alexander A. — Sun, 03 May 2026 22:18:03 +0000

The drift problem

Every project that ships a translated README has the same lifecycle:

Someone writes README.md in English.
A contributor opens a PR with README.zh.md. Great.
Three months later, English has six new sections. Chinese has the original.
A second translator opens README.es.md. Spanish gets translated from… which version? The current README.md? Or README.zh.md, by accident, because the structure looks tidier?
By month nine, you have three READMEs that disagree on what the project actually is.

You can't tell at a glance which file is stale. Reviewers don't read all three. Translations rot, and there's nothing forcing them to stay in sync.

I got tired of this and built a small Java tool — NRG — to fix it. Looking for honest feedback while it's still small enough to change direction.

The idea: one source, N outputs

Write one README.src.md. Get back README.md, README.zh.md, README.ja.md, and as many language variants as you list.

Lines in the template fall into three categories:

Shared across all languages (badges, code blocks, file paths, anything language-agnostic) — no markup needed, the line just appears in every output:

![CI](https://img.shields.io/github/actions/workflow/status/owner/repo/ci.yml)

Language-tagged — appears only in that language's output:

This library is small but hard to use.<!--en-->
Эта библиотека маленькая, но сложная в использовании.<!--ru-->
本库虽小，但难以使用。<!--zh-->

Inline per-language phrases — useful for short strings like anchor names or button labels where one full line per language would be overkill:

## ${en:'Table of contents', ru:'Содержание', zh:'目录'}

Run nrg -f README.src.md. Out come README.md, README.ru.md, README.zh.md, all stamped with a header comment so a reader knows the file is generated.

The killer feature: CI drift-check

This is the part I actually care about, and the reason "regenerate the file periodically" wasn't enough.

NRG ships a GitHub Action (nanolaba/nrg-action@v1) with a check mode. On every PR, it regenerates the READMEs into a temp dir and diffs them against what's committed. If they don't match, the build fails with a unified diff:

--- README.md (on disk)
+++ README.md (generated)
@@ line 27 @@
-## Quick start
+## Getting started

That means a contributor can't land a hand-edit to README.zh.md that bypasses the template. Either they edit README.src.md and regenerate, or CI rejects the PR. No more silent drift.

The CLI has the same flag: nrg -f README.src.md --check. Useful in pre-commit hooks.

Built-in widgets

Anything the template syntax can't express directly is a widget. The shipped set:

${widget:tableOfContents(ordered='true')} — auto-builds a TOC from heading levels.
${widget:import(path='docs/intro.src.md')} — composes templates so a giant README isn't one 800-line file.
${widget:exec(cmd='git rev-parse --short HEAD')} — embeds shell output (handy for "last built from commit X").
${widget:fileTree(path='src/main/java', depth='2')} — auto-generates a directory tree.
${widget:math(expr='\\pi r^2')} — renders LaTeX, with an SVG fallback for the cases where GitHub's native MathJax silently fails.
Plus alert, badge, if/endIf, date, todo.

Custom widgets are a one-class implementation of an NRGWidget interface — useful if you have a recurring pattern specific to your project (e.g. a "feature matrix" widget that renders a row per supported runtime).

Three integration modes

CLI — nrg -f README.src.md. Zero config beyond declaring  in the template.

Maven plugin — for Java projects, hangs off the compile phase, regenerates on every build:

<plugin>
    <groupId>com.nanolaba</groupId>
    <artifactId>nrg-maven-plugin</artifactId>
    <version>1.2</version>
    <configuration>
        <file><item>README.src.md</item></file>
    </configuration>
    <executions>
        <execution>
            <phase>compile</phase>
            <goals><goal>create-files</goal></goals>
        </execution>
    </executions>
</plugin>

GitHub Action — for Python, JS, Rust, or any non-Java project. The action provisions Java itself, so you don't need a Java toolchain in your repo:

- uses: nanolaba/nrg-action@v1
  with:
    file: README.src.md
    mode: check

That's the whole setup. There's also a Java library mode if you want to embed it in some other generator pipeline.

Honest limitations

Java 8 minimum — the binary's portable, but if you despise installing JDKs, the GitHub Action route is the only zero-touch option.
Not a translation tool. NRG keeps structure synchronized. Actual prose translation is still a human job (or your favourite LLM).
No Markdown AST. Substitution and widgets operate on raw text. This is fine 99% of the time but means a clever author can produce broken Markdown that NRG won't catch — that's why there's a separate validate mode.
Early days. Currently at v1.2, used by a handful of open-source repos. The widget API may still change.

What I'd love feedback on

Drift-check workflow — useful safety net, or annoying friction when a translator just wants to fix a typo? Curious how this lands for people who maintain translated docs at scale.
Widget syntax — ${widget:tableOfContents(title='...', ordered='true')} — readable, or have I reinvented a worse Mustache?
What would actually make you adopt this over your current setup (hand-syncing, custom script, doing nothing)? "I'd never use this because…" answers are the most useful.

Repo, full docs, and the GIF demo: github.com/nanolaba/readme-generator

Thanks for reading — happy to answer questions in the comments.

Building Privacy-First Browser Extensions: What I Learned

Weather Clock Dash — Sun, 03 May 2026 22:17:18 +0000

When I built Weather & Clock Dashboard for Firefox, I made a decision early on: no analytics, no accounts, no external calls except weather data.

Here's what I learned about building browser extensions with privacy as a design principle — and why I think more extension developers should take this approach.

The Default is Data Collection

Most web development assumes you want to know who your users are. Analytics platforms are one npm install away. A/B testing, session recording, funnel analysis — the infrastructure for surveillance capitalism is baked into the default developer tooling.

Browser extensions are in a privileged position. They run inside the browser, they can see your tabs (with permission), they load on page visits. An extension with analytics has more access to your behavior than a typical website.

What Privacy-First Actually Means

For my extension, I set these constraints:

1. No analytics scripts
2. No external requests except weather API (user-configured, optional)
3. No user accounts
4. No localStorage of personally identifiable information
5. MIT licensed — code is auditable

The localStorage Rule

The extension stores settings: your preferred city, timezone list, theme preference. But these settings live only in your browser, via browser.storage.local.

// Storing user preference — this stays on-device
await browser.storage.local.set({
  city: userInput,
  theme: 'dark',
  clocks: [{ zone: 'America/New_York', label: 'NYC' }]
});

This data never leaves the browser. It can't. There's no server to send it to.

The Weather API Problem

Weather is a hard case. To show current weather, you need to call an external API — there's no way around it. That external API will see your IP address.

My solution: require users to bring their own API key. Weather & Clock Dashboard uses OpenWeatherMap's free API tier. Users create their own account and enter their own API key.

This means:

I have zero knowledge of what city any user is in
OpenWeatherMap has a direct relationship with the user (their own account)
I have no API key to revoke if I need to shut down a server

The tradeoff: higher setup friction. Some users bounce when they see "enter API key." That's a cost I'm willing to pay.

The AMO Review Benefit

Mozilla's Add-ons review process (for Firefox) actually rewards privacy-respecting extensions. Reviewers check:

What permissions the extension requests
What external requests it makes
Whether the permissions are necessary for the stated functionality

An extension that requests <all_urls> permission but only needs to show weather will get questions. An extension with no permissions beyond storage sails through.

The User Trust Payoff

Privacy-first design communicates trust before users read a single word of your privacy policy. When I see an extension that:

Requires no account
Requests minimal permissions
Is open source
Has been reviewed by Mozilla

...I trust it immediately. That trust is the product.

For extensions specifically, trust is the moat. Users install things that run inside their browser. The bar for trust should be high.

The Technical Implementation

Here's the manifest for Weather & Clock Dashboard — notice what permissions are and aren't requested:

{
  "manifest_version": 3,
  "permissions": [
    "storage"
  ],
  "chrome_url_overrides": {
    "newtab": "dashboard.html"
  }
}

No tabs, no history, no <all_urls>. Just storage to save preferences. That's the entire permission surface.

Analytics Without Surveillance

I do want to know how many people are using the extension. AMO's install count is my only metric, and it's coarse. I can see total installs and a weekly active user count — nothing more granular.

For a lot of developers, this is unacceptable. How do you optimize UX without knowing which features are used? How do you prioritize roadmap?

My answer: user feedback channels (GitHub issues, AMO reviews) and intuition. It's less data-driven. I'm okay with that.

Open Sourcing as a Privacy Signal

MIT licensing and public source code is a form of privacy documentation that no privacy policy can match. Users can verify that the code does what it claims. Researchers can audit it. Security professionals can check for vulnerabilities.

The source code is on GitHub. I'm comfortable with anyone reading it.

Conclusion

Building privacy-first isn't a technical constraint — it's a design decision made before you write the first line of code. The constraint is deciding what you won't collect, not figuring out how to anonymize what you do.

For browser extensions especially, privacy-first design is also good product design. Users are rightfully suspicious of extensions. Being genuinely privacy-respecting — not just claiming to be — is a real differentiator.

Install Weather & Clock Dashboard if you want to see this in practice.

Cursor Session Management: How to Find, Search, and Organize Your AI Coding Conversations

decker — Sun, 03 May 2026 22:16:54 +0000

Have you ever spent 20 minutes looking for a conversation you had with Cursor last week? The one where it helped you fix a tricky async bug—and now you're facing the same issue in a different project, but can't find that thread anywhere?

This isn't a user error. It's a structural limitation in how Cursor handles session history.

The Current State of Cursor Session Management

Cursor includes a built-in conversation history panel. You can browse sessions for the current project and click into any conversation to review the context.

This works fine when you have a handful of sessions. But as usage scales, problems emerge.

Problem 1: Sessions Are Siloed by Project

Cursor ties sessions to the project level. A conversation in project-a doesn't appear when you open project-b.

This makes sense architecturally—each project has its own context. But in practice, many problems are cross-cutting: authentication patterns, deployment scripts, CI configurations. When you need to reference a solution you worked out weeks ago in a different project, you're out of luck.

Problem 2: No Cross-Project Search

Even within a project, Cursor's history panel lacks full-text search. You can scroll, but you can't search.

When you have dozens of sessions in a project, finding a specific conversation about "that WebSocket reconnection issue" means scanning through every entry manually.

Problem 3: No Export or Backup

Your Cursor conversations are stored locally, but there's no built-in way to export them. If you switch machines or need to share a particularly insightful debugging session with a colleague, you're left manually copying and pasting.

Why Session Management Matters for Cursor Users

Cursor excels at in-editor AI assistance. For many developers, it's the primary way they interact with AI for coding. This means the volume of conversations accumulates fast.

Without proper management, you lose:

Institutional knowledge about why certain decisions were made
Reusable solutions to problems you've already solved
Learning progress across projects and time

Making the Most of Cursor Sessions Today

Strategy 1: Create Project-Specific Notes

After a significant Cursor session, take 2 minutes to jot down key findings in a project note. This creates a searchable index you can refer to later.

Strategy 2: Use Descriptive Commit Messages

When you apply code from a Cursor session, include a reference in your commit message. This ties the code change back to the AI-assisted context.

Strategy 3: Cross-Tool Session Management

For developers using multiple AI tools (Cursor + Claude Code + Gemini CLI), consider a unified session viewer. Mantra can index conversations across these tools, giving you a single search interface.

Mantra is a local session viewer supporting Claude Code, Cursor, Gemini CLI, and Codex. Local features are free forever. Learn more at mantra.gonewx.com.

5 Firefox New Tab Extensions Compared: Which One Actually Improves Your Workflow?

Weather Clock Dash — Sun, 03 May 2026 22:16:44 +0000

Your browser opens dozens of times per day. Each time, you see the new tab page for a split second — maybe less. That's hundreds of micro-moments that currently show you... nothing useful.

Here's a comparison of the top Firefox new tab extensions, from a developer who builds them.

What Makes a New Tab Extension Good?

Before comparing, let's define the criteria:

Information density — does it show me something useful?
Load time — does it slow down new tab opens?
Privacy — does it track me?
Customization — can I make it mine?
Free tier — is the useful version free?

The Contenders

1. Momentum Dash

Verdict: Beautiful but limited (free tier)

Momentum shows a beautiful photo, the time, and a daily focus prompt. Premium unlocks weather, todos, and more widgets. The free tier is minimal — just time and a pretty background.

Load time: Fast
Privacy: Account required (tracks usage)
Free tier: Very limited
Customization: Moderate (premium)

2. New Tab Override

Verdict: Developer-focused, total control

New Tab Override lets you set any URL as your new tab page. It's pure configuration — no widgets, no weather, just "open this URL when I press Ctrl+T."

Load time: Depends on the target URL
Privacy: Excellent (no data collection)
Free tier: Full feature (open source)
Customization: Unlimited (you control the URL)

3. Tabliss

Verdict: Most customizable

Tabliss is a widget-based new tab with backgrounds, weather, clock, to-do lists, and more. Each widget is modular and configurable.

Load time: Moderate (many active widgets can slow it)
Privacy: Good (self-contained)
Free tier: Full feature
Customization: Excellent

4. iTab New Tab

Verdict: Feature-rich but heavy

iTab packs in a lot: bookmarks, apps, wallpapers, weather, search. It's essentially a mini dashboard.

Load time: Slower (many features)
Privacy: Mixed (some features call external servers)
Free tier: Full feature
Customization: High

5. Weather & Clock Dashboard

Verdict: Focused on the essentials

This is the extension I built (install here). I built it because I wanted exactly three things on my new tab: weather, clocks, search. Nothing else.

Load time: Instant (pure HTML/CSS/JS, no frameworks)
Privacy: No data collection, no account, no external analytics
Free tier: 100% free, MIT open source
Customization: Weather city, multiple timezone clocks, theme toggle

The Performance Test

I benchmarked new tab load times on the same machine:

New Tab Override (blank):     ~10ms
Weather & Clock Dashboard:    ~150ms  
Tableau (3 widgets):          ~400ms  
iTab (default config):        ~800ms  
Momentum (premium):           ~250ms

Note: External API calls (weather data) are loaded asynchronously and don't block the visual render.

Which One Should You Use?

Choose Momentum if: You want beautiful backgrounds and don't mind a paid subscription for full features.

Choose New Tab Override if: You have a specific webpage you want to open (your company dashboard, Notion, etc.).

Choose Tabliss if: You want maximum widget customization and are willing to configure each one.

Choose iTab if: You want a full browser home page with bookmarks and apps.

Choose Weather & Clock Dashboard if: You want live weather + world clocks without any account, subscription, or data collection. Just install and use.

The Open Source Angle

One thing worth noting: Weather & Clock Dashboard and New Tab Override are both MIT-licensed open source projects. You can inspect the code, fork it, or contribute. For a piece of software that loads on literally every new browser tab, knowing exactly what it does matters.

For closed-source new tab extensions, you're trusting that they aren't injecting ads, tracking your browsing habits, or monetizing your data in ways not disclosed in privacy policies that nobody reads.

Conclusion

The "best" new tab extension depends entirely on what you want your new tab to do. If the answer is "show me weather + current time in multiple cities + let me search quickly," then I'm biased but I'd recommend Weather & Clock Dashboard.

If you want complete flexibility, New Tab Override combined with a locally-hosted page is unbeatable. If you want maximum widgets, Tabliss has the most.

The one I'd avoid: any extension with a required account on the free tier. Your new tab page shouldn't phone home every time you open a tab.

I build Weather & Clock Dashboard. All benchmarks were performed on my own machine; YMMV.

Why I built Clever Deploy

Clever Deploy, — Sun, 03 May 2026 22:16:39 +0000

I built Clever Deploy because every time I wanted to ship a small side project, the deploy story turned into a project of its own.

The two problems I kept hitting

1. Surprise bills. I'd push a side project to a "free tier"
platform, forget about it, and three months later get a $40 invoice
because something I didn't fully understand auto-scaled, or a build
ran 200 times, or bandwidth crossed a line I didn't know existed.
The pricing pages all looked simple. The actual bills never were.

2. Complexity. I've setup Jenkins in Kubernetes for clients - believe me, you don't want that kind of complexity.

What I wanted was simplicity and no unexpected bills.

What Clever Deploy is

A deploy platform with two rules:

Click Deploy, pick a repo, get a live HTTPS URL. The defaults are right for 95% of projects, and you can override them later if you're in the 5%.
Pricing you can predict before you click. A flat number. No metered surprises hiding behind "fair use" footnotes. If a project is going to cost you money, you know exactly how much, before it's running.

That's the entire pitch. Everything else — the build pipeline, the
TLS automation, the subdomain routing, the GitHub App integration —
is plumbing in service of those two promises.

Why now

Hosting has gotten better and cheaper every year for a decade. The
ergonomics of hosting have not. The big platforms keep adding
features for the top 1% of users (edge functions, regional
replication, AI gateways) and quietly making the on-ramp harder for
everyone else.

I wanted the deploy experience I had in 2018 with Heroku free dynos, without the 2022 ending where the free dynos got turned off and nobody had a good answer for the small-project niche.

Where I'm at

Clever Deploy works end-to-end live: GitHub auth, build pipeline, live deploys, build logs, an admin dashboard. However, it's not open to the public yet - I'm letting people in from the waitlist as I shake out edge cases.

If predictable costs and one-click deploys sound like your kind of
boring, I'd love to get your feedback on it. Sign up at the waitlist at https://cleverdeploy.com/ and I'll make sure you get 50% off your first year if you decide to use us for real.

— Wasim

Giving an AI agent permission to spawn sub-agents (without losing control)

GDS K S — Sun, 03 May 2026 22:14:05 +0000

Giving an AI agent permission to spawn sub-agents (without losing control)

A reader asked me last week: "If my main agent spawns a sub-agent, what permissions does the sub-agent get? How do I make sure it cannot do more than the parent?"

This is the agent delegation problem. It comes up the moment you have agents that work in tandem. A planner that hands off to a coder. An orchestrator that fans out to specialists. An MCP server that calls another MCP server on a user's behalf.

The naive answer is: give the sub-agent the same API key as the parent. This is wrong. Once you do that, the sub-agent can do everything the parent can. If it goes off the rails, you cannot kill it without killing the parent. There is no audit trail per agent. You cannot apply different rate limits.

The right answer is scoped delegation with revocation. Here is what that looks like.

What scoped delegation means

When the parent agent spawns a sub-agent, it issues the sub-agent a token that:

Is its own credential, not a copy of the parent's
Inherits a subset of the parent's permissions, never more
Has a parent reference, so revoking the parent revokes everything downstream
Has its own expiry, separate from the parent
Has a depth limit, so a sub-agent of a sub-agent of a sub-agent eventually hits a wall

KavachOS calls this a delegation chain. The data model is:

parent_agent (token A)
  └── sub_agent_1 (token B, parent=A, scopes ⊆ A)
        └── sub_agent_2 (token C, parent=B, scopes ⊆ B)

Revoking A revokes B and C. Revoking B revokes only C. Each token has its own audit trail.

Code

import { createKavach } from "kavachos";
import { delegate, revoke } from "kavachos/agent";

const kavach = await createKavach({
  database: { provider: "sqlite", url: "kavach.db" },
});

// parent agent has a token with these scopes
const parentToken = await kavach.agent.issue({
  agentId: "planner-001",
  scopes: ["github:read", "github:write", "deploy:staging"],
  ttl: "1h",
});

// parent spawns a coder sub-agent
// it can read and write GitHub, but not deploy
const coderToken = await delegate(parentToken, {
  agentId: "coder-001",
  scopes: ["github:read", "github:write"],  // dropped deploy:staging
  ttl: "30m",                                // shorter than parent
  maxDepth: 1,                               // coder cannot spawn its own
});

The delegate call:

Verifies the requested scopes are a subset of the parent's
Throws ScopeEscalationError if the sub-agent asks for a scope the parent does not have
Sets parent_token_id so revocation cascades
Issues a fresh token with its own JTI

// this throws: ScopeEscalationError
const badToken = await delegate(parentToken, {
  agentId: "rogue-001",
  scopes: ["github:read", "deploy:production"],  // parent does not have it
});
// kavach.error.code === "SCOPE_ESCALATION"

The library refuses to issue a token with scopes the parent does not have. This is enforced at issue time, not at validation time, so a misbehaving caller cannot sneak it through.

Revocation

await revoke(parentToken);
// every descendant token is also revoked

Behind the scenes, KavachOS marks the parent token id as revoked. Any token with parent_token_id matching it (recursively) is rejected on next validation. The agent table has an index on parent_token_id so this stays fast.

You can also revoke a single sub-agent without touching the parent:

await revoke(coderToken);
// parent and other siblings keep working

Audit

Every action an agent takes through KavachOS goes into the audit log:

{
  event: "tool.call",
  agent_id: "coder-001",
  parent_agent_id: "planner-001",
  scope: "github:write",
  resource: "repos/kavachos/kavachos/contents/README.md",
  timestamp: "2026-04-29T11:42:13Z",
  request_id: "req_abc123",
  outcome: "allowed"
}

When something goes wrong at 3am, you can trace exactly which sub-agent of which parent of which root user did what. This is the answer to "the agent merged a bad PR" type incidents. Without it, you have a Slack message with no fingerprint.

Why depth limits matter

A planner spawns a coder. The coder spawns a tester. The tester spawns a fixer. The fixer spawns a re-tester. At some point, the chain has to stop. Otherwise an agent stuck in a loop can consume all your tokens and rate limits.

const parentToken = await kavach.agent.issue({
  agentId: "planner-001",
  scopes: ["github:read", "github:write", "deploy:staging"],
  maxDepth: 3,
  ttl: "1h",
});

The fourth-level descendant fails to issue. You catch this in your orchestrator and decide how to handle it: escalate to a human, fail the task, or split the work differently.

Where this matters most

This pattern is what enterprise will demand once agents are doing real work. Right now most teams ship with shared API keys and a hope. That works until it does not. When it does not, you are trying to reconstruct what happened from log fragments.

Building this from scratch is doable but boring. Token issuance is straightforward. Cascading revocation is not. Depth tracking takes care to get right. The audit log is its own project.

If you do not want to build it yourself, KavachOS handles all of it as a primitive in the same library that does human auth.

npm install kavachos

Source: github.com/kavachos/kavachos. MIT.

If you run multi-agent systems in production today, how do you scope sub-agent permissions? Shared API keys? Per-agent tokens? Something stricter? Curious where the pain is for you.

Dual-Booting Windows 11 & Rocky Linux — A Beginner's Complete Guide

William Kwabena Akoto — Sun, 03 May 2026 22:12:17 +0000

A step-by-step guide for beginners who want a gaming PC and a real enterprise Linux environment on the same machine — with every decision explained in plain English.

What Is Dual-Booting and Why Rocky Linux?
Key Concepts You Must Understand First
- UEFI, BIOS, and Secure Boot
- Partitions, File Systems, and GPT
- The GRUB Bootloader
Before You Begin — Checklist
Phase 1 — Shrink Your Windows Partition
Phase 2 — Download & Flash Rocky Linux
Phase 3 — Configure the HP BIOS
Phase 4 — Boot the Rocky Linux Installer
Phase 5 — Anaconda Installer Walkthrough
Phase 6 — First Boot & the GRUB Menu
Phase 7 — Post-Install DevOps Setup
Troubleshooting Common Problems

1. What Is Dual-Booting and Why Rocky Linux?

Dual-booting means installing two separate operating systems on the same physical computer, each living in its own isolated section of the hard drive called a partition. When you power on your laptop, a small program called a bootloader wakes up and shows you a menu: pick Windows or pick Rocky Linux. The two systems never interfere with each other.

This is different from a virtual machine, where you'd run Linux inside a window on top of Windows. Dual-booting gives each OS full, direct access to your hardware — better performance, real GPU access for your DevOps tools, and a genuine feel for what it's like to administer a server.

Why Rocky Linux specifically? Rocky Linux is a free, community-maintained and designed for 1:1, bug-for-bug downstream binary compatibility with Red Hat Enterprise Linux (RHEL) — the operating system that runs a huge chunk of the world's servers, cloud infrastructure, and enterprise data centres. When companies say they want "Linux experience", they usually mean RHEL-family experience.Rocky Linux is fullRocky Linux 10.1 is fully supported until May 2035, giving you a stable, long-term learning platform.

Rocky Linux will push you further: its default security model (SELinux), firewall tool (firewalld), and package manager (DNF) are all standard in enterprise environments that other linux distributions rarely appear in.

2. Key Concepts You Must Understand First

Before touching a single setting, you need to understand why you're making each decision. Skipping this section is how people accidentally wipe their Windows installation. Take ten minutes to read it.

UEFI, BIOS, and Secure Boot

What is UEFI / BIOS?
UEFI (or its older predecessor, BIOS) is firmware — a tiny program burned into a chip on your motherboard. It's the very first thing that runs when you press the power button, before any operating system loads. Its job is to inventory your hardware (CPU, RAM, drives) and then hand control to a bootloader on one of your storage devices.

Your computer mostly likely uses UEFI, the modern standard. UEFI uses a special partition called the EFI System Partition (ESP) — a small FAT32 partition that stores bootloader files for every OS installed. Windows already placed its bootloader there. Rocky Linux will add its own file alongside it without deleting Windows.

What is Secure Boot?
Secure Boot is a UEFI feature that checks a digital signature on every bootloader before running it. It prevents malware from hijacking the boot process. However, it can also block Linux installers that aren't signed with a trusted key.

Rocky Linux does have Secure Boot support, but to avoid any complications on first install, we will disable Secure Boot in the BIOS before installing. You can re-enable it afterwards once everything is working.

Partitions, File Systems, and GPT

What is a partition?
Imagine your hard drive as a single large plot of land. A partition is like drawing property lines to divide it into separate sections. Each section is completely independent — one can have Windows on it, another can have Linux, and they don't mix.

What is a file system?
A file system is the internal structure that a partition uses to organise files. Windows uses NTFS. Rocky Linux defaults to XFS — the same file system used on most RHEL enterprise servers.

What is GPT?
GPT (GUID Partition Table) is the modern standard for how partition information is stored on a disk. Your computer mostly already uses GPT since it might have come with Windows 10/11 already on it.

Here is what your disk will look like after the installation is complete:

[ EFI ][ Windows (C:) — ~400 GB ][ /boot ][ swap ][ /  root ][ /home ]

Mount Point	Size	File System	Purpose
`/boot/efi`	Reuse existing	FAT32	Already exists. Stores bootloaders for all OSes. Never format.
`/boot`	1 GB	ext4	Stores the Linux kernel. Kept separate for boot-process compatibility.
`swap`	= your RAM size	swap	Overflow RAM storage. Required for hibernation.
`/` (root)	40–60 GB	xfs	The OS, all installed software, and system configs.
`/home`	Remaining space	xfs	Your personal files and projects. Survives an OS reinstall intact.

The GRUB Bootloader

What is GRUB?
GRUB (Grand Unified Bootloader) is the program that Rocky Linux installs to manage booting. After installation, GRUB detects all installed operating systems and shows you a menu. When you select Windows, GRUB hands control to the Windows Boot Manager. When you select Rocky Linux, GRUB loads the Linux kernel directly.

GRUB installs itself into the EFI System Partition alongside the Windows bootloader. This is why we never format the EFI partition — doing so would delete the Windows bootloader and make Windows unbootable.

3. Before You Begin — Checklist

Work through this checklist completely before proceeding. Every item matters.

Back up your Windows data first. Partitioning operations carry inherent risk. If something goes wrong mid-operation, data loss is possible. Copy your important files to an external drive, a cloud service, or both. This is non-negotiable.

Check 1 — CPU Compatibility

Rocky Linux 10 requires a CPU supporting the x86-64-v3 instruction set. Any AMD Ryzen 2000+ or Intel 8th Gen (Coffee Lake)+ processor qualifies.

To confirm, open PowerShell on Windows and run:

wmic cpu get name

Check 2 — Disable Windows Fast Startup

Windows Fast Startup leaves the Windows file system in a "partially mounted" state on shutdown. If Linux then tries to read the Windows partition, it can corrupt the file system. Disable it permanently:

Press Win + S, search for Control Panel, open it
Go to Hardware and Sound → Power Options
Click "Choose what the power buttons do" in the left sidebar
Click "Change settings that are currently unavailable"
Under "Shutdown settings", uncheck "Turn on fast startup"
Click Save changes

Check 3 — Free Disk Space

Open Disk Management (Win + X → Disk Management). You need at least 60–80 GB of free space on your C: drive to shrink comfortably. You'll be carving that space out as unallocated room for Rocky Linux.

Check 4 — A 16 GB+ USB Drive

You'll flash the Rocky Linux ISO onto this drive. It will be completely erased. Don't use one with files you need.

Check 5 — Stable Power

Plug your laptop in during the entire process. A laptop dying mid-partition or mid-install can corrupt both operating systems.

Phase 1 — Shrink Your Windows Partition

Right now, Windows occupies the entire drive. Before we can install Rocky Linux, we need to shrink the Windows partition and leave behind unallocated space that the Rocky Linux installer will carve into its own partitions.

We use Windows' own built-in tool for this — not a third-party app, not the Linux installer. This ensures Windows is aware of the change and updates its own boot records accordingly.

How Much Space to Allocate?

Use Case	Minimum	Recommended
Occasional learning / labs	50 GB	70 GB
Active DevOps work, Docker, VMs	80 GB	120 GB
Heavy Kubernetes / container dev	120 GB	150+ GB

For a DevOps workstation, 80–100 GB is the sweet spot. Docker images alone can consume 20–30 GB over time.

Step 1 — Open Disk Management

Press Win + X on your keyboard. In the menu that appears, click Disk Management. You'll see a graphical view of your disk with all current partitions shown as coloured bars.

Step 2 — Identify Your C: Drive Partition

In the graphical area at the bottom, look for the large partition labelled (C:). This is your Windows installation. Right-click it.

Step 3 — Click "Shrink Volume..."

A dialog box appears. Enter your desired amount in the field "Enter the amount of space to shrink in MB". Convert GB to MB by multiplying by 1024:

80 GB → enter 81920
100 GB → enter 102400
120 GB → enter 122880

Step 4 — Click Shrink and Wait

Windows will resize the partition (typically 30 seconds to 2 minutes). When done, you'll see a new block of black/dark unallocated space in the disk map. Do not create a new volume in that space — leave it as "Unallocated". The Rocky Linux installer will handle it.

If Windows won't let you shrink enough: This happens when Windows has "immovable" system files near the end of the partition. Fix: disable hibernation by opening an Administrator Command Prompt and running powercfg /h off, then try shrinking again.

Phase 2 — Download & Flash Rocky Linux

Step 2.1 — Download the ISO

An ISO file is a complete, exact copy of the entire Rocky Linux installer. Go to:

https://rockylinux.org/download

Under Rocky Linux 10, select the x86_64 architecture and download the DVD ISO (~10 GB). Also download the accompanying CHECKSUM file from the same page.

Step 2.2 — Verify the ISO (Don't Skip This)

Verifying the checksum confirms the file downloaded completely and without corruption. A partially downloaded or tampered ISO can cause strange installer errors that are very hard to diagnose.

Open PowerShell and run (adjust the filename to yours):

Get-FileHash "$env:USERPROFILE\Downloads\Rocky-10.1-x86_64-dvd1.iso" -Algorithm SHA256

The 64-character hash must exactly match the SHA256 value in the CHECKSUM file. If they differ — even by one character — delete the ISO and re-download it.

Step 2.3 — Flash the USB Drive with Rufus

Download Rufus from https://rufus.ie. Plug in your 16 GB+ USB drive and open Rufus. Configure it as follows:

Rufus Setting	Value	Why
Device	Your USB drive	Double-check it's the USB, not your internal drive
Boot selection	Click SELECT → choose the ISO	Rufus will auto-detect most settings
Partition scheme	GPT	Required for UEFI systems
Target system	UEFI (non CSM)	Forces UEFI mode. CSM is a legacy compatibility mode.
File system	Leave as Rufus default	Rufus knows best for bootable drives

Click START. If a dialog appears, choose "Write in ISO Image mode" and click OK.

The USB drive will be completely wiped. All data on the USB will be gone after this step.

The flashing process takes 5–15 minutes. When Rufus shows READY in green, the USB is ready.

Phase 3 — Configure the HP BIOS

The BIOS needs to be told two things: disable Secure Boot and boot from the USB instead of the hard drive.

Step 1 — Enter the BIOS Setup

Fully shut down your laptop (not restart — shut down). Plug in the Rocky Linux USB. Power on and immediately, repeatedly tap F10 until you see the BIOS setup screen.

Alternative: power on → tap Esc → HP startup menu → press F10 to enter Setup.

Step 2 — Disable Secure Boot

Navigate to the Security tab. Find Secure Boot and set it to Disabled. You can re-enable it after installation.

Step 3 — Confirm UEFI Boot Mode

Under Advanced or Boot Options, verify UEFI Boot Mode is selected. Ensure CSM / Legacy Boot is disabled.

Step 4 — Set USB as First Boot Device

Go to Boot Order. Move the USB storage device to the top of the list using the function keys shown on screen (usually F5/F6 or +/-).

Step 5 — Save and Exit

Press F10 to save changes and exit. The laptop will reboot and boot from your Rocky Linux USB.

Alternative: One-time boot menu. Power on and press F9 immediately to choose a boot device for that startup only, without permanently changing the boot order.

Phase 4 — Boot the Rocky Linux Installer

With the BIOS configured, your laptop will boot into the Rocky Linux installer. You'll see a dark GRUB menu. Use the arrow keys to highlight "Install Rocky Linux" and press Enter.

The screen may go black for 30–60 seconds after you press Enter. The Linux kernel is loading and initializing your hardware. Do not panic and do not press any keys. Wait for the graphical installer (Anaconda) to appear.

Select English (United States) and click Continue.

Phase 5 — Anaconda Installer Walkthrough

Anaconda uses a hub-and-spoke model: one main summary screen with several sections listed. Complete them in any order. The "Begin Installation" button activates only once every required section has a green checkmark.

Time & Date

Click Time & Date. Click your region on the world map. Enable Network Time if connected to Wi-Fi. Click Done.

Software Selection

Recommended for a DevOps workstation: Choose "Workstation" for the full GNOME desktop. For a leaner, server-like experience, choose "Server with GUI" instead.

Under Additional Software, also check:

Development Tools — gcc, make, git, and other build essentials
System Tools — useful system administration utilities
Headless Management — includes the SSH server for remote access
Container Management — Podman and container tools (RHEL's Docker equivalent)

Click Done.

Installation Destination — Partitioning (Most Critical Step)

This is the most important step in the entire guide. Read every instruction carefully before clicking anything. An incorrect choice here can erase your Windows installation. There is no undo button once you accept changes.

Click Installation Destination. Select your internal drive. Under Storage Configuration, select Custom. Click Done to enter the manual partitioning screen.

Partitioning Scheme: Standard vs LVM

Scheme	Best For	Verdict
Standard Partition	Simplicity — what you see is what you get	Fine for beginners who want clarity
LVM	Flexibility — resize partitions later without data loss	Recommended for DevOps — standard in enterprise RHEL

What is LVM? LVM adds an abstraction layer between physical partitions and what the OS sees as drives. Instead of a fixed partition of exactly 40 GB, you have a "logical volume" that can be grown or shrunk while the system is running. In enterprise environments you'll constantly encounter LVM-managed disks. Choose LVM.

Creating the Partitions

Use the + button to add each partition in this order:

Never format the EFI partition. It contains the Windows Boot Manager. Formatting it will make Windows unbootable. Set the mount point to /boot/efi and ensure the format checkbox is unchecked.

Partition 1 — Reuse the EFI Partition

Click on the existing EFI System Partition in the left panel, then in the right panel:

Mount Point: /boot/efi
File System: FAT32
Ensure "Do not format" is selected

Partition 2 — /boot

Mount point: /boot
Desired capacity: 1 GiB
File system: ext4

Why ext4 for /boot? GRUB reads /boot at a very early stage when LVM may not yet be available. ext4 is simple, widely supported, and reliable in this context.

Partition 3 — swap

Mount point: swap
Desired capacity: same as your RAM (e.g., 16 GiB for 16 GB of RAM)
File system: swap

What is swap? When physical RAM fills up, Linux moves less-used data to the swap partition. It's also required for hibernation.

Partition 4 — / (Root)

Mount point: /
Desired capacity: 50 GiB
File system: xfs

Why XFS? XFS is the default file system for RHEL 7+ and Rocky Linux. It excels at large files, high I/O workloads, and parallel access — all common in server environments.

Partition 5 — /home

Mount point: /home
Desired capacity: leave blank (uses all remaining unallocated space)
File system: xfs

Why a separate /home? If you ever reinstall Rocky Linux, your user data, configurations, and project files survive untouched. Simply reinstall, mount /home without formatting it, and pick up where you left off.

Review & Accept Changes

Click Done. In the "Summary of Changes" dialog, verify:

The EFI partition is listed as "mount only" (not format)
/boot, swap, /, and /home are listed as "format and mount"
Your Windows C: partition does not appear in this list at all

If everything looks correct, click "Accept Changes".

Network & Hostname

Connect to Wi-Fi. Set your hostname. Click Apply then Done.

Root Account & User Creation

What is the root account? In Linux, root is the superuser with unlimited power over the entire system. In Rocky Linux, the root account is disabled by default — a deliberate security choice that mirrors how enterprise RHEL systems are configured. Instead, you create a regular admin user that uses sudo to gain root-level privileges when needed.

Root Account: Leave it disabled (the default).
User Creation: Set a full name, a short lowercase username , and a strong password. Check "Make this user administrator" — this adds your user to the wheel group, granting sudo access.

Begin Installation

Click "Begin Installation". The installer will format partitions, install the OS and all selected packages, and configure GRUB. This takes 15–45 minutes. When finished, click "Reboot System" and remove the USB.

Phase 6 — First Boot & the GRUB Menu

After the reboot, you'll see the GRUB boot menu with two entries:

Rocky Linux (and older kernel entries)
Windows Boot Manager

By default, GRUB auto-selects Rocky Linux after a 5-second countdown. Select Rocky Linux and let it boot to the GNOME login screen.

If GRUB doesn't appear and Windows boots directly: The HP BIOS is still prioritising the Windows Boot Manager over GRUB. Enter BIOS (F10 on startup) and move "Rocky Linux" or "GRUB" above "Windows Boot Manager" in the boot order. See the Troubleshooting section for a permanent fix.

Phase 7 — Post-Install DevOps Setup

Open the Terminal application (Ctrl + Alt + T) and run the following in order.

Step 7.1 — Full System Update

dnf is Rocky Linux's package manager:

sudo dnf -y upgrade

Step 7.2 — Enable EPEL Repository

EPEL (Extra Packages for Enterprise Linux) provides thousands of additional packages not in the base RHEL repos — like a major PPA trusted across the enterprise Linux world.

sudo dnf install -y epel-release
sudo dnf upgrade -y

Step 7.3 — Understand SELinux (Don't Disable It)

Do not disable SELinux. The most common beginner advice online is to set SELinux to permissive or disabled. This destroys the entire point of using a RHEL-based system. Every enterprise RHEL deployment runs SELinux in enforcing mode. Learning to work with it — not around it — is a core career skill.

sestatus                        # view current SELinux status
getenforce                      # should say "Enforcing"
sudo ausearch -m avc -ts recent # view recent SELinux denials
sudo sealert -a /var/log/audit/audit.log  # human-readable SELinux explanations

Step 7.4 — Understand firewalld

Rocky Linux uses firewalld instead of Ubuntu's ufw. Same concept, different syntax:

sudo firewall-cmd --state                         # check it's running
sudo firewall-cmd --list-all                      # see current rules
sudo firewall-cmd --permanent --add-service=http  # allow HTTP traffic
sudo firewall-cmd --reload                        # apply changes

Troubleshooting Common Problems

Problem: Windows Boots Directly (No GRUB Menu)

The HP BIOS is loading the Windows Boot Manager before GRUB. Open Command Prompt as Administrator on Windows and run:

bcdedit /set {bootmgr} path \EFI\rocky\grubx64.efi

Alternatively, boot from the Rocky Linux USB → Troubleshooting → Rescue, then run:

grub2-install /dev/nvme0n1          # for NVMe drives
grub2-mkconfig -o /boot/grub2/grub.cfg

Problem: Windows Missing from GRUB Menu

GRUB didn't detect Windows. Install os-prober and regenerate the GRUB config:

sudo dnf install -y os-prober
sudo os-prober                        # should output a line mentioning Windows
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot

Problem: Wi-Fi Doesn't Work After Install

Identify your network card first:

lspci | grep -i network
lspci | grep -i wireless

For Realtek cards:

sudo dnf install -y linux-firmware
sudo reboot

For Intel cards, check:

sudo nmcli device status     # list all network devices
sudo nmcli radio wifi on     # ensure Wi-Fi radio is enabled

Problem: Can't Shrink Windows Enough (Phase 1)

Disable hibernation and the pagefile temporarily. Run in Administrator Command Prompt on Windows:

powercfg /h off

Then retry Disk Management → Shrink Volume.

Problem: "No Space Left" Errors When Installing Packages

Your root partition (/) is full. Check usage:

df -h          # shows partition sizes and usage
du -sh /*      # shows what's consuming space in root

If you used LVM, you can extend the root logical volume using space from another volume — one of the main advantages of LVM over standard partitioning.

Problem: SELinux Blocking an Application

Don't disable SELinux — diagnose it:

sudo ausearch -m avc -ts recent | audit2why          # explains the denial in plain English
sudo ausearch -m avc -ts recent | audit2allow -M myfix  # generates a policy fix
sudo semodule -i myfix.pp                               # applies the fix

Conclusion

Congratulations, you have now completely dual-booted Windows 11 & Rocky Linux on the same physical hardware!

Devs Brasileiros

¿Cuánta energía, agua, dinero e infraestructura estamos dispuestos a gastar para sostenerla?

Mythos Found a 27-Year-Old Bug in OpenBSD. Your Code Is Next.

What Mythos is, in hard numbers

The asymmetry just collapsed

Project Glasswing's narrow gate

Why your legacy stack is the easy target

The defender's playbook for the next 90 days

1. Get an honest inventory of your legacy attack surface

2. Build the SBOM you should already have

3. Modernize the highest-exposure legacy primitives first

4. Assume the patch tsunami is coming

5. Threat-model with AI-assisted attackers in scope

A note for federal contractors

The honest read

Logic Apps Agent Loop + MCP: Two Bugs Worth Knowing About

Context

Bug 1 — Intermittent duplicate key error at tool registration

What happens

What makes it particularly frustrating to diagnose

Load test

What you can't do

Bug 2 — MCP Connector does not support OAuth

What happens

Why it matters

Current state

What works in the meantime

Feature Flags That Actually Ship: Lessons From the Trenches

The Patterns That Actually Matter

Release Flags

Kill Switches

Percentage Rollouts

The Questions Your Team Will Ask (And How to Answer Them)

"Doesn't this just create more code to maintain?"

"What if the flag service goes down?"

"Can't we just build this ourselves?"

Where We Go From Here

Key Takeaways

How to Prevent IDOR Vulnerabilities in Django REST APIs

How to Prevent IDOR Vulnerabilities in Django REST APIs

How IDOR Attacks Work Against Django REST APIs

Fixing IDOR by Scoping Querysets to the Authenticated User

Use Unguessable Identifiers Instead of Sequential IDs

Enforce Authorization at the Serializer and Nested Resource Level

Test for IDOR with Automated Authorization Checks

Catch IDOR in Code Review and CI

Hardening Checklist and Next Steps

Further Reading

How I stopped my README.md and README.zh.md from drifting apart

The drift problem

The idea: one source, N outputs

The killer feature: CI drift-check

Built-in widgets

Three integration modes

Honest limitations

What I'd love feedback on

Building Privacy-First Browser Extensions: What I Learned

The Default is Data Collection

What Privacy-First Actually Means

The localStorage Rule

The Weather API Problem

The AMO Review Benefit

The User Trust Payoff

The Technical Implementation

Analytics Without Surveillance

Open Sourcing as a Privacy Signal

Conclusion

Cursor Session Management: How to Find, Search, and Organize Your AI Coding Conversations

The Current State of Cursor Session Management

Problem 1: Sessions Are Siloed by Project

Problem 2: No Cross-Project Search

Problem 3: No Export or Backup

Why Session Management Matters for Cursor Users

Making the Most of Cursor Sessions Today

Strategy 1: Create Project-Specific Notes

Strategy 2: Use Descriptive Commit Messages

Strategy 3: Cross-Tool Session Management

5 Firefox New Tab Extensions Compared: Which One Actually Improves Your Workflow?

What Makes a New Tab Extension Good?

The Contenders