thedufer
This reminds me of a recent issue I had. I had just gotten a new laptop from IT. While picking it up from them, I had generated myself a password, put it in my password manager on my phone, and then entered it twice to set it on the laptop. Everything worked great. But when I got back to my desk, the password didn't work! I tried a bunch of times, watched myself hit each key to eliminate typos, etc.
I went back to IT and they asked me to demonstrate. But this time it worked! I walked back to my desk, thoroughly embarrassed. But a couple hours later I had to log in again and once again could not.
After thinking about it for awhile, I realized that I was typing at IT while standing over a sitting-height desk. Sure enough, typing in that position fixed my issue. I carefully watched what I was doing this time - something about the exact layout of the keyboard and the weird angle I was typing at ensured that I was making a particular typo I typed in that position - just a single letter switched to another, every time. Sure enough, making that one substitution to my intended password got me in.
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.
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.
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.
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.
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.
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.
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).
> SSE always breaks and requires client side retries to get it to work
Yeah, but these are automatic (the browser handles it). SSE is really easy to get started with.
Empirically this is a rather low cost. IIRC, the extra ops add less than a cycle per arithmetic operation, due to amortizing them over multiple operations and clean pipelining (and also things like shifts just being really cheap).
But yes, there are certainly applications where we almost exclusively use Int64 or Int32 rather than the primary int type, if you need exactly that many bits.
> You know that at compile time, surely, when you set the build target, no?
Well, that's true of OCaml as well.
This is ultimately a difference of opinion - I think that the cost of installing a single extra library to get ints of various widths/signedness would be worth the advantage of eliminating nearly all memory errors (and various other advantages of a higher-level language).
The main carveout I would agree with is any case where you absolutely need strict memory bounds - it's not clear to me how you'd satisfy this with any GC'd language, since the GC behavior is ultimately somewhat chaotic.
Types are fully erased after compilation of an OCaml program. However, the GC still needs to know things about the data it is looking at - for example, whether a given value is a pointer (and thus needs to be followed when resolving liveness questions) or is plain data. Values of type `int` can be stored right alongside pointers because they're distinguishable - the lowest bit is always 0 for pointers (this is free by way of memory alignment) and 1 for ints (this is the 1 bit ints give up - much usage of ints involves some shifting to keep this property without getting the wrong values).
Other types of data (such as Int64s, strings, etc) can only be handled (at least at function boundaries) by way of a pointer, regardless of whether they fit in, say, a register. Then the whole block that the pointer points to is tagged as being all data, so the GC knows there are no pointers to look for in it.
> Or is any build of an OCaml program able to target (at compile-time) either 32- or 64-bit targets, or does it mean that an OCaml program build result is always a single format that will adapt at runtime to being in either environment?
To be clear, you have to choose at build time what you're targeting, and the integer sized is part of that target specification (most processor architectures these days are 64-bit, for example, but compilation to javascript treats javascript as a 32-bit platform, and of course there's still support for various 32-bit architectures).
> Knowing one's runtime details is intrinsic at design-time for dealing with systems-level semantics, by my understanding.
Doesn't this mean that C can't be used for systems programming? You don't know the size of `int` there, either.
> But I don't want to build the programming language, I want to use it.
I meant building OCaml code, not the compiler.
I think you're misinterpreting this. That's just the date the most recent version of the library was published. The library is something like 15 years old.
> the standard integer data types (and, therefore, the standard language), that not only have no signedness
I'm not sure what you mean by this - they're signed integers. Maybe you just mean that there aren't unsigned ints in the stdlib?
> and only have Int32 and Int64, but have "one bit is reserved for OCaml's runtime operation".
The "one bit is reserved" is only true for the `int` type (which varies in size depending on the runtime between 31 and 63 bits). Int32 and Int64 really are normal 32- and 64-bit ints. The trade-off is that they're boxed (although IIRC there is work being done to unbox them) so you pay some extra indirection to use them.
> The stdint package also depends on Jane Street's "Dune", which they call a "Fast, portable, and opinionated build system". I don't need or want or need any of its capabilities.
Most packages are moving this way. Building OCaml without a proper build system is a massive pain and completely inscrutable to most people; Dune is a clear step forward. You're free to write custom makefiles all the time for your own code, but most people avoid that.
Well yeah, it's a great option for the seller. You get non-recourse cash before shipping the item. The real question is why people are willing to send it to you. From the other side, it's basically asking to be defrauded.
xmobar uses deciseconds in a similar, albeit more problematic place - to declare how often to refresh each section. Using deciseconds is fantastic if your goal is for example configs to have numbers small enough that they clearly can't be milliseconds, resulting in people making the reasonable assumption that it must thus be seconds, and running their commands 10 times as often as they intended to. I've seen a number of accidental load spikes originating from this issue.
I've been called for a rejection exactly once, less than an hour after I'd left the office where I was being interviewed. I was kind of shocked (the interviews went really well) and I didn't realize until later that the recruiter never said my name, and had previously claimed I would absolutely not get the result for at least 3 days. A week later, I got an offer, and I always felt a little bad for the candidate I unintentionally caused to get ghosted because the recruiter dialed the wrong number and I didn't figure it out.