Live data from Hacker News

Zed on Linux Is Here

zed.dev

601–610 of 703 posts

Re: Zed on Linux Is Here

#601
post #555

Earlier quoted context omitted.

> where's the difference between downloading a binary and executing it vs. downloading a script and executing The difference is that the attack vector of the shell script is an easier target. If someone was to be malicious; they could manipulate the script and inject some sort of payload in disguise. It's an easier vector to damage than say an compiled package. One that's less prone to being detected in that the scri…

If I were to serve a targeted exploit like this, I would certainly hide it in the binary and have the binary determine whether it's running in the targeted environment and then run the payload. It's much, much easier to hide a malicious payload in a binary than an easily auditable shell-script. And it's much easier to make a decision of whether the payload should be enabled or not if you are already running on the lo…

See, I wouldn't. I would go for the script to either inject the payload to the package or inject to the host.

Even if it's auditable, how many people are actually verifying the shell script before hand?

You've just been given a command to download and execute.

And the potential of having lots of users downloading a shell script has a quicker attack path than users downloading the package. You have custom repos, holding their own distro packages for the software.

Re: Zed on Linux Is Here

#602

Earlier quoted context omitted.

This is giving me flashbacks to editors of yore; EMACS, Eight MB And Continually Swapping. I remember reading almost the exact same comments on Usenet from the 80s and 90s.

Flashbacks? It’s 2024 and Emacs is still single threaded

And it still performs better than vscode.

Re: Zed on Linux Is Here

#603
post #263

Earlier quoted context omitted.

I'm on the same camp, but in the end it turns out we were not putting it to the actual, real, hard-world test. VSCode is very fast for me, when I open it in the morning and just starting my day . But once I've opened the main project and 7 support library's projects, and I'm in a video-call on Chrome sharing my screen (which is something that eats CPU for breakfast), and I'm live-debugging a difficult to reproduce sc…

> In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks. Same can be said about a lightweight web page and 'React' with tons…

Sure. Just allocate 10x the engineering resources and I can make it as fast and bug free as you like.

Re: Zed on Linux Is Here

#605

What does Zed use as the UI toolkit? Looking at the code they have a handmade UI toolkit called gpui. Does that map directly to OS/DE specific GUI bindings? I can't find where that's happening EDIT: Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild https://github.com/zed-industries/zed/blob/main/crates/gpui/...

> Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild I grew up developing Windows apps using the native Win32 API:s, and there was nothing particularly daunting about it. Using what the OS provides shouldn't be considered such an outlandish idea, and being scared of it is causing stagnation and waste (looking at you, Electron). The code here is only a co…

I'm not sure how much of it is people being (irrationally) scared vs. looking into native APIs and making the call that it just isn't worth it, given how much messing around you have to do to get basic functionality working vs. the web where you can throw a UI together very quickly to validate an idea.

I've looked into native Linux development a few times, for example, and haven't even been sure what's the best toolkit to use. It feels like you'd have to invest quite a lot in a particular toolkit to even see if it can do what you need, coming fresh from web dev like a lot of people who go for Electron obviously are (myself included).

Re: Zed on Linux Is Here

#606
post #391

Earlier quoted context omitted.

My only problem with VSCode is that it's owned by Microsoft. I'm willing to put up with some extra friction if it allows me to escape their ecosystem even a little bit. My general rule is if I can get at most of what I need from the open source version of something, I use it. Even if it's less user friendly.

I, too, prefer to cut off my nose to spite my face.

Yes, living by principles is inconvenient sometimes.

Re: Zed on Linux Is Here

#607
post #600

Earlier quoted context omitted.

If you're familiar with nvim, you slowly realize how bloated and unnecessary the indexing is in intellij. It makes the experience so awful and for what? A file search feature that takes multiple seconds to find a file in root

Indexing maybe. But there's more: IntelliJ understands your code, and this make more sense for static/strong typed langs. We do a lot of Kotlin and IntelliJ is indispensable.

This is very true. PyCharm is by far better than any other IDE for professional python work. With how dynamic Python is, PyCharm's completion and static analysis is pretty remarkable.

Re: Zed on Linux Is Here

#608
post #443

Earlier quoted context omitted.

Just an fyi, I have shot myself in the foot with Sublime's version of this. I became dependent on using unnamed/unsaved documents for quick notes, then at some interval I would clean up. And because Sublime would remember, I could rest safe that they would be there even if closed and reopened until I cleaned them up myself. Well, I also got so hooked on Sublime, I set it as my default system text editor. Then, (more…

Yes, never trust features like these for anything important, we're just not in that era of computing where losing user state is a cardinal sin. Had the same issue. Though you could use a shortcut to quit the editor instead of closing windows

Note that Sublime Text always prompts for each unsaved file in cases where their content could be lost. We heavily prioritize issues with data loss. That being said I still wouldn't recommend keeping important stuff unsaved, really they should be fully backed up like everything else important.

Re: Zed on Linux Is Here

#609

Earlier quoted context omitted.

Sublime works this way and I do appreciate it

Just an fyi, I have shot myself in the foot with Sublime's version of this. I became dependent on using unnamed/unsaved documents for quick notes, then at some interval I would clean up. And because Sublime would remember, I could rest safe that they would be there even if closed and reopened until I cleaned them up myself. Well, I also got so hooked on Sublime, I set it as my default system text editor. Then, (more…

I'm trying to follow how this can happen as I use Sublime's cache feature for temporary notes between meetings and want to make sure there isn't some corner case I've just not run into yet. The two related scenarios I can grok from this are:

- Create unsaved or modified versions of saved documents -> close Sublime completely (no prompt, documents go to cache) -> open download.txt -> new window has tabs for the cached documents and a new tab for download.txt

- Create unsaved or modified versions of saved documents -> open download.txt in a new Sublime window (2 windows open now) -> try to close unsaved/modified documents -> get popup warning that changes will not be saved (because it isn't the last window so they won't be saved for the session persistence)

But both of these are safe (i.e. you don't lose anything unless you click the button saying you want to lose something) so there must be another path to failure I'm missing.

Re: Zed on Linux Is Here

#610

Earlier quoted context omitted.

This is giving me flashbacks to editors of yore; EMACS, Eight MB And Continually Swapping. I remember reading almost the exact same comments on Usenet from the 80s and 90s.

Flashbacks? It’s 2024 and Emacs is still single threaded

It’s also 2024 and you still can’t share JavaScript objects between threads. Do not underestimate the horror that is tracing garbage collection with multiple mutator threads. (Here[1] is Guile maintainer Andy Wingo singing praises to the new, simpler way to do it... in 2023, referring to a research paper from 2008 that he came across a year before that post.)

[1] https://wingolog.org/archives/2023/02/07/whippet-towards-a-n...

Post reply on HN