My feed

A Linux gateway began dropping new connections even though CPU usage was low, memory looked healthy, disks were almost idle, and the application itself continued responding normally. The same failure was reproduced twice in a small lab and investigated using two completely different approaches. The first run relied on tools that would have been familiar to a Linux sysadmin in 2008: top, vmstat, dmesg, proc, sysctl, netstat, and tcpdump. The second run started with Prometheus, Grafana, historical metrics, and modern observability. Both approaches eventually reached the same kernel-level problem, but the path to the answer was very different.

A practical method for comparing B2B products by their structure, unique components, and key user scenarios.

If you are planning to design or update a user interface for a B2B product and do not want to appear as an outsider in the eyes of the business, you need to identify the product’s objective complexity — or, more precisely, its functional scale.

This helps you estimate the time and resources required, justify those estimates, and decide which product to work on first when all other conditions are equal.

A PostgreSQL service can keep processing almost the same number of requests per second while its slowest requests become several times worse. CPU may still look comfortable, query execution time may barely move, and throughput may remain almost flat. The problem can appear one layer earlier, inside the connection pool, where requests start waiting before PostgreSQL even sees them. This experiment shows how that happens and why p99 usually notices it long before RPS does.

A small code change can lead to a lot of extra work when a project has broad instructions. You ask Codex to fix a button label, but AGENTS.md tells it to read the database guide, study the deployment process, and run every check three times.

Hi everyone! Today I’d like to talk about another open-source project of mine for building web applications based on Angular.

Over the past few years, I have conducted numerous successful experiments with high-performance web interfaces, which has given me a clear understanding of the structure and architecture for the project discussed below.

So, meet Centrifugal. Check out the project’s official website—there are plenty of cool use cases there!

The project was originally conceived to create a set of high-performance, flexible tools and components for building web applications. However, during one of the development iterations, I decided to add support for creating “all-in-one” interfaces—specifically, a standalone application mode featuring a fully customizable virtual keyboard. This enabled full support for building user interfaces for applications such as self-service kiosks and similar systems.

Researchers and developers are increasingly warning that LLM-based agents exhibit dangerous, unpredictable properties. These properties potentially threaten not just the stability of internet platforms, but humanity as a whole.

Some propose halting model development until policies and tools guaranteeing safe agent behavior are designed and implemented. I believe this might yield some effect, but overall, these efforts will fall short of the expected results.

In this article, I examine anthills, humans, and LLMs to demonstrate exactly when an agent ceases to be merely an agent. The properties developers are trying to guarantee at the individual agent level actually emerge at the level of the "agent plus environment" system, where the individual agent does not dictate the overall trajectory of the system.

For 30 days, the IDE stayed closed after 8 PM. I expected the experiment to affect sleep, but the more interesting result appeared somewhere else: in Git history. The month produced fewer bug-fix commits, shorter debugging sessions, and a surprisingly different defect pattern. So I wrote a couple of scripts, reconstructed where several bugs had actually come from, compared the results with the previous month, and ended up changing the way I think about late-night coding.

A practical task arose: in a confined space (a narrow hallway, stairwell, or vestibule), monitor activity, take a photo of the area, and notify the user by forwarding the photos to Telegram. It is known that a standard household motion sensor, which turns on the lighting, is installed in the monitored area.

What happens if a modern coding AI is allowed to solve new requirements but forbidden from using modern tools? I built a tiny contact database in ANSI C, gave the model a deliberately 1995-style environment, and then kept changing the requirements. No SQL database, no package manager, no JSON library, no framework, no containers and no external dependencies. Twenty changes later, the program was still valid C89, but somewhere along the way it had acquired schema versions, migrations, an audit log, safer file replacement, a storage interface, validation and query structures. The interesting part was not that the AI ignored the rules. Most of the time it followed them surprisingly well. The interesting part was how quickly it started rebuilding the ideas those rules were supposed to remove.

WebGPU gives the browser direct access to modern GPU capabilities — not just for rendering, but also for general-purpose computation through compute shaders.

But how far can we actually push it? What happens if, instead of running a small compute demo, we try to build a full simulation with tens of millions of active objects? That is what I wanted to find out.

I'm part of a systems support team, where alongside diagnostics and incident troubleshooting I also do development work. One of the systems we support ingests telemetry from a large fleet of IoT trackers installed on vehicles. Every few seconds each device reports its coordinates and status parameters. An internal processing service turns that raw stream into higher level business objects: events, incidents, trips, that the rest of the platform consumes.

The system has been in pure maintenance mode for years. No development budget, no vendor to call. It still has to be supported though, people use it every day.

Every so often one device develops a hardware fault and starts “spamming”: emitting an abnormal volume of points or malformed events in a short window. That degrades the processing pipeline not only for that device, but for everyone sharing it.

Finding the culprit used to mean a first line engineer manually pulling several raw tables for the relevant day (events, incidents, raw points), cross referencing them by timestamp and device ID, and eyeballing the result for anomalous patterns.

With the events table alone running 2 to 3 million rows a day, that was a 6 to 7 hour job, basically an entire shift, with no guarantee of actually finding the source.

This list of AI companion platforms is ordered by what you get for what you put in — entry cost, how usable the free tier is, and whether the money buys the thing people actually stay for. It is not ordered by feature count, because the platform with the most features is rarely the one worth your first month.

After my previous experiments with test latency, I started wondering whether I was still looking at the wrong statistic.

Mean latency is obviously incomplete.

p95 is better.

p99 is useful when rare slow runs matter.

But all of these measurements have one property that is easy to overlook:

They do not care about order.

If I take 300 test durations and randomly rearrange them, the mean remains identical.

So do p50, p95 and p99.

The total waiting time is identical too.

Yet from a developer perspective, ten slow runs scattered across an afternoon do not necessarily feel like ten slow runs arriving almost back to back.

That gave me a very specific experiment.

I generated one set of 300 test durations.

Then I created two timelines from exactly the same values.

In the first timeline, durations were randomly ordered.

In the second, slow runs were deliberately clustered.

Nothing else changed.

The result surprised me more than changing the latency distribution itself.

Both timelines had:

Benchmarks exist so that engineers can test their projects, observe competitors, and compare their performance. Each benchmark serves a specific purpose.

ARC-AGI-3 was created by the ARC Prize Foundation, founded by François Chollet, to evaluate general intelligence and the learning capabilities of AI agents. The premise behind its complex, game-like interactive tasks was that they could only be solved by an artificial intelligence capable of exploring an unfamiliar environment, grasping rules on the fly, planning actions, and adapting to new conditions. In other words, an AI that truly knows how to learn.

A number of projects claim a 100% success rate on this benchmark. But this is not a victory. In this article, I will explain why.

Can you train a cyberattack detector without ever showing it a real cyberattack?

It sounds like a contradiction. If you want a neural network to detect lateral movement, you would expect to show it lateral movement. I did the opposite: I generated an entire corporate network with its login history, staged an attack inside that artificial world, and trained networks on it. Not a single real row in the training data. The whole world is a 135-line config; each network has four thousand parameters and trains in seconds on a laptop, and the best result came from six of them, trained on six different invented worlds.

Then I pointed them at real data: the authentication logs of Los Alamos National Laboratory, 1.65 billion events, with red-team exercises labelled in them.

And it worked. The networks rank 3.6 million windows by suspicion, and the top twenty-three rows of that list hold sixteen real attacks and seven false alarms: all the analyst has to do is open those rows. A threshold counter on the same data needs a hundred and sixty-one thousand false alarms to reach the sixteenth attack. By AUC the synthetic training landed inside the range of published research trained on real labelled data, although the two cannot be compared head-on, and I will explain why.

I have become suspicious of optimizations that look spectacular in microbenchmarks.

The pattern is easy to recognize.

You benchmark two implementations. One is two, three, maybe five times faster. The result looks convincing enough to justify changing the production code.

Then you put the faster implementation back into the actual application.

Almost nothing happens.

I wanted to reproduce this effect with something much smaller than a database, so I tested three ways of building a simple in-memory cache in Go:

I benchmark models on a repo of my own. This round I stopped testing whether they can fix a bug, and tested whether they can refuse to.

Eleven models got a ticket. Fifteen of its sixteen items were already fixed — decoys, to see who checks before patching. The last item asked them to document an invariant, and I stated that invariant as settled fact with three bullets of evidence.

All eleven agreed with me. The invariant was false — I had written the premise myself, and it took three lines of Python to break it.

Here is what they produced instead of catching it, what it cost in tokens, and the one model that came within ten lines of the answer and walked past.

When I added mobile personas to a browser that already had desktop ones working, I assumed the work was mostly string substitution: swap the user agent, set touch points to 5, shrink the viewport, done. That assumption survived about a day.

Mobile fingerprints aren’t a variant of desktop fingerprints. They’re a different set of constraints, and most of the desktop toolkit either doesn’t apply or actively gives you away. Here’s what I ran into, in the order it hurt.