Easy multi-accounting is something that I hope we already have (`foks key switch` is pretty smooth). It's a feature I use a lot (I have a personal account on @foks.app and our company account is on @ne43.foks.cloud).
This is a great point and I thought a lot about this. This is the sort of thing that can be changed later if it's really a good idea, but I got to thinking that having non-local admins would mean more server-to-server communication and more server-to-server trust, and I was trying to avoid that.
Imagine alice@foo is an admin of bluejays@bar. One thing alice@foo will need to do is to make signed changes to bluejays@bar, when adding or removing members, let's say. Right now, the server at bar will check the validity of these signatures, that they were made with the alice@foo's latest key. So in other words, there would have to be some way for bar to authenticate to foo to allow bar to read alice's sigchain and to determine her latest key.
I was thinking that keeping foo and bar separated was a good idea both in terms of privilege separation and keeping the network simpler (which would in turn be good for uptime and would simplify software upgrades).
Anubis is not meant to fully stop bots, only slow them down so they don't take down your service. This kind of bot detection is meant to prevent automation.
I think the author misdiagnoses the problem, and the proposed solution simply hides the centralization instead of removing it.
The reason AWS is expensive is not because of IPv4, or the datacenters. It's mostly in their software/managed offerings, and the ability to quickly add more servers. If you are a "serious company" and you don't want to pay AWS or a similar company, renting a rack and colocating your own servers (either within your premises or in a datacenter) is doable and done by lots of companies.
I disagree that certificates have caused centralization, and they're not something separating the haves and have-nots and are in no way comparable to having or not a mainframe. HTTPS becoming pseudo-mandatory didn't push people into having their own (sub)domains, which is nowadays the only requirement to obtain a certificate. It already happened out of convenience.
The other point of centralization mentioned is DNS, which tailscale doesn't avoid at all. MagicDNS still relies on the ICANN root, as does the tailscale control plane. And if all you wanted was a free subdomain, there are plenty of people offering that.
If you are behind CGNAT, tailnets aren't particularly less centralized, as traffic has to flow through the DERP servers. I doubt tailscale can keep providing these free of charge when the volume is in the tbps instead of the gbps.
I agree that tailscale (and similar solutions) help in the last remaining case, which is accessing your computer that is behind a NAT. I even think they could reach the dozens of millions of users. This is, in my opinion, not enough to claim the title of "the new internet".
This rests on the incorrect assumption, pointed out in the post, that most applications need the kind of scale that warrants quickly scaling to more servers.
The article tried to make k8s all about scale, when that's not the whole story.
On other socials, a screenshot of the 'Not scaling' section is getting responses of "Those idiot developers think they need k8s scaling for their 1 req/s sites, ha ha."
The author brags about being able to (skip testing, CI/CD pipelines and just) edit their perl scripts (in prod,) really quickly.
What uptime is associated with that practice? As many 9's as it takes for Brad to debug his perl program in prod? This approach doesn't even scale to 2 developers unless they're sitting in the same room.
DevOps isn't a machine where you put unnecessary complexity in one end and get req/s out the other end. It's about risk and managing deployments better.
If I really wanted to engineer for req/s, I'd look at moving off k8s and onto bare metal.
In an enterprise environment, I'd like a networking solution that allows me to run an app on my own office workstation and expose it as a service to some part of the company at an SLO that can be reasonably be guaranteed with a workstation: 99.9%. That would allow to cut so much time in "productionizing" stuff that doesn't need CI/CD pipelines or deploy to a datacenter: just me editing a Python file and restarting it.
Wouldn't there be exactly twice (or twice + 1, if you allow negative fractions) as much fractions, since fractions are represented as two positive numbers (plus a bit if you consider the sign).
(The encoding could be "represent both numbers in binary, put the denominator in the odd bits (LSB = first bit), and the numerator in the even bits" so 2/3 => 10/11 => 1110 => 14)
You can't purchase .com domains on ENS, only import them by providing a DNSSEC-based proof of ownership. This doesn't solve any of the problems with TLDs (ENS won't prevent the TLD operator from taking away your domain) so to get the benefits you have to use a ENS-centric domain like .eth
It's listed, but under geographic TLDs[1] because it's Catalonia's TLD.
Interestingly this TLD only allows website that "to serve the needs of the Catalan Linguistic and Cultural Community on the Internet"[2] which is why http.cat also offers a Catalan version[3].
> Git Operations is experiencing degraded availability. We are continuing to investigate.
https://www.githubstatus.com/incidents/n07yy1bk6kc4
reply