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

Yserver: A modern X11 server written in Rust

github.com

Post reply on HN
Print view View original

51–60 of 131 posts

Re: Yserver: A modern X11 server written in Rust

#51

Post by asdfaoeu »

nananana9 wrote: post #42
mort96 wrote: post #18

Earlier quoted context omitted.

What would you rather they use to communicate with the server? Message passing via shared memory? UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.

Yes, command buffers over shared memory are the correct way to do this. 1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side. 2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back. 3. You don't need to deal with the "oh but what if my read…

You would have a lot of security issues right? Whether or not it's useful Wayland does prevent to isolate clients from each other.

Re: Yserver: A modern X11 server written in Rust

#52

Post by scrollaway »

hypfer wrote: post #49

I'm really just tired of all these "projects" that in the end just turn out to be Claude. There is no need to put this code on GitHub. Everyone with an API key can achieve the same if you hand them the prompt. This is like committing build artifacts to version control. On top it's such a lame idea. "What if rewrite in rust applied to X server". Fits on a napkin. Man what a nothingburger :(

Ah yes, the famous zero-shot X11 server. Aren't you clever.

Re: Yserver: A modern X11 server written in Rust

#53

Post by hypfer »

scrollaway wrote: post #52
hypfer wrote: post #49

I'm really just tired of all these "projects" that in the end just turn out to be Claude. There is no need to put this code on GitHub. Everyone with an API key can achieve the same if you hand them the prompt. This is like committing build artifacts to version control. On top it's such a lame idea. "What if rewrite in rust applied to X server". Fits on a napkin. Man what a nothingburger :(

Ah yes, the famous zero-shot X11 server. Aren't you clever.

Would you be happier if I wrote "the prompts"?

Would that change anything about the fundamental cliche-ness here?

Also, no, I'm not clever, but not sure what that has to do with this comment chain.

Re: Yserver: A modern X11 server written in Rust

#54

Post by nananana9 »

mort96 wrote: post #48
nananana9 wrote: post #42

Earlier quoted context omitted.

Yes, command buffers over shared memory are the correct way to do this. 1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side. 2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back. 3. You don't need to deal with the "oh but what if my read…

You don’t have to hit the kernel for 20 bytes. Buffer up all your commands and send them to the kernel with a single write(). The other side can then read them all (or however many fit in its receive buffer) with a single read(). The only real difference is that the memcpy happens in the kernel instead of the receiver and that the kernel provides a useful blocking mechanism by default so you don’t have to manage that…

Sure. But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz.

If the compositor wants to notify the client as soon as possible, it has to send 1000 messages per second. If you buffer them, you're wasting the hardware's potential, if you don't buffer, them you're doing 1000 write()s per second, which is... ugh.

If you're literally going to design the protocol from scratch and require all existing software to deal with it, why not pick the IPC model that doesn't have this issue.

Re: Yserver: A modern X11 server written in Rust

#55

Post by freehorse »

rmu09 wrote: post #28
skeledrew wrote: post #20

> dropping legacy baggage (multiple screens[...] Looked nice, but crossed it off as soon as I saw that, as I'm working on a project currently that uses many screens. Can't just call a thing legacy because you and the people you directly know aren't using it.

Maybe they mean X11-screens. That are more or less independent screens, you can't move a window from one to the other for example.Emacs supports that somewhat with the "open new frame on display server" menu option, but usually, multiple screens are not very useful. Nowadays, multiple monitors present one big virtual framebuffer and only one logical X11 screen.

It is a niche feature, but it is still used eg when an application wants to have good control over a screen's frame buffer to display sth in an external monitor and minimise disturbances. I think it is fairly standard in psychophysics experiments, at least with some software. That's where I worked with such a ("zaphodsheads") setup.

Re: Yserver: A modern X11 server written in Rust

#56

Post by Venn1 »

I compiled it on Debian 13 and it works with XFCE4. Granted, things are a bit squirrely until you disable the compositor. No luck getting it to play nicely with LightDM so I ended up launching it from a TTY. This was on an AMD mini PC I had lying around the studio.

Re: Yserver: A modern X11 server written in Rust

#57

Post by Induane »

le-mark wrote: post #12

I really wish people gave a damn about the “gui over the network” problem x11 solves. Wayland drops this use case entirely so we’re pretty much universally stuck with vnc. Microsoft rdp is a great solution for this in windows land.

Arcan has a decent model for this.

Re: Yserver: A modern X11 server written in Rust

#58

Post by mort96 »

nananana9 wrote: post #54
mort96 wrote: post #48

Earlier quoted context omitted.

You don’t have to hit the kernel for 20 bytes. Buffer up all your commands and send them to the kernel with a single write(). The other side can then read them all (or however many fit in its receive buffer) with a single read(). The only real difference is that the memcpy happens in the kernel instead of the receiver and that the kernel provides a useful blocking mechanism by default so you don’t have to manage that…

Sure. But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz. If the compositor wants to notify the client as soon as possible, it has to send 1000 messages per second. If you buffer them, you're wasting the hardware's potential, if you don't buffer, them you're doing 1000 write()s per second, which is... ugh. If you're literally going to design the protocol from scratch a…

Wait how do you solve that with shared memory command buffers? Don’t you need to involve the kernel to notify the receiver that you’ve written stuff to the command buffer?

Or would the receiver spin in a tight loop on a memory load from some byte in shared memory which indicates a new buffer is submitted, so that it gets notified without involving the kernel? Or is there some fancy mechanism I’m not aware of?

Re: Yserver: A modern X11 server written in Rust

#59

Post by nananana9 »

asdfaoeu wrote: post #51
nananana9 wrote: post #42

Earlier quoted context omitted.

Yes, command buffers over shared memory are the correct way to do this. 1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side. 2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back. 3. You don't need to deal with the "oh but what if my read…

You would have a lot of security issues right? Whether or not it's useful Wayland does prevent to isolate clients from each other.

Not really, you can have one command buffer per client or process, and map each one in the virtual space of the process that's supposed to write to it.

Re: Yserver: A modern X11 server written in Rust

#60

Post by mort96 »

asdfaoeu wrote: post #51
nananana9 wrote: post #42

Earlier quoted context omitted.

Yes, command buffers over shared memory are the correct way to do this. 1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side. 2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back. 3. You don't need to deal with the "oh but what if my read…

You would have a lot of security issues right? Whether or not it's useful Wayland does prevent to isolate clients from each other.

They’re right on this one, shared memory isn’t some scary dangerous thing. Both processes will just have some region of their respective virtual address space which are mapped to the same physical memory, which they can use to share data. Wayland already uses this for pixel data.
Post reply on HN