X.Org Server 1.20.4 Released With XWayland Fixes

[gwgwg]

The fact that it will be phased out and discontinued means that it's on life support, and no sane person should use software that is on life support, regardless of how stable or performant it is because it can be dropped any time.

X11 has color management, Wayland does not. Those who use graphics seriously on Linux for photography, publishing, video/film editing etc. aren't about to switch to Wayland. They will be forced to switch to MSWindows or OS X (or even Android!) if X11 goes away.

[uid313]

X11 has color management, Wayland does not. Those who use graphics seriously on Linux for photography, publishing, video/film editing etc. aren't about to switch to Wayland. They will be forced to switch to MSWindows or OS X (or even Android!) if X11 goes away.

Tell Richard Hughes maybe he can fix it. He is the guy behind ColorHug.

[Weasel]

The fact that it will be phased out and discontinued means that it's on life support, and no sane person should use software that is on life support

With this logic, that's why no sane person should use Wayland.

[kozman]

Is there any cruft in X.Org Server that can be cut out?
Does it still have multiple input backends and graphics backends?
Do we in 2019 need all that old stuff from the X of the 80s and 90s?
When running X.Org Server purely under Wayland and XWayland is all of the X.Org Server needed?
Have any modules been dropped? Are any modules getting dropped?
Any code removal happening?

I'm not Linux expert but yes, code removal *is* happening. I have seen so many responses to your question stating that no code removal is happening for old crap and cruft that I registered on purpose just to respond (and I've been reading Phoronix sine it's inception!).

Really? No code removal of old stuff? Then what exactly do you call what's happened in this commit: https://cgit.freedesktop.org/xorg/xs...ade8b5b921cafd I'd say that is clearly old code / cruft removal. Maybe removing old crap is glacial in it's pace but somewhere out there, there's that one guy still rocking some ancient dinosaur. I don't agree leaving ancient cruft in to cater to old dinosaurs should be given any priority with the limited development resources that exist today.

Maybe not this year. Maybe not next year. But eventually, old crap will be removed in succeeding versions of Xorg. Count on it. I agree that the pace should be inordinately faster to remove the ancient cruft where and when possible to make a leaner, meaner Xorg.

[LillyCompton]

From the perspective of a distribution maintainer wayland still isn't stable enough. Many packages depend on it and/or their wayland support still isn't that stable as one would like.

Although an oldy with some disadvantages x11 is surely needed for years.

Lets be patient

[starshipeleven]

With this logic, that's why no sane person should use Wayland.

*Windows

[starshipeleven]

Really? No code removal of old stuff?

That's removal of ancient and unused stuff. From a module that was not affecting performance or development in any way.

I mean ok he will think it's great because he can't grasp the concept of modules, but in practice it's not really what he wants.

Maybe removing old crap is glacial in it's pace but somewhere out there, there's that one guy still rocking some ancient dinosaur. I don't agree leaving ancient cruft in to cater to old dinosaurs should be given any priority with the limited development resources that exist today.

The reason they can't really do that where it matters is mostly because of specification, the rest is dealt with by decent software design, i.e. modules and compartimentalization.

You don't need to know the whole Xorg codebase to contribute, nor you actually use most of that as modules are loaded only if needed. Having DRI1 or DRI2 or whatever does not impact you on DRI3.

But this is a concept that a webdeveloper like him can't grasp.

Maybe not this year. Maybe not next year. But eventually, old crap will be removed in succeeding versions of Xorg. Count on it.

They won't delete the crap that matters as that is part of the X specification. They don't even delete modules that are "old" for that guy's myopical webdeveloper-like perception of software (where everything that isn't the latestestest version of the software is old and deprecated and should not be used anymore).

That's why of the "no".

[Weasel]

*Windows

Well they both start with W and have 7 letters, so it's reasonable to say they share the same fate.

[cj.wijtmans]

X11 has color management, Wayland does not. Those who use graphics seriously on Linux for photography, publishing, video/film editing etc. aren't about to switch to Wayland. They will be forced to switch to MSWindows or OS X (or even Android!) if X11 goes away.

Current linux devs cant grasp this since they dont do any real production work. They only care about technicalities that maybe affect 0.0001% of desktop users.

[cj.wijtmans]

I'm not Linux expert but yes, code removal *is* happening. I have seen so many responses to your question stating that no code removal is happening for old crap and cruft that I registered on purpose just to respond (and I've been reading Phoronix sine it's inception!).

Really? No code removal of old stuff? Then what exactly do you call what's happened in this commit: https://cgit.freedesktop.org/xorg/xs...ade8b5b921cafd I'd say that is clearly old code / cruft removal. Maybe removing old crap is glacial in it's pace but somewhere out there, there's that one guy still rocking some ancient dinosaur. I don't agree leaving ancient cruft in to cater to old dinosaurs should be given any priority with the limited development resources that exist today.

Maybe not this year. Maybe not next year. But eventually, old crap will be removed in succeeding versions of Xorg. Count on it. I agree that the pace should be inordinately faster to remove the ancient cruft where and when possible to make a leaner, meaner Xorg.

As said before, xorg is modular. There is no point in cutting cruft that is not used or can be turned off in the make process. It will be phased out as needed.