Hacker News: paperplatter

New comment by paperplatter in "SQL Tips and Tricks"

paperplatter — Thu, 26 Sep 2024 16:42:19 +0000

The easiest fix for this is the "WHERE 1=1" or "WHERE true"

New comment by paperplatter in "SQL Tips and Tricks"

paperplatter — Wed, 25 Sep 2024 16:20:29 +0000

1=1 is not a security risk

New comment by paperplatter in "SQL Tips and Tricks"

paperplatter — Wed, 25 Sep 2024 16:19:28 +0000

I get how this isn't good. But how else would you handle multi-field filtering, keep all the ANDs and use (product_id = $1 OR $1 IS NULL) so the unset filters are no-op? That's ok as long as the query planner is smart enough.

New comment by paperplatter in "SQL Tips and Tricks"

paperplatter — Wed, 25 Sep 2024 16:16:59 +0000

Yeah, so often do I have an EXPLAIN ANALYZE query.txt file I'm repeatedly editing in one window and piping into psql in another to try and make something faster. So I put WHERE true at the top.

New comment by paperplatter in "SQL Tips and Tricks"

paperplatter — Wed, 25 Sep 2024 16:15:30 +0000

Sounds like that DBMS would work better with serial int PKs

New comment by paperplatter in "Support for IPv6"

paperplatter — Mon, 23 Sep 2024 20:47:54 +0000

I feel like residential ipv6 would be at least a little further along if routers simply always enabled NAT by default for it, like what cell providers do. Solves all these questions and problems for inexperienced users. Instead, you gotta ask, is the firewall enabled and default-deny, are ULAs enabled...

New comment by paperplatter in "Support for IPv6"

paperplatter — Mon, 23 Sep 2024 16:26:24 +0000

RFC 2765 isn't about keeping ipv4 blocks in ipv6, if I understand correctly. It's about translator boxes for ipv6-only hosts to talk to ipv4-only ones by acquiring temporary ipv4 addresses.

New comment by paperplatter in "Support for IPv6"

paperplatter — Mon, 23 Sep 2024 16:24:05 +0000

4-to-5 NAT would be effectively the same if that's what you use, but I don't see why you'd need one.

New comment by paperplatter in "CuPy: NumPy and SciPy for GPU"

paperplatter — Fri, 20 Sep 2024 19:04:27 +0000

Hm. Tempted to try pytorch on my Mac for this. I have an AS chip rather than a Nvidia GPU.

New comment by paperplatter in "Support for IPv6"

paperplatter — Fri, 20 Sep 2024 17:27:57 +0000

I agree then, the defaults are a problem.

New comment by paperplatter in "Support for IPv6"

paperplatter — Fri, 20 Sep 2024 17:14:36 +0000

I'm not saying we can avoid updating routers/hosts/DNS/etc, but it's only one piece of the migration puzzle. Otherwise we'd be done already. I elaborated when responding to a similar question: https://news.ycombinator.com/item?id=41603782

New comment by paperplatter in "Support for IPv6"

paperplatter — Fri, 20 Sep 2024 17:09:58 +0000

The second thing is the problem with not having NAT. On a home or corp network, I like NAT. I'm not trying to host 20 servers there. Sure ipv6 can use it too, but it's never default and often not supported on the router.

So yeah, 192.168.1.55 is my Mac's local ip, it's easy to remember.

New comment by paperplatter in "Support for IPv6"

paperplatter — Fri, 20 Sep 2024 17:02:54 +0000

But you're still using ipv4, which cannot be upgraded in-place the way I described. I responded to a sibling comment about the second question.

New comment by paperplatter in "Support for IPv6"

paperplatter — Fri, 20 Sep 2024 17:02:08 +0000

You still make the same big changes, but the difference is you don't have to do them all at the same time. You also skip the complicated add-ons of ipv6 and don't reassign everything.

Ipv5 as you call it: Phase 1 is getting routers/hosts to understand v5 headers, while users enable v5 and change nothing else. Phase 2 is the transition where people keep using padded addrs while things* are updated in-place to just support longer ones, which doesn't affect users**. Once that's done, we get to use the full space, which some users may ignore and some may use. For better and worse, the existing /32 blocks would still be around initially. Maybe this would appeal to previous ipv4 holders better; they still own the same % of the pie. Maybe 8.8.8.8 would stay forever.

What makes me kinda sure would've worked? Right now, the world has mostly already completed the equivalent of phases 1 and 2 for ipv6. There might even be a way to reuse the ipv6 protocol as-is for ipv5.

* DNS, NAT, DHCP, ARP, routers, VPSes, OSes...

** "User" includes corp network admins, cloud/datacenter operators, ISPs, and simple home customers.

New comment by paperplatter in "Support for IPv6"

paperplatter — Thu, 19 Sep 2024 23:52:47 +0000

Yes, everything has to be updated eventually, but going forward doesn't have to be this hard. A network and its hosts could start supporting ipv6 without changing anything else. Same addr and routes as before, same NAT, and no DNS6/DHCP6/etc, so very low effort and risk to turn it on. If a peer only supports v4, talk v4 to it for now.

Then once there's sufficient v6 adoption, you can disable v4 entirely and start using /40, /48, etc..

New comment by paperplatter in "Support for IPv6"

paperplatter — Thu, 19 Sep 2024 22:09:26 +0000

Yeah, the route fragmentation a disadvantage of what I've had in mind. My focus is just on getting things to speak v6 to fix the scarcity problem first. Maybe at some point the owners could've swapped addresses back to defrag things.

New comment by paperplatter in "Support for IPv6"

paperplatter — Thu, 19 Sep 2024 22:01:24 +0000

But then you're still using ipv4.

New comment by paperplatter in "Support for IPv6"

paperplatter — Thu, 19 Sep 2024 20:21:58 +0000

That's my proposal, ipv6 with extra steps. As in, incremental steps instead of one impossibly big change. tl;dr keep the pre-existing v4 /32 blocks day 1, and the rest follows.

Edit: I said "my" proposal, but pretty sure the same idea has been brought up many times.

New comment by paperplatter in "Support for IPv6"

paperplatter — Thu, 19 Sep 2024 20:08:36 +0000

Not so. IPv4->6 removes all existing v4 address blocks and redoes the addressing scheme. Those changes weren't necessary for expanding the address space. This implies that day 1 of using ipv6, all your addresses are different (and way longer), all your routes change, DNS DHCP etc all need to be swapped out, and bans/reputation are all reset with no clear replacement. And there were a bunch of smaller changes / new features.

Whatever you do to get more addresses, it will look similar in the end, but the steps could've been very different.

New comment by paperplatter in "Support for IPv6"

paperplatter — Thu, 19 Sep 2024 19:55:45 +0000

IMO the separate-stack nature of ipv6 was a mistake. I can see why they did it, but the changes could've been a lot more incremental otherwise, and we might've been done already. Everyone talks about the biggest change being the 128-bit address space, but the real leap is that pre-existing ipv4 blocks weren't preserved in ipv6.