You’re both saying the same thing.

Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.

You can carry exactly (or roughly) as much energy in the form of antimatter as you would energy in the form of fuel.

The problem is that a tiny leak will eat away your spacecraft, thereby making the situation worse.

A very different problem then the one I proposed an answer to, no?

I think "written by genAI" should be a bigger turnoff than "written in Rust".

> * it is possible to write high quality software using GenAI

From examine this codebase it doesn’t appear to be written carefully with AI.

It looks like code that was promoted into existence as fast as possible.

sure, there are bad genAI projects and there are good genAI projects. You can remove genAI term from previous sentence.

> not using GenAI could mean project won't be competitive in current landscape

why? this is false in my opinion, iterating fast is not a good indicator of quality nor competitiveness

iterating fast over quality (e.g. refactoring, tests coverage, benchmarks, documentation, trying new nontrivial ideas) is a good indicator of quality.

you can’t iterate fast over quality though. it takes patience and expertise, not a bloated repo like this.

every example you mentioned is not something you should delegate to LLMs, unless quick prototyping

> every example you mentioned is not something you should delegate to LLMs, unless quick prototyping

it works very well for me, llm with guidance produces good quality code.

Plenty of (cattle or pet) tooling essentially devolves to SSH under those layers of abstraction.

SRV is essentially a simple layer of abstraction that provides (via one approach) the required end result (reachability + UX) that is easy to add to any $PROTO client without. Supporting ESNI would complicate the actual lib/protocol, increase the amount of dev and maintenance work required all around, significantly increase complexity, and require more infrastructure and invasive integration than any DNS-enabled service already uses.

So fwiw, browsing history shouldn’t be anywhere near that big making it unlikely there what it was. It compresses well, if they were to do it I’m sure they’d do it at regular intervals instead of a years’ worth at a time, etc.

And, of course, Firefox is open source and this wouldn’t be kept a secret.

In which case I'd love to know what it was doing sending that much data to Google IPs when I don't use Google services...

I've read all the Mozilla help pages about what automatic connections Firefox makes and it wasn't accounted for there (unless possibly something to do with SafeBrowsing.)

> Mimalloc made the claim that they were the fastest/best when they released and that didn't hold up to real world testing

That’s… ahistorical, at least so far as I remember. It wasn’t marketed as either of those; it was marketed as small/simple/consistent with an opt-in high-severity mode, and then its performance bore out as a result of the first set of target features/design goals. It was mainly pushed as easy to adopt, easy to use, easy to statically link, etc.

> It was mainly pushed as easy to adopt, easy to use, easy to statically link, etc.

That is true of basically every single malloc replacement out there, that is not a uniquely defining feature.

mimalloc definitely made claims that could not be reproduced, or at least not by me. That's why I wrote this doc five years ago. "Irreproducible malloc benchmarks" https://www.dropbox.com/scl/fi/evnn6yoornh9p6l7nq1t9/Irrepro...

That’s a considerable regression for mimalloc between 2.1 and 2.2 – did you track it down or report it upstream?

Edit: I see mimalloc v3 is out – I missed that! That probably moots this discussion altogether.

nope.

Isn't that no longer necessary? Doesn't linuxulator + podman suffice?

> Doesn't linuxulator + podman suffice?

No it is not reliable enough. Some syscalls not implemented, there are edge case issues with procfs etc. Best to execute in a Linux VM.

it’s exceedingly rare that programs dont work with linuxulator, i use vivado daily and you can play games through linux steam and proton that way.

Unfortunately podman on freebsd is pretty early stage. I was only able to get very simple containers to run.