robryk @robryk@qoto.org

@delroth I wonder about false negatives caused by compression. (Doesn't python modules distributed as egg files compress native libraries?)

@delroth what string are you searching for?

@danluu Would you consider having to pay fines for lack of driving license, the lack of which was caused by rules that prevent one from getting it if one has unpaid fines, an example of Vimes' boots theory?

@delroth

https://gist.github.com/joseluisq/e7f926d73e02fb9dd6114f4d8be6607d might be helpful (tl;dr awaiting the future just executes it on the same thread; you need to spawn a task with tokio to get any parallelism)

@freemo TIL that the "pair" part meant "prepare" (https://www.etymonline.com/word/repair#etymonline_v_12814)

@equinox

Another reason why this is better than mounting a file on top of a file is that when you bind mount a file, the source of the mount is an inode. So, if the source file gets unlinked (e.g. because someone wants to atomically update it), the mount will continue to point at the file that was unlinked.

Bind-mounting a directory with the source file on the side and bind-mounting a symlink to the source file on top of the target file gets rid of that footgun (because you presumably won't want to update the symlink).

@niconiconi Ah, and yet another thing that is theoretically poorly studied IMO but does actually even appear in practice are data structures that are lock-free with high probability (i.e. with low probability they might even block).

I'm somewhat sour that this is not a better-studied area, because most of my inventiveness when I was working on this area was spent on dealing with edge cases caused by patterns of extreme scheduler unfairness that I never once managed to trigger on actual hardware. (And I would guess that if we had a way to formalize this, I could have reduced this to "particular patterns of scheduler behaviour, that are necessarily low-probability if the scheduler is not allowed to observe your internal state").

@niconiconi

One other area that is interesting and is (or at least was ~8 years ago) badly studied is measuring time in some other way than ~instructions. Back then I couldn't find a measure of complexity that would tell me that e.g. a structure where each thread increments its own memory location is faster than a structure where everyone does fetch_and_add on a shared memory location instead.

@niconiconi What would you be taking the probability over? If you think the scheduler itself is random as opposed to adversarial, then the scheduler will have almost surely bounded unfairness, and there are results that give you lots of IMO neat things when scheduler is boundedly unfair.

If you want to keep the scheduler adversarial (which I don't expect you do because it seems unrealistic), then there's lots of latitude in model definition on when (and if) that adversarial scheduler learns about your RNG's outputs.

Also, lock-free is terribly defined (wait-free and obstruction-free don't share this problem): the way it's commonly defined does not compose, and the way you need to define it so that it composes doesn't admit a neat description that I know of. (Please say so if you want this verbosified.)

@rotopenguin @danluu

Hmm~ either I am very blind to my own bias towards smartness, or the areas of software engineering that have something to do with governmental standard seem to be more about sounding right than upholding verifiable statements. Perhaps it's important that standards in other areas are older, so have went through more amendments?

@isomeme

Look at https://palant.info/2018/03/13/can-chrome-sync-or-firefox-sync-be-trusted-with-sensitive-data by @WPalant (and the linked update from this year).

@lauren If you notice it happening in the future on publicly-viewable messages, I'd appreciate a heads up so that I can see if there's anything I wouldn't expect about the messages.

@isomeme

I am under the impression that Firefox's password manager is not worse than Chrome's. Let me try to look up the sources that caused me to think so tomorrow.

@lauren

When does this happen?

`inReplyTo` just links to the immediately prior message, so if your instance didn't get B, it has no way to link A and C. Do instances seriously implement user-level blocks/mutes by doing something like this in the UI, or am I missing some other situation when this behaviour would make some sense?

@dunkelstern TBF if you set up env vars to point at the flake registry you want to use, you get to skip `--inputs-from`.

@rq Sure. Computer networks are, however, at least as old as early 1960s.

@rq That made me wonder what was the earliest portable rewriteable data storage.

@steely_glint I'd try hard to make the device not require an Internet connection at all (and not make use of one if it's available). This can sometimes be done by having it talk only BT, or by having it use LAN to communicate with the user (harder, because people something have APs that refuse traffic between different clients). That would make the criticality of updates way lower.

@kravietz I don't believe this is the reasoning behind their actions. If it were the reasoning, I'd expect starlink to try to publicly provide reasonably detailed rules on service in warzones in an attempt to lessen the risk of blackmail ("unless you favor us in this warzone, we will <damage your satellites, ...>"). What I see is Musk making statements that his decisions depend on likely _military outcomes_, which seems to me as a way to achieve the exact opposite.