> if you reduce latency from one second to a hundred milliseconds, could you celebrate that you've made it 10x faster
Yes you can, because speed has units of inverse time and latency has units of time. So it could be correct to say that cutting latency to 1/10 of its original value is equivalent to making it 10x the original speed - that's how inverses work.
Savings are not, to my knowledge, measured in units of inverse dollars.
If we're being pedantic, TGS ("ticket granting server") is the service you get service tickets from. Service tickets are (occasionally) abbreviated ST, as you'd expect. The TGS is a logical part of the KDC, distinguished from the AS which grants TGTs.
> At the same time 3.5 billion birds die hitting glass of the buildings.
Do you have a citation for this? Are you comparing North American cat deaths to worldwide building collisions? Estimates I'm seeing of North American center around 600 million, a far cry from deaths due to cats.
No, they are about the same. The 3.5 billion is the top estimate similar to how 4 billion is top estimate for killed by cats. The lower estimates in both cases around 1 billion something.
FWIW 3.5 billion is not the top estimate, although I'm not sure how to interpret the way the estimate is stated ("annual mortality may be minimally 1.28 billion–3.46 billion or as high as 1.92 billion–5.19 billion"). What does it mean to have a range for each end of the range? The author only quotes the absolute lowest number from the study in press about it (see https://www.lehighvalleynews.com/environment-science/3-5-mil...), but maybe is just preferring to be conservative.
I'm not sure what conclusions you think we should draw from that. California's advantage over Washington is primarily one of size - Washington's GDP per capita is actually about 3% higher than California's. The most generous interpretation I can think of is that you're crediting the non-compete difference for California's far larger population, which is tenuous at best.
Seattles weather does nothing to lower the denominator. The PNW is rainy and somewhat cold, but not cold enough to kill homeless on the street in large numbers which is what folks seem to think lowers the denominator. And yes I do live in the PNW.
Typewriter keys cost money, and dropping the 1 allowed them to drop a key without significantly affecting the use of it. As far as I can tell, that's effectively the entire rationale.
This wasn't meaningfully the case prior; the printing press would've just needed more copies of 'l' if they'd dropped the 1s, and letters weren't as significant a portion of the cost of the machine, anyway. And afterwards came computers, which need to distinguish between the characters even if they're displayed the same way.
They didn't just cost money. They were competing to the limited space around the typing area, what meant they were constrained at the border of a circumference that would be entirely filled with mechanisms. In other words, the cost in both money, size, and weight depended on the square of the number of keys.
Labeled tuples are effectively order-independent. Your implementation's order has to match your interface's order, but callers can destruct the labeled tuples in any order and the compiler will do the necessary reordering (just like it does for destructing records, or calling functions with labeled arguments). I don't think this is materially different from what you're describing in F#, except that labeled tuples don't allow labeling a single value (that is, there's no 1-tuple, which is also the case for normal tuples).
> But you'll never get a test that can prevent errors like name@gnail.com, name@gmaip.com, nane@gmail.com etc. So is it really worth doing any checks at all?
You can do quite well at this, if you're willing to not restrict yourself to regexes and commit to some amount of hackery. One system I worked on used a simple regex (just what is described here IIRC - assert the existence of an @ sign), plus did an MX check on the domain, plus warned (not errored) if the domain was within 1 or 2 Levenshtein distance of any of a list of most common email domains (yahoo, gmail, etc). Statistically it seems like we saved people a lot of grief with this simple filtering.
Putting a slash '/' at the end consistently gets you there, at least in Chromium-based browsers. We use this a lot at work (via DNS search suffixes, not private TLDs).
Why would that be more correct? A trailing dot indicates that a domain is fully-qualified, but that's not the issue here. The browser is trying to decide whether your query is a search string or a URL.
Also, a trailing dot would indicate the opposite of what we want - we're using single-label domains that only work if we can rely on search suffixes to qualify them.
My issue with eventsource is it doesn't use standard auth. Including the jwt in a query string is an odd step out requiring alternate middleware and feels like there is a high chance of leaking the token in logs, etc.
I'm curious though, what is your solution to this?
Secondly, not every client is a browser (my OpenAI / fine tune example is non-browser based).
Finally, I just don't like the idea of things failing all time with something working behind the scenes to resolve issues. I'd like errors / warnings in logs to mean something, personally.
>> I don't understand the advantages of recreating SSE yourself like this vs just using SSE
This is more of a strawman and don't plan to implement it. It is based on experiences consuming SSE endpoints as well as creating them.
> I'm curious though, what is your solution to this?
Cookies work fine, and are the usual way auth is handled in browsers.
> Secondly, not every client is a browser (my OpenAI / fine tune example is non-browser based).
That's fair. It still seems easier, to me, to save any browser-based clients some work (and avoid writing your own spec) by using existing technologies. In fact, what you described isn't even incompatible with SSE - all you have to do is have the server close the connection every 60 seconds on an otherwise normal SSE connection, and all of your points are covered except for the auth one (I've never actually seen bearer tokens used in a browser context, to be fair - you'd have to allow cookies like every other web app).
Yes you can, because speed has units of inverse time and latency has units of time. So it could be correct to say that cutting latency to 1/10 of its original value is equivalent to making it 10x the original speed - that's how inverses work.
Savings are not, to my knowledge, measured in units of inverse dollars.
reply