kiitos

50 ms·

601.
by kiitos 3y ago
> I'm assuming a system that tracks nodes and checks for quorum(s) Not sure why. > because if you let isolated servers be authoritative then your data integrity goes to hell Many AP systems maintain data integrity without central
602.
by kiitos 3y ago
If you try to assert a specific definition of a specific term like "HTTP error 503" then you have some authority. But if you try to assert a specific definition of a generic term like "error" then you don't really h
603.
by kiitos 3y ago
Mebibyte is well defined. Error is not.
604.
by kiitos 3y ago
> The distributed database needs a coordination system anyway, so it's not an additional point. Nope! Distributed databases do not necessarily need a "coordination system" in this sense. Most wide-scale distributed databas
605.
by kiitos 3y ago
> People use AWS for the same reason they rent houses: less investment required and you can change things more quickly. Yes, exactly. And it's very often the case that these capabilities are more valuable to users than "real pr
606.
by kiitos 3y ago
Facts not in evidence.
607.
by kiitos 3y ago
Machines are incidental implementation details of the applications which run on them. The applications matter, the machines don't.
608.
by kiitos 3y ago
It's weird that AWS is just absurdly profitable, then, isn't it? (You're wrong, there are many such scenarios)
609.
by kiitos 3y ago
Reads like a fairly junior IC.
610.
by kiitos 3y ago
If that name is expected to be a unique identifier, then certainly not!
611.
by kiitos 3y ago
Fewer points of coordination is always better. In general you shouldn't need to make a roundtrip to produce an ID.
612.
by kiitos 3y ago
Clients have/supply meaningful data. An ID isn't meaningful data.
613.
by kiitos 3y ago
IDs are one thing, cursor-able fields/columns are a different thing. You cursor on timestamps, or serial numbers, or etc., not IDs.
614.
by kiitos 3y ago
Whatever is distributing the chunks is still a point of central coordination.
615.
by kiitos 3y ago
I think we're speaking from wildly different, and incompatible, contexts. DSR is niche at best, not something that can be assumed.
616.
by kiitos 3y ago
This is obviously not true?
617.
by kiitos 3y ago
If you have multiple client-accessible IP addresses available to a server, I guess? But that's in no way common?
618.
by kiitos 3y ago
It's definitely not a given that a binary protocol + etc. will yield a "massive gain in performance" versus naive e.g. gzipped JSON over HTTP.
619.
by kiitos 3y ago
> Both load balancers and backend servers can juggle millions of concurrent connections nowadays. Maybe with SO_REUSEPORT, but not in general. A TCP connection is identified by a 5-tuple that requires a unique port for both the client an
620.
by kiitos 3y ago
It's not a question of IP addresses, it's about connections.
621.
by kiitos 3y ago
Assuming SSL, HTTP/1 does not deliver better throughput than HTTP/2 in general. I'm not sure why you believe otherwise. Got any references?
622.
by kiitos 3y ago
TCP connections are bottlenecked not just by the browser/client, but also at the load-balancer/server. Modulo SO_REUSEPORT, a server can maintain at most 64k active connections, which is far below any reasonable expectation for ca
623.
by kiitos 3y ago
You wrote "the main polluting countries", not "the main impediments to progress".
624.
by kiitos 3y ago
China is the worst offender, by a huge margin.
625.
by kiitos 3y ago
I guess it all depends on how you define "client" and "shallow history", and the guarantees you provide around propagation of that history. But if you have a central server that is considered to be the authoritative sour
626.
by kiitos 3y ago
> if an operation has been synchronized across all endpoints, no new operations will occur concurrently with it, allowing it to be safely removed from the history. This assumes that the set of endpoints (really, nodes) is both well-known
627.
by kiitos 3y ago
Unless you do that verification work as part of each DNS query, clients are still delegating trust to whatever service is responding to their requests.
628.
by kiitos 3y ago
Sure, if you ran an Ethereum client locally -- which is of course infeasible for statistically everyone. Otherwise, you're still delegating trust to a third party.
629.
by kiitos 3y ago
> keep it in your domain. If you keep all your services within your own domain you retain control over the asset. Domains are governed by registrars which are clearly "centralized" according to the definitions of the linked art
630.
by kiitos 3y ago
The long history of C has demonstrated pretty clearly that it's not possible for humans to write C (at scale) that is free of vulnerabilities.

More ›