Wayback Is An Experimental X11 Compatibility Layer For X11 Desktops Using Wayland
Wayback is a new open-source project working on providing an X11 compatibility layer for running full X11 desktop environments using Wayland components with a rootful XWayland server...
phoronix.com/news/Wayback-X11-…
Asahi Lina (朝日リナ) // nullptr::live
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •datenwolf
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •spikederailed
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •SuperDicq
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to SuperDicq • • •@SuperDicq This solution is built upon mature Wayland components for compositing and display backend that are mature, modern, future proof, and already work better than the Xorg equivalents today.
The bugs in the integration bits, which are comparatively simple are a lot easier to fix than legacy Xorg DDX technical debt.
SuperDicq
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to SuperDicq • • •@SuperDicq Not on all hardware. On Apple hardware (which doesn't implement legacy VBlank IRQs or legacy cursors) Xorg has tearing, flickering cursors, and animations run too fast because there's no VSync.
Xorg only runs well on old drivers that implement all the bloat and legacy workarounds that it needs...
SuperDicq
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to SuperDicq • • •SuperDicq
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •>At least on Apple hardware that firmware does not have full system access that could potentially snoop on or backdoor your OS.
I highly doubt that. How do you know for certain?
Also define "modern computers". My GNU Booted computers are still modern, as they can do everything that a computer sold today can do (except enforce hardcuffs to the user obviously, but I do not consider that a desirable feature).
Asahi Lina (朝日リナ) // nullptr::live
in reply to SuperDicq • • •asahilinux.org/docs/platform/i…
We know because we reverse engineered it. I personally fully reverse engineered the GPU microPPL, the only firmware component with privileged system access on a design technicality (which is only a couple kilobytes of code), and reported a vulnerability that got fixed. There are no backdoors or holes left as far as I can tell. Every other firmware blob is firewalled by an IOMMU.
The bug I found earned me a $150k bounty, so there is lots of incentive for people to find those kinds of bugs that can break security.
BTW, even the decade old ThinkPads that people flash with open firmware and say are fully free have chips running proprietary firmware on the LPC bus with full DMA access. Apple machines do much better than even those.
If you want to reduce it to "there could still be a secret silicon backdoor", that is true of every modern system by definition.
Introduction to Apple Silicon - Asahi Linux Documentation
asahilinux.orgSuperDicq
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •You have a list of firmware blobs and a rough idea of what they do. As far as I can tell you do not have the original source code or rewritten replacement software.
If this becomes available in any point in the future I might switch to an Apple laptop, but for now I will stay on my GNU Booted hardware instead.
Asahi Lina (朝日リナ) // nullptr::live
in reply to SuperDicq • • •SuperDicq
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •When you run proprietary blobs I agree it is obviously better to run them in such a way that they can not access anything. But that still is not good, because the blobs are still there denying you freedom over your own devices. They should be replaceable with free software.
That's not true. I have built my own keyboard and it my own customized fork of QMK Firmware.
But I assume you mean in the case of a regular keyboards (excluding the ones that run proprietary flashable firmware like a lot of "gamer" branded products) this firmware is backed into the device on a read-only chip. In this case is not denying its users any freedom as not being able to customize it is in this case just a hardware limitation, not something specifically put in place by manufacturer to handcuff the user.
Asahi Lina (朝日リナ) // nullptr::live
in reply to SuperDicq • • •You're repeating the arguments from the FSF word for word, so I guess you've fully drunk their kool-aid. I strongly disagree with their posture and I think it is very harmful to the free software ecosystem as a whole, but it's almost impossible to convince anyone in your position in my experience, so we'll just have to agree to disagree.
P.S. a huge majority of USB products have flashable firmware, they just don't advertise it or provide the flashing tools outside of manufacturing. You're still being "denied your freedom", you just don't know it.
SuperDicq
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to SuperDicq • • •foxido [cutie status: expired]
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •@lina@vt.social @SuperDicq@minidisc.tokyo
Asahi Lina (朝日リナ) // nullptr::live
in reply to foxido [cutie status: expired] • • •@foxido @SuperDicq Wayland is exactly as old as the Xorg modesetting driver (both were introduced in 2008) and Wayland compositors (many of which are much younger) do a much better job of driving display controllers and compositing than the Xorg solution.
You can say whatever you want about the ecosystem and desktop features, but Wayland was designed to work well with modern hardware and rendering pipelines and it has always done this better than Xorg. And that's what this solution does, run Wayland's rendering backend with the Xorg feature set on top.
shironeko
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •@ariadne If Xwayland already works for the application one wants to use, then they're not really stuck with X right?
I thought the whole issue was that some applications are not (maybe never?) supported by Xwayland, so no solution that's based on Xwayland would work for those applications?
Asahi Lina (朝日リナ) // nullptr::live
in reply to shironeko • • •No, that's for rootless XWayland running under a full Wayland compositor, which is intended to run X11 apps but not full X11 sessions (because it's running under a Wayland session), that's why it can't do everything a full X11 session can.
This is rootful XWayland which can run any X11 window manager and supports everything Xorg supports that isn't directly hardware device related. It's a full native X11 session. XWayland is the same codebase as Xorg minus the hardware drivers.