kiitos

35 ms·

451.
by kiitos 2y ago
The point of all of this stuff is to find a balance between evaluating applicants independently and objectively according to a well-defined set of critera -- equality of opportunity -- and producing an end result that is representational an
452.
by kiitos 2y ago
Wow! This is basically a master class in performative mediocrity.
453.
by kiitos 2y ago
Judges are fallible, therefore a judicial system is impossible!
454.
by kiitos 2y ago
Yelling about the "woke" left, is basically like yelling about the "ayran" right. Nobody disagrees that these things are bad, it's just that they're irrelevant.
455.
by kiitos 2y ago
The Hunter Biden laptop story had no meaningful political consequences.
456.
by kiitos 2y ago
Thanks for demonstrating my point.
457.
by kiitos 2y ago
Thanks for demonstrating my point.
458.
by kiitos 2y ago
https://www.theguardian.com/us-news/2024/oct/12/x-twitter-jd...
459.
by kiitos 2y ago
https://www.theguardian.com/us-news/2024/oct/12/x-twitter-jd...
460.
by kiitos 2y ago
The first one is entirely un-trustable, because the user-submitted timestamp can be at any arbitrary point in time, from t=0 to t=infinity. So the receiving system can use that timestamp as an important bit of signal, but it can't real
461.
by kiitos 2y ago
I suppose every message has a few timestamps, including - The timestamp that the user specified as part of the message - The timestamp of the server that the user submitted the message to, directly - The timestamp of the server that first r
462.
by kiitos 2y ago
Vector clocks provide a deterministic partial order, but partial order doesn't provide any kind of total order. That's true, yes. But (as I'm sure you're aware) there is no single deterministic total order of events in a
463.
by kiitos 2y ago
> If you have finite storage, you need to do something. Sure. > A very simple rule is to just drop everything older than a threshold. Yep, makes sense. > (Or another simple rule: you keep x GiB of information, and drop the oldest l
464.
by kiitos 2y ago
Metrics can be sampled, because metrics by definition represent some statistically summarize-able set of observations of related events, whose properties are preserved even when those observations are aggregated over time. That aggregation
465.
by kiitos 2y ago
> When multiple messages are in flight in the same 'simultaneity window', different observers may receive them in different orders and vector clocks can't determine a consistent order of those events. That's right! Ve
466.
by kiitos 2y ago
It's reasonable to drop logs beyond some window of time -- a year, say -- but I'm not sure why you'd ever sample log events. Metric samples, maybe! Log data, no point. But, in general, I think we agree -- all good!
467.
by kiitos 2y ago
Most systems _do_ compress request payloads on the wire, because the cost-per-byte in transit over those wires is almost always frictional and externalized. Weird perspective, yours.
468.
by kiitos 2y ago
If a service emits a log event, then that log event should be visible in your logging system. Basic stuff. Sampling fails this table-stakes requirement.
469.
by kiitos 2y ago
Give up on the idea of "the timestamp" of an event. There is no such thing. Clocks are unreliable, and even if every clock in a system is perfectly in-sync (via atomic transponders or whatever) they're still subject to speed-
470.
by kiitos 2y ago
> How far back should you be able to amend history? If user U1 sends a message M1 at time T1, then U1 must be able to modify/delete that message M1, in some reasonable sense, at any conceivable time from T1 forwards. Any protocol
471.
by kiitos 2y ago
You never send a single individual log event per HTTP request, you always batch them up. Assuming some reasonable batch size per request (minimum ~1MiB or so) there is rarely any meaningful difference in payload size between gzipped/zs
472.
by kiitos 2y ago
For sure, yes. But terms of art, like "crash", generally have commonly-understood definitions. And the commonly-understood definition of the term of art "crash" is that it means OS process terminating. Not always! Not al
473.
by kiitos 2y ago
It's true that an actor is not necessarily a system process. It can be a process, or a thread, or a coroutine, or etc. But "crashing" isn't anywhere near so ambiguous. Crashing doesn't mean the request fails, or the
474.
by kiitos 2y ago
Isolation: Since actors process messages they receive sequentially, there are no concurrency issues within an actor. This simplifies reasoning about state mutation and transitions. ... Fault Tolerance: State can be persisted
475.
by kiitos 2y ago
> `tail -f | grep` is like `vim | grep` or `rogue | grep` I think this position is user-hostile. `vim` and `rogue` are fully user-interactive programs. The same is not true of `tail -f`, which by default appears to users as a stream of l
476.
by kiitos 2y ago
Thanks for providing a case in point.
477.
by kiitos 2y ago
No, there isn't, at least not by default. You have to explicitly create a Threads account.
478.
by kiitos 2y ago
You have to create a Threads account explicitly, it's not automatic from an Instagram or Facebook account.
479.
by kiitos 2y ago
Great work as always. After reading thru the relevant blog posts and docs, my understanding is that Kafka defines "exactly-once delivery" as a property of what they call a "read-process-write operation", where workers re
480.
by kiitos 2y ago
> if you want to use %CPU as "how much of the total available processing power is this process using", it's potentially valuable ... the available maximum clock speed depends on variables like the ambient temperature, how

More ›