Live data from Hacker News

Linux When?

zed.dev

121–130 of 169 posts

Re: Linux When?

#121

Earlier quoted context omitted.

Some troubleshooting tips: - Move your mouse cursor to the "Zed Industries" icon in the upper-left-hand-corner, then click. - This "hypertext link" will instruct your browser to load the site's root "index.html", sometimes known as a "landing page". - The "landing page" is a great place to start if you're unfamiliar with a site or product! Here, you'll find the following text prominently displayed: "Zed is a high-per…

Some troubleshooting tips while dispensing dickface advice: There is no such logo. (If there is for you, good for you. Some information for you, different browsers get fed different content, iyt's a new thing that only started around 1993 so I can see how you weren't aware.) Actually there is one, 7000 pages down at the bottom, embedded in the footer and not looking at all clickable. "Hope this helps!"

[deleted]

Re: Linux When?

#122

Earlier quoted context omitted.

But AMD's Mantle predates both & was proposed & what lead to Vulkan. Apple saw the fork in the road & quickly scrambled to build their own thing. I'm kind of tired of this contention cropping up again and again. Technically true but insufficient & obfuscating more than revealing.

Sorry no. Vulkan literally did not exist. That's not obfuscation. It didn't even exist. Had Apple adopted Mantle then where would they be now? Apple did what they do, took ownership of their own stack.

"Sorry no" whatever. Khronos was discussing what to do with Mantle as it became Vulkan. Apple was part of those industry players who were invited to the table. Apple left and did their own thing, like Apple does.

These specs don't spring up fully formed. Vulkan was a collaboration long before it was named as such and released; Approaching Zero Driver Overhead/bindless was 100% clear writing on the wall for a while by then. Apple just doesn't collaborate; they demand control. That's why they didn't participate when everyone else was figuring out how to distill out Vulkan from Mantle & other close to the metal patterns that were already about.

Re: Linux When?

#123
post #101

Earlier quoted context omitted.

Well, that is usually refering to some form of "simulated fluid motion", not new characters appearing and disappearing. The only case where that kinda fluid motion would matter is when you have text scrolling by at semi-fast speeds.

I count myself among the people that would consider >60hz necessary. For me, it's animations, especially if I'm dragging a window or just the mouse. On 60hz it's nauseating if I'm paying too much attention to the window I'm moving. It's goes completely away around 90-100 Hz (at least for me)

I'd still say that draggin a window would count as a "simulated fluid motion". Maybe not something you'd immediatly think of, but its still trying to convey the sense of motion. Just text appearing and dissappearing isn't something I personally could categorize ass the same type of animation.

And I also count myself as someone who considers 120 at least necessary (on the primary monitor)

Re: Linux When?

#124

> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS. So they are taking the exact opposite approach of Electron (VS Code). In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on L…

I suppose ideally you'd want it to be written on Linux first, if you're that kinda person - but the market is probably on Mac?

Doing it on Linux would make people ask "why isnt it on my distro" a LOT sooner. Thus adding complexity while you are trying to prove the concept.

Re: Linux When?

#125
post #85

Earlier quoted context omitted.

Cross platform toolkits, more than other software components incur massive tradeoffs. They’ve written one themselves, tailored to their needs and open sourced it along the way. I guess I don’t see the problem here. If one that’s existed for decades fits your needs better then use that.

Wgpu seems very very well loved & supported, is one of the most successful comings together of the graphics world in ages. I'd love to hear some actual critique of it, hear what people think are shortcomings, because it feels to an outsider like this is the fantasy land, that we're living in the better place now. https://github.com/gfx-rs/wgpu

[deleted]

Re: Linux When?

#126
post #88

I really appreciate how Zed tries to tailor make and ensure their app looks and feels native on Linux. One thing that scares me with it though is the lock in of the multiplayer features. I can see it forcing me to use it and not my preferred editor, because other people use Zed. Would love it if we were not only platform independent but also editor independent regardless of social pressure.

I use Zed as a daily driver, and I haven't once used the collaborative features

    $ grep -A 999 Disable .config/zed/settings.json
      // Disable all genAI crap.
      "features": {
        "copilot": false,
      },
      "show_copilot_suggestions": false,
      "assistant": {
        "version": 1,
        "enabled": false,
        "button": false,
      },

      // Disable all "social coding" features.
      "calls": {
        "share_on_join": false,
      },
      "collaboration_panel": {
        "button": false,
      },
      "chat_panel": {
        "button": false,
      },
      "notification_panel": {
        "button": false,
      },
    }

Re: Linux When?

#127
post #21

From what I understand Zed is a text editor that is built like a game engine, which I understand is why the marketing copy uses the term "multiplayer" rather than "multiuser". I didn't find other mention of its multiplayer capabilities, which is too bad. Has anyone used it for that purpose, I'm curious as to what the experience was like.

We use them every day at Zed for pair programming, we're rather fond of the features :D

Used it the other day with my teammate to pair on some stuff, and it genuinely felt magic. We went from never having used it, to digging through their code together in about a minute, and have used it a few times since. Really nice UX.

Re: Linux When?

#128

Earlier quoted context omitted.

Wgpu seems very very well loved & supported, is one of the most successful comings together of the graphics world in ages. I'd love to hear some actual critique of it, hear what people think are shortcomings, because it feels to an outsider like this is the fantasy land, that we're living in the better place now. https://github.com/gfx-rs/wgpu

What I find interesting is that kvark, the open source contributor that made Linux port possible was the main developer on wgpu at Mozilla, yet he decided to build an alternative [1] to wgpu that he used for zed. I wonder what's the rational for that. [1]: https://github.com/kvark/blade

Dzmitry gave a talk at a rust gamedev meetup on Blade.

This ain't my turf so apologies for inaccuracies here. It appears to be a fairly novel attempt to write a graphics library with a semi conventional looking pipeline, that under the hood ends up eskewing a lot of the Vulkan concepts. Instead of per object contexts, it uses global contexts to do most work. Instead of taking resources and binding them into descriptor sets to use across pipelines (tracking state), Blade kind of recreates resources on the fly, lets them get used, and disposed of them.

Kind of interesting philosophy of a complex binding model in Vulkan/WebGPU vs a more direct diy render model?

https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gBX0gDKq7H...

Zed tool this work as an outside contribution. Maybe that someone did the work was good enough. I'm not sure what would make Blade a better match or not, vs wgpu-hal.

Re: Linux When?

#129

Earlier quoted context omitted.

The question doesn’t make sense. They don’t rerender the buffer every frame. I assume zed isn’t doing that either as it would be horribly inefficient. I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.

> I assume zed isn’t doing that either as it would be horribly inefficient. What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, wh…

You render into a texture once, and then just send that to the compositor each frame as needed.

Re: Linux When?

#130

Earlier quoted context omitted.

This is the first time I see FPS mentioned for a text editor. Is this something that matters or just an pointless metric utilized as selling point?

As far as I can tell, graphics pipelines often use frame buffering. The quicker the next frame can be drawn, the faster it feels.

GUI apps like text editors don’t redraw frames every update cycle.
Post reply on HN