To be fair, there was a roughly 6 year period when vim saw one very minor release. That slow development period was the impetus for the fork of Neovim.
Can you elaborate a little more on your setup? Are you manually copyong and pasting code from one LLM to another, or do you have some automated workflow for this?
No manual copy paste. That is not good use of time. I work in a git repo and point multiple LLMs at it.
One LLM reviews existing code and the new requirement and then creates a PRD. I usually use Augment Code for this because it has a good index of all local code.
I then ask Google Gemini to review the PRD and validate it and find ways to improve it. I then ask Gemini to create a comprehensive implementation plan. It frequently creates a 13 step plan. It would usually take me a month to do this work.
I then start a new session of Augment Code, feed it the PRD and one of the 13 tasks at a time. Whatever work it does, it checks it in a feature branch with detailed git commit comment. I then ask Gemini to review the output of each task and provide feedback. It frequently finds issues with implementation or areas of improvement.
All of this managed by using git. I make LLMs use git. I think would go insane if I had to copy/paste this much stuff.
I have a recipe of prompts that I copy/paste. I am trying to find ways to cut that down and making slow progress in this regard. There are tools like "Task Master" (https://github.com/eyaltoledano/claude-task-master) that do a good job of automating this workflow. However this tool doesn't allow much customization. e.g. Have LLMs review each other's work.
But, maybe I can get LLMs to customize that part for me...
I have been doing this with claude code and openai codex and/or cline. One of the three takes the first pass (usually claude code, sometimes codex), then I will have cline / gemini 2.5 do a "code review" and offer suggestions for fixes before it applies them.
This one has pretty heavy nostalgia for me. Resedit is a big part of why I'm in software development today. My first forays into "hacking" were to use Resedit to modify some nagware to skip the pay screen. It was a definite peek behind the curtain moment that made me much more curious about computing.
Same for me, my first foray was making changes to the game Escape Velocity using ResEdit, then I used it on anything and everything, then as soon as official modding support came out for games like Myth, Doom, Marathon, etc, I starting making mods, and then it was coding and so on. :)
Same! Escape Velocity and its sequels were at a very important point of learning software development for me. I didn’t get in to game dev, but being on the ambrosia software IRC server taught me a lot of things.
It’s significant to my dev roots too. I had both the OS itself as well as several apps customized, with the most extensively modded being a totally rebranded Netscape Communicator with custom iconography. I also used it to mod games, doing things like changing sounds something silly or replacing 2D characters with pixel-versions of my siblings.
It was always a bit disappointing to come across the odd program (usually cross platform stuff) that had little or nothing that could be edited in ResEdit.
Linode went through a rather long DDoS attack a few years back with a few of their data enters being offline for a few days, so I would guess yes there.
I'd think opening a PDF in your browser would be at the same risk-level you associate with going to any random URL. On Firefox at least, I'm pretty sure the built-in PDF viewer is simply JS parsing and rendering the PDF anyway -- nothing with elevated permissions:
> I'd think opening a PDF in your browser would be at the same risk-level you associate with going to any random URL.
Probably pdf.js is more secure, as it is more modern than the HTML/js engine, it contains less legacy code, it is written in a higher level language, and they could implement a safer subset of the pdf standard, than they could do with the HTML/js standards.
> Depends though, because in theory you could then have wildly different employment conditions depending on which union / industry you work for.
> Of course, if another industry has better conditions, you can always vote with your feet. Competing for employees benefits the employees, in theory.
There's an interesting dynamic there though that you mention that a particular union may affect the employment conditions across a whole industry. So, theoretically an employer in an industry with a bad dominant union might be be hamstrung even if they wish to improve employment conditions but the core issues stem from a bad union (I'll note this question is from the perspective of an American, with limited and generally poor interactions with unions, who wishes things were better here).
