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

How X Window Managers Work, and How to Write One (2014)

jichu4n.com

Post reply on HN
Print view View original

61–70 of 250 posts

Re: How X Window Managers Work, and How to Write One (2014)

#61

Post by Seirdy »

yyyk wrote: post #51
Seirdy wrote: post #40

Earlier quoted context omitted.

The biggest reason is security. X offers no GUI isolation. This is a basic mitigation that should have been the norm a decade or two ago. Advanced mixed DPI also comes to mind. Another is performance: Sway easily outperforms DWM/i3/AwesomeWM on most ARM devices when configured for minimal latency.

Security would be the worst reason. Zero cases in the wild, and it's not that difficult to add access checks to X - there used to be an X extension to do this. The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.

> Zero cases in the wild

Follow along this post and you'll end up with one case in the wild all by yourself on your own machine: https://theinvisiblethings.blogspot.com/2011/04/linux-securi...

Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...

Re: How X Window Managers Work, and How to Write One (2014)

#62

Post by qwerty456127 »

Seirdy wrote: post #56
vidarh wrote: post #53

Earlier quoted context omitted.

X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.

ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.

What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO.

I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.

Re: How X Window Managers Work, and How to Write One (2014)

#63

Post by loxias »

Seirdy wrote: post #55
enriquto wrote: post #44

Earlier quoted context omitted.

> The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. The word "properly" here is quite subjective, though. I have a similar setup, combining monitors of different pixel sizes. It works properly with Xorg: When I move a window of size WxH pixels from one monitor to another, it remains a window of WxH pixels. A thin line of one pixel width remains so. A chec…

> hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype. Which apps don't support Wayland? The only ones on my machine that need XWayland…

> barely any current distros still ship X in their default installations.

Bold statement. Citation needed? Debian does, and that's hardly a small percentage of market share. I guess if you include Android as a Linux distribution then you might be correct.

Re: How X Window Managers Work, and How to Write One (2014)

#64

Post by vidarh »

Seirdy wrote: post #56
vidarh wrote: post #53

Earlier quoted context omitted.

X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.

ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.

The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's.

You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.

Re: How X Window Managers Work, and How to Write One (2014)

#65

Post by Seirdy »

qwerty456127 wrote: post #62
Seirdy wrote: post #56

Earlier quoted context omitted.

ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.

What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way…

If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason.

The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.

Re: How X Window Managers Work, and How to Write One (2014)

#66

Post by sprash »

Seirdy wrote: post #42
sprash wrote: post #30

Earlier quoted context omitted.

> right as the replacemeant for Xorg starts to take off though It has been "taking off" for 13 years at this point. It seems like it doesn't have much thrust behind it.

Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years. On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not famil…

This is not an organic transition. Major organizations seems to "push" it but there is not much "pull". Compare this to the "transition" from CVS/SVN to git. There was no need to even advertise git. People saw it and wanted it.

The X11 ecosystem is more than just GNOME, KDE and i3 and porting XFCE will not be enough to "move on" (For me it is the small things like Xdotool, Xsel, Xcalib, etc. that are holding me back). Maybe X11 needs to be replaced but Wayland is not the answer. It's just not good enough and because of fundamental flaws of its philosophical concepts it will never be.

Re: How X Window Managers Work, and How to Write One (2014)

#67

Post by loxias »

IiydAbITMvJkqKf wrote: post #29
josefx wrote: post #16

Earlier quoted context omitted.

> Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering whee…

Xorg barely works on nvidia (source: me) vsync requires a compositor to work, and even picom needs a very specific combination of flags to get vsync to work. Chromium cannot gpu accelerate video playback. On rolling release distros, most major kernel updates leave your system broken, because nvidias out-of-tree driver can't build against new kernel versions. If nvidia stops supporting your old gpu, like they just did…

Xorg works just fine with Debian and Nvidia (source: me). Some longish (5-10) years ago it got so stable that I managed to stop thinking about it, because it Just Works. Even across upgrades. Your problem lies not with Linux, Xorg, or Nvidia.

Re: How X Window Managers Work, and How to Write One (2014)

#68

Post by vidarh »

qwerty456127 wrote: post #62
Seirdy wrote: post #56

Earlier quoted context omitted.

ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.

What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way…

Screen tearing is largely a software issue anyway - the moment you have hardware capable of double buffering there's no excuse for it unless you don't have sufficient memory.

Re: How X Window Managers Work, and How to Write One (2014)

#69

Post by Seirdy »

loxias wrote: post #63
Seirdy wrote: post #55

Earlier quoted context omitted.

> hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype. Which apps don't support Wayland? The only ones on my machine that need XWayland…

> barely any current distros still ship X in their default installations. Bold statement. Citation needed? Debian does, and that's hardly a small percentage of market share. I guess if you include Android as a Linux distribution then you might be correct.

Debian 10, Debian 11, OpenSUSE, Fedora, RHEL 8, Ubuntu, and others ship GNOME on Wayland by default right now. It receives better support than the X version.

KDE upstream is also Wayland by default which is reflected in the KDE version of OpenSUSE, the Fedora KDE spin, and Fedora Kinoite.

Re: How X Window Managers Work, and How to Write One (2014)

#70

Post by Seirdy »

vidarh wrote: post #64
Seirdy wrote: post #56

Earlier quoted context omitted.

ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.

The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's. You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower,…

I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.

The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL

Post reply on HN