标签：#net

Meta recently open-sourced Brain2Qwerty v2, a noninvasive Brain–Computer Interface (BCI) that can decode sentences from thoughts using electroencephalography (EEG) or magnetoencephalography (MEG) signals from the brain. In evaluations, the system achieved a word accuracy rate 61% on average, compared to 8% for other non-invasive methods. By Anthony Alford

Native XDP and generic SKB-mode XDP are not the same thing in practice. The same BPF program can pass the verifier and still behave differently depending on which mode the kernel uses, this could be a different verdict, different frame bytes, or different metadata. This post ships three things: an open differential test harness, a fixed eleven-packet corpus, and a simple way to classify the differences it finds. A tagged release lets anyone reproduce the virtio/veth baseline on Linux 6.8. The operational risk is straightforward. A firewall or rate-limiter validated only under native XDP can fall back to generic mode on an unsupported driver, a veth port, or after a reload. You keep the same bytecode, but behaviour can change, often without a clear error line. What this release includes: A harness loop: corpus → inject on the RX path → native vs generic sweep → xdpdump capture → compare.py manifest, comparing both the captured frame bytes and the XDP verdict ( PASS / DROP / TX / REDIRECT ). A deterministic corpus with eleven embedded test IDs ( 0xA001 – 0xA005 , 0xA007 – 0xA00C ; 0xA006 is intentionally omitted as a reserved gap in the generator). An operational divergence taxonomy (Class A / B / C). A virtio/veth smoke gate on Linux 6.8; now gating on frame bytes and verdict agreement that shows the full path is reproducible end to end. Scope for this post: native vs generic XDP on the virtio_vm profile only (five BPF programs, pinned manifests). This is part 1 of 2; it establishes the harness and an instrument-validity baseline; a follow-up post covers bare-metal divergence results. Physical NIC results are not part of this baseline. Ordinary conformance checks stop at “did the program load?” Differential testing asks a sharper question: given identical input packets, do the backends produce the same observable outcome at the hook? Background: native vs generic XDP Both modes load the same BPF object. They diverge at the hook point and in how the packet is represen

With residential proxies all the rage, CISA urges router users to be vigilant.

I released php-quic 1.0.0, a PHP extension that gives you raw QUIC transport with first-class access to streams. It links against the same OpenSSL that PHP already links against, and that is the whole trick. Why This Was Awkward Before QUIC is not a protocol you bolt on in userland. It is TLS 1.3, congestion control, loss recovery, and stream multiplexing, all riding on UDP, and all of it has to be right before you can send a single useful byte. You could get there from PHP if you were willing to bind to a foreign QUIC library like ngtcp2 or quiche through FFI. That works, but now your PHP app carries a second TLS stack, a second set of CVEs to track, a build story that involves Rust, and a version matrix that has nothing to do with the one your distro maintains. For a language whose entire deployment story is "the package manager handles it," that is a lot of rope. What Changed OpenSSL 3.5 shipped a native QUIC stack. Client and server, in the library PHP is already built against. That reframes the problem. The extension is no longer "embed a QUIC implementation into PHP." It is "expose the QUIC that is already sitting there." No new TLS stack, no FFI layer, no Rust toolchain in your build. If your OpenSSL is patched, your QUIC is patched. The requirements fall out of that directly: PHP 8.4 or newer (8.5 on Windows), NTS or ZTS OpenSSL 3.5.0 or newer, built with QUIC support Transport, Not HTTP/3 The thing I most wanted to avoid was shipping an HTTP/3 client and calling it a QUIC library. QUIC is a transport. HTTP/3 is one protocol that runs on it, and it is not the interesting one for everybody. DNS-over-QUIC runs on it. So does anything you want to invent that needs multiplexed, ordered, loss-recovered streams without head-of-line blocking across them. So php-quic hands you connections and streams, and stays out of the framing business. If you want HTTP/3, you build HEADERS frames and QPACK on top of it, and the README has a worked example. If you want something

Chipset makers and router manufacturers are talking about Wi-Fi 8, but what is the new standard, and when will it arrive?

The creator of TV Time is building a successor app that will let users import their watch histories and preserve the community that formed around discussing their favorite shows.

If you have ever logged into a corporate computer, searched for a colleague in your company’s email directory, or used a single set of credentials to access dozens of different internal applications, you have likely interacted with LDAP . Standing for Lightweight Directory Access Protocol , LDAP is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an IP network. In simpler terms, it is the underlying language that allows different systems and applications to communicate with a central directory to find information about users, devices, and permissions. Think of LDAP as a highly organized, digital phonebook. When an application needs to know if "John Doe" is a valid user and what his password is, it uses LDAP to ask the phonebook. How LDAP Organizes Data Unlike traditional relational databases (like SQL) that store data in tables, LDAP stores data in a hierarchical, tree-like structure known as the Directory Information Tree (DIT) . This makes it incredibly fast at reading and searching for information, which is exactly what an authentication system needs to do millions of times a day. Here are the core components of this structure: Root: The top level of the directory tree, usually representing the organization (e.g., dc=example, dc=com ). Branches (Organizational Units - OU): Categories or departments within the organization (e.g., ou=Marketing , ou=Servers ). Leaves (Entries): The actual objects being stored, such as a specific user, printer, or computer. Attributes: The specific pieces of data tied to an entry. For a user entry, attributes might include givenName (first name), mail (email address), and userPassword . Every entry in an LDAP directory has a unique identifier called a Distinguished Name (DN) . It acts like an absolute file path. For example, John Doe’s DN might look like this: cn=John Doe, ou=Marketing, dc=example, dc=com How Applications Talk to LDAP When an

Python is an excellent language for automating cloud infrastructure, but the official Kubernetes Python client leaves developers with an important architectural decision: Where should Kubernetes manifests live? Should they be constructed directly with Python objects? Embedded as multiline strings? Or stored as external files and rendered at runtime? Each approach works, but they have very different implications for readability, maintainability, and long-term operational cost. The key is recognizing that deployment logic and platform configuration evolve on different lifecycles. Your deployment code, the part that authenticates to Kubernetes, renders templates, and applies resources, may remain unchanged for months. Your manifests, however, often change weekly as applications evolve, resource limits are tuned, cloud-provider annotations are added, or networking requirements change. When those two concerns are tightly coupled, even a configuration, only change forces you to modify, test, and redeploy the delivery or application code itself. Over time, this increases maintenance costs, slows platform changes, and makes configuration drift and production mistakes more likely. This is a familiar software engineering principle: separate concerns that evolve independently. The same thinking that keeps application configuration separate from executable code also applies to Kubernetes manifests. Treating manifests as first-class configuration artifacts allows them to evolve independently from the Python code that delivers them. In this article we'll compare three ways of deploying Kubernetes resources with the official kubernetes-python-client , ranging from tightly coupled implementations to a design that cleanly separates deployment logic from platform configuration. The Landscape at a Glance The comparison below assumes a common application deployment scenario, where the desired state is largely known ahead of time. Controllers and Operators have fundamentally different r

This is Part 1 of a 5-part series on Cisco EEM. We start here with the fundamentals and a few working applets, then build toward self-healing networks, automated diagnostics, compliance guardrails, and a complete real-world deployment. Ask ten network engineers what they use EEM for, and nine will say the same thing: "Oh, I have an applet that auto-recovers err-disabled ports." Then they never touch it again. That's a shame, because Embedded Event Manager is one of the most capable tools already sitting inside every Cisco IOS device you own — and almost nobody uses more than 1% of it. It's a full automation engine that lives on the box . No external server. No API gateway. No orchestration platform. Just the router or switch, watching itself, ready to react the instant something happens — even if the WAN is cut, the NMS is down, and it's three in the morning. This series is about using that other 99%. By the end you'll have a toolkit of applets you can deploy and, more importantly, a way of thinking about on-box automation. But we start at the foundation: what EEM actually is, how it's put together, and why "on the box" is a bigger deal than it sounds. What EEM actually is Embedded Event Manager is an event-driven automation framework built into Cisco IOS, IOS-XE, and NX-OS. Strip away the jargon and it's a very simple idea: When something happens, do something about it — automatically, on the device itself. That "something happens" is an event . That "do something" is one or more actions . Bundle an event with its actions and you have an applet — the basic unit of EEM. That's the whole model. The power comes from how many different things can be an event , and how much an action can do. Events EEM can watch for include: A syslog message matching a pattern (an interface flapping, an HSRP state change, a config being saved). An SNMP OID crossing a threshold (CPU over 85%, a power supply going absent, temperature rising). A CLI command being entered (someone typing wr

It's unclear how the planet avoided its star's bloated red giant stage.

I built CreditMeter, a small Windows tray app that shows GitHub Copilot AI-credit usage like a taxi meter. Why I built it Agentic coding makes AI usage feel invisible until you look at the bill. Constraints no WinForms no WPF no backend no telemetry no dependency-heavy architecture Tech stack C# / .NET 9 Native AOT raw Win32 / PInvoke GitHub REST API DPAPI for local PAT storage What I learned For tiny tools, architecture is also about knowing what not to add. Repo https://github.com/cdilorenzo/CreditMeter

Modern applications, especially AI agents and distributed systems, need more than logs to understand what is happening. That's why I explored SigNoz, an open-source observability platform built on OpenTelemetry. Setting up SigNoz with Docker was simple. After connecting a sample application, I could view logs, metrics, and traces from a single dashboard within minutes. My favorite feature is distributed tracing. Instead of guessing where requests slow down or fail, SigNoz clearly shows the complete request journey across services, making debugging much easier. The built-in dashboards provide valuable insights into CPU usage, memory, request latency, throughput, and error rates. Having centralized logs alongside metrics and traces saves time by eliminating the need to switch between multiple tools. I also liked the alerting feature, which helps detect issues before they affect users. For AI applications, observability is essential. AI agents make multiple API calls, use tools, and perform complex workflows. SigNoz makes it easier to understand each step, identify failures, measure latency, and optimize performance. Overall, my experience with SigNoz was excellent. It combines logs, metrics, traces, dashboards, and alerts into one intuitive platform. Among all its features, distributed tracing impressed me the most because it provides deep visibility into application behavior and simplifies troubleshooting. I'm excited to use SigNoz in future AI and cloud-native projects.

The status of the controller As of March 2026, the Kubernetes SIG Network stopped maintaining ingress-nginx. That is the controller a lot of clusters have been running for years. A CNCF blog post published July 9 walks operators through the state of play. The headline for anyone still on it is short: unpatched CVEs, and no more feature work. The post names two operational risks explicitly. New security issues will not receive upstream fixes. Feature updates and community support have stopped. If your ingress plane is a piece of infrastructure you have not touched in a while, this is the reason to pull it up in this quarter's planning doc. What it means at 3am An ingress controller sits between the internet and your services. When it drops a request, you find out from your users. When it takes a CVE and no one is patching, you find out from a scanner or from a report. Neither is a good discovery path. The controller also carries the exact set of annotations, TLS defaults and rewrite rules your workloads rely on. Nothing about a retirement changes the version you have in production today, so the immediate blast radius is zero. The risk is on the calendar, not on the pager. That is the kind of risk teams reliably defer until a scanner flags an unpatched CVE. The two paths CNCF lays out The post frames the choice as a fork. Path A is a lateral swap to another Ingress controller. The example named is Contour, described in the post as Envoy-based. This keeps you on the Ingress API and mostly moves the problem of who is patching. Path B is modernization to the Gateway API, described in the post as the upstream-backed successor to Ingress. The CNCF post points at ingress2gateway to automate the translation, and recommends an incremental rollout: run the new plane in parallel and move non-critical workloads first. The stopgap version is a mix. Adopt Contour to buy time on maintained code, then schedule the Gateway API move on your own calendar rather than under duress. What

Quando voce cria um container e depois outro, eles podem nao se enxergar. O motivo quase sempre e a rede. Entender os tipos de rede que o Docker oferece resolve isso de uma vez. Comece listando as redes que ja existem no seu Docker. docker network ls A rede bridge e a rede host vem de fabrica. Nenhuma delas oferece resolucao de nomes entre containers. Para isso voce precisa criar a sua propria rede. docker network create minha-rede Agora os containers que entrarem nessa rede conseguem se comunicar pelo nome do container. docker run -d --name app1 --network minha-rede nginx docker run -d --name app2 --network minha-rede alpine sleep 3600 Teste a comunicacao. docker exec app2 ping app1 -c 2 O ping funciona. O DNS interno do Docker resolve app1 para o IP interno do container. Isso resolve 90% dos problemas de comunicacao. A rede bridge padrao nao tem esse recurso. Crie sua propria rede sempre que precisar que containers se enxerguem. Agora a rede host. Ela elimina o isolamento de rede. O container usa a placa do host diretamente, sem NAT e sem mapeamento de porta. docker run -d --name web-host --network host nginx O nginx fica acessivel em http://localhost:80 direto. Sem -p 80:80. Mas so um container pode usar cada porta, porque a porta e a do host de verdade. Para ambientes com mais de uma maquina, existe a rede overlay. Ela precisa do Docker Swarm ou de um cluster. docker swarm init docker network create -d overlay rede-overlay docker service create --name api --network rede-overlay --replicas 3 nginx Os containers em maquinas diferentes se enxergam pelo nome como se estivessem na mesma maquina. No dia a dia, a rede bridge personalizada resolve quase todo caso de uso. Host e para performance ou casos especificos. Overlay e para quando voce escala para mais de uma maquina. That's all for now. Thanks for reading!

Netflix has shows and movies. And video games. And live sports. And podcasts. And also, apparently, YouTube videos? For a company that used to seem like the next big thing in TV, it all feels a little frenetic, and maybe a tad desperate. For a company that sees sleep as its primary competitor, it might […]

Amid signs of slowing engagement, Netflix is reportedly considering launching "always-on" live channels, giving subscribers something to tune into 24/7.

Non è solo “chiedere aiuto”: è chiarire obiettivi, vincoli e tentativi. E accelera sia l’apprendimento che il lavoro in team. Nel lavoro quotidiano di un frontend developer (e non solo) capita spesso di bloccarsi: un bug che non si riproduce, un layout che “quasi” funziona, una libreria nuova che sembra richiedere di leggere mezzo internet. In quei momenti la differenza tra perdere ore e sbloccarsi rapidamente non è sempre “quanto ne sai”, ma come fai le domande . Fare domande di qualità è una skill professionale a tutti gli effetti: migliora la collaborazione, riduce il ping-pong nei thread, rende più efficaci code review e pair programming, e soprattutto ti allena a ragionare in modo strutturato. Perché fare buone domande è una competenza (non un dettaglio) Una domanda ben formulata ti obbliga a mettere ordine in quattro cose: Cosa stai cercando di ottenere (obiettivo) Cosa non sai (gap di conoscenza) Cosa hai già provato (tentativi e risultati) Che cosa non serve fare adesso (scope e priorità) Questo vale sia quando chiedi aiuto su un problema tecnico, sia quando stai decidendo cosa studiare per crescere. La domanda “cosa devo imparare?” è troppo vaga “Cosa devo imparare?” sembra utile, ma spesso non porta lontano perché manca il contesto: non definisce un obiettivo, non dà vincoli, non permette a chi risponde di proporre un percorso sensato. Una versione migliore parte da: Qual è il risultato che voglio ottenere? Cosa mi avvicina a quel risultato oggi, in modo pragmatico? E c’è un punto ancora più potente: chiedersi anche cosa NON serve imparare . Perché “cosa non devo imparare” ti fa risparmiare tempo Nel frontend c’è sempre una tentazione: allargare lo scope. Esempi tipici: “Per usare React devo prima imparare perfettamente TypeScript, poi i design pattern, poi…” “Per risolvere questo problema di CSS forse devo studiare tutta la specifica di Flexbox e Grid…” Chiederti cosa non è necessario adesso ti aiuta a: scegliere il minimo set di concetti per sbloccarti;

Rosemary: Transparent Network Tunneling Over QUIC (Kernel-Level) Ever SSH into a box and wish you could just use its network without setting up proxy chains or VPNs? Rosemary makes that happen. The server intercepts traffic at the kernel level (no proxy settings, no TUN devices) and tunnels it over encrypted QUIC through a lightweight agent on the remote host. From your laptop, curl , ping , or your browser reach private subnets as if you were there. What you get Kernel-level packet interception, transparent to all your apps TCP, UDP, ICMP, and DNS just work without configuration Route all internet traffic through a chosen agent (egress) SOCKS5 proxies, port forwards, and reverse forwards per agent Multi-hop pivoting through several agents Web dashboard with real-time agent graph Full REST API for automation Works on Linux, Windows, macOS, FreeBSD, and OpenBSD Agents run without root; traffic is AES-256-GCM encrypted over QUIC Quick start # install (requires Go) go install github.com/blue0x1/rosemary/rosemary@latest go install github.com/blue0x1/rosemary/agent@latest # start server (needs sudo for kernel interception) sudo rosemary # deploy agent on remote box ./agent-linux-amd64 -s <server-ip>:2048 -k <your-key> That's it. Open http://server-ip:1024 and you'll see the agent's subnets automatically routed. Set a default egress agent to route all traffic through a jump host: egress agent-1 Now your laptop behaves like it's on the remote network. No proxychains, no ssh -D , no friction. Check the repo blue0x1/rosemary for pre-built binaries, PowerShell agents, and the full API. Use only on systems you own or have permission to test.

While doing a routine hardening pass on an internal Firebase panel — codename PanelControl , a management tool used daily by multiple operators with different roles — what was supposed to be "let's add a few Telegram alerts for suspicious activity" turned into discovering that the app's entire login system was just a UI filter. Anyone who opened the site already had, automatically, a Firebase identity with full read/write access to the database. Here's what happened, and how it got fixed in 5 phases without ever locking the team out mid-shift. The setup PanelControl is a vanilla-JS internal panel backed by Firebase Realtime Database + Firestore. Operators log in with email/password, checked client-side against a database node, with a lockout after failed attempts. Nothing unusual so far. The original ask was narrow: add Telegram notifications for a handful of suspicious events — brute-force attempts, a never-before-seen device for an operator, an unauthorized attempt to reach the Admin section, DevTools opened during use. Pure alerting work. Bug #1: the login button that always unlocks Before writing any alerting logic, a review of the existing Admin-area password check turned up this: // ❌ The "|| true" makes the whole condition always truthy function checkAdminPwd () { if ( el . value || true ) { unlockAdmin (); // runs regardless of what's typed, or nothing at all } } A debug leftover that made it to production. Anyone who landed on the Admin password overlay got in by clicking "Log in" — password or not. Fixed by actually wiring the real permission check, plus a server-side-verified fallback in case the function were ever called directly from the console. The real discovery: a shared, hardcoded Firebase credential Looking at the Realtime Database Rules ahead of the alerting work surfaced something much bigger. The Rules restricted read/write to a single fixed auth.uid — reasonable, until you check who actually gets that uid . This ran unconditionally, for every

Netflix is thinking about adding always-on channels that would stream specific shows and movies, according to The Wall Street Journal. The move sounds like a Netflix version of always-on services like Pluto TV and Tubi, except the big hook for those is that they're free - because of the ads you have to watch. Netflix […]