Oro [she/they]

Queer individual from southeast Texas. Helping to work on the Linux desktop - currently contributing to Flatpak and Flathub, getting familiar with GNOME.

Can find me at:

https://orowith2os.gitlab.io/ https://tech.lgbt/@orowith2os https://github.com/orowith2os/ https://gitlab.com/OroWith2Os/

  • 1 Post
  • 20 Comments
Joined 1 year ago
cake
Cake day: July 8th, 2023

help-circle
  • I used to run a multi-monitor desktop setup with Xorg, via the nVidia drivers. Two identical monitors, single framebuffer, no scaling, no tearing, single vsync.

    One monitor, one framebuffer, an old use case that for some doesn’t even exist now, inefficient and slow tearing prevention, laggy vsync.

    That wasn’t a multi-monitor desktop setup. That was a hacked together multi-display, single-screen setup.

    Also why would you link an LD_PRELOAD attack? That’s not Wayland-specific in any way. Any other protocol and library is vulnerable to that too. But let’s point out one major issue with that: the LD_PRELOAD needs to be loaded in before the compositor in order to be relevant. With X, you can do that at runtime. Let’s also read the README from the repository:

    This program is in no way meant as criticism of the Wayland project. It simply demonstrates that creating a secure desktop requires more than just a few server-side restrictions.

    Wayland isn’t the only software we need for a secure desktop; it just handles making the display secure. For libraries and application sandboxing, you want Flatpak, and we’re making progress on dynamic permissions there.

    So? What’s your point? Nothing here is a Wayland-specific argument. Your setup wasn’t functional, it was fundamentally a hack, and one that not-NVIDIA/Intel/AMD hardware doesn’t support. Your argument is falling flat on its face.


  • No.

    Xorg doesn’t support any of that. Multimonitor is nonexistent if you want to use it on a desktop, Xwayland still suffers from the lack of multimonitor (fractional+integer) scaling, and it tears horribly if you don’t want to use inefficient and annoying vsync (Wayland’s is fine).

    Xorg is feature complete for its time; not for this time. The opposite goes for Wayland. Technically it’s a “feature” that any application can keylog on Xorg, that doesn’t mean that they should be free to do so without limit on Wayland too. If that means Wayland isn’t feature complete and Xorg is, then so be it.



  • The ability to stop applications from keylogging you, secure and efficient screenshare, decent compositing, not to mention all of the cruft it’s obtained over the years that stops it from obtaining all of these. And, as a whole, Xorg is completely incompatible with multi-monitor setups - no fractional scaling, and no multi-monitor scales, as well as refresh rates as you mentioned.

    All we should be using nowadays at most is Xwayland. You only get a pass for bare X if:

    1. You need accessibility tools that don’t work on Wayland yet: https://github.com/flatpak/xdg-desktop-portal/issues/1046
    2. You use some insanely old hardware that doesn’t support the appropriate in-kernel and userspace APIs for Wayland to function.
    3. You use NVIDIA, and can’t feasibly use Nouveau.

    Otherwise, get the fuck off of Xorg. The ecosystem has matured enough such that Wayland Just Works for basically everyone.





  • Nobody is actively working on it now; the same can’t be said for Wayland. Recently, it even hit a development low of all time. The only ones working on it are the ones getting paid to work on it, and even then, only those familiar with the codebase. Looking at the history, the only major changes are for Xwayland, and aren’t at all often.

    If (almost) all of the developers have abandoned something in favor of a newer piece of software that does the job better, I think it’s sufficient to say that it’s deprecated and unmaintained.











  • Doing everything explicitly can get to be annoying, especially when it comes to what you had to do before without Vulkan’s VK_EXT_shader_object.

    It’s clear that some stuff should be implicit - most types in programming languages, for example; needing to specify a struct type and then the struct itself can be annoying - and other stuff explicit, like low level operations.

    Returns are something that usually fall into that “implicit” category. Why should I do let a = function(); return a; when I can just do function()? It’s shorter, simpler, and I don’t waste keystrokes.



  • Silverblue is actually the only OS I’ve been using for the past year - I’ve gotten NixOS installed to my laptop once or twice but went right back to Silverblue since I couldn’t maintain a Nix config I liked.

    If I ever want anything newer or older, I can always rebase my Silverblue install to Rawhide or a previous commit. It’s just one rpm-ostree away.

    Arch is what I run inside of distrobox, I haven’t used it on bare metal in… I think, two years now? I’ve found Arch to be one of the best distributions for use in a container, it’s simple, minimal, and (with a few minor tweaks) very easy to understand and utilize.