Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed on Linux Is Here

zed.dev

Post reply on HN
Print view View original

281–290 of 703 posts

Re: Zed on Linux Is Here

#281

Post by kelnos »

DarkCrusader2 wrote: post #57

Does anyone know what is their monetization plan, or if they even have one? Editor with even this much polish takes a lot of time and effort. How is it being funded? Can we expect useful features to progressively get locked behind subscription as it grows in popularity (a la Gitlab)? Edit: Nevermind, found it - https://zed.dev/faq#how-will-you-make-money . Interesting charter. We envision Zed as a free-to-use editor,…

Yeah, I just can't get excited by anything this foundational that has monetization plans. While neovim is a pain to configure and will probably never be a polished "product", it's completely free to use, with no weird monetization features that might start out in good faith, but slowly creep into must-have parts of the software.

I'm perfectly willing to pay for some types of software, but for something as fundamental as my text editor, I want a model that doesn't depend on a company that needs money. That may sound a bit backward, as it otherwise depends on the goodwill of volunteer contributors, but that's the model I prefer and actually believe in.

Re: Zed on Linux Is Here

#282

Post by kokada »

oynqr wrote: post #211
kokada wrote: post #200

Interesting the decision[1] of building against glibc instead of musl. Any reason for not using musl instead (and doing a static binary)? This would avoid the compatibility issues e.g.: Alpine and Nix. [1]: https://zed.dev/docs/linux

Can you even do GPU acceleration without dynamic libraries on Linux?

This is a good question. It is not like the current `zed` binary is linked to anything that is needed for 3D rendering:

    $ ldd zed.app/bin/zed
        linux-vdso.so.1 (0x00007ffed63f6000)
        libgcc_s.so.1 => /nix/store/bihw7p4zdqwyxmnc8h67c06lnjkvdan8-xgcc-13.3.0-libgcc/lib/libgcc_s.so.1 (0x00007fb5def3c000)
        libpthread.so.0 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libpthread.so.0 (0x00007fb5def37000)
        libdl.so.2 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libdl.so.2 (0x00007fb5def32000)
        libc.so.6 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libc.so.6 (0x00007fb5ded3b000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007fb5df05d000)
However it may well be that this is dlopen during runtime, and for it to work correctly you need to use the same libc as the one in the system.

Re: Zed on Linux Is Here

#283

Post by daghamm »

School-Cotton wrote: post #275
daghamm wrote: post #259

Earlier quoted context omitted.

I disagree. They are on front page of HN with "zed on Linux is here". We got to have some standards, don't you think?

WSL is a pretty niche version of "Linux". I would guess that close to 0% of what makes it to the front page of HN had a QA team that explicitly tested it on WSL.

Please stop making up facts.

1 of 7 Rust developers use WSL: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...

Re: Zed on Linux Is Here

#284

Post by kelnos »

WhereIsTheTruth wrote: post #97

I gave it a fair try Cons: - spawning nodejs whenever you edit JSON files seems overkill, i'd prefer they use something native and more lightweight, or a way to completely disable it - text still looks a bit blurry on low DPI screens - doesn't support LSP properly, completion items are missing some data - Rust for plugins.. this is painful, compare it to Sublime Text's python API, it's night and day.. Pros: - Fast an…

> I however worry about their business model

For me, this is a showstopper. I don't want to use a text editor that even has a business model.

Re: Zed on Linux Is Here

#285

Post by rustyminnow »

mintplant wrote: post #226
llagerlof wrote: post #72

Just a suggestion. One of the best features of pure text editors (and incredible, not all of them implement it) is autosave keeping the "unsaved" state of the file. For example, if you make some changes in a file (new or not), don't save the changes, close and open the editor, the state of the opened files are kept like I never had closed the editor. The unsaved files are still unsaved. New edited files are still the…

Similarly, I have unlimited persistent per-file undo turned on in Neovim. I can open any file I've edited previously and walk through the full history of how it got there. With Undotree [0], I can even navigate branching paths in development. I don't know how people live without this. [0] https://github.com/mbbill/undotree

What are your undo settings? I set undofile and undodir, but not sure if it's unlimited.

One issue I have is if nvim is closed and the file is touched by some outside process (say git pull) it clobbers the history. Do you know if there's a fix to that?

Re: Zed on Linux Is Here

#286

Post by kelnos »

logicprog wrote: post #123
AndyKelley wrote: post #111

Earlier quoted context omitted.

I sympathize with the situation that Zed developers are in. They are thinking of the user experience first and foremost, and when trying to distribute on Linux, faced with an overgrown, chaotic landscape that utterly fails to provide the basic needs of application developers, such as the ability to distribute a binary that has no dependencies on any one particular distribution and can open a window and interact with…

> I sympathize with the situation that Zed developers are in. They are thinking of the user experience first and foremost, and when trying to distribute on Linux, faced with an overgrown, chaotic landscape that utterly fails to provide the basic needs of application developers, such as the ability to distribute a binary that has no dependencies on any one particular distribution and can open a window and interact wit…

Maybe I'm just old-fashioned, but I don't like Flatpak (or Snap or AppImage). They still don't seem to have solved all the desktop integration issues. I do not like running apps that bundle their own dependencies, because I don't trust the app developers to be on top of security issues. I trust Debian maintainers (despite mistakes in the past) to keep my system's base libraries up to date and patched. Why would I trust some random developers of some random app to do the same?

Re: Zed on Linux Is Here

#287

Post by Sesse__ »

First impressions:

  1. curl | sh, seriously
  2. The default theme is so low-contrast that I seriously struggled to read text. I could not find something that was, like, actual white on actual black.
  3. I can figure out how to enable Copilot, but not to open a file. (I had to resort to “zed file.cpp” from a terminal.)
  4. vim keybindings are not bad, but also not perfect.
  5. It feels… laggy? Isn't this supposed to be fast? Whenever I move the cursor over a symbol, it first moves and then like 100 ms later, it tries to highlight that symbol everywhere. And that takes time. In a 200-line file.
  6. Ugh programming ligatures. Where are preferences to turn it off? Where are the preferences for anything?
OK, well, I guess I could use this if I had nothing better. But if the point is that it's supposed to be zero-lag, #5 really destroys the point for me.

Re: Zed on Linux Is Here

#288

Post by kelnos »

logicprog wrote: post #127
AndyKelley wrote: post #22

> To install Zed on most Linux distributions, run the shell script below. This is not an acceptable way to install anything on Linux. If you want to target Linux users you can't distribute with a shell script for installation. I get that the idea is to reduce friction to installation and trying it out, but most Linux users - the ones you want filing bug reports anyway - are ones who will do due diligence and inspect…

My question is why they didn't just make a Flatpak. Then they and their users wouldn't need to go through any of this hassle and distro fragmentation at all. Even if they didn't want to publish it on Flathub, Flatpak supports single file packages people can directly install as well.

Flatpak is just yet another form of fragmentation though.

Re: Zed on Linux Is Here

#289

Post by kelnos »

correct-horse wrote: post #147
drdaeman wrote: post #64

Earlier quoted context omitted.

There are two schools of thought. One strives for correctness, even if that requires extra effort. Another is "anything goes as long as it somehow kind of works more than it doesn't." (Actually it's most probably a spectrum rather than a binary division, but I'm no philosopher or sociologist, so for example's sake I'll operate with this simplified model here.) The world en masse is generally preferring the latter (pi…

| among the engineers there are a significant number of people who believe that's how things should be There are close to zero people who tend to think like that among actual engineers . That's why we have reliable transportation and bridges and skyscrapers that work for (soon to be) centuries. On the other hand, we have lots of them among self-professed "engineers" who have changed many monikers over the past couple…

Can we please instead interpret people's comments in a charitable manner, as we can reasonably assume they were intended, not in the manner that allows us to pick pedantic fights with them?

Re: Zed on Linux Is Here

#290

Post by kelnos »

drdaeman wrote: post #269
correct-horse wrote: post #147

Earlier quoted context omitted.

| among the engineers there are a significant number of people who believe that's how things should be There are close to zero people who tend to think like that among actual engineers . That's why we have reliable transportation and bridges and skyscrapers that work for (soon to be) centuries. On the other hand, we have lots of them among self-professed "engineers" who have changed many monikers over the past couple…

> There are close to zero people who tend to think like that among actual engineers. Oops. My apologies - I meant exactly that, that a significant number of engineers believe in correctness and sound approaches, but I had a brain fart writing that comment. It should've been "believe in the former". No idea about how many non-software engineers take various shortcuts, though. But I think there's a non-negligible numbe…

Don't apologize; GP is being a pedant in order to pick a fight. The "real" definition of "engineer" doesn't matter; your post makes just as much sense if you'd instead used "software developers".
Post reply on HN