How X Window Managers Work, and How to Write One (2014) • Hacker News Board

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

#91

Post by Seirdy » Wed, Nov 03, 2021, 10:59 AM UTC

sprash wrote: post #83

Seirdy wrote: post #74

Earlier quoted context omitted.

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

Qubes devs are in my experience the most vocal X detractors. They had to work around X's inherent lack of isolation by using a Xen mechanism. The equivalent would be putting a wooden chest in a safe to show that wooden chests are secure on their own.

HTTP also doesn't work as well as it did before: Chromium and Firefox have begun rolling out an HTTPS-Only mode that warns when visiting HTTP pages. The landscape has also gotten more hostile: many telecoms have been caught modifying unencrypted traffic. Vodafone was also caught HTTP CSP headers for ad injection.

Firefox devs have expressed interest in removing HTTP-specific logic from FF in the distant future too, with the HTTPS-only mode being the first step. All current browsers have also disabled obsolete TLS/SSL versions, which broke several sites during the initial rollout.

There is no such thing as a trusted client; plenty of FOSS has exploitable vulnerabilities. Rather than "trusted and untrusted" software, the cybersecurity crowd has shifted to thinking in terms of "untrusted and untrusted+malicious".

There's also a reason why software audits typically have their moment of truth during binary analysis, whether or not source code is available: source code is only part of the puzzle. Runtime behavior is influenced by the toolchain behavior, host OS behavior, shared libs, and a ton of other variables that are collectively harder to audit than a black box binary. FOSS' reasons for existing should be primarily related to freedom rather than security. I don't copyleft my work because it improves security, but because it protects users from further infringements upon their freedoms.

I'd suggest chatting up a security researcher or reading some material on modern approaches to exploit mitigations (source availability is not a replacement for exploit mitigation); I could give you some starting points when I wake up if you're interested.

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

#92

Post by ch_123 » Wed, Nov 03, 2021, 11:04 AM UTC

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…

Here is one list of problems with X11 which Wayland solves. One of the author is someone who has done a lot of work on Xorg, so they know what they are talking about: https://www.phoronix.com/scan.php?page=article&item=x_waylan...

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

#93

Post by kaba0 » Wed, Nov 03, 2021, 11:14 AM UTC

RedShift1 wrote: post #87

loxias wrote: post #24

Earlier quoted context omitted.

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

Or just try to go at things with an open-mind and hell, you might learn something?

X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayland.

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

#94

Post by upofadown » Wed, Nov 03, 2021, 11:15 AM UTC

fyrn- wrote: post #2

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

It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.

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

#95

Post by vidarh » Wed, Nov 03, 2021, 11:15 AM UTC

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…

X ran just fine on machines with graphics chips with no acceleration at all, just dumb frame buffers.

You're probably right that a modern X server optimised for modern PCs won't run well on those machines, but the point being that this has little to do with X the protocol, and everything to do with the implementation of the X server and to a certain extent with clients being optimised for different performance characteristics.

As for Vulkan, there's no reason you can't use Vulcan with X. It's again an implementation question, not a protocol issue.

Now, the X protocol is awful, to be clear. There are plenty of issues with X that were worth fixing. But the time it has taken to get Wayland to a usable state (many would argue it still isn't - I certainly have no interest in running Wayland other than with XWayland possibly given the current state) suggests that opting to start from scratch instead of upgrading X step by step was a relatively poor choice - the X protocol is easily upgradable.

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

#96

Post by Seirdy » Wed, Nov 03, 2021, 11:17 AM UTC

pantalaimon wrote: post #89

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…

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.

I was referring to the fact that OpenGL is becoming a second class citizen among the silicon giants, with more attention being drawn to Vulcan/Metal/etc. Now that sway supports a Vulcan backend, it won't be left in the dust stuck on OpenGL.

I'm not aware of GNOME or KDE having similar improvements on their X backends or the same happening for X WMs.

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

#97

Post by Seirdy » Wed, Nov 03, 2021, 11:19 AM UTC

pantalaimon wrote: post #90

Seirdy wrote: post #42

Earlier quoted context omitted.

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

I wasn't aware that MATE was still on X; that's good info to know.

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

#98

Post by kaba0 » Wed, Nov 03, 2021, 11:20 AM UTC

yyyk wrote: post #82

Seirdy wrote: post #61

Earlier quoted context omitted.

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

There are so many holes in linux’s userspace’s “security” that we should start listing the actually protected parts. The only reason there are no linux botnets everywhere is because libre software fundamentally have good intentions.

So the reason for not exploiting X may very well be simply because there is an even easier exploit available..

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

#99

Post by kaba0 » Wed, Nov 03, 2021, 11:21 AM UTC

jcelerier wrote: post #32

perth wrote: post #28

Earlier quoted context omitted.

Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland. Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among…

Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt

That’s for a single monitor. Now try two monitors with different DPIs

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

#100

Post by microtonal » Wed, Nov 03, 2021, 11:23 AM UTC

blacklion wrote: post #50

loxias wrote: post #24

Earlier quoted context omitted.

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

Wayland is pushed by people, who do embedded Linux. Think: infotaiment system in your car. All UI is pre-installed and fixed to one (maybe, custom) toolkit, custom "window manager" (and it is not full-featured WM, as X11 ones are, as you can not move and resize windows arbitrarily), one theme, no remote access, very low response time. It is better than both X11 and plain framebuffer in this role, for sure.

Wayland is pushed by people, who do embedded Linux.

Maybe when Wayland was started. But X.org is now effectively unmaintained and most of the core X.org developers are now working on Wayland. From the release maintainer of X.org:

So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.

https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...