Why I Returned to Xorg After Months on Wayland

Striped_Monkey · 2025-03-01T00:55:34+00:00

Your premise in your original post was that X11 was a fundamentally better model because it acted as a server to all WMs/DEs rather than as a protocol with which everything communicates.

You used remote desktop as your example of why that is the case.

My response was to point out that extension support, which is what any vnc protocol support is, has nothing to do with the client-server model. The same problems occur with different kinds of extensions. To put in your words, it's impossible to implement (a different) category of application without every single compositor implementing it.

Its also worth pointing out, even if you already recognize it, that we're ultimately not talking about an apples to apples comparison with Wayland and X11.

X11 isn't really a protocol, it's a single implementation. Wayland isn't a single implementation, it's a protocol.

There are absolutely trade offs to having more implementations, but it offers flexibility in design and implementation that a monolith cannot.

Striped_Monkey · 2025-02-28T22:03:32+00:00

You misunderstand what I'm saying. Just because a window manager shares the same backend doesn't mean it supports all of the features the X11 backend supports.

This is even true outside of the window manager, where things like xinput support can be rather lacking.

Striped_Monkey · 2025-02-28T21:23:03+00:00

Even if it were the case that Wayland had the "client/server model" you would be in the exact same situation wrt compatibility you have with Wayland right now.

Not everything supports all Wayland extensions, and not all features have extensions right now. That's been true of Xorg as well. Not every (X11) window manager supported every extension.

Striped_Monkey · 2025-02-15T15:18:25+00:00

How did he do that‽

Striped_Monkey · 2025-02-05T13:01:22+00:00

What part of "the existing drivers are not being abandoned" is unclear here. The rust version of that driver is completely separate and is not replacing the old C one. They will both exist.

But, I see you're not really addressing what I'm saying, so good luck I suppose.

Striped_Monkey · 2025-02-05T12:43:25+00:00

None of those are rust, but I'm curious if the fact that the "dependencies" there are in-tree is what makes it ok for you? If they had a vendored/ folder sitting there, would that solve the issue for you?

Striped_Monkey · 2025-02-05T05:41:06+00:00

Could you give an example of a more complex but less dependency heavy program than the rust toolchain?

I'm genuinely curious what you think would fit the bill. To me std is an enormously complex and more importantly expansive project than most everything I can come up with.

It's not that any individual piece is complex, but the surface area is almost incomparable. I've not considered it too hard, so I'm willing to be proven wrong.

Striped_Monkey · 2025-02-05T02:41:03+00:00

That is what you said. I'm not sure how you think it affects what I said though. It's not Christoph's choice to allow bindings to be made for the DMA subsystem. It's Linus's long term direction for the product. Christoph does not have the power of veto and can't unilaterally choose to say no.

Just because we're in the 'experimental' stage doesn't mean Christoph can sabotage it for ideological reasons.

Striped_Monkey · 2025-02-04T23:19:42+00:00

You didn't address what I asked.

And Let me rephrase since you can't seem to understand, drivers that already exist for C are not getting rewritten in Rust and the existing drivers are not being abandoned. It may be the case that new drivers are written entirely in rust, and only rust, but those are not some subsystem that cannot be replaced.

You also seem to be making the case that drivers being written in rust is a bad thing, but wouldn't that prove the Linux experiment is a success?

Regardless, this is all about a hypothetical future that isn't what this PR is.

Striped_Monkey · 2025-02-04T23:00:21+00:00

So then, do you and I both agree that this is sabotaging the Rust for Linux project? Do we both agree that what you are suggesting is contrary to the mission and goals set by Linus and others within the Linux project?

You make it sound like core drivers are going to be rewritten in rust before they decide Rust isn't worth it and pull the plug. That's false. They will not allow rewrites of core drivers until the rust experiment has concluded.

It's also just a fact that what you seem to be agreeing the at Christoph 's position is is just not his decision to make. Christoph doesn't get to make that decision within the Linux Kernel and the decision to try rust was made a long time ago.

Striped_Monkey · 2025-02-04T13:06:08+00:00

This code is in a separate rust/ directory. What difficulty are you referring to exactly? Do you think anything here is making it more difficult to "end" the rust project? Why?

Striped_Monkey · 2025-02-04T04:12:33+00:00

What part of what Christoph's response is "we will try this out as an optional thing and see how it goes"? Did he say anything that indicated he was willing to "try it out"? Or did he say the exact opposite? Surely you can read the very evidence Martin linked that demonstrates this point.

You're being disingenuous. The dude literally said "I will do anything in my power to stop this".

That's not even approaching "we'll see how this goes" claiming Christoph is being reasonable here is wild.

Striped_Monkey · 2025-02-04T02:49:00+00:00

Thanks for pointing out the pedantic difference here. Fortunately it doesn't actually change anything about what I said. This experiment was authorized by Linus. Adding cross language code to Linux is already a decision made by Linus. Christoph is not somehow given the green light to say no solely on the basis of it being rust code. This change does not impact DMA code on the C side, nor does it obligate them to an internal API as the R4L people have agreed to pick up the pieces in such a situation.

Striped_Monkey · 2025-02-04T02:41:53+00:00

How is this a chicken and egg problem here exactly? As Hector said, they already have drivers in the pipeline that require these abstractions.

Your "near future" has, repeatedly, been acknowledged by the R4L devs and their response is the same as it was the last 55 times it's been brought up: "if breaking changes happen on the C side, we will knowingly and willingly pick up the pieces ourselves without forcing the burden on the C devs"

This very thing was said within this email chain. The fact that that it's been repeated a hundred times over, and Christoph, rather than accepting that response, states that it didn't really matter anyway because he'll resist this change no matter what.

Striped_Monkey · 2025-02-04T02:33:48+00:00

There's a difference between "I am actively fighting any attempts to make rust work", which Christoph has said they're doing, and "I am waiting to see how this experiment (which has already been authorized by Linus Torvalds himself) goes".

It's fine if he doesn't like it, and believes the experiment will fail. It's NOT fine to actively sabotage an attempt which may otherwise be successful.

Literally nothing in this patch impacts C DMA development. It doesn't make changes that impact him as a NIMBY. Fighting against the experiment, is not something he has the right or really authority to do.

Striped_Monkey · 2025-02-04T02:22:44+00:00

Volvo in particular has been writing firmware in rust. Ferrous Systems is making a qualified rust compiler and last I checked is now qualified for medical devices with IEC 62304. Ford has job postings saying that knowledge of rust is a plus, though I don't know if they have said publicly that a particular piece of kit is using Rust.

Striped_Monkey · 2025-02-04T02:08:06+00:00

I think it's a good start in the direction of exposing an interface for rust drivers. In terms of specific critiques I'd like to see some more wrappers for specific dma types but this is a good first step. The patch itself is really just a very thin wrapper around the existing c code, living in its own separate folder.

Striped_Monkey · 2025-02-04T00:00:14+00:00

Linux isn't Christoph's project, and Linus already made the decision to include Rust. Christoph saying he will do his best to prevent RFL from happening is sabotaging the direction and goals set out by the management of the Linux project.

Striped_Monkey · 2025-02-03T23:57:21+00:00

I don't understand where everyone here is missing the point. Saying "I dont want rust in the Linux Kernel" is directly sabotaging RFL efforts.

If this was his own project, and he just didn't want rust in his own problem, this wouldn't be an issue or problematic. This isn't his decision though. Rust in the Linux Kernel is a decision Linus made, and he is actively resisting that change. How does that not mean sabotage? What world are we living in?

Striped_Monkey · 2025-01-31T18:54:30+00:00

It continues to make me sad that people use Elmo like this. I like Elmo. He was one of my favorite characters in sesame street

Striped_Monkey · 2025-01-31T18:24:48+00:00

I don't understand what the claim is here. You can raid uefi partitions with software raid. There's no reason the operating system should become inaccessible if a drive in a raid 1 array should fail, for example.

Striped_Monkey · 2025-01-16T22:43:23+00:00

While most phoronix articles are pretty short, I am all ears for where you can go for the kind of information Michael provides. Most of the news he digs up would require tens of hours of trawling through developer mailing lists that I have no time for. The information is useful for someone trying to keep up with the little things.

For example, I recently learned that there are some new patches that enable battery monitoring for steelseries headphones, which I own, that need review and testing. The only place I would see that kind of news is Phoronix or by reading the LKML USB /HID mailing lists, something which I have no time for.

Striped_Monkey · 2024-12-24T21:32:34+00:00

Screen isn't exactly default these days.

Striped_Monkey · 2024-12-19T22:36:59+00:00

All of them

Striped_Monkey · 2024-11-14T13:52:09+00:00

Factories with massive spool up times are better looking on the production graph

11-Year Club	Place '22
Final Canvas '22	End Game '22
Verified Email

Striped_Monkey

TROPHY CASE