That's fair, largely because an LLM is a lot more capable at overcoming restrictions, by hook or by crook as TFA shows. However, most systems today are not even resilient against what humans can do, so starting there would go a long way towards limiting what harms LLMs can do.
These fake-time environments let you set the time, so you can test how the code will behave in 2039 without waiting for 13 years. For Go's synctest, 1-1-2000 is just the default initial value for now().
* focus locally; getting invoked with local politics by supporting local candidates with your time and effort - the state department runs programs to talk to city and state officials concerning foreign policy matters and city’s and local governments can create pressure on federal representatives from those states.
* vote with your wallet; boycotts and divestments are tools ordinary people have to effect conglomerates. Ensure your retirement money is not invested with companies engaging with the political ideas you do not agree with
* protest; attending in person events shows leaders numbers and images that are harder to ignore than their consultants’ polling data.
I've done all of those and while I think they are important i believe it's most important to let politicians know, otherwise they rely too much on money.
Pointing that whatever people think they are doing is not working does not mean we have to propose a solution. I'd suggest revolution, but that won't ever happen in the US.
On Windows the accessibility APIs give you this. And as these same APIs are used for screen readers, automated testing, and AI access, supporting them is definitely worthwhile.
There are lots of legacy things in tcp/ip headers. One of them can be for the extra octlet.
When ipv4 legacy flies around, that oclet will be null or 0. The entire internet could route just fine, especially if you put the extra octlet at the end. 1.1.1.1 gets an extra 1.1.1.1.newoctlet.
So every existing IP gets a bonus 255 new IPs, and for now, routing of those is hardlocked to that IP, and it works with all legacy gear.
In 30 years or something, we can care about the mobility of those new IPs.
You're at the very beginning, baby steps stage of inventing IPv6 there.
You aren't the first person to come up with the idea of adding extra bits to IP addresses to make them longer. The problem isn't finding somewhere to stash the extra bits in the packet format (which is trivial; you can simply set the next-protocol field to a special value and then put the bits at the start of the payload), it's getting all software to use those extra bits -- and getting that to work requires doing all of the new AF family, new sockaddr struct, new DNS records, dual stack/translation/tunnels etc etc that v6 does.
Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.
Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.
It is possible for the world to change, and for designs and plans and viewpoints 30+ years ago to be less correct today.
This world is not that world. That world had massive concerns about the processing cost of NAT. That was one reason for ipv6. It also had different ideas about where the net would go. We now know that the "internet of things" and "having your fridge online", as well as "5G in everything so people can't firewall it off" is just insane and malign.
We also know that tying an IP address to a person (compared to an ISP using NAT) reduces privacy. That devious and devilish actors abound.
Even though they thought these things might be neat, many of them aren't.
None of that has anything to do with what you said in the post I replied to. "Add an extra octet to v4 addresses" has hard technical barriers to deal with if you want it to work, regardless of what the world looks like or what you're designing for.
> We now know that the "internet of things" and "having your fridge online", as well as "5G in everything so people can't firewall it off" is just insane and malign
None of this is really relevant either. IP's job is to handle the addressing used when sending data over the Internet, and it should do this job well regardless of what people end up doing with it.
> We also know that tying an IP address to a person (compared to an ISP using NAT) reduces privacy
We don't tie IP addresses to people. PI allocations might sort of count, but regular users don't get those.
None of that has anything to do with what you said in the post I replied to.
Of course not, why would it? I quoted what I was replying to, and all of my comments made perfect sense in that context. In that context, I was discussing the winning ipv6's original design considerations, and yes "IPs for everything" was one of them, hence me talking about it.
I intended the quoted part to mean something like "they did consider adding extra octets to v4 addresses and setting those octets to zero to mean v4".
It's not like they weren't able to come up with that idea. It's just that if you follow that train of thought through to its conclusion, you'll either decide it can't work or you'll make enough changes to end up with something that works basically the same way v6 does.
But yes, having enough IPs for everything was obviously a design goal. It would be excessively silly to go through all the work to increase the address size and not increase it by enough to handle whatever people ended up wanting to do with it.
> That world had massive concerns about the processing cost of NAT
The processing cost of NAT is still a problem. There's that classic post by a Native American tribal ISP where it was cheaper for them to pay to replace their clients IPv4-only Roku devices with IPv6 capable Apple TVs than to upgrade their CGNAT appliance to handle the video traffic.
The concerns about the "processing cost of NAT" were edge concerns. Companies, homes, edge-devices with 100 or 1000 RFC1918 addressed devices behind them. When ipv6 was created, NAT wasn't a thing, as processing power just wasn't there.
And it was thought the processing power would never be there.
Yet now everyone has NAT in little devices at home. So the need to route 100 IPs into every person's home isn't a thing. Which is inline with my comment about how the world looked different 30 years ago, and how the concept of "IPs for everything" is the reverse of what people even want now.
IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get, basically, the same effect as moving to IPv6.
> IPv4-with-more-bytes is not backwards compatible with IPv4
Neither is IPv6
> To get, basically, the same effect as moving to IPv6
The only thing that IPv6 solves which is of interest to 99.99% of the users is having more adressable space. The rest of IPv6 features are either things that nobody asked for, or things which are genuinely worst compared to IPv4.
I consider the mere fact of enabling IPv6 an unacceptable security risk, as I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. That would be trivial with IPv4-with-more-bytes, it's a nightmare with IPv6.
> I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other.
You'd still have that in your IPv4-with-more-bytes, as you'll still probably end up running dual-stack to address those old-v4-only sites. Or you'd do the same with v6 and run a tunnel to translate those v4-only addresses to your v4-with-more-bytes. So you're in the same situation either way.
There were backwards-compatible protocols proposed, such as EIP, but the committee chose a backwards-incompatible protocol for v6. Their assumption was that v4 would run out of space in a single-digit number of years and everyone would be forced to migrate. The past 30 years have shown that not to be the case.
They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.
Yes, there's a compat-shim in the stdlib/runtime, but not in the language syntax. E.g. it by-definition won't do escape-analysis and optimize discriminated value-types with the first-class keyword.
University degrees certainly used to teach computing fundamentals without you having a computer in front of you.
reply