Wednesday, October 28, 2026

thumbnail

Next.js 16, one year on: what broke when I upgraded a real site

Next.js 16, one year on: what broke when I upgraded a real site

Posted on Oct 28 • Originally published at kunjdeveloper.com

Next.js 16 came out in October 2025. A year later it is the version most new projects start on, and the version a lot of working sites still have not moved to. This site moved this month. It is a real app, not a starter: the App Router, a Postgres database through TypeORM, a credentials-based admin panel, and a Docker image that runs on a small VPS.

The official upgrade guide is good and the codemod does most of the typing. What the guide cannot tell you is which of its changes will hit your particular stack. Two problems broke this site's production build in ways a dev server never showed. This is what broke, why, and what I would check before you upgrade yours.

The headline change is that next build uses Turbopack by default. Development already did; now production does too. For most code that is invisible. For code that relies on two routes sharing the same instance of a module, it is not.

After the upgrade, the production build served every public page fine, and admin sign-in failed with this:

The cause is how the database connection and the bundles meet. The TypeORM DataSource is created once and shared through globalThis, so whichever route connects first registers its entity classes. Turbopack gives each route its own copy of those classes. In production the first request is usually a public page, so the connection held the public page's Admin class, and the auth route asked for a repository with its own, different Admin class. TypeORM compares classes by identity, so as far as it was concerned that entity had never been registered.


馃搮 Published Date: Wed, 28 Oct 2026 10:18:32 +0000
馃敆 Original Source: Read on original site

Tuesday, October 27, 2026

thumbnail

When External Secrets Operator's Manual Refresh Runs Into `refreshInterval: 0`

When External Secrets Operator's Manual Refresh Runs Into `refreshInterval: 0`

Posted on Oct 27 • Originally published at whenitruns.substack.com

External Secrets Operator v2.11.0: with the default refresh policy and refreshInterval: 0, the FAQ's annotation, label or spec change left the Secret stale; 1h and OnChange refreshed at once.

Provider · Component: External Secrets Operator · refreshing an ExternalSecret by hand — what the manual refresh in the project's FAQ (changing an annotation, a label or the spec) does when the ExternalSecret uses the default refresh policy, Periodic, with refreshInterval: 0 and the default creation policy, Owner Versions tested: measured — External Secrets Operator v2.11.0 (the current minor release as of 2026-09-27; v2.12.0, v2.13.0 and v2.14.0, released on 2026-10-06, 2026-10-16 and 2026-10-23, were not measured, and v2.14.0 is the current minor release as of 2026-10-23; the project supports only the current minor version, and its support table lists 2.11's end of life as 2026-10-06), a single version. source-read — pkg/controllers/externalsecret/externalsecret_controller.go at the same tag. The behavior came in v0.11.0 (pull request #4086, milestone 0.11.0) — a boundary taken from the pull request, not measured. Config profile: a single-node kind cluster (kind v0.33.0, node kindest/node:v1.36.4, digest-pinned; Kubernetes 1.36 is the version the project lists for 2.11) on a dedicated test VM; the official Helm chart 2.11.0 with the controller's log level at debug; one SecretStore using the fake provider; three ExternalSecrets that differ only in their refresh settings — refreshInterval: 0s (default policy), refreshInterval: 1h (default policy), and refreshPolicy: OnChange — all with the default creation policy; the store value is changed once, then the refreshInterval: 0s object gets an annotation change, a label change and a spec change that adds a new data key, and each of the other two gets an annotation change, with 120 seconds of polling every 5 seconds after each change. Verified on: 2026-10-23 (desk sources re-checked; v2.14.0 was the current minor release) · lab measured 2026-09-28 on v2.11.0. Affects: External Secrets Operator v2.11.0 ExternalSecrets that use the default refresh policy with refreshInterval: 0 (and the default creation policy) and have synced once: the FAQ's manual refresh — an annotation, label or spec change — did not fetch the Secret again, and the object's refresh status stayed the same. The same annotation change refreshed ExternalSecrets with refreshInterval: 1h or refreshPolicy: OnChange. TL;DR: On External Secrets Operator v2.11.0, an ExternalSecret with the default refresh policy and refreshInterval: 0 kept its Secret at the old value after each manual refresh the FAQ lists — an annotation change, a label change, and a spec change that maps a new data key — with refreshTime unchanged; the same annotation change refreshed ExternalSecrets with refreshInterval: 1h or refreshPolicy: OnChange.

Full report: https://whenitruns.substack.com/p/when-external-secrets-operators-manual

Reproduction repo: https://github.com/whenitruns/when-external-secrets-operators-manual-refresh-runs-into-refreshinterval-0

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.


馃搮 Published Date: Tue, 27 Oct 2026 10:18:04 +0000
馃敆 Original Source: Read on original site

Monday, October 26, 2026

thumbnail

My SSD went silent and SMART called it perfect

My SSD went silent and SMART called it perfect

Storage monitoring assumes decay. Wear counters creep, spare blocks drain, thermals climb, and every dashboard I've ever set up is built to catch that slow slide. At 00:37 Eastern on October 24 my drive skipped the slide entirely: it stopped answering reads, its self-report stayed spotless through everything that followed, and a cold power cycle was what brought it back. The hardware in question is a Samsung 980 PRO 500GB on firmware 1B2QGXA7.

The sequence moved fast on the way down. Read timeouts first. Then controller resets that failed. Then the kernel disabled the device. Btrfs went into emergency shutdown, and the model engine exited with the mount effectively gone. Nothing in that trail warned me; the first read timeout is the first line of the incident, and there is no decay curve anywhere in it for a monitor to catch.

The log told the story because the kernel was watching from the outside: it saw a device stop answering and said so. SMART had nothing to say, and the reason is structural.

SMART had nothing bad to report at any point. One percent used. One hundred percent spare. Zero media errors. Zero error-log entries. 47C and no thermal warning time. That is a report card written by the component that had just refused to answer, and it graded itself clean.

The mechanic underneath is simple: every one of those counters lives inside the firmware that stopped responding. One percent used is the drive's estimate of endurance consumed, one hundred percent spare means every reserve block is still there, and the zero media errors line holds even against that night's read timeouts, because the counter only moves when the drive's own firmware records the failure. All of it clean, on the same drive that refused to answer. A drive that decays slowly can still report on itself accurately, and that's the case the tools are built around. A drive going silent cannot, because the reporter is the thing that failed. My dashboards watch the first failure mode and have no view of the second.

A cold power cycle brought it back. Remounted read-write, engine running on the same drive again.


馃搮 Published Date: Mon, 26 Oct 2026 10:26:08 +0000
馃敆 Original Source: Read on original site

Sunday, October 25, 2026

thumbnail

Web3 UI UX Design: Trends, Challenges & AI’s Role in 2026

Web3 UI UX Design: Trends, Challenges & AI’s Role in 2026

You launched a Web3 app with a slick UI. The wallet connects. The dashboard looks great. But users sign up, poke around, and never come back. This happens a lot, because a good-looking dApp can still feel confusing to use. We’ve talked with the global UI/UX design expert agency - Wavespace. Their team always updates with the latest trends. They know that strong visuals bring users in. But clear, stress-free flows are what make them stay. In Web3, that matters even more. So what’s working right now? And what’s still broken? Let’s look at the latest trends that experts adopt, the biggest challenges, and where AI actually helps them.

Think about how you log in to most apps. You click “Sign in with Google.” That’s it, you’re in. Web3 works differently. Here, your wallet is your account. So before doing anything, users must install a wallet. Then they save a seed phrase. Next, they buy tokens just to pay fees. After all that, they approve a request they can’t read. That’s a long road before any value shows up. And each step is one more reason to quit.

The good news is that things are moving fast. Designs hook the readers before they read a single word. These five trends are making the biggest difference in 2026.

This is the biggest change so far. Users now sign up with email, Google, or Apple. Behind the scenes, a wallet gets created for them. Most users never even notice it. As a result, the app feels normal. And being normal is exactly the goal.

Now,your account abstraction turns wallets into smart accounts. Standards like ERC-4337 and EIP-7702 make this possible. For designers, it opens a lot of doors.

For example, apps can now pay gas fees for users. They can also group several actions into one click. On top of that, they can add spending limits and recovery options.


馃搮 Published Date: Sun, 25 Oct 2026 10:23:59 +0000
馃敆 Original Source: Read on original site

Saturday, October 24, 2026

thumbnail

I found an interesting shift: from C2C physical trading to A2A AI capability trading**

I found an interesting shift: from C2C physical trading to A2A AI capability trading**

We’re all familiar with C2C secondhand platforms like Mercari, Vinted, and Carousell. These platforms are designed for humans trading physical goods. Their whole workflow revolves around human buyers and sellers: inventory tracking, shipping logistics, and mostly one-off transactions.

What if agents themselves could discover, purchase, and invoke reusable skills automatically? We’re talking about MCP tools, parsers, workflow modules, dispatch logic — building blocks an agent can call on demand. Instead of a one-time purchase, creators get paid per API invocation.

I also ran across the idea of AEO, Agent Engine Optimization. Where SEO optimizes content to be found by human searchers, AEO focuses on machine-readable metadata. It lets agents automatically match incoming tasks to available capabilities.

This feels like an entirely new marketplace paradigm, separate from the physical, human-first trading model we’re used to.

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.

For further actions, you may consider blocking this person and/or reporting abuse


馃搮 Published Date: Sat, 24 Oct 2026 11:33:03 +0000
馃敆 Original Source: Read on original site

thumbnail

Ukraine Faces Critical Gap as Starlink Service Disrupts

Ukraine Faces Critical Gap as Starlink Service Disrupts

Posted on Oct 24 • Originally published at codekhabar.com

Elon Musk’s Starlink satellite service has been a linchpin for Ukraine’s resistance against Russia’s invasion, providing high‑speed internet for civilian use and military operations. Recent, unannounced outages have forced Ukrainian officials and European partners to confront the prospect of operating without the network.

Starlink terminals, compact enough for vehicles and field units, have enabled remote control of drones for air‑defense and strike missions. The head of hardware R&D at Ukrainian defense firm BlueBird Tech said the service offers “some of the best satellite coverage available, with virtually no competitors when you consider the combination of cost, availability, and ease of use.”

The primary technical limitation is antenna positioning to maintain a line‑of‑sight with the satellites. Musk’s political actions have increasingly affected service reliability, creating uncertainty for Ukraine’s communications backbone.

With Starlink’s reliability in question, Ukraine and Europe must explore alternative satellite providers or ground‑based solutions to sustain critical links. The urgency underscores how dependent modern conflict has become on commercial satellite constellations.

Starlink’s disruptions expose a strategic vulnerability for Ukraine, prompting a swift search for backup communications. The episode highlights the growing intertwining of private satellite networks with national security.


馃搮 Published Date: Sat, 24 Oct 2026 10:19:45 +0000
馃敆 Original Source: Read on original site

Friday, October 23, 2026

thumbnail

nightporter: I stopped reading my inbox, so a 0.5B model does it while I sleep

nightporter: I stopped reading my inbox, so a 0.5B model does it while I sleep

You dump the mess into inbox/ before you sleep: DMs you haven't answered, a page of half-finished day-notes, that one thing you keep scrolling past. You run one command (or let cron do it, which is the point). You wake up to morning.md: two lines. The full one-liners land in ledger.md, dated. The originals move to done/, unread, exactly as you left them.

The model does the reading so you don't have to. Under the hood: llama.cpp and Qwen2.5-0.5B (Q4_K_M), running on your own CPU. No API key, no account, no bill, no internet connection after setup.

This week's theme is Slow and Steady: build something that does the work so you don't have to. This is the most literal version of that I could manage. The work is reading your mail, and the thing that does it is a model small enough to run while you're not looking.

That run took 15.0 seconds (timed with time ./nightporter.sh) on a single CPU core, while the rest of the machine did other things. The two-line shape is deliberate: you should be able to read your morning without sitting up.

The whole thing is ~90 lines of bash. Repo: github.com/nox-75/nightporter. The script is embedded in full below, so the post stands on its own.

The harness is plain bash. No framework, no daemon, no config file. Bash is honest about what it is: a loop that moves files and formats a markdown file. Anything I didn't need, I left out. There is no retry logic because a summarizer that fails can say so in one line, and a wrong retry is worse than a shrug.


馃搮 Published Date: Fri, 23 Oct 2026 17:50:49 +0000
馃敆 Original Source: Read on original site

thumbnail

Mitigaci贸n de Incidentes por Caducidad de Secretos en Ecosistemas MACH: Rotaci贸n Cero-Downtime con cert-manager y Vault

Mitigaci贸n de Incidentes por Caducidad de Secretos en Ecosistemas MACH: Rotaci贸n Cero-Downtime con cert-manager y Vault

Posted on Oct 23 • Originally published at mach-playbook.github.io

El pasado trimestre, una plataforma global de comercio composable sufri贸 una interrupci贸n de 42 minutos en su capa de API Gateways. El origen no fue una ca铆da de base de datos ni un ataque volum茅trico de denegaci贸n de servicio, sino un certificado TLS autofirmado que expir贸 silenciosamente en un cl煤ster de Kubernetes perif茅rico. A pesar de contar con herramientas de monitoreo, los equipos de operaciones depend铆an de scripts manuales y notificaciones est谩ticas por correo electr贸nico para renovar las claves criptogr谩ficas. En una arquitectura MACH compuesta por cientos de microservicios distribuidos que intercambian millones de peticiones diarias mediante mTLS, la gesti贸n est谩tica de secretos es una bomba de tiempo operativa. La dependencia de procesos humanos para rotar certificados y llaves de cifrado en reposo viola de forma directa los principios fundamentales de una postura de seguridad Zero Trust.

Para erradicar este vector de fallo en Operaciones de D铆a 2, la industria exige un desacoplamiento estricto entre el ciclo de vida de la infraestructura de c贸mputo y el aprovisionamiento criptogr谩fico. La integraci贸n nativa entre cert-manager y HashiCorp Vault dentro de cl煤steres Kubernetes bajo una arquitectura cloud-native permite automatizar la emisi贸n, validaci贸n y rotaci贸n de certificados x509 y secretos sim茅tricos sin intervenci贸n humana ni tiempo de inactividad en los servicios de borde.

Implementar una cadena de confianza automatizada en un entorno multi-tenant requiere coordinar identidades de carga de trabajo, emisores de autoridad certificadora (CA) y controladores de sincronizaci贸n de secretos en tiempo real. HashiCorp Vault act煤a como la Autoridad Certificadora Ra铆z e Intermedia centralizada, mientras que cert-manager opera como el agente orquestador dentro del plano de control de Kubernetes, reconciliando continuamente el estado deseado de los recursos Certificate con el estado real en los backends criptogr谩ficos.

El siguiente diagrama detalla el flujo de trabajo de emisi贸n, validaci贸n y rotaci贸n autom谩tica de certificados TLS y claves de cifrado, utilizando autenticaci贸n basada en tokens de servicio (ServiceAccount Token Volume Projection) para evitar credenciales est谩ticas en disco.

Para conectar cert-manager con el motor PKI de Vault utilizando autenticaci贸n segura basada en tokens JWT proyectados, se debe configurar un recurso ClusterIssuer. Este enfoque elimina la necesidad de almacenar tokens de acceso est谩ticos en los secretos de Kubernetes.


馃搮 Published Date: Fri, 23 Oct 2026 17:47:04 +0000
馃敆 Original Source: Read on original site

Sunday, October 18, 2026

thumbnail

My coding agent kept searching the same repo again and again, so I gave it a memory

My coding agent kept searching the same repo again and again, so I gave it a memory

Posted on Oct 18 • AI-assisted

I gave it a small bug in a CLI library. Before it touched anything, it made 32 tool calls. grep, sed, cat, grep again. That one run used 1,052,132 input tokens. For a tiny fix.

So I went and counted my own sessions. 83 sessions, 32,713 tool calls. 31% of them were the agent just searching. The median was 24 searches before the first edit. And 44% of the time it opened a file, it had already read that file in the same session.

That's what I built Engram for, in the Graph Hacks hackathon (WeMakeDevs × FalkorDB).

Then, before the agent makes its first tool call, it gets a short map. Around 200 tokens. Just where to look.

This is the real map it gave Claude Code for one click bug ("click.Choice(["Apple", "Banana"], case_sensitive=False) rejects apple"):


������ Published Date: Sun, 18 Oct 2026 11:11:26 +0000
������ Original Source: Read on original site

Thursday, October 23, 2025

thumbnail

Linux protection from ARP attacks

 Of course. Protecting yourself from NetCut (or any ARP spoofing/p poisoning attack) on Linux Mint is absolutely possible. Linux has excellent built-in tools and methods to defend against this.



NetCut works by exploiting the **ARP (Address Resolution Protocol)**, which is the method devices on a local network use to find each other's MAC addresses. NetCut sends fake ARP messages, tricking your computer into sending its traffic to the attacker's machine instead of the real router (gateway).


Here are the most effective ways to protect yourself, from simple to advanced.


---


### Method 1: The Simple & Effective Solution (Static ARP Entry)


This is one of the best and most straightforward defenses. You tell your computer to *never* change the MAC address of your router, no matter what ARP messages it receives.



1.  **Find Your Gateway's IP and MAC Address:**

    *   Open a terminal (`Ctrl+Alt+T`).

    *   Find your router's IP address (the default gateway):

        ```bash

        ip route show default

        ```

    *   Look for the line that says `default via X.X.X.X`. That IP (e.g., `192.168.1.1`) is your gateway.

    *   Now, get the *real* MAC address of your router. Use the `arp` command. First, ping the gateway to make sure it's in your ARP cache:

        ```bash

        ping -c 4 192.168.1.1

        ```

        (Replace `192.168.1.1` with your gateway's IP)

    *   Now, look up the MAC address:

        ```bash

        arp -n 192.168.1.1

        ```

    *   The output will look like this: `Address HWtype HWaddress ...`. Write down the `HWaddress` (e.g., `a1:b2:c3:d4:e5:f6`). This is the correct MAC address.


2.  **Create a Permanent Static ARP Entry:**

    *   We need to add a command to your network startup scripts. The easiest way is to add it to your `/etc/rc.local` file (you might need to create it).

    *   Open the file with root privileges:

        ```bash

        sudo xed /etc/rc.local

        ```

    *   Add the following lines *before* the `exit 0` line (if the file is empty, create it as shown below):

        ```bash

        #!/bin/sh -e

        #

        # rc.local - executed at the end of each multiuser runlevel


        # Create a static ARP entry for the router

        arp -s 192.168.1.1 a1:b2:c3:d4:e5:f6


        exit 0

        ```

    *   **Crucial:** Replace `192.168.1.1` with your gateway's IP and `a1:b2:c3:d4:e5:f6` with your gateway's MAC address.

    *   Save the file and exit the editor.

    *   Make the `/etc/rc.local` file executable:

        ```bash

        sudo chmod +x /etc/rc.local

        ```

    *   **Reboot your computer** or run the `arp` command manually to apply the change immediately:

        ```bash

        sudo arp -s 192.168.1.1 a1:b2:c3:d4:e5:f6

        ```


**What this does:** Your system will now ignore any malicious ARP packets trying to change the router's MAC address. NetCut becomes useless against you.


---


### Method 2: Using a Graphical Tool (ARPWatch)


`arpwatch` is a tool that monitors your network's ARP traffic and can email you when changes are detected. It's more for alerting than preventing, but it's very useful.


1.  **Install ARPWatch:**

    ```bash

    sudo apt update && sudo apt install arpwatch

    ```

2.  It will start automatically and build a database of known MAC/IP pairs. If a new device claims to be your router, it will log the event.

3.  **To check the logs:**

    ```bash

    sudo grep arpwatch /var/log/syslog

    ```


---


### Method 3: Advanced Tool - Using `arpon` (ARP Defender)


`arpon` is a tool designed specifically to prevent ARP poisoning attacks. It acts as a daemon (background service) that protects the local network.


1.  **Install `arpon`.** You might need to enable the Universe repository first.

    ```bash

    sudo apt install arpon

    ```

2.  **Run it in daemon mode:**

    ```bash

    sudo arpon -d -i wlan0

    ```

    (Replace `wlan0` with your network interface name. Find it with `ip a` - it's often `wlan0` for Wi-Fi or `eth0` for Ethernet).

3.  **To make it run automatically at boot** is more complex and involves editing systemd service files, but running the command above will protect your session.


---


### Method 4: Good Practice (The Human Firewall)


*   **Use a VPN:** A good VPN encrypts all your traffic. Even if someone successfully ARP poisons you, they can't *see* your data—it's just encrypted gibberish to them. They can still disconnect you, but they can't spy on you.

*   **Trusted Networks:** Be wary of public Wi-Fi networks (cafes, airports). These are prime targets for such attacks. Use a VPN whenever you're on a public network.

*   **Network-Level Protection:** The best defense is on the router itself. If you own the router, look for a feature called "**ARP Spoofing Protection**," "**Static ARP**," or "**DHCP Snooping**" in its settings. Enabling this will protect every device on your network.


### Summary & Recommendation


For most users on Linux Mint, **Method 1 (Static ARP)** is the perfect solution. It's lightweight, built-in, and extremely effective.


1.  **Do Method 1.** It will completely block NetCut-style attacks.

2.  **Use a VPN** (like ProtonVPN, Mullvad, or others) on any network you don't fully trust. This is a good general security practice.

3.  Consider installing **`arpwatch` (Method 2)** if you want to be alerted to any suspicious activity on your network.


By implementing even just the first method, you have already made yourself virtually immune to NetCut on your Linux Mint system.


About