Is your complaint about Anubis? I see the "checking if you are human" kind of text too when going to codeberg, but it is usually only a second or two. It is because I run a bit of obfuscation and resistance to browser finger printing.
But you find seeing the text for a couple of seconds too annoying to use codeberg? Maybe it is more than 2 seconds for you?
Everyone has their views on what is acceptable in the world and what they will put up with. Just, to my point of view, I think codeberg is trying to fight the good fight in keeping llms from crawling their website.
Question for mermaid users out there. I have not used mermaid more than just superficially looking at it but it looks to me like a re-implementation of graphviz? Which has been around forever. Is there something it does that makes it more appealing?
I am not knocking this Free Mermaid Diagram Editor either. Seems decent. But, similarly, edotor has been around forever.
When news broke about the affair, I remembered, 6 months prior, watching an episode of the Daily Show where Jon Stewart interviewed Paula Broadwell and they even made jokes about if her husband was jealous of her spending so much time interviewing David Petraeus.
I sort of agree with the idea that LLMs are great (sometimes) at distilling all the quantifiable things they have churned through into something similar or, perhaps, putting together things that someone has not thought of putting together yet. And not so great at the intangible things, like good taste.
But, quoting "We've reached a dangerous moment. This moment threatens to convince too many of us that our lived experiences do not matter."
I think that "moment" was long before AI LLMs came around. I can only speak from my lived experiences, and I would say the tech industry and capitalism already put a low, low value on "lived experiences". Take game development, it seems to me, that big game studios rely on "a new fresh crop of college grads" will appear every year. We can push them as hard as we can. Hopefully, they will quit, and we can hire another batch.
I see it too, with lower wage jobs. No point in trying to keep our burger flippers happy. They are going to quit. Might as well factor that into the equation and just make a system with a revolving work force. No commitment. No retirement plan.
Agreed. The best time to form a union was 20 years ago (Especially because Tech Workers had leverage because they were in demand). The second best time to form a union is today.
I jumped to a similar conclusion right away and popped over here to comment only to find you have beaten me to the punch. I use to keep a work wiki page of common problems the team encounters over and over again.
Years ago, I stumbled upon the "idea" was already debated in other fields long before programming. Lumpers and Splitters.
I wrote a while back,
Most of the executives I have met really have no clue. They just go with what is being promoted in the space because it offers a safety net. Look, we are "not behind the curve!". We are innovating along with the rest of the industry.
I love fossil. Something about it's opinionated workflow that matches what I think. But
network effects. I just can not bring my team to use fossil. They have to share code with others. Other departments. And everyone (99%+) uses git. It just feels like a disservice to force them to use fossil. It is a catch-22.
It is similar to so many other things in the tech space. Trying to get fellow developers to use functional style idioms. Trying to enforce immutability. It is like something big (like a facebook or google project) has to force the community to get on board.
Many years ago. Maybe 2005 to 2015? I had a friend who used cpanel to run a web hosting company. He made quite a bit of money doing that. He was not a programmer, but he could setup up wordpress and install plugins. I remember asking him once if he was worried he would get hacked and then lose control of his servers? Lose his customers?
He said he was worried but he had backups upon backups. I saw him restore a bunch of websites once, using cpanel, and I thought it is an amazing little bit of software with all of the click a button to setup many different things (like WAF). A real time saver and provides some guidance if you are not a unix-internet guru.
I always liked looking at the maps different people have made over the years. It is interesting how they can come out looking different but represent the same latent space.
ipv6 was standardized in 1995
6to4 was standardized in 2001
6to4 is not used in any meaningful way today.
What was missing was ipv6 should have had 6to4 (but better) in it, in 1995.
Now, I could go on about what is wrong with 6to4, but every new topic is just another surface area for ipv6 proponents to launch another question (I sometimes suspect in bad faith).
The embedding I believe you are referring to is not a part of the global routing model. (maybe I am wrong?) What I am describing is making that kind of declaration central to the system in a deterministic, network wide mapping of ipv4 to the larger ipv6 space. The translation in ipv6 ended up being handled by a mix of mechanisms after the fact, rather than a single, uniform mapping model that tied directly to the address structure. I think part of the problem is they did not put that front and center, at the beginning, when doing the initial specification.
Opening a dual stack ipv4 and ipv6 does allow the service to accept both ipv4 and ipv6 connections. But I do not think that is what zadikian is getting at?
It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity.
6to4 was an attempt at that kind of embedding and I do not think it succeeded?
The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.
I remember reading about that a long time ago. I wonder why it never really caught on?
I think part of the problem is not so much a technical one, as a coordination issue. Who are you more likely to get on board? ISP and backbone providers. What is the path forward? Here is the recommended path forward, kind of thing.
I went and re-read point 3B. I agree that some hypothetical ipv42 faces a translation problem.
But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic.
In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable.
In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts.
Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.
You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do.
But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.
I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4.
Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.
Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized
Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).