> The original developers judged Xorg is really not saveable.

No, the orignal developers judged that they couldn't be bothered saving it. This has no relationship with whether it can be saved.

> Any extra effort on X11 might help to buy more time, but will in the end be for nothing. And in this time of supply-chain attacks, vs-code plugins, npm packages, agents and what-not, X11 is just too dangerous

Wow, this is some impressive vague fearmongering. Please explain what npm packages, vs-code plugins, and "agents" have to do with X11 being "just too dangerous"?

Here, I'll try one:

"Even in 2026 the developer of the i3 window manager says wayland isn't ready for real use. Any effort poured into wayland might delay it's inevitable collapse but in these days of nodejs, rising authoritarianism, and climate change it's clear that it will never actually gain wide acceptance"

There are a bunch of legitimate issues with X.

For example there's tons of legacy cruft in there intended for working with hardware that hasn't been in use since circa 1992. Things like monochrome 3D displays with weird resolutions like 1200x240 and non-square pixels. Having that stuff in there makes supporting more modern hardware more difficult than it needs to be (and is also part of the reason behind why e.g eliminating tearing is very difficult), and it adds huge complexity to the codebase for no benefit on modern systems, which makes it much more difficult (but NOT impossible, as some love to claim) to maintain.

There's also the wayland fanboy's go-to criticism: there are also some security shortcomings in the protocol. You can find details on this shortcoming which I have never in 30 years seen exploited in the opening paragraphs of every pro-wayland article on the internet. (it is a legit shortcoming. There have been multiple suggestions on how to address it over the decades without starting over from scratch. xlibre is working on one of these)

But over the years I've slowly become more and more convinced that the biggest issue people have with X is that it's not shiny and new.

I'm expecting them to announce a rewrite in rust any day now ;)

Oh good! This is great news!

So you've managed to get redhat to commit to continue to package an X server, then? I'm impressed by this achievement and send my thanks for your efforts - they've been trying to drop it for a while now, it's only wayland's continuing status as unusable vapourware that stops them.

You don't have to use Red Hat's products or code if you don't want to. There are plenty of competitors that might suit your needs and desires better.

Oh, I don't? This is news.

So to be clear, you're saying that you've spoken to the management at my company and convinced them to switch away from redhat?

If you could post a link to a copy of the email from the higher-ups, just so I have it in writing, that'd be rad. Thanks! :)

You accept money to work on Red Hat products, that is a choice you make. The owner/manager of the company you work at is free to decide what systems to use and then pay people to carry out her strategy/direction. You probably don't get to decide what kind of office chairs you buy either.

Right. So in other words you're now saying that I do have to use red hat's products, even if I don't want to, if that's what my customers want.

(and just to head off your next comment, no, it's not my choice, because I happen to like food and shelter)

Thanks for playing

So you want to force Red Hat to keep maintaining the xorg stack because you are unable or unwilling to change jobs?

Who said anything about redhat maintaining anything?

I just thought I'd summarise this article for anybody who doesn't have the time to read the whole thing:

No. Wayland still has hilariously terrible bugs and can't adequately do very basic things we have been doing for ~30 years on X, even in 2026, and because it's not compatible with anything it requires ditching all your stable, well-tested, solid software that you've been using for decades to replace it with incompatible software that doesn't work half the time.

To summarise the summary: it's in pretty much the same place as it was in 2025. And 2020. And 2016.

I just wanted to say thanks - I read the unix-hater's handbook about 15 years ago and it taught me a LOT, maybe even changed my life. The chapter on X was particularly memorable and entertaining. Thanks!

Wow, gnome defaulting to doing something dumb, who woulda thunk it.

> How would you do this ?

It depends. I have many questions.

> My goal is to minimize CPU usage on the computer. Would h264 compression be a good thing here given source and destination are the same machine?

No.

> Other ideas?

1. Why does it need to be displayed in a web browser (as opposed to more appropriate / better performing software specifically built for video)?

2. via what interface/library is the camera connected to the machine? What format/codec is the uncompressed stream you're getting from the camera?

3. I am available at very reasonable consulting rates

Thanks.

1. It is part of a bigger web-browser dashboard/control interface and this camera display is just one component among many others.

2. Some of the (USB) cameras can have proprietary interfaces such as https://www.ximea.com/support/wiki/apis/python

How would you do in this situation, to have the video stream in the browser, with as low CPU usage as possible?

3. Not for this project but for a future project, feel free to put a link to your portfolio or contact page (even if you remove the comment later)

1. fair enough

2. "How would you do in this situation, to have the video stream in the browser, with as low CPU usage as possible?"

Since it's being consumed on (only) the local machine you've got an excellent situation where you can use any obscure codec you like, as long as the browser you're using supports it. Also you don't need to care at all about network bandwidth. If minimising CPU usage is the #1 priority then something fairly lightweight like mjpeg might do the trick. Alternatively you might get away with not compressing the video at all (but this might cause issues due to dealing with huge amounts of data). If I wanted to minimise CPU usage, I wouldn't be doing it in python.

3. You can find me if you look.

  > God knows what process led them to do video streaming for showing their AI agent work in the first place.

This was my first thought, too.

How else are they going to sell it to all those micromanagers who micromanage things?

From TFA:

    Implementation complexity: 
     h264 Stream: 3 months of rust
     JPEG Spam: fetch() in a loop

I don't see how it could have taken 3 months to read up on existing technologies. And that "3 month" number is before we start factoring in time spent on:

* Writing code for JPEG Spam / "fetch() in a loop" method

* Mechanisms to switch between h264 / jpeg modes

* Debugging implementation of 2 modes

* Debugging switching back and forth between the 2 modes

* Maintenance of 2 modes into the future

Just wait till the next version.

Mozilla love re-enabling stuff you've explicitly turned off a hundred times. Terrible hamburger menus, threaded messages in thunderbird. I've seen it so many times.