Show newer

@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?

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

starlink 

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

@eta did you happen to look at what are the provided reasons for both questions?

@samwho @isomer

A problem that occurs is that you sometimes need to operate on those secrets, so they end up in registers or on stack. Then they stay there until the next time that register/stack area is used. Vector registers aren't used that often, so secrets end up staying there longer.

You could try to have a compiler that cares about where data stays behind, but that would make performance worse, so you'll need to mark data for which this is important. That has to be "contagious": you must never be able to silently cast that property away (and should _never_ cast it away). So, you need alternate versions of e.g. libc functions that will operate on "data not to be left afterwards", which implies that it's more of an all-ecosystem evolution than msan support (where you "just" need everything to be compiled with msan, not everything to be duplicated).

robryk boosted

@samwho Rust is even more aggressive about some of this. You'd have to Pin<> things at a minimum, and that may not be enough. And any code that involves Pin<>s is usually a pain.

Put your secrets in a different address space, ideally in a different processor entirely.

@kravietz Ah, sorry, I was thinking about chamfers and not fillets (3d printing fillets is usually a bad idea, because something somewhere will exceed the maximum overhang angle). For extrusions you can easily get chamfers on the sides along the extrusion length, but getting them on all other edges was always a chore for me that left my list of groups hopelessly nonnavigable, so much that I started wondering whether it'd be better to use solvespace to design 2d shapes, export them as something like svg, and use something like libfive to do the 3d part.

@harce Even better: have something local that will request those pages as `application/ld+json` and render them by itself.

@kravietz Have you found a convenient way to do fillets on all edges of a part?

@mark @lauren

They won't stop working: they will go out and come back on ten or twenty seconds later. :)

@koakuma I would suggest luks inside LVM, separately for every volume, using same passwords. That allows you to way more easily choose to have since unenxrypted partition in the future (or even now, depending on how you boot that machine) at a imo small chat if having more places to change the passphrase in.

@mhoye @danluu @danlyke

Why is it necessarily collective? If you ask for a raise individually and get it, it's beneficial for others: it's easier for them to argue for the same, all without any coordination or cooperation.

Show older
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.