标签：#war

Originally published on hexisteme notes . A status column in one of my agent fleet's ledgers said 30 items were queued to publish. A working session that day stated a backlog close to a month at the fleet's normal rate and deferred the work that keeps posts flowing into the queue. At that moment the ledger showed the same backlog. That exact numeric match suggests — but does not prove — that the ledger informed the decision. The real number of items actually waiting was 6. At one post published per day, that is six days of runway, against a low-water alarm configured to fire at 3. The gap came from a status value that was never advanced after publication, not from the queue-file count itself. A column just quietly stopped meaning what everyone assumed it meant, and by the time it mattered, it had been wrong for a while. The pipeline, briefly The fleet runs a small publishing pipeline: a draft gets written, a promotion step validates it and drops a file into a queue directory, and a scheduled job runs once a day, picks the oldest file in that directory, publishes it, moves the file into a published folder, and appends one line to a log. Alongside the queue directory sits a separate ledger: a flat TSV file, one row per item, with a status column meant to track where each item sits in its life — staged, queued, published. Two different things track the same concept: the files actually sitting in the queue directory, and a column in a table that is supposed to describe them. Where it broke Exactly one piece of code writes status=queued : the promotion step, at the moment an item enters the queue. Nothing else ever changes that value afterward. The daily publish job moves the file and writes to the log; it never opens the ledger. Nobody had assigned any code the job of setting the status forward to published . So queued stopped meaning "currently waiting." It came to mean "was queued at some point," which, once true, is true forever. Every item that had ever passed throu

Will AI replace software engineers? No. As a staff software engineer who works with AI extensively, I can say that the fear a lot of people have is valid and understandable, but total replacement is not going to happen. Why? Software engineering requires decisions. Architecture, tech stack, workflow design, and many others. AI does not understand how to make those decisions, it was not designed for that, and it is not heading in that direction. Artificial intelligence is a tool designed to improve the productivity of humans, including but not limited to software engineering, and in that realm it is the biggest jump in day to day productivity I have seen in my career. It has increased the output of software engineering by orders of magnitude, and that is what makes it so good. It is also why some people think it might replace software engineers. Large language models, with access to the right tools and when they run in loops, are very strong and very good at improving the productivity of software engineers. They also help engineers improve the quality of their decisions. Even with the best AI models out there, and with unlimited tokens, if you instruct one to implement a product, and I am emphasizing the word product here, not just a feature, it will get it done with the happy paths only, the absolute bare bones proof of concept. It does not know how to complete the product end to end, it does not know how to integrate it into the real world, and it certainly does not know how to architect and design the flow or how to make decisions. At best it can guess, and those guesses will always fall short of what a human can do. That is why I believe software engineers will not be replaced by AI. AI is a tool, and a tool replaces parts of a job. It makes the work faster, more accurate, better documented, but it is not a total replacement.

Lessons from building a small VPN service around standard WireGuard clients instead of a proprietary app When you look at a commercial VPN product, the app seems to be the product: a polished interface, a country list, and a large Connect button. I chose the opposite approach. Instead of building another VPN client, I decided to give users a standard WireGuard configuration that they could import into an existing client. That decision removed a lot of client-side work — but it also exposed where the real complexity of a VPN service actually lives. Why build another app if WireGuard already has one? The usual commercial VPN flow is straightforward: install the vendor's app, sign in, choose a location, and connect. A proprietary client can manage server selection, subscriptions, kill switches, automatic reconnects, diagnostics, updates, and support in one place. But for a small service with one or a few locations, I had to ask a more basic question: do I really need to build and maintain a separate Windows, macOS, Android, and iOS client just to establish a WireGuard tunnel? WireGuard already has mature clients across the major desktop and mobile platforms. A user can import a configuration file or scan a QR code and get a normal VPN toggle. On paper, that looked like a very attractive tradeoff: less client code, fewer update mechanisms, fewer installers, and a smaller attack surface to maintain. What I underestimated was that the app was never going to be the hardest part. A .conf file is not just a settings file The first architectural lesson was simple but important: a WireGuard configuration is effectively a credential. It contains the client's private key. A QR code that represents the same configuration contains the same sensitive material in another form. That immediately creates product problems that have nothing to do with the tunnel itself. How do you show the configuration safely? What happens if the user loses it? Can you issue a replacement without leavin

System Design is the process of planning how a software system should work before building it. Think about constructing a large building. Before workers start putting up walls, architects decide where the rooms, elevators, electricity, water systems, emergency exits, and entrances should go. Software works in a similar way. When developers build applications such as Amazon, Instagram, Netflix, Uber, or WhatsApp, they cannot simply start writing code and hope everything works. They first need to decide how millions of users, servers, databases, files, and requests will work together. A simple way to remember it is: System Design = The blueprint of a software system. What Do We Decide in System Design? During system design, engineers make decisions about things such as: How users connect to the application Where information is stored How different parts of the application communicate How images and videos are stored How the system handles millions of users How the application stays fast How failures are handled How user information stays secure For example, imagine designing WhatsApp. A user sends a message. That message must travel to WhatsApp's servers, reach the correct person, possibly be stored temporarily, appear on multiple devices, and trigger a notification. If millions of people send messages at the same time, the system must continue working without becoming extremely slow or crashing. That planning is system design. Why Does System Design Matter? A good software system should be: Fast Reliable Secure Scalable Affordable to operate Easy to maintain Imagine Instagram without good system design. Millions of users might open the application at the same time. Servers could become overloaded, photos might take several seconds to load, comments could disappear, and the application might frequently crash. System design helps engineers prepare for these situations before they become major problems. System Design in Software Interviews System design is also common i

Remember when "AI coding" just meant inline tab-completion suggesting a for loop in VS Code? Those were simpler times. 😅 Fast forward to this week, and we’ve officially crossed the threshold into the Autonomous Multi-Agent Era . The industry is shifting away from single-turn autocomplete prompts toward async, parallelized agentic workflows that inspect, plan, write, test, and validate code across entire repositories. Three major developments dropped almost simultaneously: ⚡ Meta launched Muse Code (powered by Muse Spark 1.2) in beta, introducing parallel sub-agent execution. ☁️ AWS added an Agentic Workspace to Kiro , enabling async background task delegation for developers. 🎓 New Academic Research surfaced on how AI coding agents leverage structured "Agent Plans" for full-lifecycle repo maintenance, design, construction, testing, and validation. Let's break down why this is a massive engineering paradigm shift and what it actually means for our daily developer workflows. 🧬 1. Meta Muse Code & Parallel Sub-Agent Swarms Meta’s latest drop— Muse Code , driven by their Muse Spark 1.2 model—takes aim at one of the biggest bottlenecks in single-agent LLM systems: context dilution and linear execution delays . When you ask a traditional LLM to refactor a complex microservice, it processes everything sequentially. It reads your files, thinks, writes code, tries to debug, and eventually runs out of context space or hits token output limits. How Parallel Sub-Agent Execution Changes the Game Muse Code doesn't just run one linear chat session. Instead, a primary orchestrator agent decomposes a high-level goal into specialized sub-agents running concurrently: ┌──────────────────────────────┐ │ PRIMARY ORCHESTRATOR AGENT │ └──────────────┬───────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ SUB-AGENT A │ │ SUB-AGENT B │ │ SUB-AGENT C │ │ AST Parsing & │ │ Unit Test Suite │ │ Static Analysis

While the device is pretty and lightweight, it’s not something the everyday person needs due to its hefty price tag and size.

Introdução A Programação Orientada a Objetos nasceu com a linguagem Simula 67 , considerada a primeira linguagem orientada a objetos, e foi consolidada e popularizada por Smalltalk nos anos 1970. Ganhou adoção massiva na indústria com C++ e, posteriormente, Java e C#. A ideia central é organizar o código em torno de objetos : unidades que combinam dados (atributos/estado) e comportamento (métodos) em uma única estrutura. Os quatro pilares Encapsulamento — os dados internos de um objeto são protegidos e só podem ser acessados/alterados através de métodos expostos, escondendo detalhes de implementação do mundo externo. Abstração — o objeto expõe apenas o que é relevante para quem o utiliza, escondendo a complexidade interna (ex.: você chama CalcularSalario() sem precisar saber como o cálculo é feito por dentro). Herança — uma classe pode herdar atributos e métodos de outra, permitindo reaproveitamento e especialização (uma classe Desenvolvedor pode herdar de Funcionario ). Polimorfismo — objetos de classes diferentes podem responder de forma diferente ao mesmo "chamado" (o mesmo método CalcularSalario() se comporta de forma distinta para um Desenvolvedor e para um Gerente , por exemplo). Exemplo // Exemplo de Programação Orientada a Objetos em C# public abstract class Funcionario { public string Nome { get ; } protected decimal SalarioBase { get ; } protected Funcionario ( string nome , decimal salarioBase ) { Nome = nome ; SalarioBase = salarioBase ; } // Abstração: cada subclasse decide como calcular seu próprio salário public abstract decimal CalcularSalario (); } public class Desenvolvedor : Funcionario { private int BonusPorProjeto { get ; } public Desenvolvedor ( string nome , decimal salarioBase , int bonusPorProjeto ) : base ( nome , salarioBase ) // Herança { BonusPorProjeto = bonusPorProjeto ; } // Polimorfismo: implementação específica do método herdado public override decimal CalcularSalario () { return SalarioBase + BonusPorProjeto ; } } public class Gere

Introdução A Programação Funcional tem raízes no cálculo lambda , formalizado pelo matemático Alonzo Church nos anos 1930, décadas antes da existência de computadores modernos. Sua primeira grande expressão em linguagem de programação foi o Lisp (1958), e o paradigma ganhou força prática com linguagens como Haskell, Erlang, F# e, mais recentemente, com a incorporação de recursos funcionais em linguagens multiparadigma como JavaScript, C# e Python. Princípios centrais Funções puras — dado o mesmo input, uma função pura sempre retorna o mesmo output, sem produzir efeitos colaterais (não altera variáveis externas, não grava em disco, não modifica o argumento recebido). Imutabilidade — os dados não são alterados após criados; em vez de modificar uma estrutura existente, cria-se uma nova versão com a alteração aplicada. Funções de primeira classe / funções de alta ordem — funções podem ser tratadas como qualquer outro valor: armazenadas em variáveis, passadas como argumento e retornadas por outras funções. Composição de funções — programas são construídos combinando funções pequenas em pipelines ( map , filter , reduce são os exemplos mais comuns no dia a dia). Recursão no lugar de laços mutáveis, já que, sem estado mutável, for / while tradicionais perdem o sentido em sua forma pura. Como não há estado compartilhado sendo alterado por múltiplas partes do código, o raciocínio sobre o comportamento do programa fica mais previsível — e a paralelização se torna muito mais segura, já que não existe o risco clássico de condições de corrida sobre uma mesma variável mutável. Exemplo // Exemplo de Programação Funcional em TypeScript type Produto = { nome : string ; preco : number }; const produtos : Produto [] = [ { nome : "Notebook" , preco : 3000 }, { nome : "Mouse" , preco : 50 }, { nome : "Teclado" , preco : 150 }, ]; // Função de alta ordem que retorna outra função (currying) const aplicarDesconto = ( percentual : number ) => ( preco : number ) => preco * ( 1 - percentual )

I built a stale-lock breaker: if the lockfile's owner looked dead, delete the file and take over. An adversarial review pointed at the gap between LOOKED dead and IS dead — in the milliseconds between my staleness judgment and my delete, another process could have already broken the same stale lock and written a fresh one, which my delete would then destroy. Two owners, both convinced they won. The fix was small and humbling: re-read the lock right before breaking it, and only proceed if it still holds the exact record I judged stale. Every check-then-act on shared state has a gap in the middle, and the gap doesn't care how fast your code is. Re-validate at the moment of the irreversible act, not just before it.

Why “it encrypts” doesn't equate to “it’s secure” If you want to find a tutorial for encrypting files in code, your search results will provide dozens of tutorials. Most of these tutorials will produce code that, on the surface, performs encryption. Users can provide plaintext, receive ciphertext, and the code also performs decryption. Unfortunately, the phrase “the output looks scrambled” is an unsecure way to test a program for security. These tutorials fail to incorporate security practices, which will result in these tools being rejected in real life security assessments. By identifying these mistakes, we can reason about the validity of these encryption schemes. This article covers the correct way to build a file encryption tool and the mistakes that beginner encryption tools include. These mistakes will help you learn the correct way to build an encryption tool. SecureVault (Node.js, packaged with no dependencies) is a command-line tool that is referenced throughout to help provide context to the design decisions that were made for this tool. Prerequisite mindset: When designing secure systems, always assume that the attacker knows more than you. Do you really think that your adversary will only submit the inputs you assumed they would submit? They will submit corrupted inputs, they will submit old ciphertexts, and they will do anything you thought was impossible. You need to have a secure design. You must think "what malicious inputs can I handle here?" . The goal: three guarantees, not one Before you even think about writing code, you need to know exactly what you mean by that something is secure. A good file encryption tool must provide three guarantees. Most of the tutorials that I have seen think only about the first one. Confidentiality - the attacker that steals the file should not be able to read the file. Integrity - If the attacker alters the encrypted file, you will know. Authenticity - The file can only be generated by a user that knows the passwor

A new software update builds on WhatsApp’s group chat chops by adding anonymous polls and introducing an easier way to start a smaller private chat away from the larger group.

GitHub consolidated the npm and Actions changes it shipped from March to July 2026 against supply chain attacks, several of which alter defaults rather than add options. Hacker News discussion focused less on the individual controls than on whether waiting periods are the right instrument, or a substitute for author-side package signing. By Steef-Jan Wiggers

Klikk her: LLM Price Watch started as a simple problem: comparing per-token pricing across Claude, GPT, Gemini, DeepSeek, and Grok meant opening five pricing pages and doing the math by hand every time a new model dropped. So I built a calculator. Then I built an API behind it. Then I noticed something about who was actually going to call that API. The obvious version The first version of the API was exactly what you'd expect: GET /v1/models — every tracked model with current pricing GET /v1/models/:id — a single model GET /v1/calculate?model=X&input_tokens=N&output_tokens=N — cost for a specific call Straightforward. A human developer hits /calculate , gets a number, builds their cost estimate into a dashboard somewhere. Done. The part that changed the design The actual differentiator turned out to be a fourth endpoint: GET /v1/recommend?use_case=X . Instead of just returning prices, it returns a recommendation — which model fits a given use case (long-document summarization, high-volume classification, coding assistance, customer support) based on both price and the editorial analysis already written for the comparison pages on the site. Once that endpoint existed, the actual audience for this API stopped being "a developer building a cost dashboard" and started including something else: AI agents doing their own tool selection at runtime. An agent framework deciding which model to route a task to doesn't want to read a blog post — it wants a structured answer to "given this use case, what should I use, and what will it cost me." That's a tool call, not a page view. That reframing changed a few concrete decisions: CORS is wide open on purpose. This isn't an API with a dashboard in front of it — it's meant to be called directly from wherever the calling code lives, including client-side agent code. No API key required (for now). Every bit of friction between "an agent wants this data" and "an agent gets this data" is friction against the actual use case. A paid tie

So far in this mini-series, we've answered the biggest questions that confuse developers when they first encounter Design Patterns. We've learned: why SOLID isn't the final destination, why recurring design problems exist, why copying code doesn't create good design, what Design Patterns really are, how experienced engineers recognize them, and how every pattern can be understood through its Problem, Intent, Solution, and Consequences . Now it's time to answer one final question before we begin exploring the individual patterns. How should we learn Design Patterns so that we can actually use them in real-world software instead of just recognizing their names? The answer may surprise you. We're not going to learn Design Patterns the way they're usually taught. The Traditional Way of Learning Design Patterns Open almost any Design Patterns book or tutorial, and you'll often see something like this. Pattern Name ↓ Definition ↓ UML Diagram ↓ Code Example ↓ Advantages ↓ Disadvantages Technically, there's nothing wrong with this approach. But many developers finish reading the chapter and still wonder: "When would I ever use this?" That's because they learned the solution before understanding the problem. It's like learning how to use a fire extinguisher before understanding what kinds of fires it can safely put out. Knowledge without context is difficult to apply. The Way Experienced Engineers Learn Experienced engineers don't begin with the pattern. They begin with the software. They observe where the current design starts struggling. Only then do they search for a better design approach. Their thinking looks more like this. Business Requirement ↓ Design Challenge ↓ Current Design Starts Breaking ↓ Understand Why ↓ Explore Better Design ↓ Recognize a Design Pattern The pattern is never the starting point. It's the result of understanding the problem. The Learning Framework We'll Use Every pattern in this series will follow exactly the same structure. Business Problem ↓

Building a personalization engine for a multi-format content feed, without machine learning, and the testing process that forced us to rebuild it. TL;DR We run a collaborative cultural curation platform (think: user-submitted recommendations for movies, books, games, music, and long-form posts, all mixed into one feed) on a fairly ordinary PHP + MySQL stack. Over about a year we went through two full generations of the feed ranking algorithm. The first version solved the obvious problem (stop being purely chronological) but quietly failed at real personalization. The second version fixed that by rethinking what "user taste" even means, moving scoring out of SQL and into application code, and adding a layer of post-ranking business rules. This post walks through both generations, why the second one had to happen, and how we actually tested and calibrated a feed ranking system without a data science team or an ML pipeline. No exact weights, table names, or formulas below — just the engineering story. The starting problem: one feed, five content shapes Before personalization is even on the table, a multi-format feed has a normalization problem. Movies, books, games, music, and editorial posts live in different tables, with different columns, different publishing cadences, and engagement numbers on completely different scales. "1,000 likes" on a music post and "1,000 likes" on a book review are not the same signal. So the very first architectural decision — before any ranking logic existed — was building a unification layer that maps every content type into a shared shape (type, author, title, cover, category, engagement counters, timestamp) before any scoring happens. Everything downstream depends on that layer being consistent. Generation 1: a weighted ranker living inside a single SQL query The first real version of the algorithm — internally we called it the hybrid model — had a modest goal: get away from a purely chronological feed without building anything resembl

The Movinkpad 11 a versatile little graphics tablet that can help make your wildest digital art dreams come true.

19 new maps continue the story from MachineGames' other campaign additions.

The EU AI Act's Article 50 transparency rules went enforceable on August 2, 2026. If you ship a generative AI feature that touches EU users, you now owe the regulator a machine readable marking on your output. The obvious shortcut, drop a C2PA manifest and call it done, does not survive contact with production. Here is what actually works, with the code to make it real. The Two Layer Reality Article 50(2) requires effective, interoperable, robust, and reliable marking. The EU Code of Practice interprets that as at least two layers: signed metadata (C2PA) plus imperceptible watermarking (SynthID or equivalent). Fingerprinting is optional layer three. The reason for two layers is not bureaucratic. It is a screenshot. C2PA lives in a JUMBF metadata box. X strips it on upload. CDNs strip it during optimization. Screenshots destroy it entirely. Microsoft admitted this openly in its February 2026 Media Integrity report: preventing every attack on provenance is not possible. Invisible watermarks embedded in the pixel content survive those operations but carry very little information. You need both. Generating a Signed C2PA Manifest (Node) // npm install c2pa-node import { createC2pa , ManifestBuilder } from ' c2pa-node ' ; import { readFile , writeFile } from ' node:fs/promises ' ; const c2pa = createC2pa (); async function signGeneratedImage ( inputPath , outputPath , generationMeta ) { const asset = { buffer : await readFile ( inputPath ), mimeType : ' image/jpeg ' }; const manifest = new ManifestBuilder ({ claim_generator : ' firesafe/1.0 ' , format : ' image/jpeg ' , title : ' ai-generated-image.jpg ' , assertions : [ { label : ' c2pa.actions ' , data : { actions : [{ action : ' c2pa.created ' , digitalSourceType : ' http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia ' , softwareAgent : generationMeta . modelName , }], }, }, { label : ' com.firesafe.generation ' , data : { model : generationMeta . modelName , modelVersion : generationMeta . modelVer

If you are building anything that touches European business data — onboarding, invoicing, KYB, fraud checks — you will eventually ask the same question I did: which countries can I actually get company data from, for free, without an account? I could not find this written down anywhere, so I worked it out the hard way while building a supplier checker. Here it is. The baseline: VIES The European Commission runs VIES , which validates VAT numbers across all 27 member states plus Northern Ireland ( XI ). It is free, it needs no key, and it is the obvious starting point. Two things about it are worth knowing before you build on it. It answers one question: is this VAT number currently registered. It does not tell you the company is solvent, trading, or that it has not been struck off. A company in liquidation keeps a cleanly resolving VAT number for months, because deregistration and insolvency are run by different authorities on different timetables. Name and address are returned for 25 of the 28 jurisdictions, not all of them. Germany and Spain confirm registration but publish no company name through VIES. I tested three valid numbers for each before accepting that. For those two, a yes/no is genuinely all you can honestly show. Where you can go further, free Ten countries publish enough through a national register to add something meaningful on top of VIES: Country Free register Reports company state Reports VAT-active Romania yes yes yes Poland yes — yes Slovenia yes — yes Estonia yes yes — France yes yes — Greece yes yes — Bulgaria yes yes — Latvia yes yes — Czechia yes — — Finland yes — — Company state means the register tells you whether a business is inactive, in liquidation, bankrupt, insolvent, terminated or struck off. This is the valuable column, and only six countries have it. VAT-active matters more than it sounds. VIES cannot distinguish "this is a real company that is not VAT-registered" from "this number belongs to nobody". Three registers can. Note th

1. Language Architecture in Ghidra When Ghidra loads an architecture (such as the MOS 6502), it parses the .ldefs manifest file, which declares metadata and binds three foundational specification pillars: The .pspec (Processor Specification): Defines the processor’s hardware context. It declares special-purpose registers (e.g., stack pointer SP , status/flags registers), default memory maps (RAM, ROM, I/O), and hardware interrupt vectors. The .cspec (Compiler Specification): Defines the ABI and calling conventions (e.g., parameter passing mechanisms), stack alignment rules, and return value handling. This is the critical building block enabling the decompiler to reconstruct assembly into readable C code. The .sla / .slaspec (SLEIGH Specification): .slaspec : The human-readable source file describing the instruction set architecture (opcodes, instruction formats, and p-code semantics). .sinc (SLEIGH Include): Modular inclusion files (typically used to split complex architectures like ARM or x86, or isolate instruction subsets like Thumb). Given the simplicity of the 6502, everything is defined directly within the .slaspec file. .sla : The compiled binary version of the .slaspec (generated by the Sleigh compiler). Ghidra loads this compiled .sla file into memory at runtime for optimal performance. 2. The Challenges of Reverse Engineering Undocumented Binaries When dealing with a binary compiled for an undocumented processor, Ghidra's default paradigm faces major limitations: The .slaspec file is unavailable. Ghidra attempts to aggressively disassemble everything. Analyzing an undocumented target requires a strict two-phase approach. 3. Missing .slaspec File Without a valid .slaspec definition, Ghidra renders ?? for every opcode. The primary objective when tackling an unknown CPU is precisely to reconstruct this missing .slaspec specification. 4. Overcoming Ghidra's Aggressive Disassembly By default, Ghidra (like most disassemblers) employs an exhaustive strategy (usin