That would shut out most people working for big corp, which is probably a huge percentage of the user base. It's dumb, but that's just the way corp IT is (no torrenting allowed).
It's a sensible option, even when not everyone can really use it. Linux distros are routinely transfered via torrent, so why not other massive, open-licensed data?
Oh as an option, yeah I agree it makes a ton of sense. I just would expect a very, very small percentage of people to use the torrent over the direct download. With Linux distros, the vast majority of downloads still come from standard web servers. When I download distro images I opt for torrents, but very few people do the same
> very small percentage of people to use the torrent over the direct download
BitTorrent protocol is IMO better for downloading large files. When I want to download something which exceeds couple GB, and I see two links direct download and BitTorrent, I always click on the torrent.
On paper, HTTP supports range requests to resume partial downloads. IME, it seems modern web browsers neglected to implement it properly. They won’t resume after browser is reopened, or the computer is restarted. Command-line HTTP clients like wget are more reliable, however many web servers these days require some session cookies or one-time query string tokens, and it’s hard to pass that stuff from browser to command-line.
I live in Montenegro, CDN connectivity is not great here. Only a few of them like steam and GOG saturate my 300 megabit/sec download link. Others are much slower, e.g. windows updates download at about 100 megabit/sec. BitTorrent protocol almost always delivers the 300 megabit/sec bandwidth.
With Linux distros they typically put the web link right on the main page and have a torrent available if you go look for it, because they want you to try their distro more than they want to save some bandwidth.
Suppose HF did the opposite because the bandwidth saved is more and they're not as concerned you might download a different model from someone else.
Testing. If you share something you've tested and know works, that's way better than sharing a prompt which will generate untested code which then has to be tested. On top of that it seems wasteful to burn inference compute (and $) repeating the same thing when the previous output would be superior anyway.
That said, I do think it would be awesome if including prompts/history in the repos somehow became a thing. Not only would it help people learn and improve, but it would allow tweaking.
It's gotten more popular for sure, but it's definitely been around a long time. Even just on HN there have been conversation about gdb tui ever since I've been here (starting browsing HN around 2011). For anyone who works in embedded systems it's a very common term and has been since I got into it in 2008-ish. I would guess it was much more of a linux/unix user thing until recently though, so people on windows and mac probably rarely if ever intersected with the term, so that's definitely a change. Just my observations.
I'm not GP, but I have backups, plus I always make sure I've committed and pushed all code I care about to the remote. I do this even when running a prompt in an agent. That goes for running most things actually, not just CC. If claude code runs a git push -f then that could really hurt, but I have enough confidence from working with the agents that they aren't going to do that that it's worth it to me to take the risk in exchange for the convenience of using the agent.
You can roll a script to do this, something that would consume a mic from Pipewire when triggered and then push results to clipboard. With a Parakeet ONNX model in between.
I had cause to do the the opposite: Hotkey -> clipboard TTS
My ~1.7% WER and faster than realtime processing in my application make it more than adequate. My application is multi-speaker with WPM rates >300 for long durations.
Indeed, if you're running the db in production and aren't using TLS, you're doing it wrong nowadays. Nearly every compliance framework will require it, and it's a very good idea anyway even if you don't care about compliance.
This is the perennial argument that IMHO is based on a fallacy. If the vim people suddenly stopped working on vim, it doesn't mean all their effort would go to neovim. People work on what they want to work on in open source. Also the two projects have very different goals/philosophies. The code bases have also gotten pretty different in architecture because neovim did a monstrous refactor. It's open source working as intended that we have both.
One little thought is, has there been much drama between the vim and neovim communities? (I guess community can be defined broadly enough that the answer to that question is always “yes,” but I haven’t seen much). They both seem completely happy to just do their own thing. I think the perennial argument just exits in the mind of some fans.
It is nice to see a pair of projects with so much potential for competition coexisting peacefully. Plenty of room on the internet I guess.
> That said I'd have preferred something other than Lua if I had the choice.
Same. I know we as a community would never agree on what that language should be, but in my dreams it would have been ruby. Even javascript would have been better for me than Lua.
Lua, especially with LuaJIT, is nearly as fast as C. I certainly don't want to have to run a slow language like Ruby or especially a full blown JS runtime like V8 just to run Vim, the entire point is speed and keyboard ergonomics, otherwise just use VSCode.
You don't need V8 for running JS for scripting, you have quickjs[1] or mquickjs[2] for example. You might have problems importing npm packages, but as we can see from lua plugins you don't even need support for package managers. Performance is not as good as luajit, but it is good enough
Because I know javascript a lot more than I know Lua (and I suspect given js popularity, a lot of people are in the same boat). Yes Lua is easy to learn, but it's still different enough that there is friction. The differences also aren't just syntactically, it's also libraries/APIs, and more. I also don't have any need/use for Lua beyond neovim, so it's basically having to learn a language specifically for one tool. It's not ideal for me.
But the people who did the work wanted Lua, and I have no problem with that. That's their privilege as the people doing the work. I'm still free to fork it and make ruby or js or whatever (Elixir would be awesome!) first-class.
I agree but also wonder if editor plugins fall squarely in the range of things an LLM could vibe-code for me?
There is a large class of problems now for which I consider the chosen programming language to be irrelevant. I don't vibe code my driver code/systems programming stuff, but my helper scripts, gdb extensions, etc are mostly written or maintained by an LLM now.
I'm right there with you, and to be honest Lua just works. I helped with Neovim when it started ~10 years ago, and didn't understand the big deal about implementing lua.. But now that it's here, I can't believe it wasn't forked and implemented sooner
IME, Claude is quite good at generating Lua code for neovim. It takes some back and forth because there's no easy way for it to directly test what it's writing, but it works.
i’ve written probably north of a million lines of production js, maybe around 100,000 lines of production ruby, and about 300 lines of production lua. lua is a fun language and i think a much better fit than JS for technical reasons (who has a js engine that is both fast and embeds well? nobody), but i am certainly more productive in those other languages where i have more experience.
lua array index starting at 1 gets me at least once whenever i sit down to write a library for my nvim or wezterm.
reply