cormacrelf

2 miesiące temudiscuss

No? CK is better than I gave it credit for, didn’t take 15 minutes, took 2, somehow a lot faster than before, probably system busy. I was using hybrid which is wrong for this query.

Still semble is a few orders of magnitude faster and gave better results against ck —-sem. I am running both on rust-lang/rust and CK is going to take hours at least, extrapolating from current stats probably 3 days? Semble: 26 seconds without any caching. The thing doesn’t have a cache and it’s still massively faster. I added caching support and watchman integration and got it down to 1.4 seconds. 3 days is basically not good enough for this use case. It’s slow enough that indexing is going to lag your code changes. Semble is fast enough that it’s not going to be behind.

cormacrelf

2 miesiące temudiscuss

Try running both on the CK codebase. CK takes like 15 minutes to index itself and gives hundreds of completely irrelevant doc comments as results for “run model on CPU” query. Semble indexes for like 3 seconds and prints out the actual code that runs the model on the CPU.

cormacrelf

2 miesiące temudiscuss

Realistically, if you are scanning each kernel commit to check if they might be patching a security issue, you are going to be asking an LLM "is this security related, if so vaguely how" with low effort and taking "maybe" as a yes before feeding it to a more expensive model. You aren't trying to establish a probability of an ultimately unknowable fact, there is ground truth that you can find by producing an exploit, so you are just trying to pre-filter before spending the money to find it.

cormacrelf

5 miesięcy temudiscuss

For GET /, sure, and some mature load balancers can do this. For POST /upload_video, no. You'd have to store all in-flight requests, either in-memory or on disk, in case you need to replay the entire thing with a different backend. Not a very good tradeoff.

cormacrelf

5 miesięcy temudiscuss

And at the same time, Apple claimed it was the biggest ever album release by number of downloads, or something like that. They were not only messing with our libraries, they were claiming we wanted it and were in fact U2 fans.

cormacrelf

9 miesięcy temudiscuss

You can absolutely do that and there is nothing for general linear algebra libraries to do.

The actual paper is very clear about what it's for: https://fiteoweb.unige.ch/~eckmannj/ps_files/ETPRL.pdf

It says:

    Consider now a general time-dependent field B(t) of duration T. The pulse B(t) may be extremely convoluted ... Can one make the field B(t) return the system to its original state at the end of the pulse...?

This pulse is modelled as a long sequence of rotations. For maths purposes if you had such a sequence, you can obviously just multiply all the rotations together and find the inverse very easily. For physics purposes, you don't really have access to each individual rotation, all you can do is tune the pulse. Creating an "inverse pulse" is quite unwieldy, you might literally need to create new hardware. The paper asks "what if we just amplified the pulse? Can we change this alone and make it not impart any rotation?"

They are trying to take any pulse B(t) and zero out any rotation it imparts on some particle or whatever by

    uniformly tuning the field’s magnitude, B(t) → λB(t) or by uniformly stretching or compressing time, B(t) → B(λt)

And the answer is that you can do that, but you might have to perform the pulse twice.

cormacrelf

9 miesięcy temudiscuss

How about -F -regexthatlookslikeaflag? Verbatim, that errors out as the command line parsing tries to interpret it as a flag. If you don’t have -F, then you can escape the leading hyphen with a backslash in a single quoted string: '\-regex…', but then you don’t get fixed string search. And -F '\-regex…' is a fixed string search for “backslash hyphen r e g e x”. The only way is to manually escape the regex and not use -F.

I think maybe a syntax like -F=-regex would work.

cormacrelf

3 lata temudiscuss

No, this is a timing attack. https://en.wikipedia.org/wiki/Timing_attack. See also https://en.wikipedia.org/wiki/Side-channel_attack for more general usage of "timing attack" beyond cryptography.

cormacrelf

3 lata temudiscuss

If I’m reading it right, reabstraction is about allowing you to make a protocol implementation more generic in future. If it’s implemented for String today, then if you change it to be implemented for all T in future then the dylib is still usable. The reabstraction thunks are checking that the type you’ve called it with is actually covered. So they’re not free.

The idea of calling polymorphically compiled functions with pointers to witness tables in extra arguments seems like something we could throw a simple JIT compiler at. A poly-function might have a list of available concrete implementations it could forward you to. You could, as a consumer of a dylib, for each call site on a poly function where you’re passing in a type known at compile time, initially write out a stub function, that the first time it runs, caches the result of this lookup and replaces the stub with something better. The stub would have a signature shaped optimally, the initial body of the stub would pad that out with the witness tables and code to initiate JIT using the poly function, and the JITed replacement would in the ideal case just be a jump instruction to a concrete implementation with a signature identical to the stub’s. Would that help?

cormacrelf

4 lata temudiscuss

What? I know how twitter blocking works. Do you mean the word "drop"? Because I know what dropping .eth from a username means.

Edit -- oh. Amendment incoming.

cormacrelf

4 lata temudiscuss

Maybe enough people used that username.eth auto-blocker that their engagement figures dropped a non-negligible amount. My guess is the original list to check reverted usernames against came from https://antsstyle.com/nftcryptoblocker/

Note the stats on that page, before it was shut down: "So far, it has performed 52.8M blocks and 10.6M mutes on behalf of users." That was one of maybe 5 different tools. Compare that to ~200-300M monthly active users. [[~~Assuming everyone who used those tools is a MAU, those usernames were collectively reaching 20% fewer people as a lower bound.~~]] Yeah, I guess this actually is a drop in the ocean. All you can say is that they were reaching 50M fewer eyeballs cumulatively. Of course that's counting everyone more than once, because they block more than one person each. Anyway, I think it's at least plausible that the people in the "growth area" for engagement stopped engaging one way or another. Folks using these tools were most likely in this segment, and the fact that they existed meant people had figured out a simple rule for you could simply avoid listening to & engaging with at all, whether the tools did actual blocking or not.

Many of those blocks were presumably people who were fed up with the amount of NFT/.eth content in their feeds, and had been providing some negative engagement (but system doesn't care, that's still engagement). I think there's a thin but possible case to be made that this idea worked and now people have to strip their .eth to stop haemorrhaging engagement.

Another more likely theory is that this represents people who have lost interest and no longer want to make it a very visible part of their identity.

cormacrelf

7 lat temudiscuss

Yes. "It's not RICO dammit" means "the suit that has been filed will likely not succeed on the RICO claim" or "what you're talking about does not meet the RICO elements", not "that suit was not a RICO suit".

cormacrelf

9 lat temudiscuss

maybe try that again keeping 4 spaces before each line?

cormacrelf

9 lat temudiscuss

There's nothing stopping you from doing merges instead of rebases.

       * latest feature commit #3 (feature)
       * merge
      /|
     * | more master commits you wanted to include (master)
     | * feature commit #2
     | * merge
     |/|
     * | master commits you wanted to include
     | * feature commit #1
     |/
     *   original master tip
     *   master history...

Then, when you're done with feature, if you really care about clean history, just rebase the entire history of the feature branch into one or more commits based on the latest from master. I think checkout -b newbranch; rebase --squash master does the trick here:

     *   feature commits #1, #2 and #3 (newbranch)
     | * latest feature commit (feature)
     | * merge
     |/|
     * | more master commits you wanted to include (master)
     | * feature commit #2
     | * merge
     |/|
     * | master commits you wanted to include
     | * feature commit #1
     |/
     *   original master tip
     *   master history...

Then checkout master, rebase newbranch, test it out and if you're all good, delete or ignore the original.

     * feature commits #1, #2 and #3 (master, newbranch)
     * more master commits you wanted to include
     * master commits you wanted to include
     * original master tip
     * master history...