TuxPowered

My FreeBSD loadbalancers block packets with IP Options with default config. It’s not rocket science, no matter how Cloud providers are trying to tell us.

> The various internal networks offer isolation of containers from the rest of the network stack. If I have a rails app in a docker compose configuration with PG, Redis, Elasticsearch, etc, in a development environment, most of the time I don't want the service/accessory containers anywhere near anything other than the app's container.

Which can be achieved with normal routed networks with firewall on the “router” just fine, even on IPv4. Each container can have its own IP address, its own hostname and listen on a standard port, all reachable from containers and from the main OS of the workstation.

> In practice, nobody uses IPv6 for printers, so it'll work just fine over IPv4.

I bought a HP printer 6 years ago, configured it to connect to my WiFi and it automagically became available on my Mac. It advertises itself over mDNS and my Mac talks to it over IPv6 link-local.

All of this happened without any special configuration changes. I’m pretty sure quite a few people around the world print over IPv6 without even knowing that.

> With IPv4, the local ip table isn't impacted by a change in WAN ip

Which can also be true for IPv6. If you need stable LAN addressing you can add ULA prefix to your network. Some CPEs do this by default.

Hi, question from a sysadmin / network engineer. Why localhost with port forwarding? Why not native mechanism like routing and mdns? I’ve gave Docker and other container managers which do networking the same way a try a few times and I always found the network unnecessarily complicated. Eventually I came across OrbStack which uses the aforementioned mechanisms. Every container gets an IP address in the local bridge and responds to mdsns queries. This plays especially well in “compose” scenario when services on containers can all use original port numbers. And containers can be accessed with hostnames, so there won’t be conflict between port numbers especially if I run multiple composed stacks.

Double deckers I’ve seen have just one narrow staircase. You can’t have people go up and down at the same time. Through a door you can move some people in and out at the same time, however it’s rude, but since it’s a door and not a lengthy corridor, you can easily have a group of people go out, let new passengers in, and get in again.

The goal of public transportation is to move people fast around the city. Not to have the driver sell the tickets, that’s what the ticket machine is for (both on stations and on board). Anybody using public transportation daily probably has a monthly ticket anyway. And not to provide tourist information.

People want to get to work on time after all. Entering and leaving the tram or bus through all door is a simple way to improve public transports reliability.

„Coding is solved” or something, I dunno, I’ve landed on another continent the moment I’ve barely touched the screen.

Every Fucking Website 2026:

- Paragraphs emerge from the background as you scroll, sometimes only after 3/4 of your screen is empty.

- Some paragraphs are hidden until you expand them. You can’t expand more than one at a time.

- Horizontal scrolling for some items, like e.g. meal categories in a restaurant. The buttons for the scrolling are different on each site, or are dots you must click on.

So will the Chromium bug 5569 finally get fixed?

> I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.

iPhone does that, and I’m pretty sure I’ve seen Android doing the same. The phone keeps a single /128 from the /64 assigned by the mobile network on its mobile interface and the re-assigns the /64 on the WiFi interface. No NAT is involved.

> Nothing is stopping an ISP from implementing it by taking one ip and assigning ports 1-10.000 to customer A, 10.001 - 20.000 to customer B, and so on. Similarly, nothing is stopping an ISP from adding long-lived mappings to an otherwise-random pool which outlive the initial connection.

I’m pretty sure that the scarcity of Legacy IP addresses and port numbers (!) is exactly what stops providers from doing that, at least by default. I’ve seen NAT running out of ports way too many times, and shortening of connection tracking lifetime comes with a whole set of hard to spot bugs.

> Even if you want to geek out and manage it yourself, a VPS is a very attractive option.

And some VPS providers already started charging extra for hosting the server on Legacy IP.

While debugging some issues in some system Claude refused to write test case because it broke terms of use.

Oh shit, all this fantastic technology is in hands of corporations and they get to decide what we’re allowed to use it for.

The availability of GitHub is still at 0% - it can't be reached over IPv6.