paperplatter

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

1=1 is not a security risk

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.

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.

Sounds like that DBMS would work better with serial int PKs

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...

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.

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.

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

I agree then, the defaults are a problem.

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

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.

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.

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.

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..

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.

But then you're still using ipv4.

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.

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.

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.

Seems clear that he considers Rust a good thing. And if he hasn't gone back on his C++ opinions, that would suggest he likes Rust way more than C++, right?

I know how to compile and link C. I've never done C<->JS FFI but could probably figure it out. But if I have relatively small C code in single files, why bother? I'll take the easy route unless there's a clear reason not to.

The thing is, I'm not already using the Bun runtime and wouldn't switch just for this.

Not Android

If they want to be for-profit because that's how they get the investment to build GPT-4, fine, do it from the start. That doesn't justify the switch.

So does OpenAI, the nonprofit, own a for-profit corp that does everything?

(Which btw isn't exclusive to emojis, there's also Hangul Jamo that the Unicode standard says is used for "archaic" Korean characters, but emojis are probably the main use case.)

Refs in C++ go against this, right? At the call site, it's not clear that you're passing in a ref instead of a value. I don't mind it too much cause at least the rules are the same for everything, not different for structs vs classes.

It can get tough with the native dependencies involved.

For some apps, I can see this. Question is, did the startups regret taking the shortcut upfront, or were they fine paying later for the improved version?

Btw, sometimes I think about how much I've been paid by various people to move a backend from SQL to NoSQL then from NoSQL to SQL, despite me telling them not to.

Ah, it's coming back to me now. I remember when they fixed that and I was relieved.