
Red Hat Expecting X.org to “Go into Hard Maintenance Mode Fairly Quickly” - qalmakka
https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Maintenance-Mode-Quickly
======
technofiend
What irritates me with regard to Wayland is the assumption that all rendering
is local. The great thing about X was on a _LAN_ you could bang up an ssh
session somewhere, carry across your $DISPLAY and have the exact same
application running somewhere else but rendered to your screen. It doesn't
sound like much but there were times when it was incredibly useful.

Thin terminals brought this to the logical conclusion of not needing a desktop
at all, but unfortunately X's protocol is too chatty and sensitive to latency
to really shine across a WAN. These days you can work around all of that by
opening a session via Guacamole or the like but that's still one tab in a
browser per graphical session. There's no just using SSH in a for loop and
opening up a raft of xterms to a bunch of machines in Wayland, AFAIK.

From the Wayland FAQ

 _Is Wayland network transparent / does it support remote rendering?_

 _No, that is outside the scope of Wayland. To support remote rendering you
need to define a rendering API, which is something I 've been very careful to
avoid doing. The reason Wayland is so simple and feasible at all is that I'm
sidestepping this big task and pushing it to the clients. It's an interesting
challenge, a very big task and it's hard to get right, but essentially
orthogonal to what Wayland tries to achieve._

~~~
saltcured
To be honest, I think remote rendering is unnecessary and is mismatched for
actualy application workloads. The amount of data and IO needed by the
renderer in many applications outstrips that needed to send the rendered
result to a display. I.e. the textures, models, or font curves loaded into
GPU-local RAM and then resampled or reinterpreted to draw frames. This stuff
is the heart of a graphical application, and doesn't really make sense to
split across a network.

When the application host is really resource-starved and does not need to
supply much content to a renderer, we are better off using more abstract
network interfaces. On one hand, HTML+CSS+js are the remote rendering protocol
to the browser which becomes the remote renderer. On the other hand,
sensor/data interfaces become the remote data source for a GUI application
that can be hosted somewhere more appropriate than on the resource-starved
embedded device.

What I will miss from SSH X-forwarding is not remote rendering. It is per-
window remote display. I would be perfectly happy with remote applications
doing their rendering within their own host, and just sending their window
contents to my display server, where my local compositor puts the window
content onto my screen. Protocols more like VNC or RDP could be used for each
of these windows, adaptively switching between damage-based blitting, lossless
and lossy image codecs, or even streaming video codecs. What is needed is the
remote window-manager and display protocol to securely negotiate and multiplex
multiple windows opening and closing rather than one whole desktop.

What I won't miss from SSH X-forwarding is window and application lifecycle
tied to the network connection. Let me disconnect and reconnect to my remote
application and its windows. Let me share such a connection to have the same
windows displayed on my desktop and my laptop, or to window-share with a
coworker down the hall...

~~~
jacquesm
That's pretty typical. "I don't need it, so therefore nobody should need it,
so therefore I will remove it".

Unix is different things to different people and to remove the network
capability from X is a step back, not a step forward. There are a whole pile
of neat things that you can do with networked graphics, so much, in fact that
Plan 9, in many ways a successor of Unix used that theme as the core of many
of the system services. All of them work locally as well as remote.

~~~
a3n
Yeah, I sure liked being able to run RPi apps rendered on my laptop with X.

Per a discussion the other day, my RPis are in a drawer. Have we swapped out
screwdrivers for RPis in the modern junk drawer?

~~~
delinka
> Have we swapped out screwdrivers for RPis ...

No, they've been added to the screwdrivers. I've found it challenging to use
RPi to drive screws.

~~~
saalweachter
Surely they can at least manage a flathead.

------
hedora
Uggh. RedHat has a long history now of replacing working stuff with half
baked, regressed-by-design replacements.

I’d really like to have a working Unix environment, and Linux stopped being
that for me years ago.

More conservative alternative distros keep bit rotting due to upstream
(usually RedHat induced) breakage. (SystemD, Wayland, DBUS, PulseAudio, Gnome
3, kernel API brain damage, etc)

Does anyone know of any alternatives? Is there a distro/foundation that will
actually support open source Unix moving forward (BSD, maybe?)

~~~
ainar-g
I've been experimenting with OpenBSD, and it's been pretty nice. The code is
beautiful, and a lot of stuff just works. Not sure how it will behave on a
laptop though.

~~~
brobdingnagians
I bought a ThinkPad specifically to install OpenBSD. It's a great combination.
I find OpenBSD much more straight forward and coherent than Linux. There are
some bells and whistles that I wish it had, but in terms of the foundation it
is wonderful.

~~~
imiric
How is the graphics support in OpenBSD for the ThinkPad, and which model?

I've found the recent P and X models underwhelming as far as hardware goes,
and support in Linux hasn't been great in my experience. While I'd like to
give BSD a try, I fear I'll have to deal with even more driver issues.

For example, all video out ports on my X1 Extreme are wired to the dedicated
NVIDIA card, which forces me to either use Nouveau which causes kernel panics,
or use huge binary blobs from NVIDIA, which I'm reluctant to do for several
reasons, one of which is breaking my initramfs image and making the system
unbootable.

I'm quite tired of the amount of these types of issues in the Linux ecosystem,
so I'm very interested in trying something simpler and better thought out, as
long as the hardware support is decent.

------
markstos
It's about time. A 10+ year transition from X.org to Wayland is long enough.

X.org is open source, it is does not belong to Red Hat. It's a truly desirable
technology, anyone else is welcome to contribute to the maintenance of it or
fork it.

When no one else wants to maintain it favor of newer technologies, that's a
good sign it's ready for retirement.

~~~
erik_seaberg
In those ten years, clusters in remote datacenters went mainstream, but
Wayland has never delivered network transparency except by embedding X. Where
are these users who are still running everything on one computer under their
desk?

~~~
danarmak
I think the demand for remote GUI apps went down, for several reasons:

\- Web apps got better and more common

\- Windows (and MS SQL Server etc), which are some of the big OS-level reason
for using remote GUI management tools, has improved its command-line
management story and added UI-less server editions

\- Network improvements (more bandwidth, more clouds and POPs) made existing
'remote desktop' protocols more tolerable on the Internet, all the way back to
the venerable VNC and RDP

What kind of remote UI app/workload do you see as common today?

------
nisa
Sad. It's probably unpopular but wayland is not ready yet IMHO and lacking on
a conceptual level. Yet another few years/months until most bugs are fixed and
more broken functionality...

~~~
tomxor
Maintenance mode != dead [1]

This just means that development of _new_ features and research should take
place on Wayland where it belongs. From what I've read X has been a long
evolution into a hodepodge of historical but effectively dead interfaces with
newer ones crammed along side... it doesn't make sense to continue the
tradition of cramming more features into X, but that doesn't stop people
developing new things on top of it while Wayland matures.

[1]
[https://en.wikipedia.org/wiki/Maintenance_mode](https://en.wikipedia.org/wiki/Maintenance_mode)

~~~
kevin_b_er
You mean _parity_ features? SSHing into a server and launching a small GUI
tool is still dead. It was killed by Wayland intentionally and willfully as a
fundamental design idea. In fact, the feature of doing that is considered "not
part of wayland" by Wayland designers.

The root problem is that wayland replaced half of x.org and left the rest for
someone else to figure out.

~~~
jhasse
> SSHing into a server and launching a small GUI tool is still dead.

They are working on native support for that via PipeWire. For the time being
you can still do that with Xwayland.

~~~
erik_seaberg
PipeWire is video streaming, not remote rendering. They're assuming a rack of
GPUs in the datacenter and a virtual circuit dedicated to me, but in reality I
have a congested link and one GPU attached to my display.

~~~
vardump
The question is, which is more data. Rendered result or the data to do the
rendering.

If the rendered result is lighter, then a video stream makes perfect sense.

If sending the data over to render is lighter, there's still one more issue:
that GPUs are still not interchangeable, and the server hosting the
application needs to have the necessary information about all the possible
GPUs, their quirks and limitations. And you might still get inconsistent
results at various clients.

My personal guess is that the data to render is a lot more than data the
required to do video streaming. So much depends on doing CPU rendering
directly to textures. Although more and more is moving to GPU, so...

------
mrighele
I'm wondering if all the resources that went to Wayland for the past TEN years
were directed to slowly evolve X11 to the same direction we would be in a
worse or better situation. It seems to me very similar to the Python2/Python3
debacle.

What pisses me off more than anything else is having to replace a lot of tools
there are working perfectly with xorg but are not compatible with wayland.

A few example

* Window manager (of course)

* taking screenshots

* setting desktop background

* Intercepting multimedia key (e.g. volume handling)

* using redshift to set the screen temperature

* ...

Yes, I know that I'm using an unconventional setup, but the freedom to do that
was one of the reasons that attracted me to a unix environment. Redhat is
working very hard to change all of that for a "year of the linux Desktop" that
(in my opinion) will never come.

~~~
vmchale
Might be time for me to stop using XMonad, unfortunately.

Pretty annoying IMO. XMonad works exactly how I want it to.

~~~
meruru
[https://github.com/waymonad/waymonad](https://github.com/waymonad/waymonad)

------
pinewurst
With the coming IBM transition, I'm expecting Red Hat itself to go into "Hard
Maintenance Mode" fairly quickly. Another comment here estimates 10 years of
RH support, but I'm confident that X.org will outlast RH.

~~~
zzzcpan
And Wayland might get completely abandoned in the process.

~~~
Iolaum
If wayland gets abandoned it will have to be re-invented. It solves real
problems with X11. That doesn't mean Wayland itself doesn't have problems
though. Over time they will get solved. If people or companies need them to
get solved sooner I m sure Wayland devs will welcome any contributions.

~~~
ubercow13
It's not implausible, there's ready Arcan

[https://arcan-fe.com/](https://arcan-fe.com/)

~~~
dmix
> At every step of the way, the underlying development emphasises security,
> performance and debugability guided by a principle of least surprise in
> terms of API design.

I'm very happy they started that list with security, which links to a nice
security overview:

[https://github.com/letoram/arcan/wiki/Engine-
Security](https://github.com/letoram/arcan/wiki/Engine-Security)

One of the things no one mentions is how awful security is on X.

------
nsajko
The Wayland developers have a security model [-1] that is hostile to "power-
users" (those who like to use the Unix (or other OS) programming environment
to its full potential) and the visually impaired (eg., blind). See [0] [1] [2]
to see what features I am talking about.

It is possible to implement some of those features on a per-compositor basis,
but the result of that will be graphical API fragmentation, as programs that
interact with GUIs will need to have separate code for each compositor. And
the work is not done even for Gnome (more precisely Gnome's Wayland compositor
and the Gnome applications that use it) yet.

On the other hand one could say, eg. "Why not make a compositor accessibility
protocol on top of Wayland?". End result of that, it is easy to guess, would
be something worse than X Windows (because of even more layers of abstraction,
and possibly even more incompatible standards/APIs/protocols), which the
Wayland people were supposedly trying to escape from.

Edit: Another thing that makes Wayland (at least without an extension ...)
unsuitable to replace X Windows is forced compositing. This means unavoidable
double buffering and thus worse video performance (especially noticeable for
interactive stuff like video games).

[-1] I prefer calling it security theater, because it does not bring any real
security improvement in practice.

[0]
[https://news.ycombinator.com/item?id=20308011](https://news.ycombinator.com/item?id=20308011)

[1]
[https://wiki.gnome.org/Accessibility/Wayland](https://wiki.gnome.org/Accessibility/Wayland)

[2]
[https://www.freedesktop.org/wiki/Accessibility/Wayland/](https://www.freedesktop.org/wiki/Accessibility/Wayland/)

------
OliverJones
The X Window System has had a great run; a whole generation. And it's still
going, even if it's trailing edge tech now. Thanks Bob Scheifler, Jim Gettys,
and the whole crew.

------
sandGorgon
Fedora 31 is looking to be the most advanced OS yet. If you haven't tried it
yet..I strongly recommend trying it out (for those who don't know, Linux can
be tried out using a usb drive without affecting your hard disk called
"liveboot").

Fedora is a much more polished experience than Ubuntu and other than the lack
of Sketch and Photoshop, I daresay at par with OSX.

~~~
chacha2
From a normal users perspective it didn't seem any more advanced than Ubuntu.
Exactly the same but installing software on the command line takes 2 minutes
longer.

~~~
sandGorgon
that's incorrect. the dependency resolver in dnf is far faster and accurate
than ubuntu.

Its pretty good computer science reading as well -
[https://fedoraproject.org/wiki/Formal_methods_tool_suite#Boo...](https://fedoraproject.org/wiki/Formal_methods_tool_suite#Boolean_Satisfiability_.28SAT.29_Solvers)

[https://developers.redhat.com/blog/2016/08/30/why-red-
hats-n...](https://developers.redhat.com/blog/2016/08/30/why-red-hats-new-dnf-
package-manager-is-not-just-another-yum-2/)

I have done system upgrades since fedora 22 to fedora 30 without breakage. I
have never had that happen with Ubuntu.

In general, Wayland/Systemd/Xorg etc are maintained by Fedora . If you look at
the blog post - [https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-
fed...](https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-
workstation-31/)

>> _he reality is that X.org is basically maintained by us and thus once we
stop paying attention to it there is unlikely to be any major new releases
coming out and there might even be some bitrot setting in over time. We will
keep an eye on it as we will want to ensure X.org stays supportable until the
end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for
everyone who rely the work we do maintaining the Linux graphics stack, get
onto Wayland, that is where the future is._

~~~
dralley
>the dependency resolver in dnf is far faster and accurate than ubuntu

As a Fedora user, that's probably true, but that doesn't make DNF itself
faster. Actually installing and removing packages tends to be fairly slow.

But, it's much better than legacy yum.

~~~
mmplxx
Yes, the constant refreshing of metadata is very annoying. You can disable it
for searches, though. Gnome software sometimes becomes very unresponsive
because of this (and because of flatpaks silently downloading a >1GB runtime).
Probably a reason while it gets so much FUD.

------
ronjouch
I wish I could move to Wayland, but I make heavy use of X-only automation
tools (
[https://github.com/autokey/autokey](https://github.com/autokey/autokey) for
keyword expansion and cross-app macros, and wmctrl/xdotool for window
switching using
[https://github.com/ronjouch/marathon](https://github.com/ronjouch/marathon) )
and nothing similar exists under Wayland.

So far, it doesn't look like similar tools are planned, and neither GNOME nor
Sway offer these features I'm looking for :-/ .

~~~
AnIdiotOnTheNet
Oh, I was going to mention Sway too, since of all the compositors I've seen it
is the only one that seems to care about replicating such functionality. Is it
really still that lacking on the automation front?

------
bryanlarsen
Everybody's blaming Red Hat. Why should they maintain something they're no
longer using? If a credible new maintainer would step up, I'm sure Red Hat
would be happy to hand over the reigns.

~~~
rvp-x
They shouldn't call it maintenance mode just because they stopped using it.
There's a lot of non-Red Hat contributors to X.org.

~~~
dralley
>There's a lot of non-Red Hat contributors to X.org.

There's maybe 5 people that really "know" Xorg top to bottom and none of them
want to work on it any more. The ones that were working on it anyway were
being paid to do so and many of them are also working on Wayland on the side.

A lot of people have made small contributions, but that's not the same thing
as being able to design and develop large new changes. The people with the
knowledge to do that, don't have the will to do so any longer.

~~~
rvp-x
You should try living less in a bubble.

~~~
dang
Please don't do personal attacks on HN.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
afitnerd
Nvidia's lack of support for Wayland really hurts linux desktop adoption.

It's especially bad new if there's no more x.org support

~~~
mspnp
Linux on the desktop would be a reality already if Linux had a stable driver
API.

~~~
Iolaum
Not really. It is well known across the industry how you can get drivers in
linux now. There many players, big (Dell, Lenovo) and small (system76,
Entroware, etc) that sell linux supported devices.

Here's a great write up on the technical merits of linux's approach to drivers
[https://www.kernel.org/doc/html/latest/process/stable-api-
no...](https://www.kernel.org/doc/html/latest/process/stable-api-
nonsense.html)

~~~
rocqua
I think OP was thinking about commercial players who do not like to upstream
their driver code. This might be for copyright/GPL reasons, or for trade-
secret / code obscurity reasons. This is impossible with linux drivers. To
quote from your link:

So, if you have a Linux kernel driver that is not in the main kernel tree,
what are you, a developer, supposed to do? Releasing a binary driver for every
different kernel version for every distribution is a nightmare, and trying to
keep up with an ever changing kernel interface is also a rough job.

Simple, get your kernel driver into the main kernel tree (remember we are
talking about drivers released under a GPL-compatible license here, if your
code doesn’t fall under this category, good luck, you are on your own here,
-snip-).

Thing is, this excludes quite a lot of drivers from getting into the kernel.
And that kind of sucks.

~~~
akoncius
I’m noob what regards kernel specifics, so probably a stupid question: so
basically if you want kernel to support all possible hardware in the world,
you would need to add those drivers to main kernel ? seems like a bad idea
because the kernel’s source code would not fit into terabyte size disk..

~~~
rocqua
If you want your driver to run _in kernel space_ you need that code to be in
the main kernel. Anything that runs in user-space can be kept outside of the
main kernel repo.

There is a bad middle version where you put some interface exposed to user-
space into the mainline kernel and then dump in binary-blobs to interface with
this. The bad part is doing this if you will be the only user of that
interface, and if you do it to intentionally keep your driver out of the
kernel. I believe there was/is an attempt by nvidea to essentially get a shim
for their windows drivers into the kernel.

The good version of this is where the userspace interface evolves naturally,
and in cooperation between multiple consumers. Or at least a case where in the
end there are multiple consumers of the interface in the end.

------
kevinherron
The biggest thing preventing me from using Wayland right now is that XWayland
applications don't scale correctly on high DPI screens.

I don't even own any screens that _aren 't_ high DPI at this point.

~~~
carwyn
This is especially bad with anything based on Chromium/Electron and fractional
scaling at the moment. The Ozone/Wayland back end is still a way off it seems.

~~~
mmplxx
Why do you believe that? Apparently it's possible to build a somewhat
functional version from their git branch. Anyway, chromium is just the first
step. Then electron has to work with the wayland version of chromium.

------
Epskampie
I want to switch to wayland, but it’s impossible until Nvidia get their shit
together on linux. I hear AMD has awesome open source drivers now, time to
give them a shot!

~~~
jammygit
I read that OpenCL has some compatibility issues with various libraries still,
or else it would be an easier choice

~~~
atemerev
Not only that, OpenCL is a lower-level alternative to CUDA, somewhat
comparable to Vulkan/OpenGL relationship. Trying to actually write something
useful with OpenCL is... rough.

------
bananaoomarang
Have been using Sway on Wayland since 1.0 came out six months or so ago and
the only awkward part has been HiDPI (I have an Intel card so not effected by
the nVidia support). Otherwise good riddance to X, honestly. It felt old 10
years ago! Here's hoping the major desktops etc can finally sort out the
remaining instability/rough edges over the next year or two.

~~~
ndarwincorn
> HiDPI

Hasn't HiDPI support been one of the main drivers of the renewed interest in
Wayland the last few years?

------
doubleunplussed
Here's hoping that the wlroots protocols become more widespread so that one
can actually make cross-DE tools like taskbars. I'm using tint2 on Xorg at the
moment and there just isn't any alternative on wayland - you have to use what
your DE gives you or suck it.

That means a plethora of taskbar extensions on GNOME, all of which suck (poor
multi monitor support, poor workspace support). Having to have a separate
software project for each DE is the way to get bit rotting projects nobody
cares about.

------
IceWreck
* Nvidia drivers suck on Wayland

* KDE and most non-gnome based DEs don't work with Wayland

Wayland is not ready for mass usage

~~~
floatboth
huh? KDE Plasma 5 works well, GNOME and KDE are considering/merging nvidia
proprietary support (fuck nvidia, btw)

~~~
bscphil
>KDE Plasma 5 works well

I use Plasma, and test the Wayland compositor every couple of months. Last
time I checked, many features were still missing, performance was bad, and I
still got crashes occasionally. If it's really gotten into a usable state
since then, that's great.

~~~
nwah1
Resume from sleep causes a black screen. Crashes do happen occassionally,
where the plasma desktop will die and restart itself... this happens _more_
frequently with the latest releases. In recent releases, with multiple panels,
sometimes the kicker menu doesn't open on one of them. On multi-monitor
setups, it doesn't remember the monitor positions after reboot.

On the plus side, I think the copy-paste situation with XWayland is finally
improved.

------
tannhaeuser
I really hope they consider that Linux' graphic stack isn't an end in itself,
but a driver for running the relative wealth of graphic apps (GIMP, Inkscape,
Krita, Blender, Firefox, and more) many people spent the last 30 years or so
developing. Those aren't going to be rewritten from scratch into Electron-
based apps or whatever, and loosing them, as well as BSD and Mac OS compat, is
no option IMHO.

~~~
_ph_
Why do you think those apps would need to be rewritten and what has electron
to do with that? Most of these apps already run natively on top of Wayland, as
they are written using a toolkit like GTK or QT and those toolkits support
Wayland.

Also, there is XWayland, which implements the X protocol on top of Wayland, so
any X application should continue to run. The only thing they talked about
stopping development on is the standalone X server X.org.

I have been using Wayland on my desktop for a while and am quite happy about
it.

~~~
DonHopkins
Electron needs to be pushed down the stack to the bare metal, to become the
window system itself. Then there will only be one instance of it running, that
every other application can share, and the window manager and user interface
and networking can all use standard web technologies, that everything else
uses.

~~~
DonHopkins
If you disagree, then tell me what X-Windows or Wayland can do that a modern
web browser with bare metal drivers couldn't do much better?

You've got JavaScript and WebAssembly for programming, WebGL and <canvas> and
<video> and DHTML and CSS for drawing (including low latency rendering with
desynchronized canvases), JSON and XML and ArrayBuffer for data
representation, HTTP and WebSockets and WebRTC for networking. What is it
missing?

[https://developers.google.com/web/updates/2019/05/desynchron...](https://developers.google.com/web/updates/2019/05/desynchronized)

There's really no need for X-Windows or Wayland any more.

~~~
carapace
You're catching downvotes (have some goddamned respect people) but I'm facing
this choice right now.

I have a project that involves a compiler written in Prolog targeting Prof.
Wirth's RISC chip (for Project Oberon[1]), and I want to make it easily
accessible.

I can use e.g. TCL/Tk/Tkinter/Python+SWI-Prolog, and make a native app that
the user has to install... or...

There is a Prolog in JS[2], and an emulator for the chip in JS[3], and rich
widget frameworks (I like Knockout[4], but there are literally dozens in JS),
so it's pretty easy to make a SPA that shows off the code (literate
programming style) along with live compilation and emulation, and you can even
let users save their work[5]. "Installation" is just visiting the page.

I keep trying to come up with reasons NOT to go that route (out of some
perhaps-misplaced JS prejudice) and I can't.

> There's really no need for X-Windows or Wayland any more.

Indeed!

[1] [http://www.projectoberon.com/](http://www.projectoberon.com/)

[2] Tau Prolog [http://tau-prolog.org/](http://tau-prolog.org/)

[3]
[http://schierlm.github.io/OberonEmulator/](http://schierlm.github.io/OberonEmulator/)
[https://github.com/schierlm/OberonEmulator](https://github.com/schierlm/OberonEmulator)

[4] [https://knockoutjs.com/](https://knockoutjs.com/)

[5]
[https://calroc.github.io/HulloWurld/Hullo.html](https://calroc.github.io/HulloWurld/Hullo.html)

------
iso-8859-1
Interestingly, the old maintainer (Keith Packard) has a fairly recent (2018)
list of improvement ideas for Xorg:
[https://keithp.com/x-ideas/](https://keithp.com/x-ideas/)

------
robrtsql
Let's hope it doesn't go into maintenance mode before this feature is
released:
[https://www.phoronix.com/scan.php?page=news_item&px=GLXVND-O...](https://www.phoronix.com/scan.php?page=news_item&px=GLXVND-
Offload-Improve-1.21)

Not sure if I understand correctly, but the absence of this is what has
prevented Nvidia's proprietary drivers from supporting GPU switching without
having to restart the X server session.

------
hamilyon2
This is big news, no?

~~~
Jasper_
It's more an admission of the current state of things. Adam Jackson, the
previous release manager, stepped down, decided to switch gears to doing other
graphics-related stuff, and nobody has volunteered to make a new X server
release.

xorg-devel has always been a relatively slow mailing list, and very little new
R&D has been done on the X server for the past 5 years or so. Latest I can
think of is the DRM lease work, which is still ongoing.

~~~
bluGill
x.org has always been that way. Slow, hard to get started developing, and not
really "sexy". it is critical infrastructure, but nobody wants to maintain it.

Wayland was at least started by people frustrated with the real problems in X.
(unlike most other replace X projects I've seen over the last 20 years where
were someone who had no idea what is really wrong proposing a solution that
didn't solve the real problems.

~~~
dralley
>Wayland was at least started by people frustrated with the real problems in X

Many of whom, it's worth pointing out, are themselves the core Xorg developers
who don't want to be stuck maintaining Xorg forever.

------
quotemstr
RIP, X11. You had the correct architecture. I still believe that the goals of
Wayland would have been better achieved as a collection of X extensions than
as an entirely new system that's lost many of the capabilities of X, including
network transparency, input configuration, and window manager decoupling.
Wayland is great if you want to build a Windows clone that works exactly the
way Red Hat wants it to work --- but it represents a decline from the Unix
ideal of configurability, experimentation, and simplicity.

~~~
frou_dh
Ken Thompson himself is on record bashing X Windows, so that's a strike
against its ideal Unix status

~~~
nsajko
Everybody who knows it hates X Windows, but that does not mean Wayland is
better, or even that it is a possible replacement for X Windows.

~~~
AnIdiotOnTheNet
The sad reality is that as bad as X is, Wayland is too much of a half-baked
replacement to say that it is definitely better. Case in point: it's about 10
years old now and people still say it isn't ready yet!

------
dimitar
One thing I'm reminded of is the huge role of Red Hat in maintaining loads of
open-source software. They get to choose what direction "linux" is taking by
simply having paid developers put in a lot of time writing and maintaining
software that everyone then adopts. So Wayland will get adopted by most
distributions, just like SystemD because Red Hat will invest in it.

------
shmerl
Still waiting for KWin to become functional on Wayland. Some serious bugs
prevent it. And where is RedHat rushing exactly? Something like adaptive sync
doesn't even work with Wayland compositors yet. So good luck using your fancy
adaptive sync high refresh monitor with games in Wayland session.

------
dpacmittal
I currently use x11vnc to use a third monitor (via raspberry pi connected to a
monitor). Is something like this possible with Wayland?

~~~
kbumsik
Nope. It is impossible by design. They believes not allowing it would bring a
better security. Huh.

------
frabbit
So Raspbian will be the only viable option on the new Raspberry Pi 4 due to
the lack of Wayland for the VideoCore 6?

~~~
floatboth
> lack of Wayland for the VideoCore 6

What?

Even VideoCore 4 with the Mesa vc4 driver supports Wayland — since it's Mesa,
of course it implements GBM and whatnot. I've used Weston on an RPi3 with Arch
Linux ARM.

For VideoCore 5/6, IIUC the __only __driver is Mesa v3d, even better
situation, of course everything should work, and it will always work since no
proprietary crap driver would ever get into people 's hands.

------
pnutjam
Is there an NX type solution for Wayland?

~~~
hedora
If there is something like NX, it was added as an afterthought (last time a
Remote Desktop protocol for wayland came up, it was explicitly outside the
scope of what wayland was designed to support).

------
archy_
The Unix philosophy has been abandoned at this point. What advantages have we
really gained from it? More gaping security flaws? Unnecessary centralization
is pushing the old Unix admins who laid the groundwork for Linuxs success into
BSDs and other alternatives, and the Linux kernel will likely rot as a result.
Could we consider this moment the peak of Linux development?

~~~
DonHopkins
And for good reason! It's about time, too. The "Unix Philosophy" is
intellectually bankrupt. You shouldn't have to fork a process from the shell
to multiply two floating point numbers (especially when the CPU can do that in
one instruction), or do simple string manipulation. That's ridiculous.

~~~
pdkl95
> The "Unix Philosophy" is intellectually bankrupt.

The rest of your post appears to be about shell (presumably Bourne) script,
leaving this claim unsupported. "UNIX philosophy" != "writing shell scripts".

> You shouldn't have to fork a process from the shell to multiply two floating
> point numbers

I can't remember a single time in the >25 years I've been writing Bourne shell
(or bash) scripts where I've wanted to "multiply two floating point numbers".
I've sent large lists of floating point numbers to various programs for
processing, but other languages are far more appropriate for problems that
requires any amount of actual calculation (especially floating point
calculations). If I did need to multiply two floats for some reason, it would
be such a rare event that the few hundred milliseconds "wasted" in spawning bc
is utterly irrelevant.

You seem to be complaining about shell by selecting a feature that is not
actually needed in common use. What, specifically, were you doing that you
needed fast floating point match but needed to use Bourne shell instead of
C/Python/whatever?

> fork a process ... do simple string manipulation.

For many types of string manipulation, you don't. Manipulating strings
(command lines) is what the shell was designed to do! Sometimes sed/awk/etc is
useful for _complex_ tasks, but the shell's variable expansion and other
builtins are generally enough for most _simple_ needs.

And if your needs actually are complex, the cost to start another process
(which is probably much smaller than you think) is insignificant.

~~~
DonHopkins
You're blinded by the limitations of your tools. Of course you wouldn't do
something that's impossible with the shell, because you know it's impossible,
and would switch to another language if you needed to do that. That doesn't
mean that you never need to use floating point numbers. It just means you need
to switch languages when you need to use them. Which is my point.

And no, the kind of stuff you need to fork sed or awk to do is not "complex".
It's simple. It only seems complex because you're writing a shell script, and
the backflips you have to do to escape the parameters and fork the processes
to do that simple string manipulation is complex, not the string manipulation
itself.

~~~
stevekemp
I look forward to using your enhanced tools, once they're ubiquitious and
fully-featured.

More seriously I can't imagine what "points" you're trying to score. Yes the
shell is good at launching external processes, and yes the built-in facilities
for other things are lacking in some ways. On the whole people work around
them by using perl, python, and other tools.

It might be, as you say, that people resort to using such external
scripts/languages because their shells suck. But I have to ask: So what? They
get the job done. A "super-shell" doesn't need to be present, even if people
do things the "hard-way".

~~~
DonHopkins
When did I every say or imply that I was writing my own shell? There are
already ample real programming languages to use that can fork off and manage
sub-processes just fine, thank you, instead of writing ridiculously
inefficient complex hard to maintain un-modular shell scripts.

Why would I waste my time trying to fix something that's fundamentally flawed,
and that nobody would use because it wasn't "standard"?

We already have Python, JavaScript, Perl, etc. Even PHP is overwhelmingly
better and more modular than bash! Why try to put lipstick on a pig like bash?

My point (which I already stated) is that the "Unix Philosophy" in
intellectually bankrupt, not that the shell should be extended with string
manipulation and floating point to make it unnecessary to fork "sed", "awk"
and "bc".

------
mspnp
Can you even disable desktop composition in Wayland? One of the reasons I hate
Windows is that I'm forced to use composition, which provides nothing to me.

~~~
floatboth
If visual perfection is nothing to you, if you love screen tearing, slow
window redraw when moving, Windows 95-esque window trails, etc. — keep using
Xorg.

Wayland is a protocol fully designed around composition. Clients have their
own buffers, the server composites them. There is no way to draw directly to
the screen, because we're not in the 90s with 640K of RAM and there's no
reason whatsoever to implement the crappy way of rendering windows.

~~~
andreyv
Forced composition and vsync is a mistake for gaming.

The added output latency is unacceptable, especially for first-person
shooters. A little tearing is nothing compared to the vsync lag.

If Wayland wants to replace X.org, then it should support also this use case.
But full composition being mandatory isn't very encouraging in regard to this.

~~~
andrius4669
Untrue in my experience.

Games still can render more FPS than mandated by vsync.

I tried playing sauerbraten (with SDL2) on sway other day, it was butter
smooth (no tearing) with vsync off in game, and I felt no input lag unlike
when I switch vsync flag on in game which limits FPS.

It probably does triple buffering, but somehow on sway it worked better than
triple buffering of intel's xorg driver back when I tried that.

~~~
throwaway2048
VSync fundamentally introduces a frame+ of delay by design, it does not matter
what your FPS is.

------
atemerev
Wayland doesn't work with Nvidia (and no improvements in last 3 years). Nvidia
is the most popular GPU option out there. The end.

------
quotemstr
Meanwhile, Windows has become an acceptable Unix. (I'm not trolling.) I don't
want to admit this, but I've been wondering whether, over the long term, FOSS
stuff really can't match the quality of a sustained commercial endeavor.

~~~
newsoul2019
You may be right (about Windows) but I am not going to pay $100 (for a new
Windows license) or so to find out.

edit for clarity

~~~
alphabetam
You can buy online-only keys for about 10€ on amazon. They work well, although
they are not transferrable to a new pc.

~~~
genera1
Those cheap Amazon keys are still not legal, so you might as well pirate
Windows

~~~
sekh60
Thank you! I hate people on Reddit who advocate for those cheap keys. If you
don't follow the license you are pirating it. Simple as that. Now whether or
not piracy is okay is a whole different issue.

------
peterwwillis
After 18 years struggling with the Linux desktop, I switched to Windows for my
GUI needs. Everything just works, if somewhat slowly. My "working environment"
is a Linux VM. If I need to run a graphical app from the VM, there are plenty
of rootless X servers for Windows, plus Windows 10 has workspaces.

I get the best of both worlds: real vendor support for hardware, and the best
software for getting work done (windows business software, Linux coding
software). Honestly, this feels like the future to me, and I hope M$ is
working towards this being a normalized hybrid platform.

~~~
pkulak
The new Windows Subsystem for Linux looks legit. Is that what you're using, or
are you spinning up your own VM?

~~~
peterwwillis
Some things don't work well with WSL right now ( _stares at Docker intensely_
) so it's a Vagrant VM w/Ubuntu.

~~~
nailer
Doesn't Docker use WSL2 now officially?

~~~
joaobeno
I tried it on the weekend, and it indeed work...

------
nsajko
Wayland is broken by design (or, as another commenter says, "lacking on a
conceptual level") and NOT A REPLACEMENT for X Windows.

Wayland has a bonkers security (theatre) model based around protecting from
untrusted processes (graphical applications) connected to the compositor. (If
you must give untrusted code a process on your machine, the correct solution
is to give it its own Unix user and run an X Windows server owned by the same
user.)

One consequence is that screenshots/screencasts do not exist on Wayland,
applications can only see their own windows. Also, quoting Red Hat:
"Furthermore, there isn’t a standard API for getting screen shots from
Wayland. It’s dependent on what compositor (window manager/shell) the user is
running, and if they implemented a proprietary API to do so."

EDIT: Other stuff that you can not do with Wayland and is justified by their
"security" model is injection of input events and reading other applications
input (think xdotool, autohotkey; this is great when you want more control of
your graphical user interface system).

~~~
qcowhwcugwcgoiu
What you describe as broken by design in terms of security is in fact its
primary advantage from my perspective:

With the security nightmare that is modern web browsers I do not want any of
them which runs on my machine to be able to access a single bit of more data
than which is necessary.

Firejail helps a lot for this purpose, but fixing the browser to not be able
to spy on other X applications requires sticking them into a Xpra sandbox,
which greatly intereferes with performance and is a hell of an ugly hack (it's
like running a local VNC server and connecting locally to it).

Putting software into different user accounts isn't a solution either because
the usability of that is well, unusable.

~~~
nsajko
Use different users and/or virtual machines if you want security.

BTW, Firejail is also shit, it had some stupid design decisions and security
bugs. And it basically relies on Userspace namespaces which are or were an
experimental/unsecure feature in Linux.

Wayland's security model is bonkers because the attack surface it implies is
just too great.

BTW, Is useradd not usable for you?

~~~
qcowhwcugwcgoiu
> Use different users and/or virtual machines if you want security.

The Internet is so important that for daily computer usage I, and probably
everyone else, have a browser open at basically any point in time.

So do you want me to switch users between the $browser_user and $main_user
every 5 minutes I need to do something outside of the browser?

~~~
nsajko
I just run chromium as my main user (but usually with a temporary scripted
--user-data-dir and HOME environment variable), because it is relatively
secure.

And switching Linux consoles/X servers is just two key presses anyway.

~~~
nsajko
Correction: usually it is three key presses: Control, Alt, F3; for example.

