nrr

Specifically, the BeOS required support for the rtdsc instruction for its timing, and that was only available on the Pentium chips or later.

I don't know what cats you've interacted with, but my cats literally use me as furniture and cry at me when they can't.

Though, slight typography nit—and I don't especially like being a pedant except when I can teach something—the em-dash isn't typically set off by spaces as you've done. The only real exception that I can recall off-hand is in newspapers, and that's for reasons of space management.

Exactly, and there isn't really any backwards compatibility possible. Below csrss.exe on the stack, you really are wedded to a particular kernel patch level.

Linus found religion in a stable system call interface somewhere in the 2.4 series, and it's made the Linux container experience rather nice. Windows moves that particular kind of interface stability much, much further into userspace, and it makes the Windows Containers situation untenable.

It happens to be the major version reported by `wsl --version` on my system.

    NRR-WT1; wsl --version
    WSL version: 3.0.1.0
    Kernel version: 6.18.40.1-1
    WSLg version: 1.0.79
    MSRDC version: 1.2.7214
    Direct3D version: 1.611.1-81528511
    DXCore version: 10.0.26100.1-240331-1435.ge-release
    Windows version: 10.0.26300.9457
    NRR-WT1;

Windows Containers, owing to how NT itself is put together, are incredibly awkward to use. Container images have to go all the way down to smss.exe (the NT equivalent to init), which ties you to a particular kernel patch level.

Upgrade the container host? Re-bake your container images. It's a massive pain in the ass.

I write Ada that targets Windows and COM, which I consider to be real work.

> Your feels are not proof.

No, but it's how I formulate hypotheses for testing. It's why that claim I labeled as verging on vacuously true is uninteresting: how the fuck do I even go about testing that?

> The “mathematically uninteresting” claim would be the parsimonious one: as low temperatures go up, cold deaths will decrease, for a net reduction in temperature-related deaths.

I fear I may be misunderstanding what you mean by parsimonious here. There's a scientific sense wherein there's an explanation that requires fewer assumptions, and in this sense, I'm still not understanding the argument you're proposing. Simplest hypothesis under what model? I think is the question I want to ask here???

The unfortunate part is that it's prima facie unclear that the climate system would be conservative in this way. I'll admit that's due to some ignorance on my part about how climate systems work, but it's also that ignorance that fuels an understanding that there are variables that I can't account for, let alone control for, which limits the kind of modeling that I can undertake to understand this problem (and, as a consequence, your argument, whatever that happens to be).

Forgive me if it seems like I'm asking stupid questions, but I'm legitimately trying to understand your contributions as positively contributory. I have no real priors for this that I'm trying to validate or invalidate.

I was asking more what argument you had hoped to add to this thread. The fact was quite clear, but the additional exposition around it made me raise an eyebrow.

You had made a remark in another post somewhere that there was an unfalsifiable claim in asserting that people will die from both extreme cold and extreme heat, and that claim is one I don't really find all that interesting. Mathematically, it's verging on vacuously true, very firmly in "Yeah, so what?" territory.

I'm more curious if there's some (minimally associative but preferably causal) relationship between those extremes that you might know about; e.g., for every linear step increase in heat deaths, we realize some exponential step increase in cold deaths.

Sorry, I'm unsure what your thesis is in presenting deaths due to extreme cold this way.

> one thing I've always wondered about Georgism and Land Value Tax is whether land supply is actually inelastic

It isn't actually perfectly inelastic, but looking at land reclamation (and erosion!) relative to the ease with which places to live can be added to a locale, the supply of land is relatively inelastic. Even then, that kind of misses the core of George's argument about land value.

George himself distinguished land from labor and capital by looking at it through the lens of whether the economic value of a piece of land needed to be attributable entirely to improvements undertaken on that land. This is his "all natural opportunities or forces," and those are where the constraint lies.

For land reclamation in particular, there are two things to look at: (1) the value attributable to the land reclamation effort; and (2) the residual site value. (2) is land rent, and the Georgist model really is predicated on the relationship the surrounding community has with a piece of land. As it goes, if the community's feelings toward, say, a reclaimed waterfront are tepid, that reclaimed land won't have much value (even if the land reclamation were undertaken at great expense!), and won't command high land rents.

It's kind of the same distinction between backups and restores, wherein the restores are what's important, but they're impossible without the backups to restore from.

One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.

I'll push back against this slightly: learning what good code is requires debugging bad code, whether by way of a symbolic debugger or judicious use of printf() or breaking an algorithm down into its steps so that you can figure out its asymptotic behaviors.

I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.

The state of affairs in C and C++ is abhorrently bad. Not only is there `char` but also `signed char` and `unsigned char`, and the standards seem to leave the signedness interpretation of bare `char` up to the implementation.

Ada explicitly settled on `Character` being an enumeration type based on a specific character set encoding. When I learned Ada 95, the ARM specified the ISO 8859-1 character set for `Character`, likewise with `Wide_Character` and `Wide_Wide_Character` explicitly settling on 16- and 32-bit implementations of UCS. I wish more language specifications made decisions like this.

D following suit with tying its `char`, `wchar`, and `dchar` to UTF-8, UTF-16, and UTF-32 is commendable.

More to the point, MAUs are a measure of reach and not revenue or business health.

Looking at this from an investment standpoint (as if, e.g., I were establishing funding requirements for a pension fund or an annuity or some other such financial vehicle), MAUs are a nice to have because they can establish a counterfactual[0] for volume, but I'd be looking at the performance of X's products relative to the financial performance of X's customers buying those products (e.g., for advertisers, things like conversion and customer acquisition cost come to mind), legal exposure (because of, e.g., CSAM distribution) and other tail risks, and also whether there's an existential risk to the liberal democratic order that enables the financial vehicle I'm working with to operate at all, among other portfolio-level risks.

--

0: Well, kinda. The counterfactual actually comes in when we ask questions like, "If the reach changes, what happens to the economic performance?" Relying on MAUs as a baseline measure of the reachable population based on observation enables us to establish these kinds of counterfactuals.