btrfs is a drop-in replacement. Nothing changes for the user when they switch to it. With Wayland many basic features are missing even today. (Yes I know someone will explain here that everything works. Don't make me laugh)
Actually the fact that X11 can be used today despite the fact that we went through several cycles of vastly changing GPU hardware shows that it absolutely has stood the test of time.
The X server became a pretty useless middle man between clients and the compositor. And the vastly changed GPU hardware is the reason we should prefer a superior solution - we no longer draw as we did 3 decades ago, so we should cut out the middle man.
Terminal applications stood the test of time as well. For everything that is not graphical in nature they are indeed good solutions.
> The X server became a pretty useless middle man between clients and the compositor.
X is a middle man but far from useless. Just as Wayland is a middle man as well. And looking at the protocol actual access to GPU memory is more opaque on Wayland than on X11 and as such to me Wayland is a more intrusive middleman.
If you want to "cut out the middle man" you have to use DRM directly.
Wayland is not a middle man as it is the compositor itself as well - it does the minimal amount of work necessary to compose the desktop. X on the other hand just transfers messages between clients and the compositor without doing any actual work (x render functions are almost never used by modern applications)
Also, DRI3 doesn’t solve the fundamental security flaw of X - which can only be solved by nesting multiple X servers into each other. At that point we would have a much uglier architecture than we have with wayland.
But the problem is basically: you can either have 1-2-4-8 cores at most writing pixels into a buffer one after another (but due to the complexity of interactive GUIs it will most often be single threaded), so a circle will be displayed as going over an area and coloring each pixel.
Versus specifying some condition and having the GPU run it on every pixel in large batches, almost doing it in one go. Of course for 3 lines, what previous GUI iterations were, you don’t need gpu, but for gradients, media!, and basically a bunch of other things you simply need the GPU’s orders of magnitude more parallelism. Add to the picture that we are using much bigger screen resolutions (full hd has 6x number of pixels compared to 480p, and then we are not even talking about 4k. And 120, 240fps monitors are a thing now) and you can quickly see that 1) drawing is a greatly parallelizable task 2) having it done serialized simply doesn’t scale to today screens.
This is because said graphical applications are designed to be used with a modern GPU and they use stuff like OpenGL to render their components.
"but for gradients"
Maybe we can go without them. Modern UIs are too heavy, latency-inducing, battery consuming, and can turn your device into a heater easily.
"And 120, 240fps monitors are a thing now"
Re-drawing the window in every frame is a wasteful action that tends not to happen with applications designed for software rendering.
While you may not like gradients, animations (which absolutely mandate GPUs) for example do give context on what happens because humans are used to physical objects that don’t teleport from one place to another. I wouldn’t consider these needless features either.
And, may I ask,why are you so quick to dismiss the core developers of X?
Except new GPU hardware at reasonable prices has been unobtainable for 2 years now, and AMD's new Linux friendly stance was only a couple of years before that. So there's like a 2-3 year window where you could have said "Well, you should have known to buy the FOSS friendly hardware". (Which came with other tradeoffs, AMD had uncompetitive hardware and poor GPGPU support in that time period)
I have seen various comments claiming that the code was very clean.
"Since the late 00s, all of the window managers had already started doing compositing themselves"
Most window managers don't do compositing.
Also, XCB is async.
You must perform regular maintenance on btrfs or it will quite simply break. This is a huge departure from for example ext4, which is (to the end user at least) hassle free.
- a few years ago, one system would suddently not boot (due to btrfs); this happened twice
- nowadays, on one system, background scrub doesn't start
This is anecdata of course, but I've never had a good impression overall. I don't see any reason to use btrfs rather than ZFS, considering that Ubuntu and derivatives are starting to add builtin support.
Scripts for actually doing so can be found f.e. here: https://github.com/kdave/btrfsmaintenance