All IPv4 addresses can already be represented in the IPv6 address space, by the same method you describe here.
As for "backwards compatible with IPv4", I'm afraid that's not possible for the same reason IPv6 isn't getting major traction. Right now, we literally CANNOT upgrade our entire networking infrastructure. What you're proposing requires updating every switch and middlebox to support routing using additional bytes, which is physically impossible. The biggest problem would be middleboxes, which includes NAT router, firewalls, etc. For context: most middleboxes drop anything that is not IPv4/TCP or IPv4/UDP. This is why QUIC is encapsulated inside a UDP header (and funny enough, these vendors STILL didn't learn, trying to match a "QUIC header" despite Google themselves saying there is no fixed QUIC header), and RoCEv2 using a header that looks like UDP. There is absolutely no way a new L3 protocol that is not IPv4 (and in some cases, IPv6) can be supported by these boxes.
The only time we successfully replaced the L3 protocol was with the adaption of IPv4. In which networks were much smaller, and networking research was under the US DoD. The DoD basically gave an ultimatum that "if you don't switch to IP by this date we will cut your funding". That won't fly now that the Internet is managed by a cluster of ISPs.
Also: IPv6 is stupid simple. It's basically IPv4, with everything not commonly used stripped out (and added back with "optional headers", and a much larger address field. Since the address field is much larger, it is recommended to write them in hexadecimal, which looks more scary than IPv4.
Side note: I don't think any of these IP protocols is the solution here. If you only keep extending the address field, you're still gonna run into IP problems (routing, ddos, caching). The future of the Internet should be something like NDN. But for the same reason I described above, I don't think that's going to happen unless the Internet is a pile of smoldering ruins.
Sounds like you got lucky. libgdata was part of the second round of attacks and was quickly reverted. It's likely you're running the last official release.
libgdata here is specifically very messy. It was an official package since it was a required dependency for older versions of GNOME, then in GNOME 50 they dropped the dependency and so did Arch from their repos. But because pacman doesn't remove dangling dependencies, you end up with libgdata still installed, until Arch Linux moves dropped packages into the AUR as an orphan, which happened in this case 5/31. This allowed it to be perfectly timed for the attackers to pick it up on 6/11. Now, you'd inadvertently update libgdata from an AUR source if you're using an AUR helper.
Disclaimer: I don't smoke anything, so I don't know any details.
Wouldn't a button connected to a heating coil be a fire hazard? Is there no automatic shut-off based on temperature? If you add enough safety features, it might end up costing about the same as an embedded SoC.
Because an existing SoC at scale is cheaper than a custom ASIC.
You see this all the time, custom keyboard running ARM+Linux, SmartNICs using RISC-V cores/FPGAs instead of ASIC accelerators. Even Microsoft refuses to commit to ASICs for network processing in their DCs and use FPGAs instead.
They were banned banned. No showing of any phones in class/hallways/dorms etc. If a teacher sees a phone anywhere they're supposed to confiscate it and call the parents.
Granted, actually happened was that a few exam top scorers carried a phone in their bag since they "needed it in case of emergency contact from prep school". The teachers turned a blind eye to it, and of course, the parents were also in on it. What are you gonna do, suspend the ranked No. 1 student? If anything, the only people targeted were kids with bad grades, or didn't fit in with the "prime and proper" image the school was cultivating.
Back in the BERT days I had a physics major friend that stuffed a bunch of Norwegian names in a file and trained a Norwegian name generator. He also made a Moby Dick sentence generator for funsies.
PewDiePie's project is nothing different than a personal pet project like these cases. Nothing about being a YouTuber makes you an expert at machine learning. It should be treated the same way as any other pet project.
If the concern is someone with large amounts of influence causing disproportionate harm with their personal projects by name alone, at least in this particular case, I feel it's appropriate to blame someone who trusts a YouTuber's pet project in the first place.
Before anyone comments saying "only the brain damaged would apply for a green card now", I would like to point out that the timeline for PR takes anywhere from years or decades.
These aren't people who filed after T-virus got in the White House, these are people who have been betting their lives and savings on living in the US 10-20 years ago. If you pull out now, it may be viewed as a negative factor to bar you from ever seeing your friends and family in the US ever again.
This is practically impossible. We have proverbially locked the keys in the room. IP/UDP/TCP are here to stay due to the prevalence of buggy/nonstandard middleboxes (hardware firewalls, ASIC switches, NAT routers) in the Internet.
We have new protocols, new theories for networking (look at NDN, in which is physically incapable of being censored or ddosed). However, anything that doesn't conform to existing IP/TCP/UDP will get dropped by these so-called "middleboxes". Even things that DO conform to IP/TCP/UDP will sometimes get dropped by these middleboxes (e.g. new TCP extensions, QUIC, etc). We cannot build an Internet replacement without almost fully scrapping every piece of networking equipment deployed since the 90s.
Middleboxes were supposed to be a temporary solution until we could transition to a new protocol like IPv6. Companies went for the cheap solution and violated the end-to-end principle of networking instead. Now we're paying the price and stuck with it.
Because the goal is to get people to learn/think about something. We don't care what you use as long as you retain knowledge taught in the course. If what helps you learn is LLMs, then go for it.
Problem right now is there is a significant amount of people that are using these tools to do the thinking for them. And this is when Office Hours, Homework feedback, Email (I guarantee all students emails are responded to within 24hrs. Most are handled within 30 minutes) are all available and paid for (by tuition). I am even happy to schedule one-on-ones if privacy is a concern, but none of this is being utilized.
Networking researcher here chiming in.
All IPv4 addresses can already be represented in the IPv6 address space, by the same method you describe here.
As for "backwards compatible with IPv4", I'm afraid that's not possible for the same reason IPv6 isn't getting major traction. Right now, we literally CANNOT upgrade our entire networking infrastructure. What you're proposing requires updating every switch and middlebox to support routing using additional bytes, which is physically impossible. The biggest problem would be middleboxes, which includes NAT router, firewalls, etc. For context: most middleboxes drop anything that is not IPv4/TCP or IPv4/UDP. This is why QUIC is encapsulated inside a UDP header (and funny enough, these vendors STILL didn't learn, trying to match a "QUIC header" despite Google themselves saying there is no fixed QUIC header), and RoCEv2 using a header that looks like UDP. There is absolutely no way a new L3 protocol that is not IPv4 (and in some cases, IPv6) can be supported by these boxes.
The only time we successfully replaced the L3 protocol was with the adaption of IPv4. In which networks were much smaller, and networking research was under the US DoD. The DoD basically gave an ultimatum that "if you don't switch to IP by this date we will cut your funding". That won't fly now that the Internet is managed by a cluster of ISPs.
Also: IPv6 is stupid simple. It's basically IPv4, with everything not commonly used stripped out (and added back with "optional headers", and a much larger address field. Since the address field is much larger, it is recommended to write them in hexadecimal, which looks more scary than IPv4.
Side note: I don't think any of these IP protocols is the solution here. If you only keep extending the address field, you're still gonna run into IP problems (routing, ddos, caching). The future of the Internet should be something like NDN. But for the same reason I described above, I don't think that's going to happen unless the Internet is a pile of smoldering ruins.