cormacrelf

Joined 14 years ago

Karma

2,648

Submissions

795

Member since

Mar 24

View on Hacker News

Recent submissions

Comment · 3 months ago

This story was reported by 404 media. OP linked some random person’s tweet.

https://www.404media.co/ai-companies-are-buying-tons-of-old-...

Comment · 5 months ago

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.

Comment · 5 months ago

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.

Comment · 5 months ago

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.

Comment · 8 months ago

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.

Comment · 8 months ago

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.

Comment · 1 year ago

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.

Comment · 1 year ago

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.

Comment · 1 year ago

From the article:

> The way Nixpacks uses Nix to pull in dependencies often results in massive image sizes with a single /nix/store layer ... all Nix and related packages and libraries needed for both the build and runtime are here.

This statement is kinda like “I’m giving up on automobiles because I can’t make them go forward”. This is one of the things Nix can do most reliably. It automates the detection of which runtime dependencies are actually referenced in the resulting binary, using string matching on /nix/store hashes. If they couldn’t make it do that, they’re doing something pretty weird or gravely wrong. I wouldn’t even know where to start to try to stop Nix from solving this automatically!

I wouldn’t read too much into their experience with it. The stuff about versioning is a very normal problem everyone has, would have been more interesting if they attempted to solve it.

Comment · 1 year ago

> Meta has a sophisticated implementation of a target determinator on top of buck2, but I don’t believe it is open-source.

It is: https://github.com/facebookincubator/buck2-change-detector

> Some tools such as bazel and buck2 discourage you from checking in generated code and instead run the code generator as part of the build. A downside of this approach is that IDE tools will be unable to resolve any code references to these generated files, since you have to perform a build for them to be generated at all in the first place

Not an issue I have experienced. It's pretty difficult to get into a situation where your IDE is looking in buck-out/v2/gen/781c3091ee3/... for something but not finding it, because the only way it knows about those paths is by the build system building them. Seeing this issue would have to involve stale caches in still-running IDE after cleaning the output folder, which is a problem any size repo can have. In general, if an IDE can index generated code with the language's own build system, then it's not a stretch to have it index generated code from another one.

The problem is more hooking up IDEs to use your build system in the first place. It's a real slog to support many IDEs.

Buck recently introduced an MSBuild project generator where all build commands shell out to buck2. I have seen references to an Xcode one as well, I think there's something there for Android as well. The rust-analyzer support works pretty well but I do run a fork of it. This is just a few. There is a need (somewhat like LSP, but not quite) for a degree of standardization. There is a cambrian explosion of different build systems and each company that maintains one of them only uses one or two IDEs and integrates with those. If you want to use a build system for an IDE they don't support, you are going to have a tough time. Last I checked the best effort by a Language Server implementation at being build-system agnostic is gopls with its "gopackagesdriver" protocol, but even then I don't think anyone but Bazel has integrated with it: https://github.com/bazel-contrib/rules_go/wiki/Editor-and-to...

Comment · 2 years ago

Maybe it’s better selfhosted, but GitLab is almost unbearably slow. I booted up a Gerrit instance to compare and simply rendering a MR page is maybe 10 seconds vs zero. GitHub is still 10x faster. GitLab manages to be almost that slow for cached pages, making you wait, then realise it’s outdated, and load again, totalling maybe 20 seconds just to “go back to the MR list”. Its awful.

Whatever it is you think you might like about GitLab in theory, it’s much worse when this is your reality. When it takes that long to render a single MR, you do not want to be creating more of them than you have to, and you certainly don’t want to make yourself and the rest of your team navigate between MRs to do code review.