1. 44
  1. 13

    Wayland only is not an option that will ever work across the board. It is not a replacement, it is a fundamental change of principles. Stop trying to market it as some kind of inevitable transition. There are strong differences that will not get smoothed over regardless of how many ‘protocols’ you define; Wayland is Policy over Mechanism, X11 is Mechanism over Policy. This is the real barrier. Not unsubstantiated claims of ‘security’. It is a tectonic shift and no matter your feelings about that, we won’t all be in the same country or continent anymore.

    I thought this article was going to be about deprecation in general, and how it often happens against the wishes and needs of users, and how with FLOSS, users can take the power into their own hands and give new life to software which they love and want to continue using. And that’s basically what I got, and I’m grateful.

    1. 8

      it is alarming trend of stable simple old software torn out with roots and replaced with complex new unstable.

      hackers not asleep at the wheel please work to preserve knowledge or we,ll be left with nothing.

      1. 12

        Yes, let’s go back to the halcyon days of stable simple old software. Say, 1995, when adding or removing hardware from a machine still often meant trying to unheck overlapping IRQ’s and bus numbers, and could involve changing driver settings for every peripheral on your machine if you weren’t careful. Or 2000, when one basically had to build a custom machine to run Linux successfully and getting both Xfree86 and audio working usually took about a week all told. 2005 was pretty good, as long as you didn’t need 3D graphics or a virtual machine that ran off something other than VMWare, though X11 configuration still usually took hours if not days. 2010 was even better, as long as you didn’t mind laptop batteries that lasted 90 minutes and usually had screens that were worse quality than a high-end laptop from 2000. And so on.

        1. 3

          Yeah, good thing we rewrote the batteries and reimplemented the peripheral busses in software.

          1. 2

            Yes, all those things sucked and were real problems.

            And they led to creation of good software which could tolerate that world.

            Should we automatically get rid of all the good things? No.

          2. 7

            Let me relay to you one of the dark laws of software engineering thermodynamics:

            Any small, easy-to-replace system will eventually be displaced by a larger, more complicated one.

            Consider with despair the asymptomatic behavior of this fact.

            1. 1

              Thermodynamics is right. My laptop is continually hot to the touch, even though I run a “lean” window manager.

            2. 3

              It probably needed to happen, but in the way that it did and how it is going - there really are no winners. I am somewhat convinced that the big desktops are locked biting down on their own tails and the real compromise will be shove it all in a virtual machine. Emulation tends to stick around.

              1. 2

                It,s true, VMs are great.

                I now do quite a bit of blogging from Windows Me, Office 97, and IE6.

                On an old laptop with a spin drive, in VBox, runs circles around currents.

            3. 8

              It would be nice that people remembered that you don’t have to leave scorched earth in your wake as you leave a project. It’s not a surprise to me that Xorg is begging for working hands when its active maintainers seem to repeatedly write blog posts telling people it’s deprecated.

              1. 5

                There are some nuances here that many will miss as it requires you to know something about the architecture of the X server. The main thing is to not conflate ‘xfree86’ with rest of what you think of as X, hence why the blog post separates out XFree86-the-project from ‘xfree86 the hardware driver’.

                As someone knowing almost nothing about Xorg’s architecture, I am still missing these nuances. What is xfree86 the hardware driver? If I built Xorg without it today and tried to run a graphical environment, what would happen?

                1. 11

                  xfree86 is a hardware driver. Xvfb == can draw to a framebuffer, Xvnc == exposes a virtual screen as a vnc server, Xephyr == treats its output as an x11 client (nesting), Xwayland == maps its outputs to wayland-like surfaces (a bit special in a terrible way)

                  A (big) point is that xfree86 is the one that BOTH uses KMS/GBM (what some refer to as the modern graphics stack “DRI2/DRI3”) AND act as an actual driver (think UNIVBE in MS-DOS if you are that old). It is a complete historical document, you can find ISA VGA controller code all the way up to today’s things. This is what the maintainer doesn’t want to touch. This is the part of X that is actually really bad.

                  The suggested compromise is that the library @emersion has been working on could replace that. Doing so fixes one of the core issues with current Xorg, and significantly improves the odds for the same code being used in Wayland compositors and brings both projects forward.

                  1. 2

                    Thank you, I think I get it now! It sounds like an abstraction and compatibility layer like terminfo, but for graphical displays.

                    1. 2

                      What is the difference between hw/xfree86 and driver/xf86-video-ati ?

                      1. 4

                        I will re-check the code later to make sure, but my memory is that driver/xf86-video-ati (and all the others) attach to the “xfree86” driver DDX so think of those as ‘plugins’ that go into it.

                  2. 2

                    Will you write it, are you collecting feedback, or are you hoping it “will happen by itself” and merely showing a way, @crazyloglad? That hasn’t been addressed and I’m not sure corporations (RedHat) are willing to invest here.

                    IIRC there are also concerns about the input layer, where I remember the NetBSD porting effort complaining about Wayland’s implicit ties to libinput. libliftoff excludes input. Something to do with libarcan-shmif-server, then?

                    1. 7

                      For the input layer: that is why I brought up the libarcan-shmif-server part (example from 0 to video buffers and input events). It means that you can just copy the code I already wrote for Xarcan and wscons and re-use it, as external input drivers even example of external input client

                      Write the code myself: Not more than what I already have (above); that blog is about bitter design musings. I have next to nothing to gain from this solution.


                      1. Arcan can be used as a Wayland compositor. WM level example. it just the part that I hate working on the most. It is 90% writing boiler plate to convey something trivial, then stare vacantly into 100% async traces wondering what went wrong.
                      2. It has a KMS/GBM/EGLStreams/Evdev backend, which is my second most loathed part, but more of a necessary evil as the goal of recovering from GPU crashes practically requires non-abstracted control. “I brought it on myself”.
                      3. I have an Xorg fork since about 4 years back. I can spend a few weeks at most and fix what is missing to outperform Xwayland and be able to translate window management. It’s more pleasant work than 1.

                      I can easily spend all my spare time screaming into a pillow on 1 and 2 alone. It has nothing to do about the ‘feature level’ part of the protocol as such. It is all consequences from just how bad the API+internals of the server side library are. There are multiple ticking time bombs in it that are going off when your threat model includes denial of service. I refuse to have it in the main process as I know I can’t trust myself to code for it without vulnerabilities. That means timing will be different than for others (not necessarily binned around vsync) which uncovers more asynch bugs in clients.

                      I would like to see the X class of window managers live on. I would like to see Wayland not worsening through forced adoption of more and more X ‘features’ - the simplicity it once had is a parrot in a Monty Python sketch by now.

                      The first presentation on Arcan literally said, “hey for normal clients, we will use Wayland” in bold letters. The exception is that I want tighter integration with KVM/QEmu and that class of specialised clients, and nothing more.