TuxPowered
TuxPowered on Hacker News
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.
> not fully compatible with OpenBSD one
The OpenBSD NAT and scrub syntax, and af-to are available in FreeBSD 15.
Even with IPv6 you still might have stateful firewalls allowing only for outbound connection at both ends (e.g. a CPE a.k.a. “WiFi router”) and to establish communication you’d need to punch a hole in those firewalls.
> just like almost all transportation is done today via cars instead of horses.
That sounds very Usanian. In the meantime transportation in around me is done on foot, bicycle, bus, tram, metro, train and cars. There are good use cases for each method including the car. If you really want to use an automotive analogy, then sure, LLMs can be like cars. I've seen cities made for cars instead of humans, and they are a horrible place to live.
Signed, a person who totally gets good results from coding with LLMs. Sometimes, maybe even often.
It should always be at 0, because GitHub is unreachable over IPv6, which in 2025 should be considered an incident.
I did traffic shaping per user for a few hundred users on 1GHz Pentium III on Linux. It can be done just fine.
> On what's now almost 10 year old hardware, we could drop 44Mpps of a volumetric DOS attack and still serve our nominal workload with no impact.
Was filtering done with pf, ipfw or some custom firewall?
> How do you avoid this
IPv6 of course.
> or is it just not important
Port knocking not a security feature anyway.
Making my web resources IPv6-only has solved the problem for me. I don’t consider this a solution for ever, but for now it’s apparently way too modern or complicated for the A-so-called-I companies.
So that’s the only hope to get MRU tab switching in Chrime - get hired at Google?
Is this another incarnation of Sofort? Fortunately nobody is forced to used the former nor the later, you can either pay with card or just make your own SEPA transfer from any bank in Europe.