"Don't worry, it'll make us rich -- and that's nearly the same as everything being just fine"

> The current government is maximally evil

Wow. That's incredibly optimistic. Imagine, for example, the next 'no kings' protest is met with machine gun fire, rather than ice sporadically killing activists. And then start adding on stuff.

Today, the people at the top need people at the bottom to sustain their lifestyle. Put on your billionare sociopath hat for a moment and ask yourself: If AI ever becomes sufficient to run an economy, why should you care about whether they live or die?

Then, ask yourself why the wealthy are so obsessed with AI.

> why the wealthy are so obsessed with AI

Because they want to be more wealthy, and AI is the draw for investors now.

Future is bright because it's going up in flames.

> Not to mention you just can't trust a model's judgement if the highest bidder chooses what it thinks

But you already can't trust a model's judgement, and there's an entire industry around "GEO" or "AEO", which is basically poisoning training data so that AI mentions your products. The post above is the owner of the model taking a cut of that.

But this is a company building on AI.

The project itself is open source and doesn't have any AI features.

Also while Imbue is in some sense an AI startup it does have a very different ethos from a lot of tech companies: https://imbue.com/about

Ethos is lived not told.

It's weird seeing someone trying to promote self-hosting, while building everything with Claude.

AI is a tool. the use of this tool to deliver something unrelated is... unrelated

Does self-hosting need to be all or nothing?

I didn’t get that from their comment at all

"It's weird seeing someone pay for food when they have a garden at home."

LLMs can be self hosted though. Using Claude to build a self hosting platform is a bit like telling people they should be vegan while you're eating a bacon sandwich.

In what way are those remotely similar?

Veganism is incompatible with bacon. You can self-host, and also pay for cloud services when they are better than what you can self-host.

If anything it's like suggesting making food instead of getting takeout while buying bread from the store, because it's better than what you can make at home.

It's weird seeing someone promote home gardening by selling grocery store products.

Why would you use uring to read from an mmap? Couldn't you just memcpy?

To be more precise: i use that map to send assets out directly to clients from a zip file.

Its a new web server i am building and its the fastest way i could find out.

Just switching from epoll to liburing made the server ~45% faster too, its ridiculous. It can serve 10 gigabyte per second with a single thread, or around 10 million responses per second with h2 and 32 multiplexed requests.

I had to write a new http load generator for that since i couldn't find one which could generate enough load to saturate my server or be fast enough to withstand it.

10 gb per second is pretty slow for a disk. You should be seeing much higher than that.

??? The only configuration that will allow disk reads at 10 GB/s is if you're using PCIe 5.0. PCIe 4.0 or lower, and SATA will not drop out long before that.

He's very clearly hauling data straight from the page cache.

...I'm still confused why you wouldn't use memcpy?

How can one memcpy from a fd to a socket? I don’t touch the bytes in userspace, I just tell the kernel to send them out.

So why would you mmap?

to not let the bytes i forward enter userspace, i serve from the page cache for the asset path, directly from a zip file.

i open the file, mmap it, close it and tell io_uring_prep_send which bytes from the mapping to send, this also saves me from a possible SIGBUS cause the access to the mmap happen inside the kernel, and when a SIGBUS would happen in userspace the kernel just reports a shorter send in cqe->res

Maybe they meant using IORING_OP_MADVISE with MADV_WILLNEED to bring ranges into memory?

The Linux-specific MADV_POPULATE_READ is much more reliable than MADV_WILLNEED if you want to implement read-ahead for a memory-mapped file.

In my opinion, the POSIX advices specified for madvise are useless or even dangerous.

On Linux, for precise control of memory-mapped files one should use only these 4 Linux-specific advices: MADV_COLD, MADV_PAGEOUT, MADV_POPULATE_READ & MADV_POPULATE_WRITE.

These should be used within io_uring, so that they will be executed asynchronously.

These have a well-documented meaning and using them carefully should be sufficient to reach optimum performance with mmap.

Though at that point you can just use FADV_WILLNEED.

I'm just steelmanning here ¯\_(ツ)_/¯

Yes, the same compiler generates the same output given the same input. I'd be willing to put a large amount of money on that result.

I read a lot of assembly.

How is this different from what's built into Claude?

Works across agents for one.