mahboi

The only one I can think of is, having a better idea of which way the presidential election goes might've been useful for some people, or some other large election. There's a lot of egg on the faces of all these mainstream media polls.

Yep. Hope they kill Kalshi.

It's the least inaccurate way. There's money to be made if you're sure you have a better way. The real problem is we're already seeing these markets influence the outcome.

Besides the brokerage being regulated, stock markets are regulated.

Wonder how VPNs play into this, since Utah was recently in the news about an age verification law that basically said you're liable if anyone physically in Utah accesses a restricted site.

Also "Utah is one of only two states where gambling is also prohibited under the state constitution"

Yeah that too, so only the big ones. Obviously the law can't distinguish since it's all the same kind of gambling.

I liked it for political races as an alternative to polls. Was terrible for several other things. 99% of it was really just sports betting, which I can't see being a good thing.

Oh also, last time I used this was years ago, and I'm willing to try Debian next time I use desktop Linux now that uh things have changed

I'm referring to the ubuntu-drivers thing. You can do the equivalent in Debian if you add non-free repos and find the right packages, it's just more hassle. But if all you need is GPU drivers, no need for that tool.

At least Debian is on Wayland. Mint is on X11, which was causing black screen out of the box on my fairly typical PC.

Just because I can reconfigure the entire OS to work on my computer doesn't mean I want to

Desktop Ubuntu purely because of the drivers. Normally used Debian for my own servers, but haven't done that in so long, and Ubuntu is often default on cloud providers so yeah.

It can't. You use 32-bit only until enough hosts are on ipv5.

I wanted switching to v6 to involve the minimum necessary changes. You keep your old /32. If you're sending from a /32 to a /32, it follows the same path of routers that an ipv4 packet would follow, that's what I meant by same route. There could be a v4-only router in the middle requiring translation, but I'm not even assuming that's a common issue at this point.

"or a superset in the later stages (shared down to /32, v6-only in deeper subnets)": The ipv6 state would be a superset of the ipv4 state. So if a router owns 1.2.3.4 in v4, it also owns that in v6. The ownership of 1.2.3.4.5 below that would only be part of v6 state.

What we got instead was two separate states, or parallel networks. Switching to v6 means changing everything all at once.

> Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?

It's not that simple, otherwise they would've done it. They have stuff like multiple addresses, geo DNS, and rate-limiting. Separate issue, AWS was v4-only for a long time and still treats it as more first-class because of how many internal things need to change for v6, well beyond just having hardware + OSes support it.

IPv4-compatible v6 address was only for dual-stack hosts talking over a v4 network. They still had their own v6-native addresses that they had to use if they wanted a v6 network. So this isn't what I described where the v6-native route is the same as the v4 route, or a superset in the later stages (shared down to /32, v6-only in deeper subnets).

The thing I want to solve isn't just v4 routers in the middle, that's more of a bonus. All the routers between my machine and any service probably support v6 anyway, but a bunch of services are v4-only because of the migration effort. They should be able to turn on v6 without having to change everything about their networking.

By not sharing state, I mean v6 doesn't honor v4 routes/addresses, DHCP state, and DNS entries. They made all-new address blocks. This seemingly never gets talked about for how big of a deal it is. That makes it so enabling v6 instantly means reworking your entire network, not just speaking a different protocol.

Say I have 1.2.3.4/32 in v4. Let me keep that in v6. Just getting everyone onto v6 is a big enough change without also changing the routes. If I talk to 9.8.7.6 and it's v4-only, fine, the last v6 hop translates to v4. Even DNS doesn't strictly need to change yet. Then let's say enough people get on v6, so I hand out 1.2.3.4.5 to some host. If 9.8.7.6.5 wants to send to that, but there are some v4-only routers in the middle, no problem. The last v6 router translates to v4 dst=1.2.3.4 and puts the extra address bits in the payload, then when it reaches my router, it knows to rewrite as 1.2.3.4.5. Even in this later state, you really only need v6 support on the ends and any routers going deeper than /32.

DHCP and NAT state on LAN too. My home router should be able to speak both protocols while sharing all state. A host at 192.168.1.2 should be able to just turn on v6, it's still 192.168.1.2, some other host gets leased .3 instead, and the router knows to translate if .2 and .3 want to talk. I don't want it to suddenly be FC00::whatever.

I have no complaint about the v6 header, and a subset of the v6 protocol is fine because it's indeed just v4 w/ extra bits like you said. That ipv5/whatever proposal people keep making is doable with most routers/hosts just seeing it as ipv6 w/ DHCP+NAT.

And yeah, today I could use DHCP6 if I really wanted, but it'd mean lots of incompatible devices get either booted off my network or put on a separate SLAAC one, so it's not a serious choice. NAT66 is way more doable but also rare on consumer routers. So my only complaint about the protocol is that the defaults are backwards.

It's not NAT64 or 6to4. An ipv6 host doesn't own such an address; it goes to a relay, and the v6 host is using a random unrelated v6 address. The ipv5 thing is ipv6 natively using ipv4 /32s.

No, the field should be 128-bit to have headroom, but you don't need to hand out /128s to everyone. Everyone with a /32 now would be fine with /32 or /40.

I know. All these things were possible and completed for IPv6, but that's only part of the battle. The rest is making it easy for users at various levels to migrate. IPv6 didn't do that, that's why we're stuck in today's situation.

There's no requirement to change DNS upfront if your IPv6 addresses are 32-bit. V6 translation to/from v4 should be doable at any hop instead of relying on a flaky anycast relay. You shouldn't need a different DNS or DHCP server for IPv6 either, only one that supports both protocols (also shouldn't be forced to use SLAAC).

IPv6 also had an upfront requirement to change all existing routes, which is huge. That shouldn't even be needed in the final step. It should just be that people start using longer addresses given that both ends are v6. Even still there should be no requirement for every hop along the route to be v6, only the ones that go deeper than /32 near the ends.

I didn't say it's about being used to one. It can be "in the 20s" C for multiple months, kinda silly. 22.0˚C also feels different from 22.5˚C. There's a right amount of granularity for temperature and for speed.

Foot and pound have unambiguous meanings in the US. There's a reason the whole survey foot and gold-pound thing is trivia that nobody knows, they're niche or abandoned systems that you only use if you're being clear that it's not regular feet or pounds. I also know that the US system is technically not "imperial," but nobody cares.

6to4 and NAT64 are not what I'm saying. Those involve a relay server and v4 translation, and there's an entire memo on why that's unreliable and abandoned. I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.

The world is already managing with 32 bits of addresses plus NAT, and NAT most likely gives you less than 256 concurrent users per address. But sure, if some cheap ISP only owns a few /32s and needs to use more octets, let them do that, doesn't mean my 4-octet address needs to be super long too.

You're kinda forced to use 128 bits in v6 if you're an end user, cause that's the lowest common denominator. SLAAC is default, DHCP6 is widely unsupported. Most ISPs also only give out a /64 per spec minimum.

Yes it's 3A. They didn't need to make the new protocol have separate state from the old one. Let me keep my old address on the new protocol.

Yeah it's in the wild, but random crappy software isn't the reason all these big services are v4-only. Transitioning from v4 to v6 requires redoing your entire network, except you still have to maintain the v4 side until everyone else has done this. So it's not worthwhile unless you have an easy way to go v6-native and only use v4 at the ends, eg cellular networks.

Even if I owned my ISP, pretty sure no other ISP would honor that announcement. That's a reserved 6to4 range.

IPv6 invalidated the existing IPv4 addresses, changed the addressing scheme, and de facto got rid of DHCP and NAT in favor of SLAAC and global routing. It doesn't share any state with v4. This was a very different set of choices from just adding more bits to v4.

They don't need to be really long. Adding one more octet to v4 makes it 1 trillion addresses. Sure the header should support longer than that, but it doesn't mean everyone needs to use all of it.

V4 address blocks, DHCP, and NAT, not SLAAC. So if I have 1.2.3.4 in ipv4, my ipv5 address is also 1.2.3.4. Ipv5 isn't a separate network from v4, it shares all the v4 state, and I can enable without giving it much thought. And once there's enough adoption, I can start handing out addresses like 1.2.3.4.5 that are incompatible with v4-only hosts.

Nah, the details in the spec all have good reasons, but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.

I would like 71.177.17.171, encoded as 2002:47b1:11ab:: or whatever static prefix, to go directly to my router as v6 packets without ever being translated to v4. 2002:47b1:11ab:: doesn't do that, it goes to a 6to4 relay and is translated to v4. I'm pretty sure every ISP will at best give you a v4 /32 and an unrelated v6 /64. I don't want that separate v6 address, I want the same logical address for both.