@keepamovin this looks cool, but notice that your README and github links are ghosting us (404)

Thanks. I posted and really didn't expect any points. So checking back after 40 minutes and seeing it blown up was quite a shock. I'm working through all the things people have pointed out!

You can run nullclaw etc on a Pi zero. People who are paying big $ are mostly trying to run local LLMs.

Personally, I would rather pay a few bucks for Qwen or just use gemma4 which runs on a potato. But I guess we are all different.

There was an AI roundtable on HN front page 2-3 months back. Someone made an outlier analysis and put it on his github.

Guess which LLM was the top outlier and about what type of questions it disagreed with all other LLMs...

Okay, this sounds familiar.

If you run Claude Opus 4.6 at max settings on forgejo repo, it will give you a bunch of RCE's ... that need prior knowledge of the server internal token :) You have to tell the stupid LLM that these attacks doesn’t make sense.

The author seem to be a experienced security researcher. I am surprised he didn't catch this.

I think the author would argue they did try to do so, but their efforts were poorly received.

The author doesn’t owe forgejo anything. They are doing them a favor by highlighting the issues

coordinated disclosure has always been a courtesy (with a deadline to motivate the vendor to fix their stuff) and i don't like how people seem to just expect it now

Advisory, fresh from the owen

https://github.com/Lightning-AI/pytorch-lightning/security/a...

Also, that zig team is already working on other approaches that are better and more stable than what Bun team did:

https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Notable quotes:

>There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0!

>Each [incremental] update is taking less than 0.4s, compared to the 120+ seconds taken to rebuild with LLVM. In other words, incremental updates are over 300 times faster on this codebase than fresh LLVM builds are. In comparison, an enhancement capped at a 4x improvement is pretty abysmal. [..] Again, this feature is available in Zig 0.16.0—you can use it!

WTF is the "planned shooting" you casually dropped here?

Oh, nothing special, just a run-of-the-mill school shooting he wanted to do at some point.

i was beginning to wonder if this is the new world we're living in now where such things are casually discussed

I assume its a misstranslation, basically somebody trying to go to the shooting range with friends?

I doubt that it is the case. The registration of the gun is a part of the process everywhere afaik.

I dont get it. What exactly does kitty give use here?

Zed seems to have many fans on HN.

But it is not for me. Multiple issues on Linux and high memory usage makes it a worse alternative to vscode and jetbrains.

Maybe it's better on OSX, but I dont use that anymore and why use an editor that treats your platform as a second class citizen?

On MacOS I never really felt there was a noticeable performance difference to using Zed vs VSCode. I still like the idea of it being Rust/GPU based but just like those GPU optimized terminals (Kitty, Alacritty, etc) the difference is usually pretty marginal for day to day stuff.

The only time VSCode gets slow is if you use a bunch of poorly written plugins, which hasn't been an issue for me in years. It's just like Chrome, chrome is extremely fast as a base but you can mess it up by not being careful with what you add to it.

I still plan to revisit Zed in another year or so once it progresses further, as I find it's still behind Cursor in many ways.

This is exactly how I feel.

Cursor works just fine for me. I just don't have the incentive to learn a new tool even though I think Zed is cool.

So I'm not so sure how you arrived at your conclusion of Zed having higher memory use than VSCODE but in testing just now that's not at all close to true.

Zed for me on my Linux machine opened to a massive C++ project (the Ladybird browser if you were curious) is (not including LSP or extension processes) using around 480MB of memory.

VSCode on the other hand with nothing open but a 20 line JSON file is (again not including any LSP or extension processes) using around 920MB of memory as reported by its own builtin task manager thing.

I suppose 480MB for a text editor might be a tad high but calling it worse than VSCode is a massive stretch.

If editors own memory usage is your main concern then you should use emacs or even better mg or vi.

The editor + its plugins + it's LSP server is what counts. I dont care if zed is written in rust and uses 400MB when it spawns a multi GB nodejs process when I work on my tiny golang project.

I mean all 3 of those also support LSP plugins, so would also spawn "multi GB nodeJS processes" with your tiny golang projects if you enable them.

Yeah but other editors do not foolishly choose to install and run those things out of the box.

I've personally found it uses significantly less memory on large projects than VSCode. VSCode has historically been nigh-unusable for me on Linux, it gets incredibly sluggish.

Hey, support engineer at Zed here.

If you have a reproducible setup for a bug we don't know about, we'd love to get a proper report of it.

You can schedule 15mins with me here: https://calendar.app.google/fyLQkqvne7EdvR8XA