Live data from Hacker News

Zed on Linux Is Here

zed.dev

671–680 of 703 posts

Re: Zed on Linux Is Here

#671

I've kept my neovim config, vscode, and zed configs in parity for a while now. To the point that the keybinds and behaviors are the same (or as simliar as they can be) across all three. In my personal experience zed is eating into the time I use vscode, but not really touching neovim as much. It really has come a long way, and I'm excited I'll be able to use it on my Linux machine without having to jump through hoops…

Tips please, esp configure vscode like nvim.

It comes down to using the vim extension and making use of the context it adds when setting key binds. Both in settings and keybind json files you set commands for certain vim modes, or bind native VSCode commands to your leader. Zed does almost the same but with no defined leader key so you just have to be more specific about the command and the context they are executed in.

Re: Zed on Linux Is Here

#672
post #496
post #88

Man, I'm conflicted. I mean, Zed works pretty damn well. So far my biggest annoyance with Zed though is that it's constantly trying to download language servers and other tools and run them. And sure, that's handy, but 1. I don't really want it, I'd much rather only use distribution-provided tools. 2. It doesn't work at all on NixOS, so it's just wasting its time and our bandwidth constantly downloading and trying to…

And with that all my interest is gone and I won’t bother with zed. I highly recommend Little Snitch or opensnitch to protect oneself from rogue developers. Yes, anybody downloading things or uploading things without my consent is a rogue.

[dead]

Re: Zed on Linux Is Here

#673
post #664

Earlier quoted context omitted.

I don't think I understand your point? My argument is that the install method is just piping a curl command to your shell is _no less secure_ than any other typical application install procedure, and the user experience is pretty decent. I don't think we should be generating "loud warnings" about so called "insecure install methods" nor should we fault the Zed authors for not solving software security.

The point is that when you use a distro, you trust that distro and its maintainers. If you use the package they build for you, then you rely on this trust. Now if you use a random script from the internet, then you don't give your distro maintainers a chance to actually review the package and instead you blindly trust this script. Arguably you increase your attack surface. Also a system package manager checks the pac…

Curl checks the https certificate.

Distro maintainers in general do not audit the code they package.

Re: Zed on Linux Is Here

#674

Earlier quoted context omitted.

If any zed devs are in this thread: I highly highly suggest that any auto-download or upload (be it telemetry, plugins being downloaded, and worse: plugins uploading god knows what) is opt-in or at the very least easy to opt-out . The eagerness to download stuff without my consent at the moment precludes me from using this e.g. in a job that touches a sensitive proprietary codebase.

This is a non-starter for many larger companies. With supply chain attacks being what they are currently, this would directly prompt Security teams to block this outright.

Yes.

Even more importantly: I wouldn't use it in my personal machine :) I don't like my computer doing things without my permission.

Re: Zed on Linux Is Here

#675
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…

Well, it can actually check if it’s being downloaded from the browser or from the shell (user-agent), so unless you are downloading it and running the downloaded script, it might still spoof what will get executed. Also, it can itself download other scripts.

Re: Zed on Linux Is Here

#676
post #532
post #500

Earlier quoted context omitted.

Yes, but more in a QoL way. I say negative as in - if you don't have it you lose a customer, rather than if you have it, you gain a customer. If performance is a feature, then it's not an important feature. Otherwise, people would use Paint, for everything. Or put it another way, you want to do X1 task. It's editing a picture to remove some blemishes from skin. You could use a console, to edit individuals pixels, but…

> if you don't have it you lose a customer, rather than if you have it, you gain a customer I completely agree with that take. That's exactly the reason why, for example, whenever I'm about to do some " Real Work " with my computer (read: heavyweight stuff), all Electron apps are the first to go away. My work uses Slack for communications, and it is fine sitting there for the most part, but I close it when doing some…

I use slack (and spotify) exclusively in the browser because I need a browser open anyway. Never met anything that required the desktop client.

Re: Zed on Linux Is Here

#677

Earlier quoted context omitted.

In what way is VSCode comparable to enslaving human beings?

Having the freedom to take away freedom does not make a society more free. MIT takes freedom away from end users at the expense of the developer's freedom.

Exactly how?

It sounds like you are trying to define freedom as Stallman would. Based on that, here are his “4 freedoms”…

1. The freedom to run the program as you wish, for any purpose.

2. The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.

3. The freedom to redistribute copies so you can help your neighbor.

4. The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Which of the above does MIT not provide? Honestly, which one?

What you seem to be looking for is to take away the ability for somebody who writes NEW code to be able to choose a license for it. You want to take away their freedom?

And why exactly? What “user freedom” does this serve?

Well, it forces that users will get access to FUTURE code that developers write.

I think it is a stretch to suggest that a developer writing new code makes existing users less free. Forcing a license for the new code certainly does make the developer less free though.

If “having the freedom to take away freedom does not make a society more free” then the only morally acceptable choice is to stop using the GPL. Is that what you were trying to say?

Re: Zed on Linux Is Here

#678

Earlier quoted context omitted.

In a way that is comparable to enslaving human beings?

When you enslave a human being, you take away someone's freedom. I'm not sure how to more clearly express this.

You mean when you force developers to adhere to your desires and force them to labour for free? Is that what you mean?

Re: Zed on Linux Is Here

#679
post #530

I do not get the focus on collaborative editing (surely niche?) while the Remote Development in VS Code (in which "remote" can mean in a docker container running on your local Docker, or a container elsewhere, or a whole-ass other computer you own, or a rented computer/instance in le cloude) seems like such a more game-changing feature, similar in some ways but probably less work. And make that the thing you charge f…

Remote development is being worked on. It’s available in preview and has been assigned a priority task. https://zed.dev/docs/remote-development

Re: Zed on Linux Is Here

#680
post #616

Earlier quoted context omitted.

Erm, you do know that a founding principle of TS, is that the “compile” step is literally just stripping out the type annotations. You could implement it with a Regex if you really wanted to. The only place this rule is broken, is TS Enums, and that generally considered to have been a mistake, but one that too old to rectify.

>The only place this rule is broken, is TS Enums, and that generally considered to have been a mistake, but one that too old to rectify. Why is that?

Historical accident I think. JS has no enum concept, but early on TS devs believed that enums were an important feature. To TS produces some small JS fragments for every enum to mimic enum behaviour. It’s not exactly a lot of code, or deep woven into the final output, but it is code that doesn’t have exist in the input.

Later I think people realised that enums aren’t that important, and certainly not important enough to break the golden rule. But alas it was too late. Maybe JS will get an enum concept, and then TS can drop its hack. But until then, it’s the one spot where the TS “compiler” produces output code that doesn’t exist in its input.

Post reply on HN