Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RipGrep musl binaries occasionally segfault during very-large searches

github.com

Post reply on HN
Print view View original

201–210 of 216 posts

Re: RipGrep musl binaries occasionally segfault during very-large searches

#201

Post by krageon »

gruntled-worker wrote: post #190
doubletwoyou wrote: post #189

Earlier quoted context omitted.

If we know ‘where it came from’ in the sense that the author couldn’t even bother writing anything themselves, why should other people bother reading this deluge of nonsensical strung together words?

That's my point, we won't bother reading it. We'll let agents read it. People will eventually stop getting ticked off at this stuff. One exception: if the model is poor or on 'low' and that leads to a crappy report. That's the equivalent of shipping performance-critical code built with -O0 in the compiler analogy.

This is a crappy report, that's what is being discussed

Re: RipGrep musl binaries occasionally segfault during very-large searches

#202

Post by gruntled-worker »

krageon wrote: post #201
gruntled-worker wrote: post #190

Earlier quoted context omitted.

That's my point, we won't bother reading it. We'll let agents read it. People will eventually stop getting ticked off at this stuff. One exception: if the model is poor or on 'low' and that leads to a crappy report. That's the equivalent of shipping performance-critical code built with -O0 in the compiler analogy.

This is a crappy report, that's what is being discussed

Is there any indication that it was a mini/fast/older model, or on a low effort level? My read of the reactions above is "ugh AI", not "ugh AI on the cheap". Not a single poster mentioned model or effort choice. It seems more like the usual irritation at "AI slop".

If you just mean that the result was technically incorrect or off, that's probably true, but it doesn't affect my argument.

Re: RipGrep musl binaries occasionally segfault during very-large searches

#203

Post by inigyou »

fc417fc802 wrote: post #183
inigyou wrote: post #148

Earlier quoted context omitted.

The Linux kernel defines syscalls as its stable ABI (note: there are also non-kernel ABIs on Linux, such as Wayland) while Windows defines the DLL calls as its stable ABI. One isn't better than the other. Linux's approach allows binaries to be fully statically linked, which is a more predictable environment for binaries, but Windows's approach composes better, as every process loads DLLs and this allows for things li…

TBF the GPU thing makes a fair amount of sense if you dig into it. It arguably falls entirely outside the kernel's domain of responsibility. However given how fundamental GPU acceleration is (as well as various other pieces of dedicated hardware in various scenarios) it would be nice if the kernel defined some basic portable semantics for linking with important drivers. These could exist independently of libc and the…

Yeah we could all just use glibc. You see the problem with that though right?

Re: RipGrep musl binaries occasionally segfault during very-large searches

#204

Post by lrvick »

NewJazz wrote: post #186
lrvick wrote: post #170

Earlier quoted context omitted.

We use musl+mimalloc by default for our entire production operating systems: https://stagex.tools

Interesting. Not sure if you are aware, but your toolchain looks nearly identical to another linux distribution.. You might have luck looking for patches there if you ever need them. https://chimera-linux.org/about/#alternative-userland

While we are building for a dramatically different threat model, we use quite a few of their llvm patches and are very thankful for their work, and alpine making llvm/musl a viable option for us.

Re: RipGrep musl binaries occasionally segfault during very-large searches

#206

Post by fc417fc802 »

inigyou wrote: post #203
fc417fc802 wrote: post #183

Earlier quoted context omitted.

TBF the GPU thing makes a fair amount of sense if you dig into it. It arguably falls entirely outside the kernel's domain of responsibility. However given how fundamental GPU acceleration is (as well as various other pieces of dedicated hardware in various scenarios) it would be nice if the kernel defined some basic portable semantics for linking with important drivers. These could exist independently of libc and the…

Yeah we could all just use glibc. You see the problem with that though right?

That isn't at all what I said. I'm pointing out that in reality there aren't 20 competing libc implementations each with a unique dynamic linking scheme used by the userspace of 20 corresponding linux distributions. Instead we have ... glibc. So if the kernel actually specified a common portable linking scheme to fall back on as a means to interface with critical drivers it would presumably adopt the glibc way of doing things for that purpose.

Also I did not say "just use glibc" but rather suggested to just include a secondary glibc compatible dlopen routine. Exactly as you would have to do if the kernel bothered to specify.

Re: RipGrep musl binaries occasionally segfault during very-large searches

#207

Post by inigyou »

fc417fc802 wrote: post #206
inigyou wrote: post #203

Earlier quoted context omitted.

Yeah we could all just use glibc. You see the problem with that though right?

That isn't at all what I said. I'm pointing out that in reality there aren't 20 competing libc implementations each with a unique dynamic linking scheme used by the userspace of 20 corresponding linux distributions. Instead we have ... glibc. So if the kernel actually specified a common portable linking scheme to fall back on as a means to interface with critical drivers it would presumably adopt the glibc way of doi…

If the kernel wanted to force you to use glibc it would do so. We could get rid of the stupid hardcoded paths in PT_INTERP for example.

Re: RipGrep musl binaries occasionally segfault during very-large searches

#208

Post by fc417fc802 »

inigyou wrote: post #207
fc417fc802 wrote: post #206

Earlier quoted context omitted.

That isn't at all what I said. I'm pointing out that in reality there aren't 20 competing libc implementations each with a unique dynamic linking scheme used by the userspace of 20 corresponding linux distributions. Instead we have ... glibc. So if the kernel actually specified a common portable linking scheme to fall back on as a means to interface with critical drivers it would presumably adopt the glibc way of doi…

If the kernel wanted to force you to use glibc it would do so. We could get rid of the stupid hardcoded paths in PT_INTERP for example.

Right. Obviously. What I'm pointing out is that if the kernel decided to include dynamically linking to certain drivers within its scope (which it does not wish to do at present as you rightly point out) then it would need to specify a scheme for doing so. At which point glibc is all but a foregone conclusion.

So just pretend they did that and include a second dlopen routine and get on with life because at that point you're compatible with ~all major linux distros.

Far more pressing is a blessed filesystem path for where to find the things.

Re: RipGrep musl binaries occasionally segfault during very-large searches

#209

Post by monitron »

gruntled-worker wrote: post #202
krageon wrote: post #201

Earlier quoted context omitted.

This is a crappy report, that's what is being discussed

Is there any indication that it was a mini/fast/older model, or on a low effort level? My read of the reactions above is "ugh AI", not "ugh AI on the cheap". Not a single poster mentioned model or effort choice. It seems more like the usual irritation at "AI slop". If you just mean that the result was technically incorrect or off, that's probably true, but it doesn't affect my argument.

At work I am sitting on a small pile of incomplete/wrong/missing-the-point bug reports right now, all generated by Opus 5 on High effort. Even under good conditions, LLMs are still wrong quite a lot, and confidently so. I can see why you think instant dismissal of LLM generated work is shallow, but I think it's at least as shortsighted to assume that when it creates poor quality work it must be an old/cheap model, bad settings, bad prompting, etc.

Re: RipGrep musl binaries occasionally segfault during very-large searches

#210

Post by fc417fc802 »

agumonkey wrote: post #166
PunchyHamster wrote: post #134

Earlier quoted context omitted.

I usually go for "If I wanted LLM answer I'd ask LLM instead of reading your answer/article/content"

But it goes beyond this. The whole 2020s era is about cheap ways to do anything and be able to stream it to billions of people. Yet I feel no density in the work because there was no energy spent on it.

It's proof of work applied to social interactions. The father back in history you go the rarer I imagine the root problem was.

There's a similar conundrum with gifts. When everyone is able to order approximately anything from anywhere in the world via the internet exchanging gifts begins to feel like a bizarre ritual meant only to transfer money to businesses.

Post reply on HN