BitPirate

zswap and systemd-oomd/earlyoom are your friends.

Why do you need a low ttl for those? You can add multiple IPs to your A/AAAA records for very basic load balancing. And DNS is a pretty bad idea for any kind of failover. You can set a very low ttl, but providers might simply enforce a larger one.

Borg 2.0 (unreleased) is moving in a similar direction with borgstore:

https://www.borgbackup.org/releases/borg-2.0.html

Alternative: Stirling PDF

Took me a while, but I found the repository: https://github.com/VSRemoter/LuxPDF

The play store version isn't updated anymore. You should switch to F-Droid.

Asahi Linas explanation:

https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input...

Yet here we are in 2025, with OpenSSL still lacking a QUIC server API and RFC9000 approaching its fourth birthday.

While the price of energy production is likely to continue to fall, I fear that this will be completely overshadowed by the necessary investment in the grid. Both energy storage and the need to adapt the grid to the more decentralised nature of renewables could lead to a plateau in end user prices.

That's why you should run a tarpit instead.

With RFC8441 websockets are just HTTP/2 streams.

Your observation doesn't contradict the use of firewall rules to accomplish this.

The benchmark is apparently a bit flawed[1]. I'd take the results with a grain of salt.

[1] https://caddy.community/t/nginx-vs-caddy-benchmark-video/261...

Reply by Matt Holt: https://news.ycombinator.com/item?id=42073885

If we stopped using things that had vulnerabilities, we'd be using sticks and stones by now.

Other operating systems weren't affected, so it's not inherent in the protocol itself.

The EEVDF scheduling algorithm is also a good example. Designed back in 1995 and it's the default process scheduler of Linux now.

Pseudo justification? The bark beetle is wreaking havoc in our forests here in Germany.

Sadly things are a bit broken if IPv6 is involved:

https://github.com/szimek/sharedrop/issues/55

Ashton Kutcher and his Thorn organisation?

The author mentions PostgreSQL's JIT compiler. Up to this day, I've only seen it degrade the performance of queries. Disabling it is on my install checklist.

The performance difference between H1/H2 and H3 in this test doesn't really surprise me. The obvious part is the highly optimised TCP stack. But I fear that the benchmark setup itself might be a bit flawed.

The biggest factor is the caddy version used for the benchmark. The quic-go library in caddy v2.6.2 lacks GSO support, which is crucial to avoid high syscall overhead.

The quic-go version in caddy v2.6.2 also doesn't adjust UDP buffer sizes.

The other thing that's not clear from the blog post is the network path used. Running the benchmark over loopback only would give TCP-based protocols an advantage if the QUIC library doesn't support MTU discovery.

It's a bit like drag racing. If all you care about is the performance of a single transfer that doesn't have to deal with packet loss etc, HTTP/1 will win.

My biggest gripe with Firefox on Android is that sometimes I enter a domain in the address bar, press enter and nothing happens.

This behaviour seems to be erratic and only affects a few websites, such as https://forum.syncthing.net.

Closing the tab or using a different one doesn't solve the problem. I need to force close the app to fix this.

I'd argue that the decision to keep it in userspace was the right one. If an application doesn't get security updates, a broken QUIC stack is probably the least of your worries.

You also mention Android, which is notorious for having a lot of devices that don't get OS updates because they've reached end-of-life.

Protocol ossification at the OS level is also a valid concern.

https://http3-explained.haxx.se/en/quic/quic-userspace

Ubiquitis Unifi controllers and the TP-Links clone called Omada always remind me of the glory days of the NoSQL fad. Want to install our software? Please add a third-party mongodb repository to install an obsolete version. They can't handle version upgrades of their own database properly, but hey! At least it's web-scale.

Most of the bootstrapping[1] is already done, but the import[2] from Github is causing them troubles.

[1]: https://github.com/go-gitea/gitea/issues/1029 [2]: https://github.com/go-gitea/gitea/pull/18165

How long until they scrap on-premises AD and try to force companies to use Azure?

One of the changes which isn't upstream yet: https://github.com/quic-go/quic-go/pull/3471

Tailscale is using GSO/GRO now. They blogged about reaching the 10Gbit/s milestone.

https://tailscale.com/blog/more-throughput/

In the age of CGNAT? Not a good idea.