My favorite Peanuts comic was always the one where Linus is standing at an intersection next to a 'Push Button To Cross Street' sign. He is sucking his thumb and clutching his blanket despondently.
In the last panel, Charlie Brown tells him, "You have to move your feet, too."
Not clear what your point is. The Signal server wakes up the app via an empty message. At most the info this conveys is that a Signal app got a message to pull.
My point is there is no reasonable way to remove oneself from Google and Apple even with a fully custom application, they control the notification servers for their devices.
At what point could I confidently publish the addresses 1:2:3:4:0:0:0:1 and 1:2:3:4:0:0:0:2 in DNS records for people to reach those two servers? After my ISP has switched, or after everybody's ISP has switched?
There are two groups that should update to v8 in order to be fully functional: users' OS net stack and ISPs' infra.
The incompatibility of IPvs between two endpoints can be solved by a couple of mechanisms. One is to make a preflight check if all nodes support v8, another is to start with a flag isv8=1 and change it along the path. If a single node is still at v4, all the communication continues v4-like (the v8 nodes send 0 at the ls32b).
It will be a gradual migration, in some regions faster or slower, but it will be SEAMLESS for the user, without the awful v6 UX that we have now.
The answer comes from the suggested design: you update your DNS right after you run the new stack, irrespective of what others (ISPs and users) do. The records will initially still function as v4 (discard the lb32b). Only when all others switch, they will enable their full length.
Obviously there should be simulations and refining to avoid edge cases and conflicts. I will not design the full spec.
So anybody without the new stack loses access to your site, because they're querying for the A record that you removed. How is this "a gradual migration" or "expanding the address space without inventing a new stack"?
Nobody will want to switch to the new stack if it means instantly losing clients that don't have the new stack yet, so the only way to switch would be to coordinate everybody on the planet to switch simultaneously. This is as far away from a gradual deployment as you can get. A flag day for the Internet isn't viable, no matter how much you shout it.
These are not edge case questions we're asking here. They're fundamental questions about how to expand the v4 address size without ultimately doing the same things v6 had to do. You don't need to design the full spec, but you don't get to argue we should replace v6 if the best alternative approach you can come up with works the same way v6 does and has the same limitations v6 does.
So you haven't solved the incompatibility at all. Your v8 requires the client, server and everything between them to support v8 or it has to fall back to using v4, just like v6 does.
> There are two groups that should update to v8 in order to be fully functional: users' OS net stack and ISPs' infra.
A lot of software hardcodes AF_INET or sockaddr_in, and so can only handle 32-bit addresses. Also, there's the end-user's border router, and any internal routers on the client or server side, and the LANs on the client and server sides. There are databases, protocols and data structures that store IP addresses. Any attempt to use v8 with any of these will break them even if half of the v8 address is set to zeros, because they can't handle the 64 bits of a v8 address. They'll either reject the address or it'll corrupt the next 32 bits of memory. A seamless update to the OS net stack and ISP infra isn't sufficient to make them work with v8, because they'll still be limited to 32 bits.
I understand that your core idea is to say that a subset of the v8 address space maps directly to the v4 address space, so that you can convert that subset to v4 to work with the above things. This idea itself isn't bad; it's a perfectly sensible backwards compatibility mechanism that's used by v6 too. You're correct that it allows just that subset to be passed to an application over an AF_INET socket, used to send/receive v4 packets to the corresponding v4 address and so on. This approach is seamless if you stick to exposing the addresses as v4 addresses rather than as v8, because then they could be handled the same way v4 addresses are.
The problem is, you can only make it seamless by hiding the full v8 addresses and pretending they're v4, which can only be done for a small fraction of v8 addresses. What about the rest of them? You haven't actually extended v4's address space past 32 bits, so if you want to use v8's extra addresses you'll have to expose the full v8 addresses as v8 addresses, which is no longer seamless because that's a whole new stack the user and their software has to deal with.
If it was possible to seamlessly switch to bigger addresses, there would be no reason to restrict yourself to the subset of v8 addresses that end in :0:0:0:0 in the first place. You're doing that because using bigger addresses isn't seamless, which is an acknowledgement that a seamless upgrade to bigger addresses isn't possible. It would be if they were the same size, but then you've failed your goal of extending the address space.
So no, you can't claim this upgrade would be seamless unless you can remove the part that's only in there because it's not.
> If a single node is still at v4, all the communication continues v4-like (the v8 nodes send 0 at the ls32b).
If a single node is still at v4, that node will drop your v8 packets even if you set the ls32b to 0, because it doesn't understand the v8 packet format in the first place. This node will prevent you from switching to v8 even if you stick with the limited v4-compatible subset of v8 addresses.
> it will be SEAMLESS for the user, without the awful v6 UX that we have now
That "awful v6 UX" is the same UX you'd get with v8 if you tried to use the expanded address space. Or, if you limited yourself to just the v4-mapped subset of v6 then it would be just as seamless as v8 is. This should be obvious, because you already lived through OSs adding support for v6 in their net stacks and it was seamless so long as you stuck to the part of v6 which maps directly to v4. Which is what you were asking for, wasn't it?
I read through some of the discussion on Wikipedia. The operator of the bot comes across as agreeable and arrogant at the same time.
Questioned about it, he's asking his rig why it did something and quotes verbatim from the generated text. Then when a Wikipedian asks how the bot logged in, berates them how it's all ephemeral code and he could only guess.
The overall attitude is that this was going to happen anyway and we should feel lucky he's so helpful. I rather agree with another commenter here that this was "pissing in the fountain". Whatever pure motivations there may have been, cleanup was left to others.
What I want to see is a dating service where I can pledge some money to some charity. Everybody on the site can check what I've pledged, and I can release it anytime. The service can take their cut, fine.
Now when I meet somebody through the service, and we think it's serious, we can release that money. And we can check whether the other did too!
Sure there will still be profiles with people that don't pledge, because they're just testing the waters, or poor, or scammers. Whatever. Point is I can send a signal that at some point I want to be done with the service, and then pay them for that.
I don't think it's as easy as looking at open weight API prices. We don't know whether the operators are making a profit on all the hardware they bought. Maybe the prices we pay just cover electricity. And it's not even certain that running costs are covered by API prices: The operators may be siphoning content and subsidize from selling that.
In the current volatile environment, the API prices are more of a baseline where we can assume it can't be much cheaper to operate these models.
That doesn't make sense in this environment because everyone is compute constrained with huge backlogs they can't fulfill. If these inference providers aren't making any money, they'd simply sell their GPUs to those who are starved for compute.
I wouldn't call it cheating. But I have no trouble drawing lines that exclude some people, if that levels the field for a bigger group. In this case the female olympics would soon be known as the intersex olympics given the selection pressure. I can understand the decision to make the competiton more interesting by barring intersex people. No need to frame it as cheating though.
Since we don't actually do genetic tests at birth, this would only ocurr in the context of national qualifying, think about what the experience of someone who trains to be good enough to qualify for the Olympics, then gets this test and is told, "Sorry, you aren't really a woman. Too bad. No Olympics for you. Sorry you wasted all those years training."
How else should the person who just got that information interpret it except... Sorry, you're not really deserving, even though your score qualifies you. And what do call someone who has a score that qualifies but doesn't get to go?
And there are far more of people with this experience than the experience of being born and treated by society as a man and becoming an Olympic athlete as a woman.
Why assume trick ingredients?
reply