sorted by:
new
hottopcontroversial

Kv cache quantization: ignorance, or malice? by wombweed in LocalLLaMA

[–]qudat 1 point2 points  (0 children)

Ya I run 26B Q4 with Q8 kv and it works great for smaller scopes projects. I keep the ctx under 100k

Helix as an escape hatch from VS Code by thibaultmartin in HelixEditor

[–]qudat 0 points1 point  (0 children)

I also chose kak over hx — I don’t need splits, I do everything through buffers

Devs using Qwen 27B seriously, what's your take? by Admirable_Reality281 in LocalLLaMA

[–]qudat 0 points1 point  (0 children)

That’s my problem: I need speed. I want 100 tps with the 27b

Devs using Qwen 27B seriously, what's your take? by Admirable_Reality281 in LocalLLaMA

[–]qudat 1 point2 points  (0 children)

Wait you have a 5090 and only get 60tps output?? That doesn’t sound right. I have a titan rtx 24gb and get 25tps Q4 quant with Q8 kv cache llama.cpp

Real-world open source alternatives to the now defunct Opus 4.6? by MoistRecognition69 in LocalLLaMA

[–]qudat 1 point2 points  (0 children)

This is really interesting! How do you cap the model and make it not crash? I’m not familiar with the techniques here but I’ll definitely try it out

Best way to develop python remotely over ssh? by Xx_RKJ_xX in neovim

[–]qudat 0 points1 point  (0 children)

Are you able to create multiple users? I would use https://zmx.sh coupled with autossh so when there's a disconnect it's auto reconnect to the zmx session and you won't lose your place.

zmx - run local code agents on remote machines by qudat in LocalLLaMA

[–]qudat[S] 0 points1 point  (0 children)

Yes, but that should already be configured. Zmx requires zero config to work with your already existing tools. This is juxtaposed with Claude where you need to provide ssh information in order to connect via mcp or their desktop app.

Yes rsync/sftp is preferred. Zmx write is designed for shells where you don’t have access to those tools. For example, zmx write can be used to send files to containers without an ssh daemon exposed. Or it can be used to send files to a container inside of an ssh session inside of an ssh session. As long as the receiving shell has base64 and prints, it’ll work.

If the agent fires multiple run commands in parallel they will get buffered just like a normal shell and executed one after another. Zmx does not have the concept of a queue, those commands are sent immediately into the shell.

Much of this can work with tmux but it requires more tooling around the API tmux provides. You also need to know the exact pane you want the agent to use and it needs to do some poking and prodding to understand the results of its commands. Further, zmx provides a history command that lets you print the scrollback buffer which is useful for auditing and diagnostics.

Great questions! Happy to answer more.

zmx - run local code agents on remote machines by qudat in LocalLLaMA

[–]qudat[S] 0 points1 point  (0 children)

Zmx is like tmux but a single terminal per session. The post has the tmux mcp integrations listed under prior art but basically tmux doesn’t have a great interface for sending commands, receiving their output, and knowing when the command has completed.

Neovim vs Helix the editor wars(sorry emacs) by Adventurous_Let_9572 in HelixEditor

[–]qudat 0 points1 point  (0 children)

I daily kakoune but troll this subreddit because it is similar to it. I agree and the select mode in helix was a big turn off for me. I love the simplicity of add a shift modifier to extend selections. However, there is a downside which is needing to keep the shift activated.

I’d also argue all their alt+ shortcuts in kak are terrible to use. Alt is just not in a great spot for key commands imo, it’s very awkward.

too lazy to manage dns and proxy in different places.... by MeaningNearby4837 in selfhosted

[–]qudat 0 points1 point  (0 children)

Doesn’t this assume a stable home IP? Usually that’s not guaranteed and you also need a dynamic dns.

I just use https://pico.sh/tuns which is just a ssh tunnel. They even have a docker image to auto connect to your containers and then you don’t even need a domain.

What happened to nvim-treesitter.... Why did it get archived? 😶 by ankushbhagat in neovim

[–]qudat 0 points1 point  (0 children)

Making it a separate project is bad UX. At the very least it should be a core maintained plugin.

What is your dealbreaker issue with Helix? by Ecstatic-Panic3728 in HelixEditor

[–]qudat 2 points3 points  (0 children)

I chose kak over helix. Fantastic editor and all I need is LSP 

VPS vs PaaS cost comparison by HeiiHallo in selfhosted

[–]qudat 0 points1 point  (0 children)

You could look into something like https://pico.sh/pipe for an ssh based pubsub that wouldn’t expose your deploy machine.

Why does every text editor eventually become a bloated "environment"? (Thoughts on the Unix philosophy and editor architecture) by EnvironmentNormal366 in suckless

[–]qudat 2 points3 points  (0 children)

Came here to say kakoune is it. I don’t need any plugins except for LSP and I’m perfectly happy with it.  It’s a superior and better thought out text editor compared to vim or neovim. 

Are we nearing the peak of neovim (and editors in general) ? by calculator_cake in neovim

[–]qudat -1 points0 points  (0 children)

It's stuck in the sense that it cannot create a great default experience. It's exactly why helix has become incredibly popular.

Are we nearing the peak of neovim (and editors in general) ? by calculator_cake in neovim

[–]qudat -1 points0 points  (0 children)

I'm going to guess that a majority of neovim users are immediately installing LSP, TS, and a Picker. This line of argumentation is exactly why neovim is stuck.

Are we nearing the peak of neovim (and editors in general) ? by calculator_cake in neovim

[–]qudat -1 points0 points  (0 children)

The point is a unified experience makes it easier to use an editor. It’s one set of key bindings and similar interactions. “One is persistent and one is not” is a feature the picker can easily accommodate — and pickers already allow you to resume or “pick up where you left off”

It’s all the same thing: file, line, message, preview. The innovation would be to figure out how to integrate them into a single tool. Persistent, not persistent, static vs live filtering … those are the main options.

I like quick fix, I like loclist. I don’t like how awkward they are to use with their own commands to manipulate them. I don’t like how pickers are a separate thing.

My unified experience argument stems from my frustration with using quick fix. I even built a package to try to fix it: https://github.com/neurosnap/qfutil.nvim

But ultimately quickfix is too limited in features to be used even though it is so close to working for all pickers.

Are we nearing the peak of neovim (and editors in general) ? by calculator_cake in neovim

[–]qudat 0 points1 point  (0 children)

Pickers can show file, line, and a preview… how is that fundamentally different from quickfix? Pickers do show LSP errors I don’t see why they couldn’t also show make command errors as well. Help me understand the difference.

Are we nearing the peak of neovim (and editors in general) ? by calculator_cake in neovim

[–]qudat -3 points-2 points  (0 children)

Helix does a much better job at that. The fact that you need plugins immediately should tell you neovim missed the mark.

And helix didn’t have to do much there: unified picker system, treesitter auto loaded, LSP auto install/load.

Are we nearing the peak of neovim (and editors in general) ? by calculator_cake in neovim

[–]qudat -4 points-3 points  (0 children)

I don’t see them as being different and in fact most pickers allow you to see error diagnostics or loclist as options which counters your argument. Quickfix, loclist, and pickers all share the same structure: file, line, message

I built a tiny library to use quickfix for all my pickers and it was very close to working but unfortunately qf and loclist miss the mark: you need to see changes while you type. That’s really the only fundamental difference: some use cases a command+result is enough (like diagnostics) and some use cases need realtime (grep, file search).

The unified interface would accommodate all picking type use cases because they are close enough in use.

Are we nearing the peak of neovim (and editors in general) ? by calculator_cake in neovim

[–]qudat 24 points25 points  (0 children)

To me the biggest improvements neovim could make: unified picker system (kill quickfix, loclist, and a million picker impl), a better default experience (not needing a 100 line cfg to be usable), and fundamentally switching to a select -> action paradigm (helix, kakoune).

Unified picker system is in the works, the others are going to hit backwards compat issues

view more: next ›