Comment by mcmatterson
15 hours ago
Amazing project! But man, that README is just a textbook example of LLM word salad. It's wild how these tools are so incredibly capable at many things, but their writing sticks out like a sore thumb
15 hours ago
Amazing project! But man, that README is just a textbook example of LLM word salad. It's wild how these tools are so incredibly capable at many things, but their writing sticks out like a sore thumb
When the lines in the ASCII charts don't even line up my immediate assumption is that the author didn't even bother to glance at it.
The percentage-overhead comparison is pretty choice nonsense. It has only percentages to try and "explain" that overheads don't matter if the system is slow anyhow.
A fair comparison would be this project vs virtio.
Virtio? what virtio? virtio native drm native context, is that what you mean? We actually use it in nesbox[1] for AMD/Intel cards.
Venus is the only one we could directly compare to, as it is the only one that supports Nvidia GPUs. vDRM works only on AMD/Intel GPUs and has a similar performance (~98% baremetal performance) to virtio-nvgpu.
[1] https://github.com/nestrilabs/nesbox
I meant vfio-pci.
Claude is much worse for having a distinctive style you can spot from a mile away. I’ve found GPT-6 to not suffer from this or it’s insanely verbose markdown salad.
I see everyone saying this but I've been using 6-astra lately and afaict it's not much better
it's not just literary authorship, it's pretty easy to spot LLM driven programming paradigms too, especially if you look at the test suites of a given package.
My bad, i am not a native English speaker... I did my best to try and brush it up. Terribly sorry if it did not match your flow.
LLMs are pretty good at translation, they're just pretty awful at generating natural-sounding English prose from scratch. In my opinion, probably the best solution is to simply write the README in your native tongue and use an LLM to translate it.
This! Claude word salad is worse than maybe subpar translations, with which I'm sure PRs can help.
All good friend! I'm as guilty as anyone. It's a super cool project though.
Now that I have you on the hook, is there any benefit to this over virtio for a single KVM passthrough situation? I previously ran a proxmox based gaming PC setup (docs here: https://github.com/mtrudel/rabble/tree/4d9329f3dd0fb09123a8f...), and was lucky enough that the GPU passthrough part of that build 'just worked'. I'd started down a path of trying to share the GPU between VMs based on a naive 'one VM owns it at a time' setup, but never really got it off the ground.
The benefit is that you do not have a limit to how many VMs you can run at the same time. However, virtio-nvgpu has no Windows support as of yet, please check back in a while :)
You should check out Nestri [1], another project we are working on, that helps you do exactly that. It helps run multiple gaming sessions for you and your friends on the same GPU, without anyone meddling in the other person's session. Everyone gets to stream their game to whatever desktop or device they want. It is still a work-in-progress though.
[1] https://github.com/nestrilabs/nestri
Jdkhdkhdoudludlhxljdluelxfgncbt vkcljxlj. Fulxkhxjcouxyo. Choxoufoudljcljcljc gufkhxpjclixluxouc vfuoxoudydoudljc ycoucupck mccddhxhoxohxoj ljxohhlxljcluxkh ckhxoydoudljcljcljn lhxkhdhx.
Sorry. Qwerty isn't my native keyboard.
Fucukdyshd iohhfghfhgh ggbvfg gdh ghcfjh hdhvbbghb hjjgigggfv.q gfghbdbdbd cjcjcjcnn. Dr rhrjfnnf cjcucjcjjcnr rbjjdisnxbbfb hehrbrbrb. Xjcjcjcjbd rhrjrnrbrb xhfjcjcjbde hdhdbcncbfn dhdjjfjchcnbdbdbffnndnd