perbu

Yes. This is my experience as well. The software quality is generally horrible. It surely has improved a lot over the last couple of months, but it is still pretty horrible.

It is quite normal for me to have to force-close Claude Desktop.

I’ve raised money here and there. Never really had issues with the EU regulations.

But the lack of risk capital and investor brainpower has been a huge problem.

This is quite a low quality post. There is nothing of substance here. Just hot air.

The only software I've seen designed and implemented by OpenClaw is moltbook. And I think it is hard to come up with a bigger pile of crap than Moltbook.

If somebody can build something decent with OpenClaw, that would help add some credibility to the OpenClaw story.

A proper library OS doesn't have syscalls. Everything operates in the same space, no user/kernel split.

Not at all. There is no indication that the world won't need more GPUs going forward.

Software I built will have the following ingredients.

source from git ~30 go packages ~150 npm packages ~A three layered docker image

Want to verify the installed package, the package should provide checksums you can verify. AFAIK, the SBOM is to documents the build, not the install.

I have the same and I'm very happy with UX, but less happy about the key leaving the machine.

The reason this makes sense, at least for Github, is because the only valid reason to run your own action runners is compliance. And if you are doing it for compliance, price doesn't really matter. You don't really have a choice.

If you've been running your runners on your own infra for cost reasons, you're not really that interesting to the Github business.

JFS-CPP bans exceptions because you would lose control over the execution of the problem. The HFT crowds didn't like it because you'd add 10ns to a function call.

At least before we had zero-cost exceptions. These days, I suspect the HFT crowd is back to counting microseconds or milliseconds as trades are being done smarter, not faster.

Last I checked the user guide to the API was 3500 pages.

3500 pages to describe upload and download, basically. That is pretty strange in my book.

You are not a sovereign wealth fund representing a whole country, though.

He knows a lot of things and is amongst the best software developers I've worked with, but on a project like this you need a lot more breath than any single developer can bring.

The post is about mmap and my somewhat successful use of it. If I've described my whole stack it would have been a small thesis and not really interesting.

random reads are ok. writes through a mmap are a disaster.

Not really.

We've been funding phks work on Varnish and Vinyl cache for 20 years. Do you think phk can write, maintain and release something on his own? Vinyl Cache cannot be a one-man-show, be real.

We need to support over 10M files in each folder. JSON wouldn't fare well as the lack of indices makes random access problematic. Composing a JSON file with many objects is, at least with the current JSON implementation, not feasible.

CDB is only a transport medium. The data originates in PostgreSQL and upon request, stored in CDB and transferred. Writing/freezing to CDB is faster than encoding JSON.

CDB also makes it possible to access it directly, with ranged HTTP requests. It isn't something I've implemented, but having the option to do so is nice.

This is amazingly good feedback. I hadn't thought of that at all. It is so much harder to reason about the Go runtime as opposed to a threaded application.

The point is that invoking the OS has a cost. Using mmap, for those situations where it makes sense, lets you avoid that cost.

This is a niche scenario. The scenario outlined is reading CDB databases.

Yes. When Varnish Cache launched, in 2006, I worked in a rather small OSS consultancy, which did the Linux port of Varnish Cache and provided maintenance and funding for the project.

It's about scalability. If you have 100 instances you really want them to share the cache so you increase hitrate and keep egress costs low.

End-to-end (glass-to-glass) latency is substantially better. Mostly because the protocol isn't request/response any more.

Unikernels are quite an intriguing concept. They'll be re-discovered every five years, like programmers keep re-discovering functional programming.

They made the amd64 architecture. Let’s not forget that.

The black market isn't going to care about it. It isn't really exploitable.

It isn't. Filippo is a x-googler that used to work on Go crypto for Google, so assumptions are easy to make.

The project seems to be sponsored by Let's Encrypt, fwiw.

Back in 2008-2009 I remember the Varnish project struggled with what looked very much like a memory leak. Because of the somewhat complex way memory was used, replacing the Glibc malloc with jemalloc was an immediate improvement and removed the leak-like behavior.

Markdown is the native formatting of large language models. As such, support for it will be everywhere in the coming years.

I suspect LLMs, not users, have been the requesting this feature at Apple.

I'll suspect it'll be more like the next little thing. Most of don't interact that much with structured data, so the applications will be very specific.

However, the algo-trading crowd, will likely be very interested in this. They deal with structured data all day and it would surprise me if most of them don't already have things like this working in their networks. They seem to be very secretive, though, so we're not gonna hear much.