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

81–90 of 250 posts

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

#81

Post by DonHopkins »

josefx wrote: post #16
5e92cb50239222b wrote: post #12

Earlier quoted context omitted.

What "Wayland people"? You probably mean the former Xorg developers who shifted to full time Wayland development long ago. Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.

> 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…

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles — but you’d be able to shift gears with your car stereo. Useful feature, that. - Marus J. Ranum, Digital Equipment Corporation

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

#82

Post by yyyk »

Seirdy wrote: post #61
yyyk wrote: post #51

Earlier quoted context omitted.

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 XAC…

>>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

I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter.

Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on.

Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.

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

#83

Post by sprash »

Seirdy wrote: post #74
sprash wrote: post #66

Earlier quoted context omitted.

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)…

Xdotool and xsel have had Wayland equivalents for years: see ydotool/wtype and wl-clipboard. The reason why major orgs have had to push for Wayland is the same as the reasons they had to push for HTTPS and TLSv1.2, unique passwords, keeping software up to date, etc: using outdated and insecure software with significant attack surface has real costs even if it's convenient.

All "equivalents" you mention have less functionality than their originals and some only work on specific compositors like wlroots/sway. Like all things Wayland it's a mess with zero benefits for the user.

HTTPS vs HTTP is a false equivalent. HTTP works just fine like before. X11 can be made fully secure (e.g. QubesOS does it) but nobody uses it because there is really no need on a FOSS system where 100% of clients you run are trusted.

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

#84

Post by DonHopkins »

vidarh wrote: post #53
Seirdy wrote: post #47

Earlier quoted context omitted.

1. Wayland does support remote execution; see waypipe for an example. 2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).

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

Mid 80s hardware, actually.

Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here:

https://blog.dshr.org/2018/05/recreational-bugs.html

>"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");
WHAT IS YOUR ROOT?

    root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?

    win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
                              BlackPixel(
                                  display,
                                  DefaultScreen(display)),
                              WhitePixel(
                                  display,
                                  DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.

(the next client tries to connect to the server)

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");
WHAT IS YOUR COLORMAP?

    cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?

    favorite_color = 0; /* Black. */
    /* Whoops! No, I mean: */
    favorite_color = BlackPixel(display, DefaultScreen(display));
    /* AAAYYYYEEEEE!! */
(client dumps core & falls into the chasm)

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");
WHAT IS YOUR VISUAL?

    struct XVisualInfo vinfo;
    if (XMatchVisualInfo(display, DefaultScreen(display),
                         8, PseudoColor, &vinfo) != 0)
        visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?

    /* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */
WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!!

(server dumps core & falls into the chasm)

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

#85

Post by erik_seaberg »

Seirdy wrote: post #47
qwerty456127 wrote: post #21

Earlier quoted context omitted.

This is exactly why I would rather do. I see absolutely no reason to abandon X and want to learn its internals to be able to maintain it myself. To me X seems a perfect piece of software which just works and does its job flawlessly, while having all the features I ever needed (including remote execution - I used Windows apps running on a remote Linux machine with Wine over SSH over OpenVPN on a local Windows machine…

1. Wayland does support remote execution; see waypipe for an example. 2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).

Waypipe ships client-rendered images across the network; datacenters would fall back to software rendering because there’s no way to take advantage of a user’s desktop GPU. I think the industry will continue moving to Javascript or Wasm apps as the most widely portable and accelerated remote display system we have.

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

#86

Post by Seirdy »

qwerty456127 wrote: post #79
Seirdy wrote: post #70

Earlier quoted context omitted.

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 outp…

> ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio? > I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. Why does it have to be? What do we get for this cost? The only things in which I wou…

> Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability.

A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more.

I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link.

A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.

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

#87

Post by RedShift1 »

loxias wrote: post #24
fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community o…

> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.

This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.

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

#88

Post by DonHopkins »

sprash wrote: post #30
fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

> 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.

FWIW, that's much less time than Perl 6 has been taking off for!

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

#89

Post by pantalaimon »

Seirdy wrote: post #70
vidarh wrote: post #64

Earlier quoted context omitted.

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 outp…

There are no problems with running Vulkan applications on X11.

You must confuse something here - wlroots recently got a Vulkan backend, meaning you can run it on top of Vulkan API.

It has nothing to do with what Graphics API the clients will use.

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

#90

Post by pantalaimon »

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…

There are a lot of smaller projects that lack the resources for the Wayland transition.

I'm a happy Mate user and while there is ongoing work to move towards Wayland, it will likely take several years to complete.

So for the time being I keep X11 dear to my heart, and to be honest I'm not sure what I'm missing with Wayland (expert apparently problems with screen sharing applications that have not been updated to Wayland yet …). X11 + Compiz work fine for me.

Post reply on HN