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

81–90 of 131 posts

Re: Yserver: A modern X11 server written in Rust

#81

Post by TacticalCoder »

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.

> I really wish people gave a damn about the “gui over the network” problem x11 solves.

Security-wise there are concerns but...

Early dial-up Internet days (early for me), 28.8k modem, I was already running Linux, probably on a 486. I also had a very old PC laptop (I think a friend of my parents gifted it to me after he got a new one from work), a 386 I think (with the horrible slow display/refresh rate: a TFT IIRC). I used a parallel cable and PLIP (Parallel Line IP) and X11 networking to send a window manager+browser from the desktop (the 486) to the laptop.

So my brother and I could both go on the Internet at the same time.

It felt like the future and, honestly, we've kinda seriously regressed when it comes to "GUI over the network".

Re: Yserver: A modern X11 server written in Rust

#82

Post by rwmj »

simmonmt wrote: post #9
chadgpt3 wrote: post #3

Earlier quoted context omitted.

X screens are legacy. It used to be you could connect to a particular screen by number to open windows on that screen but the modern way to do it is to have one big virtual screen. X screens were like having a separate X server for each monitor, but with a single shared cursor and shared VRAM. You can see why that's an obsolete model.

Yep. When did virtual screens come in? My last full time experience with X was with Xsun in the early 2000s under Solaris. There was a shared cursor, I thought you could drag windows between monitors, but I also thought the DISPLAY variable was different for each (though I could be misremembering)

$DISPLAY is definitely different for each X11 screen, ie. :0.0 for the first screen, :0.1 for the second and so on. (:1, :2 is used for more instances of the X11 server).

I can't recall any application able to use multiple X11 screens (except in the trivial sense that you could set DISPLAY when starting the application), and I've been using X11 since X11R4.

Re: Yserver: A modern X11 server written in Rust

#84

Post by jitl »

hypfer wrote: post #53
scrollaway wrote: post #52

Earlier quoted context omitted.

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.

"Please don't give me a present on my birthday. Anyone with a credit card could get me the same thing if you hand them the url."

i'm personally okay receiving presents on my birthday even if they were purchased from a store on the internet, and i'm okay receiving software presents on github.com even if they were purchased from a store on the internet.

Re: Yserver: A modern X11 server written in Rust

#85

Post by simonask »

aleph_minus_one wrote: post #45

Concerning the name "Yserver": be aware that there also existed (the implementation is still available for download) the "Y Window System" > https://www.y-windows.org/ by Mark Thomas as an experimental sucessor of the "X Window System" (its development has been cancelled for a long time; the latest release that is available on this website is from 2004). The German Wikipedia still mentions the "Y Window System": > ht…

On general principle, I think 22 years of inactivity is perfectly reasonable for considering any software project perfectly dead.

Re: Yserver: A modern X11 server written in Rust

#86

Post by obezyian »

simoncion wrote: post #78
Liskni_si wrote: post #72

Earlier quoted context omitted.

> So realistically no application did this. Old versions of GIMP (back when the toolbars etc. were separate windows) used to let you move any of its windows to a different X screen. And by "move" I don't mean drag - there was a menu where you could select the screen to move to.

I really miss the tear-off-into-their-own-window menus. They were so handy. I have to wonder if the fact that Wayland either never had or has only very recently gotten support for applications that need to place their windows at application-commanded locations on the screen meant that those lovely tear-off menus had to die.

The gtk3 docs give the following reason for the deprecation:

Menus are not meant to be torn around.

Yeah, they are meant to be implemented with web technologies and look like shit.

BTW, this tear-off style is probably quite old. Long ago, I used an early version of ANSYS (for Windows) which apparently was still close to its Unix original, and it had its menus pop up like real windows, with close buttons! They were nicely cascaded, but one could rearrange them.

Re: Yserver: A modern X11 server written in Rust

#87

Post by aleph_minus_one »

simonask wrote: post #85
aleph_minus_one wrote: post #45

Concerning the name "Yserver": be aware that there also existed (the implementation is still available for download) the "Y Window System" > https://www.y-windows.org/ by Mark Thomas as an experimental sucessor of the "X Window System" (its development has been cancelled for a long time; the latest release that is available on this website is from 2004). The German Wikipedia still mentions the "Y Window System": > ht…

On general principle, I think 22 years of inactivity is perfectly reasonable for considering any software project perfectly dead.

That's why I wrote "existed" (simple past).

Re: Yserver: A modern X11 server written in Rust

#88

Post by simonask »

simoncion wrote: post #78
Liskni_si wrote: post #72

Earlier quoted context omitted.

> So realistically no application did this. Old versions of GIMP (back when the toolbars etc. were separate windows) used to let you move any of its windows to a different X screen. And by "move" I don't mean drag - there was a menu where you could select the screen to move to.

I really miss the tear-off-into-their-own-window menus. They were so handy. I have to wonder if the fact that Wayland either never had or has only very recently gotten support for applications that need to place their windows at application-commanded locations on the screen meant that those lovely tear-off menus had to die.

FWIW, they have been unfashionable for much longer than Wayland has been usable, on all platforms.

And that’s understandable. It’s not actually good usability.

Re: Yserver: A modern X11 server written in Rust

#89

Post by goodmythical »

simonask wrote: post #85
aleph_minus_one wrote: post #45

Concerning the name "Yserver": be aware that there also existed (the implementation is still available for download) the "Y Window System" > https://www.y-windows.org/ by Mark Thomas as an experimental sucessor of the "X Window System" (its development has been cancelled for a long time; the latest release that is available on this website is from 2004). The German Wikipedia still mentions the "Y Window System": > ht…

On general principle, I think 22 years of inactivity is perfectly reasonable for considering any software project perfectly dead.

On general principle, I think sharing but a single character between names of products is perfectly reasonable for considering any names perfectly seperable.

No one's comparing this to 'y'combinator or 'y'ahoo.

'server' and 'window system' are completely different...

Re: Yserver: A modern X11 server written in Rust

#90

Post by simonask »

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…

Just to let you know, 1000 messages per second over a UNIX socket between two processes is very much well within the capabilities of any recent machine running, say, Linux. That’s not many at all.
Post reply on HN