thedufer

Can't log in when standing up

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.

OCaml predates multicore CPUs. Having a global lock was basically free at the time it was invented. It's totally crazy to dislike a language because the authors made a decision that was obviously correct at the time.

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.

you actually need to get a service ticket (TGS)

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.

That's an interesting update. I remain a bit skeptical based on the fact that the obvious sources I'd look to for this sort of thing haven't updated on that study (it seems to be https://www.tandfonline.com/doi/full/10.1676/23-00045), and I'm not really able to evaluate it on my own. USFWS (https://www.fws.gov/story/threats-birds-collisions-buildings...) is citing the previous numbers, as is Wikipedia (https://en.wikipedia.org/wiki/Bird%E2%80%93window_collisions).

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.

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.

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.

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.

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).

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.

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).

I think the author was pointing at the fact that "Venessa" looks like a typo.

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).

I don't understand the advantages of recreating SSE yourself like this vs just using SSE.

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.

But, oh!, the poor ints.

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.

I don't get it. What is it reserved for then, if the int size is determined when the runtime is built? How can that possibly affect the runtime use of ints?

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.

which has a pub date from Oct 19, 2022

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.

18f built but did not then manage login.gov. It was handed off elsewhere. The implication of them managing it was that disbanding 18f left login.gov ownerless (or at least handed off to some group that knows nothing about it) which does not seem to be the case.

I would assume they're pointing at the comment at the top of this thread ("They built / manage login.gov?") rather than the article itself.

is pretty straightforward to accept without fear of charge-backs or fraud

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.

Now, why Junio thought deciseconds was a reasonable unit of time measurement for this is never discussed, so I don't really know why that is.

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.

Ah, we draw a distinction between checked-in generated code and JIT generated code, and the former does show up in code review (which is sometimes the point of checking it in - you can easily spot check some of it to make sure the generator behaves as you expect).

I have both and they certainly each have their place. The Steam Deck has a much wider variety of games and can handle heavier graphics loads, but it is too heavy to be all that comfortable for handheld use, and the Switch is in my mind the undisputed champion of local multiplayer (more portable controllers, controller connections Just Work, good variety of local multiplayer games, etc).

Our code review process involves a reviewer explicitly taking ownership of the PR, and I think it's a reasonable expectation with the right practices around it. A good reviewer will request a PR containing 1000s of lines be broken up without doing much more than skimming to make sure it isn't bulked up by generated code or test data or something benign like that.

All of the months with numerical prefixes are wrong by the same offset, though. So as long as you remember that as well, it can be useful. Particularly since they're the last ones and thus take the longest to count to.

September is a funny choice to use as an example, because it is named after a number (sept-: prefix, 7). The wrong number, though.

In fact, it sounds like the 40% includes all exits, including those that returned only 1x. That would mean that the 60% is all 0s, and that the chart shows a negative total return in all rows, without even discounting for the holding period.

I didn't realize this was becoming more common. It seems far more uncomfortable for everyone involved, although based on the comments it does seem like some people appreciate a phone/Zoom call. I don't really understand why, though (please try to explain!). An email gives me more time to process difficult news, and prevents me from needing to act positively in an unambiguously negative situation.

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.

Gap insurance covers a tightly-bounded amount of loss (it will never pay out more than the remainder of your loan), which is why it's so cheap. That's also why it's a great target for self-insurance - you know exactly how much you need to have to cover the worst-case loss. If you have the cash, you are almost certainly better off skipping this one.