That's true to a point, but Amazon is finding out the hard way that eventually the well of people willing to put up with bullshit runs dry and it becomes much harder to get actually good talent or workers.
Meta needs to be careful IMO. The subset of capable people willing to work for a company as demonstrably evil as them is not infinite.
Not that I don't agree, but PKI relies on a trusted authority which can be compromised. If you're running a trustless system, basically any party can be compromised but the blast radius is limited to just the compromised infrastructure and money, not the entire system.
> "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes."
>
> Now this is a good idea that I've never seen in a VCS.
There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited success. Honestly, it may have even been done for proprietary languages and VCS systems that have since faded into obscurity.
I'd settle for searching the git history for a particular regex/string and then running a blame on that.
Based on my understanding, PLC is centralized primarily because there needs to be a global, authoritative source of truth for the current state of a given plc. You could in theory namespace a plc to a particular directory instance with a backwards reference or something, but I don't think it buys you anything when in theory you can just choose to trust a different PLC directory at the read/application layer if you really need.
At the end of the day, truly fully decentralized systems are literally impossible, there's always a centralized aspect (at least for bootstrapping) and it's usually DNS-shaped.
That being said, PLC directories are a problem that blockchains (yuck) actually solve very well: trustless, public ledgers. I would not be surprised if we see a separate implementation based on an architecture derived from such systems.
Companies are also much more inclined to spend money to solve a problem while hobbyists are much more likely to get enjoyment out of the process of building. I'm firmly in the latter category, having built a rather robust ZFS array on NixOS with a pretty gnarly NVMe cache hierarchy built on LVM. It was fun to do.
I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
It really isn't comparable. Sure, nixpkgs is huge, but the surface area for what you need to understand and work with is considerably smaller. They aren't even really in the same domain anyways. I was able to get very comfortable with Nix(OS) in a single weekend, but it took me months to get to a similar level with the K8s ecosystem.
I use NixOS with nginx + acme / caddy, coredns and no docker anywhere. It's extremely homogeneous, easy to scale out (add another flake output, deploy to a new server, update DNS records). You could easily automate some of that with more nix, but I don't bother because that's already only like 50 lines of config.
I have a strong preference for renting bare metal and it has served me extremely well.
The driftless area certainly has some truly beautiful parts, but my statement is less about the homogeneity across the entire region and more about the distance between any notable landmarks. Hills alone aren't really that interesting either and I stand by my statement that most of the Midwest is boring and flat.
The Midwest in particular is extremely homogeneous and flat, mostly plains and farmland for hundreds of miles. The West cost has more in 15 miles than the Midwest has in 100, on average. There are pockets here and there, but not enough to warrant the several hour drive it will take to get there.
Honestly, most of the US is like this. It's huge and very, very sparse.
That violates the worse is better principle which has held true since the inception of software.
Switching costs are real. It's not that hard to make an improvement, but it's very hard to make an improvement that justifies the cost in both money and time.
0: https://www.theguardian.com/technology/2022/jun/22/amazon-wo...