DEV Community: Ron Northcutt

HAProxy Holds Your Tokens for 206ms? Here's What the Default Is Actually Doing (And Why)

Ron Northcutt — Mon, 21 Sep 2026 12:37:00 +0000

NOTE: I work at HAProxy, so I'm probably a bit biased. Still, this is an accurate look at the situation. A fun little deep dive, actually. Regardless, this is my own opinion/research, not official from the company.

A recent benchmark post made the rounds with a table that seems bad for HAProxy. Four proxies sat in front of a scripted LLM emitter sending one tiny frame every 50 milliseconds. Through nginx, Caddy, and Traefik, tokens arrived 2 to 3 milliseconds after the proxy got them, one per read, indistinguishable from no proxy at all. Through HAProxy, the first token showed up 206 milliseconds late and the rest arrived in bursts of five with no gap between them.

The post's verdict: HAProxy buffers your tokens. That sounded unusual for such a performant tool, so I decided to dig into it a bit.

Here is what I found: nothing in HAProxy is collecting tokens in a bucket. The delay comes from HAProxy telling the kernel to wait for more data, on purpose, documented almost to the millisecond, and reversible with one line of config. And the answer to "why is it on by default" is that for most of the traffic HAProxy carries, the default is the faster choice.

The hold happens in the kernel

The background is Nagle's algorithm, named for John Nagle and described in RFC 896 back in 1984: a sender holding small amounts of data should wait for a full packet's worth, or for the receiver to acknowledge the previous packet, before putting another tiny packet on the wire. The reasoning is arithmetic. Without batching, a 60-byte write pays a header-sized envelope, and those headers can double the bytes transmitted, or worse as frames shrink.

Nagle isn't the actor here, though. HAProxy already sets TCP_NODELAY on its TCP sockets. What holds the tokens is a second, explicit mechanism: while a response body is still being received, HAProxy tags every client-facing write with the kernel's MSG_MORE flag, which tells the kernel "more data is coming, hold this." In the 3.4 source the article tested, the H1 mux sets the tag on every in-flight body write (src/mux_h1.c, via CO_SFL_MSG_MORE) and clears it when the body ends. The configuration manual describes the effect exactly: the system "waits for enough data to be available in order to only send full packets. Typical delays are around 200 ms per round trip."

A token stream never fills a packet. Sixty bytes every 50ms, with a round trip sitting between each one, so the corked writes sit in the kernel until the tag clears or a timer cycle releases them. The tokens leave in batches, late by a few cycles, and they reach the client mashed together: five frames, zero gap, 206 ms. That matches the benchmark numbers.

First, this is not application buffering. HAProxy forwards the response body as it arrives. The waiting happens in the kernel's send path, not in a proxy buffer.

Second, the benchmark author says this himself: frames-per-read is a property of the stream shape, not a permanent fact about the proxy. Same proxy, 1.1 KB frames instead of 60-byte ones, and the delay drops to 53 ms with near-zero coalescing. The batching only bites when frames are small relative to a packet, which is, unfortunately, the exact shape of an LLM token.

Batching wins for bulk traffic

For the traffic HAProxy was built to carry, batching is a measurable win, and the costs fall on workloads that never notice.

HAProxy's home turf is bulk HTTP at high concurrency: API responses, uploads, downloads, and everything in between, at request rates where packet counts and syscall overhead show up directly on the CPU graph. Every tiny write batched into a bigger packet is a syscall saved, a header not transmitted, and a few microseconds returned to the event loop. The HAProxy troubleshooting guide states the trade plainly: Nagle "definitely remains enabled when forwarding an HTTP body (and this contributes to the performance improvement there by reducing the number of packets)."

For those workloads the latency cost is invisible, because a download or an API response doesn't care about 40 ms of accumulated batching once per connection; the payload arrives in bulk regardless, and nobody waiting on it can tell the difference.

The design also thought about interactive traffic. The batching is skipped automatically in pure TCP mode and in tunnels. WebSockets and CONNECT requests are explicitly documented as unaffected. The default was tuned with a clear picture of what "interactive" meant at the time: a tunnel, an upgraded socket, or someone pushing a protocol through HTTP that the HTTP spec never intended.

Which brings us to the core issue.

SSE slipped through the model

Server-sent events are plain chunked HTTP. There's no upgrade, no tunnel, nothing to trip the existing exemptions. To HAProxy, an SSE response is an ordinary body that happens to dribble in, so every client-facing write carries the hold tag.

The benchmark measured 206. The manual's "around 200 ms per round trip" predicted it because its just math.

None of this is hidden, and none of it is an accident. The defaults were tuned for the traffic HAProxy has carried for most of its life: bulk responses at high concurrency, workloads where waiting to fill a packet costs nothing and saves real CPU.

Token streaming inverts that trade. The frames are tiny, the stream runs for minutes instead of milliseconds, and the wait lands between a model and a user watching the screen. A default shaped for one kind of traffic cannot also be shaped for its opposite, and bending it until it fits both is how you end up with slower defaults for everyone.

This is precisely why the adjustment exists. option http-no-delay is the designed escape hatch for workloads whose trade-offs differ from the common case, documented in the same manual as the default itself. The system works the way a configurable system should: fast by default for the many, one line to match the few. The benchmark's real contribution is showing which default fits which traffic, and for token streaming the answer is one line long.

The adjustment

backend llm-inference
    option http-no-delay
    server inference 10.0.0.5:8000 check

One line, in the backend carrying the stream. It tells HAProxy to stop tagging the writes, so the kernel never holds them, and the manual describes the result directly: "all such optimizations will be disabled in order to make the exchanges as fast as possible." Frames leave when they arrive.

This isn't just documentation. The benchmark was reproduced on loopback with the same stream shape the article used, 60-byte chunked SSE events every 50 ms, running a local HAProxy 3.2 after reading the 3.4 source the article tested:

setup	first event	frames per read
direct to origin	1 ms	1.00
through HAProxy, default	212 ms	5.00
through HAProxy, `option http-no-delay`	1 ms	1.00

Same shape as the original numbers, and the one line erases the delay completely: first token back to 1 ms, one frame per read, indistinguishable from no proxy. The benchmark author listed "whether option http-no-delay removes it" as a test he'd still like to run. Consider this cell run, with credit to his rig for the design.

Turning it off costs something

With Nagle off, every frame goes out as its own write, which means one packet and one syscall per frame instead of one per full segment. On a 50 ms token cadence that's roughly 20 packets a second per stream, which no individual user will ever notice.

Across tens of thousands of concurrent streams on a busy edge, however, it becomes a real and measurable bump in CPU consumption and packet overhead, and the overhead compounds anywhere the network path is slow or congested.

The manual warns about this too: the option "should never be used by default," and its cost "may significantly lower performance in high latency environments," where every small packet now pays the full round trip alone instead of sharing it with its neighbors.

So the move is not to paste it into a global defaults section. Scope it to the backends that stream. Let the bulk traffic keep the batching.

When to change it

A rule of thumb that applies:

If the payload is the message, turn it off. If the payload is bulk, leave it on.

Tokens, chat deltas, live logs, trading ticks, anything where a human or a model is waiting on each frame: those want option http-no-delay. File downloads, API JSON responses, images: keep the default and keep the efficiency.

When it's unclear which side the traffic falls on, measure it. The benchmark harness from the original post is a good template, and the author's write-up of the fourteen ways he broke it before trusting it is worth reading regardless of which proxy runs in front of the service.

Why nginx made the opposite bet

It's fair to ask, because nginx ships the reverse wager. Its tcp_nodelay directive defaults to on, so small writes leave immediately. In exchange, nginx buffers more aggressively at the application layer (proxy_buffering defaults to on). HAProxy does the opposite: it forwards responses almost immediately and asks the kernel to batch the body writes instead.

The benchmark shows both bets working. nginx's buffering cost about 50 ms only in a deliberately nasty case: a 328 KB payload pushed to a client that sleeps 200 ms between reads. For prompt clients on small streams, it costs nothing. HAProxy's batching costs 200 ms only for small-frame streams. For everything else, it's free throughput.

Neither default is wrong. nginx is friendly out of the box for streaming and pays slightly more overhead on bulk workloads, while HAProxy is leaner on bulk HTTP at scale and needs one line of config for streams. If the product is a stream of tokens, both are available at once: HAProxy's throughput and nginx's latency, for the price of one config line.

A knob, not a wall

A default is an opinion about the common case, and HAProxy's defaults are opinions worth having. They favor throughput, low CPU, and safety at scale, and the numbers behind them show up in every large deployment.

The 206 ms number is real, it's documented, it's reproducible, and it's a knob, not a wall. If tokens are streaming through HAProxy today, add the line, re-run the benchmark, and take the milliseconds back.

Thanks to the original author for the careful measurement work. This post started as a technical review of it, and the rig's honesty (killed findings, one-shot cells, published configs) made the review easy.

Photo by Jahanzeb Ahsan on Unsplash

Raw PHP, opcache, JIT, and AOT: what actually happens to your code

Ron Northcutt — Tue, 15 Sep 2026 14:07:57 +0000

A few weeks ago, I posted a carousel on LinkedIn about TypePHP, the ahead-of-time compiler the Swoole team open sourced. It turns PHP source into a native executable that starts on its own, with no PHP CLI and no separate interpreter process involved.

The response surprised me. Almost nobody wanted to argue about the benchmarks. What people kept asking, in one form or another, was: isn't this just JIT? Doesn't opcache already do this? Where does this fit with what I'm already running?

Thnking about it, I realized my own mental model had gone fuzzy. I knew opcache was important and I knew JIT existed, but I couldn't have clearly explained the difference to someone who asked. So I went back and worked it out.

This is that refresher, written up for anyone else who wants it.

The short version

If you've got two minutes, here's the whole thing.

PHP has to do two separate jobs before your code produces a result.

1) First it has to understand your code, which means reading the text and turning it into instructions.
2) Then it has to execute those instructions. The four approaches each attack a different part of that.

Raw PHP does both jobs on every single request. It reads your files, compiles them, runs them, and throws all the work away. Then the next request comes in and it does the whole thing again.

Opcache fixes the first job. It saves the compiled instructions in memory so PHP stops re-reading your source on every request. This is the single biggest performance win available to a PHP app and it costs you nothing but memory. If you take one thing from this article, take this one.

JIT attacks the second job, with limited success. While your code is running, it watches for hot spots and converts them to native machine code on the fly. It produces impressive numbers on math-heavy code and almost nothing on a normal web request.

AOT attacks the second job by changing the rules. It compiles your PHP all the way to a native binary before you ever deploy it. It goes far faster than JIT can, but only because it gives up part of the PHP language to get there.

The first three are about making your existing app faster. AOT is more about redefining what you can build with PHP at all... and that's the part I find really interesting.

First, what PHP is doing with your code

When a request hits your app, PHP reads your .php files as plain text. It parses them, checks the syntax, and compiles them into something called opcodes. Opcodes are small, simple instructions, roughly the PHP equivalent of assembly. Something like $a + $b becomes an ADD opcode with two operands.

Then the Zend VM takes over. The VM is a loop. It grabs the next opcode, figures out what it means, does it, and moves to the next one. Over and over until your script finishes.

There are two specific things you need to keep in mind.

The first is that PHP variables aren't raw values. They're zvals, which are little containers that hold both the value and a tag saying what type it is. When the VM adds two variables, it has to check the tags first, because $a + $b means something different for two integers than for two strings. That type check happens at runtime, every time, because PHP doesn't know the types ahead of time.

The second is that all of this work gets discarded when the request ends. PHP's process model throws everything away and starts clean. That's actually a feature. It's why PHP is so hard to leak memory in and so forgiving of sloppy code, but it also means any work you do during a request has to be redone on the next one. And the next one. And the next one.

These strategies offer different answers to the question: "which part of that can we stop repeating?"

1. Raw PHP - goldfish memory

This is PHP with nothing turned on. Every request: read the files, parse them, compile them, run the opcodes, throw it all away.

Nobody should be running this on purpose in 2026, but it's the baseline and it's worth understanding why it's so bad.

The problem isn't your code. The problem is your framework. A modern Drupal or Laravel install loads hundreds or thousands of PHP files to serve one page. Every one of those files has to be read off disk, tokenized, parsed, and compiled before a single line of your actual application logic runs. On a typical framework request, that setup work can eat more time than the work you actually care about.

You'll still run into this sometimes. A misconfigured container image, a dev environment nobody set up properly, a hosting provider cutting corners. If an app feels inexplicably slow and the database looks fine, checking whether opcache is actually enabled is a good first move.

2. Opcache - caching is your friend

Opcache fixes the obvious waste. The first time a file is requested, PHP compiles it as usual, but then opcache stores the resulting opcodes in shared memory. Every request after that skips straight to execution.

Your source files stop being read. The parser stops running. All that setup work happens once instead of thousands of times a day.

On a framework-heavy app this commonly gets you several times the throughput, which is an enormous return for a config flag. It's built into PHP, it's on by default in most modern builds, and the only real cost is a chunk of memory.

But notice what opcache does not do. The Zend VM is still there, still walking through opcodes one at a time, still checking zval types on every operation. Opcache removed the cost of understanding your code. It did nothing about the cost of running it.

however, a tight loop that does math a million times gets essentially nothing out of opcache. Opcache removed the cost of compiling that loop, which happens once. The time is going into the VM executing it a million times, and opcache never touches that part.

That gap is what the next two approaches go after.

3. JIT - good on paper, but...

JIT stands for just-in-time compilation, and it arrived in PHP 8.0. It builds directly on top of opcache — it's not a separate thing you run instead, it's a layer that sits on top.

The idea is that while your code is running, PHP watches which parts run most often. When something crosses a threshold, PHP compiles that section into real native machine code and runs the machine code instead of interpreting opcodes. The compilation happens during execution, which is where "just in time" comes from.

On paper this should be huge. In practice, for most web apps, it's roughly nothing. There are a few key reasons why.

PHP's dynamic types get in the way.

The JIT wants to compile $a + $b into a single machine instruction. To do that it needs to know that $a and $b are both integers. But PHP can't promise that because anything could have been assigned to those variables. So the JIT emits the fast machine code plus a guard check that verifies the types are what it assumed. If the guard fails, it bails back to the interpreter. Those guards cost time, and they're everywhere.

It has to preserve all of PHP's behavior.

References, magic methods, error handlers, the ability to redefine things at runtime. The JIT can't optimize away anything that might be observable, and in PHP an awful lot is observable.

The work doesn't survive.

The compiled machine code lives in one worker process. When that process recycles, it's gone, and the next one has to warm up from scratch.

Most web requests aren't CPU-bound anyway.

A typical page load spends its time waiting on MySQL, waiting on Redis, waiting on an API. Making the PHP execution faster doesn't help when the PHP was already sitting around waiting.

Where JIT genuinely does earn its keep is code that's actually doing arithmetic in a loop: image manipulation, numeric simulation, machine learning inference, statistical work, anything that grinds on numbers without touching the network.

If that's your workload, turn it on and measure. If it isn't, JIT is a config option you can safely leave alone.

4. AOT - now this is interesting

AOT stands for ahead-of-time. Instead of compiling while your program runs, it compiles before you deploy at all. That makes sense.

TypePHP takes your PHP source, translates it into C++17, and hands that to gcc or clang. What comes out the other end is a native binary. No interpreter, no opcodes, no VM. Just machine code, the same as if you'd written the thing in C.

And here's the part that matters: the reason it goes so much faster than JIT isn't that compiling beats interpreting. It's that AOT gets to know the types.

What you gain

By requiring you to write in a typed subset of PHP, the compiler can turn a PHP int into an actual machine integer instead of a zval. No box, no tag, no runtime type check, no guard, no bailout path. Once the types are real, it can hand the whole program to a C++ optimizer that's had thirty years of work poured into it... inlining, loop unrolling, constant folding, vectorization, all of it, with full visibility into your code.

That's where the impressive numbers come from. The project reports around 69x on a hundred-million-iteration pi calculation and roughly 135x on a recursive Fibonacci. Broader language benchmarks are more modest, at about 8x on bench.php and 6.5x on micro_bench.php. Not bad, that's for sure.

What you lose

The catch is exactly symmetrical to JIT's. JIT keeps the entire PHP language and accepts a performance ceiling. AOT breaks through the ceiling by giving up part of the language. TypePHP compiles a defined subset and publishes the incompatibility list openly, which I respect. Global scope is declaration-only. Binary mode wants a main() with a specific signature. Some dynamic reference and reflection patterns simply don't compile.

So no, you can't compile Drupal core. But that was never really the point.

Check the fine print

Binary mode produces an executable that starts directly, with no PHP CLI and no separate interpreter process. That's real and it's useful. But the executable still links libphp and PHPX, and those have to ship in your deployment package.

So, this isn't a statically linked Go binary you can scp anywhere and run. It's closer to any other compiled program with shared library dependencies where you ship the program and the libraries it needs.

That's an important detail that I missed in the initial reporting, and not really "no PHP required." It's also the kind of thing worth knowing before you promise it to anyone.

You don't have to compile all of it

Here's the thing that isn't get talked about enough. Binary mode gets the attention, but TypePHP also has -m ext, which outputs a .so (or .dll) that PHP loads as a normal extension.

That inverts the whole question. You're not compiling your application. You're compiling a piece of it, and the rest of your code base stays ordinary interpreted PHP that calls into it like it would any other extension.

Think about where that lands in a large app. A router. A cache backend. A template compiler. A serializer. A pricing or rules engine that runs on every request. In most mature code bases there's a small percentage of the code responsible for a large percentage of the CPU time, and it tends to be the stable, well-tested, rarely-touched part. That's exactly the profile you want for something you compile.

PHP extensions have always been able to do this. The catch was that writing one meant writing C, which put it out of reach for basically every team that wasn't already maintaining an extension. Now the thing you write is PHP!

So the realistic question isn't "can we compile Drupal." It's "which two percent of our code is hot enough to be worth compiling, and can we carve it out cleanly?" That's a much smaller, much more answerable question.

Opcache gets you a large, reliable win. JIT on top of it gets you approximately nothing on a normal web app, but sometimes it can help.

The AOT bar has no length because there isn't an honest one to draw. Nobody can compile a whole framework app today, so "AOT throughput on a standard Laravel install" is not a number that exists. What you can say is that on whatever portion you do compile, you'd see somewhere between 6.5x and 135x depending on what that code is doing.

Which is the real reason AOT sits awkwardly in a performance comparison. It isn't competing with opcache and JIT. It's answering a different question.

So which one do you actually use?

Opcache is not optional.
Turn it on, give it enough memory to hold your whole codebase, and verify it's actually running in production. This is the highest-return thing on the list by a wide margin. If you do nothing else after reading this, go check.

JIT is a targeted tool, not a general upgrade.
Enable it if your PHP is doing real computation, and measure before and after. Don't turn it on across the board expecting your web app to get faster, because it won't, and you'll have spent memory for nothing. The default for most applications is to leave it off.

AOT is a different kind of decision entirely. Don't evaluate it as "should we make our app faster." Evaluate it as "is PHP execution genuinely our bottleneck, or do we need to ship something PHP couldn't ship before?" If it's the first, you're looking at extension mode and a profiler, not a rewrite.

That second part is probably the most useful in the near term. A native executable that starts on its own, with no PHP CLI to install and no vendor directory to ship, is a distribution capability that no amount of opcache or JIT tuning will ever give you. Neither will linking against a Rust library, or handing a customer something they can run without installing PHP first, or putting PHP code somewhere a PHP runtime was never going to fit.

Super cool, but doesn't change things that much ... yet

Anyone running PHP apps probably doesn't need anything else right now. For a typical request that's waiting on a database, none of the four helps much beyond opcache. If your p99 is dominated by queries, the answer is indexes and caching, not compilers. AOT matters when PHP execution itself is the bottleneck, or when the thing you want to ship isn't a website at all.

Wrapping up

Four approaches, and they're not really competing with each other.

Raw PHP re-does all the work on every request. It's the baseline, and if you find yourself here it's a misconfiguration rather than a choice.

Opcache stops PHP re-reading and re-compiling your source. Several times the throughput for a config flag and some memory. Always on, no exceptions, this is where the biggest and cheapest win lives.

JIT compiles hot code to machine code while your program runs, but PHP's dynamic types force it to hedge with guard checks, and the work vanishes when the worker recycles. Real gains on numeric code, near-zero on ordinary web requests. Reach for it deliberately and measure, because turning it on by default costs memory and buys most apps nothing.

AOT compiles everything up front and gets to eliminate the type checks entirely, which is where the 69x and 135x figures come from. The price is a restricted language subset, a build step, and a compatibility audit.

You don't have to swallow it whole, though. Extension mode lets you compile one hot subsystem and leave everything else exactly as it is. Worth it when execution is genuinely your bottleneck, or when you need to ship something in a shape PHP could not produce before.

The first three make your existing app cheaper to run. The fourth changes what you can point a PHP team at.

That's why I don't think AOT belongs in the same conversation as opcache and JIT, even though it keeps landing there. Opcache and JIT are answers to "how fast is our website." AOT is an answer to "what can we build." Those are different questions.

Whether TypePHP's supported subset grows fast enough to matter is genuinely open. But languages that find a way out of their original niche tend to stick around a lot longer than the ones that don't.

One wildcard cert and a script: local domains for every app you run

Ron Northcutt — Wed, 09 Sep 2026 12:33:25 +0000

NOTE: Yes, I created a shell script that will do all of this for you, so you can be lazy (see below). But I still recommend doing it at least once by hand. It's a great way to learn (or remember) and it's pretty quick. Learn it by hand once, and then get lazy.

Part one got one local app onto a local domain with a green padlock. That setup has a ceiling, and you hit it fast: every new app means a new cert, a new ACL, a new backend, and another trip through the same four commands.

This post removes most of that. One cert covers every .omni domain you'll ever create, the config pattern scales to as many apps as you want to run, and a script collapses the whole thing into one command.

One wildcard cert for everything

Generating a cert per app works, but you can skip that step forever with a single wildcard cert:

mkcert -cert-file ~/.config/haproxy/certs/omni-wildcard.crt \
       -key-file ~/.config/haproxy/certs/omni-wildcard.key \
       "*.omni"

cat ~/.config/haproxy/certs/omni-wildcard.crt \
    ~/.config/haproxy/certs/omni-wildcard.key \
    > ~/.config/haproxy/certs/omni-wildcard.pem

Point the crt line at omni-wildcard.pem and every app.omni you add is already trusted. Adding a new app drops to three steps: hosts entry, ACL + backend, reload. No new cert, ever.

That next app is two lines in the frontend and two in a new backend:

    acl is_work req.hdr(host),host_only -i work.omni
    use_backend work_backend if is_work

backend work_backend
    server loopback 127.0.0.1:3000

Two things:
1) Name the pem something generic like omni-wildcard.pem, since it now belongs to the whole setup instead of one app.
2) The wildcard only matches one label deep: *.omni covers omnideck.omni and work.omni, but not api.omnideck.omni. If you nest subdomains, add them to the cert explicitly.

Putting it together: three instances at once

Here's what this actually looks like day to day. I run three Omnideck instances with different configs and different model backends: one for work, one for personal projects, one for breaking things.

Hosts entries first, one per instance, since the hosts file has no wildcards:

sudo tee -a /etc/hosts <<'EOF'
127.0.0.1 work.omni
127.0.0.1 home.omni
127.0.0.1 lab.omni
EOF

The wildcard cert from above covers all three. And the whole config, start to finish:

global
    log stdout format raw local0

defaults
    log global
    mode http
    option httplog
    option forwardfor
    timeout connect 5s
    timeout client  1h
    timeout server  1h
    timeout tunnel  1h

frontend http_in
    bind *:80
    tcp-request connection reject if !{ src 127.0.0.0/8 ::1 }
    http-request redirect scheme https code 301

frontend https_in
    bind *:443 ssl crt /Users/you/.config/haproxy/certs/omni-wildcard.pem alpn h2,http/1.1

    tcp-request connection reject if !{ src 127.0.0.0/8 ::1 }

    http-request set-header X-Forwarded-Proto https

    acl is_work req.hdr(host),host_only -i work.omni
    acl is_home req.hdr(host),host_only -i home.omni
    acl is_lab  req.hdr(host),host_only -i lab.omni

    use_backend work_backend if is_work
    use_backend home_backend if is_home
    use_backend lab_backend  if is_lab

backend work_backend
    server loopback 127.0.0.1:46176

backend home_backend
    server loopback 127.0.0.1:46177

backend lab_backend
    server loopback 127.0.0.1:46178

Check it, reload, and confirm all three:

haproxy -c -f $(brew --prefix)/etc/haproxy.cfg
brew services restart haproxy

for host in work home lab; do
  curl -s -o /dev/null -w "$host.omni -> %{http_code}\n" "https://$host.omni"
done

Three 200s and you're done. A 503 means the request reached HAProxy but no ACL matched, which is usually a typo in the hosts file or a missing use_backend line. A connection refused means the instance behind that port isn't running.

NOTE: the tcp-request connection reject lines carry over from part one, and they matter more here. Three unauthenticated instances behind a wildcard bind is three times the surface on conference wifi. See the FAQ if you want the stricter version.

Automate it with a script

Doing this by hand for every new app still gets repetitive. This script wraps the hosts entry, the cert generation, and the HAProxy reload into one command:

👉 GitHub Gist: add-omni-domain.sh

Usage:

./add-omni-domain.sh omnideck.omni 46176

It takes a slightly different route on certs than the wildcard above. Instead of one cert for everything, it generates a cert per domain and points HAProxy's crt at the whole directory, letting SNI pick the right one per request. Same outcome, no config edit either way.

NOTE: This script requires sudo, so don't trust it blindly. Read it first, or at least have AI check it before you run it. Better yet, use it as a guide and build your own. Put in your own responses, make the emojis better, and extend it to do other cool things.

What else?

That's the whole setup. Local apps answer to real domain names with HTTPS, and adding the next one takes a single command. I'm actually thinking about adding it as an optional step for the omnideck cli installer, but I'm not sure. Thoughts?

FAQ

Can HAProxy route wildcard .omni domains?

Yes. Generate a wildcard cert with mkcert "*.omni", point crt at the combined .pem, and match the Host header with an ACL to send each subdomain to its own backend.

Can I stop editing /etc/hosts for every app?

Yes, with dnsmasq. Install it via brew, add address=/.omni/127.0.0.1 to its config, and on macOS create /etc/resolver/omni containing nameserver 127.0.0.1. Every .omni name then resolves without a hosts entry, and adding an app drops to ACL, backend, reload. Pair it with the wildcard cert and new apps cost you four lines of config.

Is the reject rule enough, or should I bind to loopback?

The reject rule is enough for a laptop you carry around. The port stays open and answers nothing, which is the practical outcome you want.

If you'd rather the port never open at all, bind the interface instead of the wildcard:

    bind 127.0.0.1:443 ssl crt /Users/you/.config/haproxy/certs/omni-wildcard.pem alpn h2,http/1.1
    bind [::1]:443 ssl crt /Users/you/.config/haproxy/certs/omni-wildcard.pem alpn h2,http/1.1

On Linux the sysctl from part one already covers this. On macOS it won't work as your user, because Mojave's low-port exception applies only to wildcard binds. You'd need sudo brew services start haproxy, which installs HAProxy as a system daemon rather than a user agent. That's a real tradeoff for a dev box, which is why the reject rule is the default in these posts.

Do I have to restart HAProxy every time I add an app?

brew services restart is a full stop and start, so in-flight connections drop. On a dev box that's usually fine. If you're mid-stream on something you care about, haproxy -sf $(pgrep haproxy) reloads with the new config and lets the old process finish what it started.

My agent run dies partway through. Is that the proxy?

Probably, if it dies at a suspiciously round interval. HAProxy's default 50s client and server timeouts cut off idle SSE and WebSocket connections, and a streaming run looks idle to the proxy between chunks. The 1h timeouts in the config above, timeout tunnel especially, are there for exactly this.

Photo by Homa Appliances on Unsplash

Stop typing localhost ports: custom local domains with HAProxy and mkcert

Ron Northcutt — Wed, 09 Sep 2026 12:18:45 +0000

When you build local apps, typing port numbers gets old fast. Omnideck runs on localhost:46176. A Go microservice sits on another port. A scraper sits on a third. 127.0.0.1:46176 works, but https://omnideck.omni is cleaner and easier to remember.

Plus... it's just cooler. That's not a huge reason to do it, but it doesn't hurt! This guide maps custom .omni domains to local Omnideck instances, but you can use any pattern you like (.mine, .lab, .grid, and so on).

The stack:

HAProxy as the reverse proxy
Homebrew for installs and services
mkcert for local HTTPS

NOTE: This is part 1. The next article covers how to use one wildcard cert for a simpler setup.

Prerequisites

macOS or Linux with Homebrew installed
sudo access to edit /etc/hosts
Your apps already listening on localhost ports

Why do this?

Readable URLs. omnideck.omni beats remembering ports for five projects.
Production parity. Cookies, CORS, OAuth redirects, and HTTPS-only APIs behave differently on localhost than on real domain names. Testing on a domain catches these early.
Multiple apps at once. Run work.omni and home.omni side by side with no port juggling.

Why Homebrew?

Homebrew keeps the proxy binary, config, and service in one place:

One package manager for installs and updates. brew install haproxy works on macOS and Linux.
Managed services. brew services start haproxy runs HAProxy in the background and starts it again when you log in.
Config files live in $(brew --prefix)/etc/ instead of scattered across the system root.

Step 1: map the domain in /etc/hosts

The hosts file maps hostnames to IP addresses. It has no concept of ports, so 127.0.0.1:46176 is invalid there. Add the mapping:

echo "127.0.0.1 omnideck.omni" | sudo tee -a /etc/hosts

Run that once. Running it again appends a duplicate line.

Verify it resolves:

ping -c 1 omnideck.omni

If a browser still shows the old page, flush the DNS cache or restart the browser. On macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Step 2: reverse proxy with HAProxy

HAProxy listens on port 80 and forwards matching requests to 127.0.0.1:46176.

Install it:

brew install haproxy

On Linux

In Linux, user services can't bind to ports below 1024 by default. So, you need to lower the limit to 80:

sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80

That value resets on reboot.

To keep it, put net.ipv4.ip_unprivileged_port_start=80 in /etc/sysctl.d/99-ports.conf and run sudo sysctl -p /etc/sysctl.d/99-ports.conf. Keep in mind that this lets any user process bind ports 80-1023, not just HAProxy.

On macOS

You can skip this step. Since Mojave, unprivileged processes can bind low ports, but only on a wildcard address: bind *:80 works, while bind 127.0.0.1:80 still returns permission denied.

The tradeoff is that a wildcard bind answers on every interface, which the config below deals with.

HAProxy config

Edit the config at $(brew --prefix)/etc/haproxy.cfg:

global
    log stdout format raw local0

defaults
    log global
    mode http
    option httplog
    option forwardfor
    timeout connect 5s
    timeout client  1h
    timeout server  1h
    timeout tunnel  1h

frontend http_in
    bind *:80

    # Answer only requests from this machine
    tcp-request connection reject if !{ src 127.0.0.0/8 ::1 }

    # host_only strips any port the browser appends to the Host header
    acl is_omnideck req.hdr(host),host_only -i omnideck.omni

    use_backend omnideck_backend if is_omnideck

backend omnideck_backend
    server loopback 127.0.0.1:46176

That tcp-request connection reject line is important! You're binding a wildcard, so the proxy is reachable from every device on whatever network you join, and the app behind it probably has no auth of its own.

The rule drops non-local connections before the handshake even starts. The port still shows up in a scan, but nothing off your machine gets an answer. Drop that line if you actually want the apps reachable from a phone or a VM on your LAN. But do it on purpose.

The long timeouts are deliberate. The usual 50s defaults are fine for page loads, but they cut off idle SSE and WebSocket connections, which is exactly what a streaming agent run looks like from the proxy's side. timeout tunnel is the one that governs an established WebSocket.

Check the config, then start it:

haproxy -c -f $(brew --prefix)/etc/haproxy.cfg
brew services start haproxy

Test it:

curl -i http://omnideck.omni

You should see an HTTP/1.1 200 OK line from your app, not a connection error.

Step 3: HTTPS with mkcert

HTTPS removes browser warnings and lets you test features that require a secure context.

Install mkcert and trust its local CA:

brew install mkcert
mkcert -install

mkcert -install adds a root CA to your OS and browser trust stores once. After that you never import .crt files into Chrome or Firefox by hand. One catch on both macOS and Linux: Firefox keeps its own trust store, so install certutil first (brew install nss or apt install libnss3-tools) or Firefox will keep warning you.

NOTE: You can also just manually upload the cert into your browser.

Generate a certificate:

mkdir -p ~/.config/haproxy/certs
mkcert -cert-file ~/.config/haproxy/certs/omnideck.crt \
       -key-file ~/.config/haproxy/certs/omnideck.key \
       "omnideck.omni"

cat ~/.config/haproxy/certs/omnideck.crt \
    ~/.config/haproxy/certs/omnideck.key \
    > ~/.config/haproxy/certs/omnideck.pem

HAProxy needs one combined .pem file, certificate first, then key.

Update the config for TLS termination:

global
    log stdout format raw local0

defaults
    log global
    mode http
    option httplog
    option forwardfor
    timeout connect 5s
    timeout client  1h
    timeout server  1h
    timeout tunnel  1h

# Port 80: send everything to HTTPS
frontend http_in
    bind *:80
    tcp-request connection reject if !{ src 127.0.0.0/8 ::1 }
    http-request redirect scheme https code 301

# Port 443: TLS termination
frontend https_in
    bind *:443 ssl crt /Users/you/.config/haproxy/certs/omnideck.pem alpn h2,http/1.1

    tcp-request connection reject if !{ src 127.0.0.0/8 ::1 }

    # So the app knows it's behind TLS and builds https:// redirects
    http-request set-header X-Forwarded-Proto https

    acl is_omnideck req.hdr(host),host_only -i omnideck.omni
    use_backend omnideck_backend if is_omnideck

backend omnideck_backend
    server loopback 127.0.0.1:46176

Four notes on that block:

HAProxy does not expand ~ in config paths. Run echo ~/.config/haproxy/certs/omnideck.pem and paste the absolute path into the crt line. On macOS that starts with /Users/, on Linux with /home/.
alpn h2,http/1.1 enables HTTP/2. It needs a TLS library with ALPN support, which means OpenSSL 1.0.2 or newer. Homebrew's HAProxy links against OpenSSL 3, so you're covered.
Without X-Forwarded-Proto, an app that builds absolute URLs will hand back http:// links and break the OAuth redirects you set this up to test in the first place.
The reject rule now sits in both frontends. It runs at connection time, so a remote client gets dropped before the TLS handshake and never learns which certs you're holding.

Linux users: port 443 is already covered by the sysctl setting from Step 2, so just reload:

brew services restart haproxy

Visit https://omnideck.omni. No warning, green padlock.

What's next

One app, one domain, one padlock. Adding a second app means a second cert, a second ACL, and a second backend, which is fine once and tedious by the third time.

Part two fixes that: one wildcard cert for every .omni domain you'll ever make, a full config running three Omnideck instances side by side, and a script that does the whole thing in one command.

FAQ

Why can't /etc/hosts take port numbers?

It maps hostnames to IP addresses and nothing else. Port routing lives above DNS resolution, so it belongs in a proxy like HAProxy or nginx. See, silly things like this can teach us stuff.

Why .omni instead of .local or .dev?

.dev and .app are on the HSTS preload list, so browsers demand valid public certificates. .local is reserved for mDNS (Bonjour), which can add resolution delays. A made-up TLD like .omni avoids both problems. If you want zero collision risk, use .test (reserved by the IETF) or .internal (reserved by ICANN in 2024 for exactly this purpose). I use .omni because, again, it's cooler.

Why does my browser search instead of loading the site?

Made-up TLDs aren't in the browser's public suffix list, so Chrome treats omnideck.omni as a search query. Type http://omnideck.omni once, or take the "did you mean" prompt, and it stops guessing.

How does mkcert stop browser warnings?

mkcert creates a local certificate authority, registers it with your OS and browsers, and signs your certs with it. Browsers trust the CA, so every cert it issues is accepted with no per-site imports.

I rebooted and now I get ERR_CONNECTION_REFUSED

Read that error as good news: DNS worked. The name resolved to 127.0.0.1 and nothing was listening there. A bad hosts entry gives you ERR_NAME_NOT_RESOLVED instead, so this one is HAProxy, not DNS.

On Linux, the usual culprit is the sysctl from Step 2. Without the permanent version, HAProxy comes back after the reboot, fails to bind 80 and 443, and exits. brew services list and the log at $(brew --prefix)/var/log/haproxy.log will confirm it.

Why HAProxy instead of nginx or Caddy?

Any of them will do this. Caddy needs the least config and handles certs on its own. I reach for HAProxy because the ACL syntax stays readable as the rules pile up, the config validates before it loads, and it's the same thing I'd put in front of a real service. Use what you already know.

The OpenAI API everyone copied isn't the one OpenAI recommends

Ron Northcutt — Wed, 24 Jun 2026 14:52:07 +0000

I kept seeing "OpenAI-compatible" stamped on projects that have nothing to do with OpenAI. Ollama. vLLM. LM Studio. Most of the local model tools I run on my own hardware. None of them are OpenAI, yet they all advertise the same compatibility badge. So I went looking for what that badge actually means, and the answer turned out to be more interesting than I expected.

There isn't one OpenAI API spec. There are two formats, they serve different purposes, and the one everyone copied is not the one OpenAI now tells you to use.

Two formats, not one

OpenAI exposes two main ways to send text and multimodal requests to its models. The older one is the Chat Completions API. The newer one is the Responses API, introduced in March 2025 and now recommended for new projects.

This distinction matters because of a quiet mix-up I see all the time. When people say a tool is "OpenAI-compatible," they almost always mean Chat Completions. That's the format the rest of the industry cloned. The Responses API is the direction OpenAI is steering everyone toward, but it isn't the thing that became a standard. Knowing which one you're talking about saves a lot of confusion.

Let me walk through both, then get to why this happened and whether you should care.

How Chat Completions works

Chat Completions models a request as a list of messages, where each message carries a role. The roles do the work:

developer sets the persona and the rules. Older models called this system.
user holds the human prompt.
assistant holds the model's previous replies, which is how you replay conversation history. A request looks like this:

{
  "model": "gpt-5.4-mini",
  "messages": [
    {
      "role": "developer",
      "content": "You are a helpful assistant that speaks like a 1920s detective."
    },
    {
      "role": "user",
      "content": "Where did I leave my keys?"
    }
  ],
  "temperature": 0.7
}

The response wraps the answer inside a choices array. The array exists because you can ask for more than one variation with the n parameter, so even a single reply comes back at index zero:

{
  "id": "chatcmpl-123",
  "object": "chat.completion",
  "created": 1677652288,
  "model": "gpt-5.4-mini",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Listen here, pal. If I knew where your brass keys were hiding, I'd be buying juice, not cracking wise."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 34,
    "completion_tokens": 26,
    "total_tokens": 60
  }
}

There's one catch worth knowing. Chat Completions is stateless, so the server doesn't remember your conversation. Every turn, you resend the full message history, including any tool outputs from earlier in the exchange. For a simple chatbot that's fine. For a multi-step agent that calls tools, it gets unwieldy fast.

Why Chat Completions became the standard

OpenAI shipped this format in 2023, it worked, and it arrived early. That timing matters more than any technical merit.

Once enough tutorials and production apps were written against the messages and choices shape, the format stopped belonging to OpenAI in any practical sense. Other model providers added compatibility so developers could swap them in without rewriting code. Local inference engines like vLLM and Ollama did the same. So did gateways like OpenRouter, whose whole job is normalizing access to many models behind one interface. At that point, supporting the format wasn't a favor to OpenAI. It was table stakes for anyone who wanted developers to adopt their thing.

This is a classic network effect. The format won because it was everywhere, and it stayed everywhere because it won. Simon Willison flagged the obvious risk back in 2025: a whole industry was building clones of one company's proprietary API, and that company could change it whenever it liked.

How the Responses API differs

So OpenAI changed it. Sort of.

The Responses API is a redesign aimed at agents rather than chatbots. It separates your standing instructions from the actual input, and it can hold conversation state on the server so you stop resending the whole transcript.

A request is leaner:

{
  "model": "gpt-5.5",
  "instructions": "You are a concise data analyst.",
  "input": "Summarize our Q2 performance."
}

The instructions field carries the system-level guidance. You pass the actual prompt through input, either as a plain string or a list of messages. If you want the server to remember the last turn, you send store: true and then pass a previous_response_id on the next call instead of replaying everything.

The response is where I see the most misinformation, so here's the real shape. The output is not a single top-level string. It's a typed output array of items, because a single response can now contain a message, a tool call, a reasoning trace, and more, all on one timeline:

{
  "id": "resp_9z8x7c...",
  "object": "response",
  "created_at": 1782384000,
  "model": "gpt-5.5",
  "status": "completed",
  "output": [
    {
      "type": "message",
      "id": "msg_...",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "Q2 revenue rose 14% quarter over quarter, driven mostly by enterprise software renewals.",
          "annotations": []
        }
      ]
    }
  ],
  "usage": {
    "input_tokens": 28,
    "output_tokens": 16,
    "total_tokens": 44
  }
}

You'll see response.output_text in a lot of examples, and it looks like a top-level field. It isn't. It's a convenience helper in the SDK that digs into the output array and pulls out the text for you. Handy, but don't expect it in the raw JSON. Also note the token counts renamed themselves: Chat Completions reports prompt_tokens and completion_tokens, while Responses uses input_tokens and output_tokens. Small thing, easy to trip on.

OpenAI's pitch for Responses is concrete. Better cache utilization cuts cost on multi-turn workloads. Reasoning models score higher because the API preserves their reasoning context between turns. Built-in tools like web search and code execution save you from wiring up your own function-calling loop. For agent work, those are real wins.

There's a deeper reason the stateful design matters, and it's easy to miss. Reasoning models generate a hidden chain of thought before they answer. In a stateless setup, the client has to send the whole history back every turn. That forces an awkward choice. You either strip the reasoning out and lose the model's train of thought, or ship it back and forth as encrypted blocks. Holding state on the server avoids both. OpenAI keeps the reasoning trace on its own backend from one turn to the next, so the model stays sharp without exposing how it got there. That's one of the real reasons behind the push.

Open Responses changes the question

Here's the part that made this worth a blog post. In January 2026, OpenAI and a group of partners published Open Responses, an open-source specification built on the Responses API.

The launch partners are telling. Hugging Face, Vercel, OpenRouter, LM Studio, Ollama, and vLLM all signed on. These are the same tools that cloned Chat Completions on their own. This time, instead of reverse-engineering a proprietary format and hoping it doesn't shift, they helped write a documented spec with formal acceptance tests and a shared schema. The vLLM team said as much: they used to guess at provider behavior, and a real spec ends that.

The idea is one schema you describe requests and outputs against once, then run across OpenAI, local models, or other providers with minimal translation. Notably absent from the launch lineup were Anthropic and Google DeepMind, which keep their own formats. Even so, the spec lists both as targets it aims to reach through adapter layers, so the plan is to cover them, not route around them. This isn't a universal peace treaty, but it's the open part of the field agreeing on a baseline.

There's an irony nobody is hiding. Building an "open" standard on top of one company's API is a strange way to escape that company's gravity. But for anyone tired of writing a wrapper around a wrapper, a documented, testable spec beats a de facto one that lives at OpenAI's discretion.

A few parameters worth knowing

Whichever format you call, a handful of payload options control behavior:

temperature sets randomness. Push it to 0.9 for creative output, drop it to 0.2 for focused, near-deterministic answers.
stream set to true returns text token by token over Server-Sent Events instead of making you wait for the full reply. The streaming events differ between the two formats, which is one more reason adapters need a spec.
Structured output is handled differently in each. Chat Completions uses response_format with a JSON schema. Responses uses text.format. Both can force valid JSON out of the model.
For length limits, watch the naming. Chat Completions deprecated max_tokens in favor of max_completion_tokens. Responses uses max_output_tokens. Same intent, three different names, depending on where you are. ## Where I landed

The practical takeaway, especially if you self-host like I do, is that compatibility is the whole game. Because Ollama and vLLM speak the OpenAI formats, I can point a tool at a local model and a frontier model with the same code and only a base URL between them. That portability is worth real money and real freedom, and it's exactly what Open Responses is trying to protect going forward.

If you're starting something new, build against the Responses API and lean on the Open Responses spec where you can. If you're maintaining an existing app, Chat Completions isn't going anywhere. OpenAI has committed to supporting it indefinitely, and the rest of the field still runs on it. Either way, knowing which spec you're actually talking about is half the battle.

Further reading: OpenAI's migration guide, the Open Responses specification, and Simon Willison's original take on the standardization risk.

Photo by Zdeněk Macháček on Unsplash

When the conclusion comes first

Ron Northcutt — Sun, 14 Jun 2026 19:40:48 +0000

A sponsored benchmark is just an experiment with a sponsor. So read it like one.

I read a lot of vendor benchmarks. Most are fine. They are marketing, sure, but the honest ones tell you what they tested, show their work, and let you decide if it maps to your world.

Then there are the other ones. The ones where you can feel the conclusion was written before the test was. You read the setup and realize the whole thing was arranged to arrive at a number that was decided in a meeting months earlier.

A new one landed recently (March 2026) that is a near-perfect teaching example, so I want to walk through it. Not to dunk on a product, but because the techniques in it show up everywhere, and once you can spot them you can spot them in any report.

The report is Tolly #226104, published in March 2026 and commissioned by F5. It compares F5's BIG-IP Next for Kubernetes running on an NVIDIA Bluefield DPU against three open source load balancers: HAProxy, Envoy, and a third "other open-source solution" that, oddly, never gets named. The pitch is that F5's intelligent AI load balancing crushes the open source field on token throughput, time to first token, and CPU usage in an AI inference cluster.

I want to be fair up front about two things, because they matter.

First, I have no reason to think the numbers are faked. I think the data was measured and reported honestly. That is not where these reports usually go wrong.

Second, the underlying ideas are real. Offloading network work to a DPU genuinely frees up host CPU. Routing requests around busy GPUs is genuinely smarter than routing blindly. Both of those are good engineering. If the report had simply said "our purpose-built, GPU-aware product on dedicated offload hardware beats a general-purpose proxy that was told to ignore GPU load," it would be true. It would also be boring and obvious, which is exactly why the report does not say that.

The problem is not the data. The problem is the experiment.

What the test was actually built to measure

Here is the core of the setup. Before each run, the testers manually loaded 50% of the GPUs with background traffic. That load did not pass through any of the load balancers. It was just dumped onto half the cluster to create a lopsided, half-congested pool.

Then they sent real traffic through each load balancer and measured the result.

F5's product is designed to watch GPU load and steer traffic toward the idle accelerators. The open source proxies were configured with plain round-robin, which sprays requests evenly without caring whether a GPU is already buried.

So the test does exactly one thing: it checks whether a load balancer can detect and avoid pre-loaded GPUs. F5 had that feature switched on. Everyone else had it switched off. The result was decided the moment they chose the configurations.

This is the part that should bother you, because round-robin is a strawman. No competent engineer runs static round-robin into a pool where half the backends are known to be slammed. HAProxy, Envoy, and the rest all support dynamic, load-aware algorithms and health-based routing that exist precisely for uneven backends. None of that was turned on. The open source tools were handed the dumbest possible config and then measured at the one task that config is guaranteed to fail.

Would smarter configs have closed the gap completely? I honestly do not know, and I am not going to pretend otherwise. Connection-aware routing is not the same thing as GPU-load-aware routing, and F5's product was built specifically for this scenario. The fair comparison, with every tool tuned by someone who actually wanted it to do well, was never run. That is the whole point. The report does not answer the interesting question. It answers a rigged one and prints the rigged answer in 40-point font.

The CPU number is a hardware fact dressed as a software win

The other headline is that F5 used about 2 CPU cores while HAProxy used about 12, out of 16 available. Roughly 80% less CPU.

That gap is real, and it is also not surprising, because F5 was running offloaded to a DPU with its own dedicated ARM cores and HAProxy was running on the host. Of course the host uses less CPU when you move the work to a separate chip. That is what offload hardware is for. The honest version of this claim is "dedicated offload silicon uses fewer host cores than host software," which is true of basically any offload, for any workload, forever.

Attributing that to software efficiency is like winning a footrace because you brought a motorcycle, then writing up your superior running form.

How to read any report like this

Strip away the specifics and you are looking at an experiment. So judge it the way you would judge any experiment.

Follow the money. Who paid for it, and does the result flatter them? F5 commissioned this. That alone is not damning, plenty of good research is funded, but it raises the bar for everything else.
Count the changed variables. A clean experiment changes one thing. This one changed the hardware platform, the routing algorithm, and the software maturity all at once, then credited the winner's software. When several variables move together, you cannot attribute the outcome to any single one.
Check the baseline. Was the thing being beaten given a fair shot, or set up to lose? Round-robin into a half-loaded pool is a baseline chosen to fail.
Watch for cherry-picking. The "up to 40 / 61 / 34%" headline quietly picks the worst competitor for each separate metric. Against Envoy, the throughput edge was 21% and the latency edge 17%. And the most jaw-dropping figures, 114% and 406%, came from smaller models that were only ever tested against HAProxy, "due to time constraints."
Try to reproduce it. Could you? An unnamed third competitor, early-access software, and no published configs mean no, you cannot. Real results survive other people repeating them.

Tolly, to their credit, says the quiet part in the fine print. Their own terms note that tests "may have been tailored to reflect performance under ideal conditions." That sentence is doing a lot of work.

The part that actually disappoints me

None of this is illegal, and Tolly is a long-standing testing house that documented its setup well enough that a careful reader can take it apart. I would rather have this report, with its methodology on the page, than a glossy claim with no test behind it at all.

What gets me is that F5 did not need to do this. They are an enormous company with real engineering and a product that, by their own description, has a genuine architectural idea behind it. They could have published a transparent, reproducible, tuned-on-both-sides comparison and let it stand on its merits. Instead they paid for a setup engineered to make the entire open source proxy ecosystem look primitive at a task the test was built to make it fail.

That is the move I find hard to respect. Not competing. Competing is great. It is using scale and a budget to manufacture a lopsided story about volunteer-built and community-built software that cannot commission a rebuttal report of its own.

So read the report. Seriously, the link is public at tolly.com/publications/226104. Read the methodology, not the bottom line. Then ask who paid, what changed, and whether you could ever run it yourself. If the answers do not hold up, the big number on the front page does not either.

Whether F5's product is actually better is a real and open question. This report just is not the thing that answers it.

Photo by Myles Bloomfield on Unsplash

Variables in Javascript: A Comprehensive Guide to Var, Let, and Const

Ron Northcutt — Mon, 22 Jan 2024 08:00:00 +0000

In software, a variable is a symbolic name that represents a value or a reference to a value. It's a way to store information that can be reused and manipulated throughout your program. You can think of a variable like a label or even a sign pointer - it represents the data (which can potentially change) but is not the actual data itself.

I am often reminded of that great scene in the Bruce Lee movie, "Enter the Dragon", where he tells his student that "it is like a finger pointing the way to the moon - don't concentrate on the finger, or you will miss all of that heavenly glory." The variable is important, but what it represents is actually what you care about.

Ok, maybe that's a little bit of a stretch, but you get the idea. Variables are essential building blocks in JavaScript programming, allowing developers to store and manipulate data. There are 3 main ways to declare a variable, and your choice can have significant implications on your code's behavior and maintainability. Many developers just choose one and use it for everything, but that's just lazy and can sometimes cause problems.

Let's explore these three methods of variable declaration in JavaScript: var, let, and const, diving into when and why to use each, along with their respective advantages and drawbacks.

1. `var`: Function-Scoped Variables

In JavaScript, var is a keyword used to declare a variable. It has some specific behaviors that set it apart from other variable declaration keywords like let and const.

Here's what you need to know about var:

Function Scope: Variables declared with var are function-scoped, meaning they are accessible within the function where they were declared (or globally if declared outside any function).
Hoisting: Unlike let and const, variables declared with var are "hoisted" to the top of their containing function or global scope. This means that they are technically available from the beginning of that scope, but their value will be undefined until the code where they are assigned is executed.
Reassignment: You can reassign new values to a variable declared with var.
Redeclaration: In non-strict mode, you can redeclare a variable using var in the same scope without getting an error, which is not allowed with let and const.
No Block Scope: var does not respect block scope (such as inside an if statement or a loop), which can sometimes lead to unexpected behavior. If you declare a variable with var inside a block, it's actually available to the entire surrounding function or global scope.

Because of these peculiarities, and with the introduction of let and const in ES6 (ECMAScript 2015), the use of var has become less common in modern JavaScript, and it's often recommended to use let or const instead for clearer scoping rules and better maintainability.

When to Use

You need a variable with function-level scope.
You are working with older code that doesn't support ES6.
Typically, you should avoid var, but it can be handy in some cases.

Pros

Function Scope: Variables are accessible within the entire function where they're declared.
Hoisting: Variables are moved to the top of their scope and initialized with undefined, allowing them to be referenced before declaration.

Cons

Lack of Block Scope: Variables can be accessed outside the block they were declared in, leading to potential bugs.
Hoisting Quirks: Can cause confusion as variables are available before their declaration.

Example

    function varExample() {
      console.log(x); // undefined, because of hoisting
      var x = 10;
      console.log(x); // Output: 10

      if (true) {
        var x = 20; // Same variable, even though it's in a different block
      }

      console.log(x); // Output: 20, because var does not have block scope
    }

2. `let`: Block-Scoped Variables

So, if we had var, why did we need something else? The reason why the let keyword was introduced to javascript was because function scope is confusing and this led to a number of bugs and errors. let was was introduced in ES6 (ECMAScript 2015) as an alternative to var, with some key differences in behavior:

Block Scope: Unlike var, variables declared with let are block-scoped, meaning they are only accessible within the block in which they were declared (e.g., inside an if statement or a loop).
No Hoisting: Although let declarations are hoisted, the variables are not initialized until the code execution reaches the declaration. Attempting to access the variable before its declaration will result in a ReferenceError.
Reassignment: Like var, you can reassign new values to a variable declared with let.
No Redeclaration: In strict mode, you cannot redeclare a variable using let in the same scope.

When to Use

You need a variable with block-level scope.
You expect to reassign the variable within its scope.
Probably should be your default method for creating variables.

Pros

Block Scope: Variables are only accessible within the block where they're declared, reducing potential errors.
No Hoisting Issues: Variables are not initialized until the code execution reaches the declaration.

Cons

More Limited Scope: Might require more careful planning of where the variable is declared.

Example

    function letExample() {
        console.log(x); // ReferenceError, because it doesn't exist yet (no hoisting)
        let x = 10;

        if (true) {
            let x = 20; // Different variable because it's in a different block
            let y = "I see how it works";
        }

        console.log(x); // Output: 10, because we are in the block for the original variable
        console.log(y); // ReferenceError, because y is block-scoped
    }

3. `const`: Block-Scoped Immutable References

The const keyword, which, like let, was introduced in ES6 (ECMAScript 2015). It has similarities to let, but with some unique characteristics:

Block Scope: Just like let, variables declared with const are block-scoped.
No Hoisting: Similar to let, const declarations are hoisted, but accessing them before their declaration in the code results in a ReferenceError.
No Reassignment: Unlike var and let, once a variable is assigned with const, it cannot be reassigned. Attempting to do so will result in a TypeError.
No Redeclaration: You cannot redeclare a variable using const in the same scope.
Must Be Initialized: A const declaration must be initialized with a value at the time it's declared.

When to Use

You want to declare a variable that should not be reassigned.
You need block-level scoping.

Pros

Immutable Reference: Prevents reassignment, making the code more predictable.
Block Scope: Like let, variables are only accessible within the block where they're declared.

Cons

Not Fully Immutable: Only the reference is constant, not the object itself. If the variable is an object, its properties can still be altered.

Example

    function constExample() {
        if (true) {
            console.log(PI); // ReferenceError, because it doesn't exist yet (no hoisting)
            const PI = 3.14159;
            PI = 3; // Error: Assignment to constant variable
        }
        console.log(PI); // ReferenceError, because PI is block-scoped

        const obj = { value: 5 };
        obj.value = 10; // This is fine because object properties can be changed
        obj = { value: 20 }; // TypeError, reassignment not allowed
    }

Conclusion

In modern JavaScript development, understanding the appropriate use of var, let, and const is crucial. While you can safely plan to use let most of the time, it is important to understand how block scope works so you know when it makes sense.

Use var for function-level scope, mainly when dealing with older code or specific scoping needs.
Utilize let when block-level scope is required, and you expect the value to change within the block.
Opt for const when you want to ensure that the reference to a value stays constant within a block scope.

By carefully choosing the right declaration method, developers can write code that is not only more readable but also more resilient and less prone to errors and unexpected behavior. It is usually better to hit scope-related errors earlier (more strict) than later (less strict).

A Hands-on Guide to Git Rebase & Resolving Conflicts

Ron Northcutt — Fri, 08 Dec 2023 07:00:00 +0000

Goal

By the end of this tutorial, you will have a practical understanding of how to use git rebase to integrate changes from one branch to another and how to maintain a clean commit history.

Want a more information about this image? Checkout the "Understanding Git Rebase" guide.

Prerequisites

Basic understanding of Git
Git installed on your system

Overview

Git rebase is a powerful command that allows you to integrate changes from one branch into another. Instead of merging, which takes all the changes in one branch and merges them into another with a new merge commit, rebase takes a different approach. It replays your changes on top of the branch you're rebasing onto. This results in a cleaner, more linear commit history.

Of course, it's not all sunshine and rainbows - problems do pop up. So, lets take a look at how to use git rebase and also how to deal with conflicts when they arise.

1. Set up a Test Repository

Lets go ahead and create a test repository that we can use to play around with git rebase.

# Initialize a new repository
git init rebase-demo
cd rebase-demo

# Create a main branch for primary development
git checkout -b main

# Create a file and commit it to the main branch
echo "Initial content" > file.txt
git add file.txt
git commit -m "Initial commit on main"

2. Create a New Feature Branch

Now, let's create a new feature branch that we will rebase into the main branch later. We will create a simple file and commit that change to the branch.

# Create a feature branch and add a file to it.
git checkout -b feature-branch
echo "Some feature content" >> file.txt
git commit -am "Add feature content"

3. Make More Changes to the Main Branch

Let's go back to the main branch and make some more changes. These changes are what our rebase will be added to.

# Go back to the main branch and make changes
git checkout main
echo "Another line in main" >> file.txt
git commit -am "Update in main"

Now, you have two branches: main and feature-branch, both with unique commits.

4. Rebase the Feature Branch

Now, the magic happens. We switch to the feature branch, and rebase it into main.

git checkout feature-branch
git rebase master

Wait, is that it? Is it really that simple?

It can be, for sure! Assuming all went well, the commit history will show the feature-branch commits will be on the main branch. Those experienced or very observant developers may have noticed a problem above... we will have a conflict. However, not all is lost. Let's take a look at how you can adapt to this situation and fix any minor problems.

5. Resolve Conflicts

During the rebase, you'll encounter a conflict because line 2 of file.txt is different in each branch. That's ok - no need to panic. All merge conflicts can be fixed with the same basic steps. Here's how to resolve it:

Identifying the Conflict: Git will indicate that there's a conflict. You'll see a message similar to:

Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
error: could not apply a669cc6... Add feature content

This message tells you that there's a conflict in file.txt that needs resolution.

Evaluating the status: One of the great things about Git is that you can always ask for a status update to see what is going on and what you may need to work on. Just make a note of the problems to fix and handle them one at a time.

interactive rebase in progress; onto 117fde3
Last command done (1 command done):
    pick a669cc6 Add feature content
No commands remaining.
You are currently rebasing branch 'feature-branch' on '117fde3'.
    (fix conflicts and then run "git rebase --continue")
    (use "git rebase --skip" to skip this patch)
    (use "git rebase --abort" to check out the original branch)
Unmerged paths:
    (use "git restore --staged <file>..." to unstage)
    (use "git add <file>..." to mark resolution)
    both modified:   file.txt

Viewing the Conflict: Depending on how many changes you are dealing with, you may know exactly what the problem is. Alternatively, you can also use git diff to see the changes. Open file.txt in your favorite editor. You'll see the conflicting changes demarcated like this:

Initial content
<<<<<<< HEAD
Another line in master
=======
Some feature content
 >>>>>>> Add feature content

The content between <<<<<<< HEAD and ======= is from the main branch, and the content between ======= and >>>>>>> Add feature content is from the feature-branch.

Resolving the Conflict: Edit file.txt to keep the content you want. For instance, if you want to keep the content from both branches but want the feature content to appear before the master content, you'd modify file.txt to look like this:

Initial content
Some feature content
Another line in master
Save and close the file.

Marking the Conflict as Resolved: After resolving the conflict, mark it as resolved with Git:

git add file.txt

Continuing the Rebase: Once the conflict is resolved and marked as such, continue the rebase process:

git rebase --continue

If there are more conflicts, Git will pause again and let you resolve them. If there are no more conflicts, the rebase will be completed.

6. Check the Commit History:

Use git log to see a clean, linear history of commits, showing that the feature branch commits now come after the master branch commits. Once the rebase is successful, it will be a fast-forward merge, maintaining a linear history.

Conclusion

Git rebase is a powerful tool for maintaining a clean commit history and integrating changes from one branch into another. While it can be a bit more complex than merging, especially when conflicts arise, the resulting linear history can be worth the extra effort, especially in large projects.

Remember, practice makes perfect. Feel free to experiment with git in safe environments (like our demo repo) before applying it to larger projects. Happy rebasing!

Additional Resources

How to Correctly Execute a Loop Synchronously with Javascript

Ron Northcutt — Wed, 11 Oct 2023 08:37:59 +0000

Understanding synchronous and asynchronous operations is fundamental when working with JavaScript, especially when dealing with loops. In this article, we will explore how to run loops synchronously, even when they contain asynchronous tasks.

The Synchronous for Loop

To execute a loop synchronously with JavaScript, you can use the for loop. The for loop allows you to iterate over a sequence of values and execute a block of code for each value. By default, the for loop is synchronous, meaning that each iteration will wait for the previous iteration to complete before starting.

Here's an example of a for loop that counts from 1 to 10 synchronously:

for (let i = 1; i &lt;= 10; i++) { 
  console.log(i); 
}

In this example, the loop starts with i equal to 1 and increments i by 1 each time through the loop until i is equal to 10. The console.log() statement inside the loop will be executed for each value of i, printing the value to the console.

Introducing Asynchronous Operations

However, real-world scenarios might require you to perform asynchronous tasks within your loop, like fetching data from a server. Here's where understanding the synchronous nature of loops becomes essential.

For instance, if you used JavaScript's native fetch method or another API call within a loop, it would not work synchronously by default. Each request would be initiated almost simultaneously, and the responses would likely return out of order.

Making Loops Synchronous with Asynchronous Tasks

If you need to execute an asynchronous task inside the loop, such as making an API call or fetching data, you can use the async/await syntax to wait for the task to complete before moving on to the next iteration of the loop. Here's an example:

async function fetchData(num) { 
  // Simulating an API call
  return new Promise(resolve => {
    setTimeout(() => resolve(`Data for ${num}`), 1000);
  });
} 

async function myFunction() { 
  for (let i = 1; i <= 10; i++) { 
    const data = await fetchData(i); 
    console.log(data); 
  } 
}

In this example, the fetchData() function makes an asynchronous API call and returns the result. Inside the myFunction() loop, we use the await keyword to wait for the API call to complete before moving on to the next loop iteration. This ensures that the loop is executed synchronously, with each iteration waiting for the previous iteration to complete before starting.

Understand your needs

While using async/await within loops guarantees order, it might not be the most efficient approach for all use cases, especially if the asynchronous operations don't depend on the result of the previous one. In such cases, running them concurrently might be more time-efficient. You might also want to use events or even Promise.all() to handle all the results when they are complete.

Using loops synchronously in JavaScript is straightforward. However, when introducing asynchronous operations within loops, it's essential to ensure they maintain the desired flow. The async/await syntax offers a neat way to achieve this, but it's vital to consider the efficiency and nature of the tasks when applying this method.

The Evolution of Git: A Dive Into Tech History

Ron Northcutt — Tue, 19 Sep 2023 16:49:19 +0000

In the earliest days of my career, I never used version control. At that time, Git didn't exist and most version control systems were clunky tools used mostly by corporate engineering teams. I was doing a lot of freelance consulting, so most of my projects were just me working alone. SFTP, occasional backups, and lots of *.bak files worked reasonably well. Still, I lost work or wished I could return to an earlier version after multiple refactors... especially since I was still learning.

When I joined my first team as a developer, I was introduced to "Subversion". This was a whole new world - the ability to see all changes, go back in time, and to safely make changes was great. It changed the way I thought about code. The problem is that it was slooooow. I was working on a large project, and updates took quite a while.

Then, I joined a company as a Sr. Developer, and they were using this new thing called "Git". I wasn't familiar with it, and actually, my first commit to the main branch broke the app in production (cue heart attack)! I had no idea about merge conflicts or how to fix them. However, once I got the basics down, I became a huge fan. It was FAST. So much faster than Subversion, and really much easier to use. With just a few commands, I was fairly proficient, and for more complex things I could easily find help online.

Today, it is almost impossible to learn about software development without learning about Git. For many developers, the command git commit is a daily ritual. It's the heartbeat of countless projects yet, how many of us know the story behind this powerful tool? We've all heard bits and pieces, but let's take a deeper look at Git and how it came into being.

What is Git?

"I'm a very lazy person who likes to get credit for things other people actually do. In the Linux project, I started it, and I'm still considered the central point, but I'm not a good programmer. I'm a good manager. My only job is to say 'no' to people, and sometimes I accept patches and put them into my tree. I wanted a tool where I can do that. That was my only design criteria, and it turns out when you do that kind of tool, you can use it for a lot of other things too."

-- Linus Torvalds

To start with, what the heck is Git? At its core, Git is a distributed version control system (VCS). It lets multiple users track changes in source code during software development, maintaining a history of code changes, and ensuring traceability. It is like a shared digital diary for computer code, allowing many people to write in it while keeping a record of all changes made over time.

But unlike many version control systems that came before it, Git operates on a distributed model, meaning every developer's working copy of the code is also a repository with complete history and version tracking abilities, independent of network access. This means that developers can work locally on their machine, and then sync those changes later. This was a big change in how VCS affects the daily workflow of a developer.

One of Git's key advantages is its efficiency in handling changes. Instead of sending an entire copy of the codebase each time, Git only transmits the differences (or changes) from the last known version. This approach significantly reduces the amount of data transmitted and results in faster sync times, providing a performance advantage, especially for large projects.

The Genesis: Why Was Git Created?

"So I’d like to stress that while it really came together in just about ten days or so (at which point I did my first *kernel* commit using git), it wasn’t like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started. I’d seen the problems others had. I’d seen what I wanted to avoid doing."

-- Linus Torvalds

Flashback to 2005. The Linux kernel, an enormous open-source project, used a proprietary VCS called BitKeeper. However, due to a conflict between the community and the company behind BitKeeper, the free-of-charge status was revoked. Necessity is the mother of invention, and this incident paved the way for the creation of a new system. Linus Torvalds, the creator of the Linux kernel, took the reins. He aimed to create a tool that was:

Distributed: Unlike other systems where a central repository was required.
Compatible: The new tool would incorporate as many features and workflows as BitKeeper.
Secure: Ensure the integrity of source code and protect against corruption, accidental or malicious.

So, after a few days of work, Torvalds had a working prototype of Git, and less than a month later, Git was managing the Linux kernel source code. On April 7, 2005, Linus Torvalds made the first-ever commit to Git. It wasn’t a grand feature; it was a simple README file. However, the major version (v1.0) took its time and was released on December 21, 2005. But, what's interesting is that version 2.0 was released almost a decade later on June 1, 2014.

Git got the important things right in the beginning, and that set the stage for a valuable project.

The Showdown: Git vs. CVS

'Well, it was obviously designed for our workflow, so that is part of it. I’ve already mentioned the whole “distributed” part many times, but it bears repeating. But it was also designed to be efficient enough for a biggish project like Linux, and it was designed to do things that people considered “hard” before git – because those are the things *I* do every day.'

-- Linus Torvalds

Concurrent Versions System (CVS) was one of the pioneering tools in the version control domain. So how does Git stand out when compared to such a veteran system?

Distributed vs. Centralized: CVS follows a centralized model, meaning the version history is stored in a central server. If that server crashes without any backups, you lose everything. Git’s distributed approach ensures that every developer has a local copy of the entire history, making it decentralized and significantly safer.
Performance: Git’s local operations, thanks to its distributed nature, means that many tasks are faster in Git than CVS. There's no need to communicate with a central server for every tiny operation.
Branch Management: Branching in Git is a walk in the park. It's an integral part of the workflow. In CVS, branching is a cumbersome process, often avoided due to its complexity.
Atomic Operations: Git operations, like commits, happen atomically. Either they succeed with all changes or fail without any. This isn't always the case with CVS.
Data Integrity: Git uses a SHA-1 hash to manage data, ensuring the repository’s integrity. If something goes awry, it's immediately noticeable.

Notable Performance Improvements in Git

"Just to pick an example: the concept of “merging” was generally considered to be something really quite painful and hard in most SCM’s. You’d plan your merges, because they were big deals. That’s not acceptable to me, since I commonly do tens of merges a day when in the merge window, and even then, the biggest overhead shouldn’t be the merge itself, it should be testing the result. The “git” part of the merge is just a couple of seconds, it should take me much longer just to write the merge explanation message."

-- Linus Torvalds

Git's inception was driven by the need for performance, but that didn’t stop the community from further refining it.

Packed Refs: Instead of keeping every single object (commit, tree, blob) as individual files, Git packs them.
Delta Compression: When packing, Git identifies the differences between versions and stores just the changes.
Garbage Collection: Over time, some objects become obsolete. Git has a garbage collector that removes these unnecessary objects.

These optimizations, combined with many under-the-hood improvements, ensure that Git remains lightning-fast, even for mammoth repositories. Soon after its creation, developers around the world started contributing. Junio Hamano is one such name that stands out. Within just a few months of Git's inception, he took over its maintenance, ensuring it didn’t remain just a side project but evolved into a robust system.

Under Hamano's stewardship and with contributions from developers worldwide, Git was not just about committing or branching. It introduced:

Staging Area: This intermediary area allows developers to format and review commits before finalizing them.
Remote Repositories: With platforms like GitHub and GitLab, remote repositories became a staple, facilitating collaboration among developers globally.
Hooks: Custom scripts triggered by important actions, enhancing Git's capabilities and automation.

It's hard to imagine Git without some of these features today, but think about how innovative and unique these were when they were created.

"Git": An Odd Name with a Humorous Origin

“I'm an egotistical bastard, so I name all my projects after myself. First Linux, now Git."

-- Linus Torvalds

In an email, when asked about the name, he once quipped, “The name 'git' was given by Linus Torvalds when he wrote the very first version. He described the tool as ‘the stupid content tracker’ and the name as (depending on your way): random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of 'get' may or may not be relevant. Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.”

"Git" is British slang for a silly or contemptible person. Silly? Irreverent? Absolutely! But it’s another testament to Torvald’s personality and the informal, community-driven spirit of open-source software.

Git's Journey Continues

From its rapid inception to becoming the backbone of software versioning, Git’s journey is a testament to open-source power. Its success lies not just in its utility but in a global community that continues to nurture and refine it. Git has transitioned from a quick solution to a kernel project hiccup into an essential tool for individual developers and tech giants alike. Its distributed nature, performance optimizations, and robust branching capabilities make it superior to many version control predecessors.

So, as you git push your next big feature or troubleshoot with a git blame, take a moment to appreciate this tool's history, and perhaps, share its story. Because, in a way, every developer using Git today is part of its ongoing saga.

Photo by Yancy Min on Unsplash

DEV Community: Ron Northcutt

HAProxy Holds Your Tokens for 206ms? Here's What the Default Is Actually Doing (And Why)

The hold happens in the kernel

Batching wins for bulk traffic

SSE slipped through the model

The adjustment

Turning it off costs something

When to change it

Why nginx made the opposite bet

A knob, not a wall

Raw PHP, opcache, JIT, and AOT: what actually happens to your code

The short version

First, what PHP is doing with your code

1. Raw PHP - goldfish memory

2. Opcache - caching is your friend

3. JIT - good on paper, but...

PHP's dynamic types get in the way.

It has to preserve all of PHP's behavior.

The work doesn't survive.

Most web requests aren't CPU-bound anyway.

4. AOT - now this is interesting

What you gain

What you lose

Check the fine print

You don't have to compile all of it

So which one do you actually use?

Super cool, but doesn't change things that much ... yet

Wrapping up

One wildcard cert and a script: local domains for every app you run

One wildcard cert for everything

Putting it together: three instances at once

Automate it with a script

What else?

FAQ

Can HAProxy route wildcard .omni domains?

Can I stop editing /etc/hosts for every app?

Is the reject rule enough, or should I bind to loopback?

Do I have to restart HAProxy every time I add an app?

My agent run dies partway through. Is that the proxy?

Stop typing localhost ports: custom local domains with HAProxy and mkcert

Prerequisites

Why do this?

Why Homebrew?

Step 1: map the domain in /etc/hosts

Step 2: reverse proxy with HAProxy

On Linux

On macOS

HAProxy config

Step 3: HTTPS with mkcert

What's next

FAQ

Why can't /etc/hosts take port numbers?

Why .omni instead of .local or .dev?

Why does my browser search instead of loading the site?

How does mkcert stop browser warnings?

I rebooted and now I get ERR_CONNECTION_REFUSED

Why HAProxy instead of nginx or Caddy?

The OpenAI API everyone copied isn't the one OpenAI recommends

Two formats, not one

How Chat Completions works

Why Chat Completions became the standard

How the Responses API differs

Open Responses changes the question

A few parameters worth knowing

When the conclusion comes first

What the test was actually built to measure

The CPU number is a hardware fact dressed as a software win

How to read any report like this

The part that actually disappoints me

Variables in Javascript: A Comprehensive Guide to Var, Let, and Const

1. var: Function-Scoped Variables

When to Use

Pros

Cons

Example

2. let: Block-Scoped Variables

When to Use

Pros

Cons

Example

1. `var`: Function-Scoped Variables

2. `let`: Block-Scoped Variables

3. `const`: Block-Scoped Immutable References