baruch

I find it useful to see such a project. It's an interesting view of the system and a neat idea, I don't care if it's just a couple of ai prompts and will be abandoned next week or maintained for life, the idea itself is good to learn from and maybe used as a start for other useful tools for my work.

Thanks for sharing this.

It is possible to get more tokens out of the same hardware by leveraging fast storage for KVCache, it is especially useful for agentic workloads.

If they started doing caching properly and using proper sunrooms for that they'd have a better chance with that

It is mathematically impossible for a proper hash function (one with an output range smaller than its input range) to not have collisions. The proof uses the Pigeon Hole Principle https://en.wikipedia.org/wiki/Pigeonhole_principle

You can ask an LLM to create a github action for that. The action can fail if the rebase fails and you can either fix it yourself or ask an LLM to do it for you.

Isn't that handled pretty well these days with sub agents? They can research the code without polluting the context.

There is a global setting you can do to disable using the Claude.ai MCPs from being used on your Claude code.

The complaints are against the open-weight LLMs, I didn't try them much. I do use mostly Claude as that's what the company is paying for. They don't pay for laptops with GPUs or locally hosted LLMs to test those.

It's not like it knows perfect D, it does make mistakes and I don't work on a C++ or Rust project to compare its behavior. Generating templates from scratch is a bit of a challenge but given we have plenty of examples in our code with some prodding it manages to write well enough.

I work with D and LLMs do very well with it. I don't know if it could be better but it does D well enough. The problem is only working on a complex system that cannot all be held in context at once.

Is it possible to put such a driver for nvme under igb_uio or another uio interface? I have an app that uses raw nvme devices and being able to tests strange edge cases would be a real boon!

Ages ago, working on an embedded system we did something similar by running gdb server on the embedded machine and gdb on the server and running a script to collect periodic stack traces to get a sampling profiler.

The company still got $20B of cash(?) in its books, it can pay dividends to its shareholders (investors) and they get their payment. The company can go down the drain afterwards. If it can still make money with its remaining assets that's only a nice small bonus.

So the only ones getting shafted are the employees.

We do storage systems and use DPDK in the application, when the network IS the bottleneck it is worth it. Saturating two or three 400gbps NICs is possible with DPDK and the right architecture that makes the network be the bottleneck.

Once there will be a business around this and people will make money the businesses will maintain a lobby to keep doing it and even increase the operation.

I only use my common sense here, but it doesn't stop the production it just prevents the transport from the source to the destination through the area that was previously iron deficient and couldn't use the fully the other nutrient which passed on to another area.

It's easier to write the system's front end while paying little attention to the backend and "just" letting a local filesystem do a lot of the work for you, but it doesn't work well. The interesting question is if the result is also that the frontend-to-backend communication abstraction is good enough to replace the backend with a better solution. I'm not familiar enough with Ceph and BlueStore to have a conclusion on that.

I happen to work for a distributed file-system company, and while I don't do the filesystem part itself, the old saying "it takes software 10 years to mature" is so true in this domain.

I find that my understanding of different layers is usually not needed but is rarely important toy ability to solve thorny issues or figure out ways to do things or debug issues that others are not even trying.

I'm working in areas of systems programming where such knowledge and willingness to go deeper into the stack is helpful, even if rarely so.

I can't say I understand the kernel, I only scratch the surface of most of it and only dug deeper where I really needed to and only as deep as time allowed me and the need required though.

The advantage for text based interfaces is that they work over ssh/tmate over trans atlantic connections whereas the GUI tools would suffer greatly. It just works everywhere and if you learn it, it will be just as good as a gui debugger. Potentially even more ergonomic without hunting for options with a mouse.

Asynchronous IO with user space threads works wonders to get both the performance of async IO and the convenience of sequential programming.

My day job is working on a product that uses DPDK for a super high performance file system.

Your company already doesn't really care about you (for the vast majority of them at least), so there is a conflict of interest but you personally shouldn't take the side of the company.

I do. To learn a code base it before tremendously, also to find what happened and why things were done it is off great help. I don't need it every day but I routinely do git archeology.

Do note that more drives mean higher chance to see a failure...

I'm working mostly with enterprise drives and not consumer. These drives can write continuously at 1 to 4 GB/s depending on the specific type (mixed use vs read intensive vs very low writes).

They do fail and you should have redundancy and backup but there isn't a real point to do the optimization that the article describes.

NVMe drives fail at a fairly low rate so this is an optimization for a very small edge case and since they are also very fast it's not like you'll be doing a rebuild for 6+ hours like with HDDs.

It also doesn't change anything for distributed storage.

And here we are working on systems with dual 400Gbps and sending data out of storage clusters at 5 TiB/s.

I believe pricing (in quantity, these usually do not sell by single pieces) is around 6 cents a Gig so about $7680. I could very well be wrong though, it's been a while since I heard pricing of DC SSDs.

Effect of element alignment in a memory pool by L1 cache collision.