Hacker News Reader

Comment by jchw | Hacker News Reader

> Wayland solves no issues I have

This is a common sentiment, but it is kind of funny. Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn.

Wayland indeed “breaks a lot of shit” but it’s not an accident or done due to incompetence. Also, it’s worth noting that since there is not one Wayland server the way there is one Xorg server, that not all of this applies evenly. For example, wlroots-based compositors like Sway do not suffer from the screen recording issues as Sway just supports a permissive screen recording API out of the box. I do think the XDG portal idea is a good idea, though, overall, and that the security improvements will be worth the toil eventually.

But more to the point, that the problem is that moving away from Xorg as a display server really needs to happen eventually. The legacy is holding back desktop Linux quite a lot. Issues like supporting modern high DPI displays or multi-GPU setups are ones that Xorg struggles with that Wayland can be made to handle more elegantly (in case of DPI, already does significantly.) It’s not just that. There’s tons of weird old crufty garbage in Xorg. Clipboard is weird. Drag and drop is weird. Wayland is simpler and makes improvements that are welcome, like a good API for keeping window configuration synchronized to help eliminate “imperfect” frames.

No doubt there are issues. I have some choice words about the decision of GNOME to push for using dbus to communicate cursor size changes on high DPI setups, and I do not like the way client side decorations are favored in Wayland.

View on HN

> [...] reducing technical debt, improving security practices, etc

Reducing technical debt by rewriting everything from scratch (almost?) never works. It's the baby and the bathwater. It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues. The new, conceptually beautiful system always fails to capture that embedded knowledge, and ends up breaking many things in many ways for many people.

Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

This is why you need tests, otherwise you're stuck with your legacy forever.

There are also cases where the embedded knowledge and workarounds collected over years are a problem and can be solved in better ways by nuking the whole section. It's a 36 years old project after all. But it takes deep understanding of the Xorg system to tell which case it is... which I expect most people on HN do not have.

> Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.

I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons.

Edit: Thanks for pointing out that Xorg is actually much older. My argument indeed doesn't hold.

Xorg was kind-of forked from a working solution (XFree) whereas wayland started from scratch.

Ahh, 2004 is when Xorg forked off of XFree86, but XFree86 had already been going on since 1991, and already that was an implementation of X which already existed since 1984, and you can trace back even further than that if you want. It’s been a long ride home.

Xorg development largely halted circa 2008 though, since then most of the "Xorg" features have been deleting code in X and moving it to Mesa/libdrm/the kernel.

Wayland's latest release "mostly contains bug fixes and minor protocol updates." [0]. That is ~12 months worth of changes. Pretty similar to 1.18. It isn't like the protocol is a hotbed of massive changes, it looks largely complete according to the release notes.

[0] https://lists.freedesktop.org/archives/wayland-devel/2021-Ja...

> I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons.

Xorg is a fork of Xfree86, which was released in 1991 (https://en.wikipedia.org/wiki/XFree86).

> Xorg is 16 years old

Xorg is a fork of Xfree86 which started in 1991 but feature parity minus the cruft has been reached years ago. Some people disagree about what is cruft however.

For example, I view 90% of the list in the posted articles to be minor softwares relying on undesirable behaviour and unwilling to adapt (the remaining 10% being misrepresentation of actually solved issues listed in bad faith). The original author would obviously disagree.

Then again, I consider X.org to be and always have been completely unusable. How can people accept to use a display manager with constant screen tearing is beside me.

> How can people accept to use a display manager with constant screen tearing is beside me

That's solved by using a compositing window manager such as Compton.

That's also solved by using Wayland with Gnome 3 which comes by default and doesn't require me to tweak anything.

You don't even need a compositor. Just activate Force Full Composition Pipeline if you have an nvidia card.

see: https://imgur.com/a/lDfObqw

It's in the advanced settings.

Silky smooth Xorg web browsing and video at no extra compositor cost.

Or `Option "TearFree" "on"` in your xorg.conf for AMD users. Might even be the default by now.

Thank you so much for this! I've been looking for a solution in picom config for way, way too long.

You're welcome.

Frankly I have no idea why it's not enabled by default.

No, that does not solve the issue. Not using a compositor definitely makes tearing worse, on top of a number of other things, but even with a compositor, you'll get tearing on X, at least using intel graphics.

My notebook is using Intel graphics and there's definitely no screen tearing nowadays on X.org with compositing enabled.

> How can people accept to use a display manager with constant screen tearing is beside me.

I never even noticed it, and I never quite understood what people are on about with this. I had to go to YouTube to watch a demo video to see what it really looks like. And if I try it, then yes, I suppose I see some tearing if I move a window and pay close attention to it. But I never even noticed on my own, and am not bothered by it in the slightest.

Would it be better without it? Sure. But the amount of effort to eliminate what I experience as basically a non-issue is a poor trade-off IMO.

Same here on all points, including Youtube. I always envisioned some kind of critical graphics failure from the way people talk about it. Maybe my standards are too low.

Maybe it's overhyped, but tearing does make me feel like I'm using an amateur OS, especially when I'm using X for some weeks and then hop over to wayland or Mac or Windows, and the picture looks stable.

Tearing can be a gigantic issue when you have full screen videos or render games. However as far as I could find these are caused by the KDE/Gnome/etc. compositor not running in sync with the screen refresh rate. Find a way to bypass the compositor(KDE options to disable it, GNOME with full screen windows, or tell the X window to override the compositor) and it goes away. Its easy to lob all problems on X but whats next? Did it also cause 9/11?

I'm not familiar with the internals enough to know if you're right about tearing being the compositor's fault, though I'd be quite surprised if disabling the compositor resulted in less tearing. But I do know that I experienced tearing using compton with i3 (though much less than i3 with no compositor).

If Gnome, KDE and compton all manage to get compositing wrong on X, and yet every wayland compositor manages to get it right, then maybe it is a problem with X, even if there is some arcane way to fix the issue.

> though I'd be quite surprised if disabling the compositor resulted in less tearing

I have been running OpenGL based applications on KDE for some time and the answer to tearing was always disabling the compositor in the desktop settings or just overriding the compositor related redirect state of the window. OpenGL tends to sync against vblank anyway so I don't find it surprising that rendering directly to the final output buffer instead of an off screen buffer that is at the mercy of the compositor helps.

It's especially noticeable with fast-moving videos or games.

I never noticed it in that either. I played plenty of action games on my Linux machine twenty years, going back all the way to many hours I spent with the Loki port of Unreal Tournament, and I've watched plenty of videos in the last twenty years as well: but it just never registered for me. Maybe I'll notice it now that I know what to look for, but I'm the kind of person who is pretty happy with 1080p (or even 720p) too, so I suppose my brain is just not very good at picking up these kind of visual things, or something.

Yes, tearing is visible in fast-moving videos or games (when run in windowed mode), but video players or games usually run full-screen, where tearing does not happen (as applications can do vsynced doublebuffering), so usually it is not an issue.

> How can people accept to use a display manager with constant screen tearing is beside me.

I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing.

How often does it actually happen to you, and under which circumstances?

Personally I've been using computers since 1995, (Windows and Linux) and I practically never encounter screen tearing. And this is on a wide variety of hardware. Spread evenly over intel, nvidia, and AMD.

The rare times I did encounter it, was only on one PC with an ancient nvidia graphics card (running Arch linux, bspwm). And it would only ever (if even) happen right before a restart after updating the nvidia drivers.

>> I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing.

>> How often does it actually happen to you, and under which circumstances?

It happens every time I Watch a video on X, which is really annoying. It also happens when dragging large windows on my 4k. Wayland is fantastic in this regard.

> How often does it actually happen to you, and under which circumstances?

Scrolling, moving windows, resizing windows, approximately constantly.

Then you haven't switched on Full Composition Pipeline on your nvidia card (if you're using nvidia that is).

I've been enjoying silky smooth Xorg and video for a very, very long time.

Screen sharing seems a critical feature to enough people to rise well above mere “minor feature” if the goal is to replace Xorg. That was probably true 12 months ago, but definitely true 8 months ago.

If the goal is to have a different display protocol that a significant fraction of the possible user base can’t reasonably use as their root display because it provides yet another way in which “Linux isn’t ready for this to be the year of the desktop”, that’s a perfectly reasonable aim, but it seems like Wayland is targeting replacing X, in which case supporting screen sharing (and recording) is probably not an ignorable “minor feature degradation”.

Wayland definitely supports screen capture.

Can you write an application which uses screen capture on Wayland, and which works equally well regardless of compositor?

If not, then Wayland doesn't support screen capture. Individual compositors might, but asking developers to implement five separate screen capture protocols is a big ask.

You can. The standard is new, but it exists, and now works on Gnome, KDE and wlroots based compositors https://wiki.archlinux.org/index.php/PipeWire (read past the intro paragraph to where it talks about the various backends available)

Screen tearing for me has been a thing of the past for years now - just switch on "Force Full Composition Pipeline" on your Nvidia card and hey presto, no more tearing.

In 25 years I've never noticed any screen tearing on a variety of hardware. I'm sure it's happened but it's never been a noticeable issue

Is this really a problem for people?

Yes. Even scrolling a long page (like this HN thread) in a web browser can easily produce it. Can be very, very annoying.

I consider tearing a feature. Tearing is an unavoidable consequence of writing to the front buffer, and writing to the front buffer is required if you want the minimum latency possible. If you write to the front buffer, then so long as the part of the screen you're updating is below the raster position you'll see it that same display frame. If you write to the back buffer and then wait for vsync to swap buffers and avoid tearing then you won't see it until the next display frame. I value latency more than aesthetics, so I never use a compositor or Xorg's TearFree feature.

The goal of Wayland is "every frame perfect", which means I consider it broken by design. I want imperfect frames right away, not perfect frames later.

In an ideal world that would be an option to toggle. I can see use-cases/occasions for both "fast&nearly_perfect" and "slow&pixel-perfect"

X as a display server is over three decades old, the popular incarnation in the nineties being XFree86, which devs abandoned in 2004 to form Xorg due to licensing issues. Most of the code itself really is ancient.

I agree that rewriting things needlessly is bad. However I actually think the folks working on this knew exactly what they were doing and actually made a reasonable choice; they’re not rewriting Xorg, they’re making something completely and utterly foreign to what Xorg is. And I think it is justified regardless of whether Wayland ultimately succeeds or fails.

Here is a reasonable overview from 2012: https://lwn.net/Articles/491509/

It feels important to note that in the case of Wayland, it is indeed designed by the very seasoned folks that have worked with Xorg. If someone like keithp who have worked with X since before X11 has opinions on the design, it is likely well informed.

I think very few people involved underestimate the work involved to replace X, and that it is going to be many years before it is somehow done.

Well, if the protocol is fundamentally broken there's no way to go but an incompatible rewrite.

The protocol is extensible. Nothing would have stopped an approach of having new clients signal they support new behaviour and aggressively deprecate old functionality to iterate the protocol.

The problem was not the protocol, but that the Wayland devs explicitly wanted to throw out a whole lot of functionality people actually depend on without having put thought into replacements.

> It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues.

Many seasoned Xorg developers work on Wayland. All the decades of lessons form Xorg _were_ carried over to Wayland.

Many of the lessons are being carried over no doubt. Others are embodied in the heads of people not working on Wayland or in the codebase itself as emergent properties from interactions never consciously designed.

There will be some loss of lessons with almost no doubt.

>> Many seasoned Xorg developers work on Wayland.

All of them are either working on Wayland or moved on. There are no Xorg developers.

Who is downvoting this and why? Face it, Xorg is on life support. The only patches it still receives are Xwayland-related fixes.

I don't expect a stable application to receive many patches. How many patches do you think Xorg should receive nowadays and in what areas?

There are a ton of long standing security issues. Which is why they are working on wayland: X11 isn't possible to secure as bad security is part of how it works.

My desktop is not a smartphone where I download random shady apps from an app store. I don't need any of the "security" wayland offers. If I don't trust some software I simply won't apt install it.

You are not the only user.

I am the other user like him. Where are your imaginary users?

X isn't stable

No. That's exactly what I'm saying doesn't happen with a rewrite, ever. You think you take all of the knowledge with you, because after all, you wrote the thing so you know how it works. But it just doesn't work that way. There is too much complexity to carry around in your head.

I'm sure many lessons from Xorg were carried over to Wayland, but "all" is an insane exaggeration. And I'm sure many new mistakes were introduced. It's inevitable with any new system.

too hardline. progress is possible in this world. software is complex but starting with better sorted fundamentals counts for a bulk ass ton of the marbles.

> It's the sort of thing that seems attractive to junior developers

You make it sound like Wayland has been pushed by some script kiddies, when in fact the lead developers on Wayland are the actual Xorg maintainers.

To me, the migration from X11 to Wayland looks similar to the switch from DOS-based Windows to Windows NT. At the time, lots of programs were broken by the move because they assumed you could meddle in other application's internal memory. But breaking those applications was not malicious intent on the side of the Windows devs. It was a legimitate move towards a more sustainable architecture. I'm not intimately familiar with X11 internals, but my read of the situation is that X11 just exposes too many internals in its interfaces, and therefore it becomes increasingly impossible to adapt it to contemporary needs (in this case, application sandboxing).

> when in fact the lead developers on Wayland are the actual Xorg maintainers.

Daniel Stone[0] incredibly funny and educational talk[1] from 2013 could help many critics who missed the 3 decade long ongoing discussion of why X is bad. We've talked about this already in the mid 90ies (when there were no alternatives) and now 8 years after this popular linux.conf.au talk, people still having troubles understanding why X has always been a terrible tradeoff for both security and performance (well for literally everything).

[0] https://www.fooishbar.org/about/

[1] The Real Story Behind Wayland and X https://www.youtube.com/watch?v=RIctzAQOe44

edit: BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?

The talk was interesting but it also shows how the speaker is a little deluded that everything turns around technical quality of code and developers. X is used and preferred by many users and application authors because it is the standard and it works.

> so what is the 1 thing X does, and what is it doing well?

It provides functional and well-established(accepted standard) graphics server technology/libraries for any application that uses graphics.

I don't care if it takes 10 liters of blood to compile one version of X or whatever. I'm a user. All I care is that my desktop works as robustly as did it yesterday or 5 years ago. If that's not happening, I'm not interested in macros, classes, variables, declarations, structs, or any other geeky CS technobabble. That's irrelevant. And a product that advertises itself as being created to be convenient for the people developing it is a paradox. Don't develop it, then. Makes things even easier.

-- from https://www.dedoimedo.com/computers/fedora-25-wayland-vs-xor...

Yes and no.

Application sandboxing is not a need I have or one that I want my display manager to solve.

But incompatibility vs the architecture disallows features like screen sharing, automation or accessibility means I will not ever have it installed anywhere.

I can't tell people want to do, but those features seem very "contemporary" to me.

Perhaps it's because I use linux as my work desktop. I suppose if this is the feature I should just migrate to OSX.

Because I need video conferencing. I don't need a sandbox. I already am selective about what I install and most of those things aren't even desktop applications.

> I already am selective about what I install and most of those things aren't even desktop applications.

in X any application can turn into a keylogger, and you don't need a GUI for it, as long as the program can "speak X" it will be able to read the shared memory of all other programs the X server manages.

Yeah. But that's a company risk.

Not being able to participate in video conferencing and desktop sharing is an employment risk.

Im a picky person though. I already use i3, but also have NVidia gpu's. I don't mind spending some money on another real GPU (will it work with AMD).

I understand the frustration of the developers too. But screen sharing or my custom screenshot tool.. are things that will make me recompile if needed for days before I give up and abandon linux for the desktop.

I realize I'm spoiled, but I do wonder if this is the direction things are going who is going to be that hypothetical user that cares?

I run 4 applications: Chromium, Xterm, Gimp and IntelliJ. Am I unsecure?

You don't need application sandboxing from your display manager. I at least, do want my display manager not to break all other application sandboxing.

Exactly! I laugh at this petition because nobody is maintaining X.org server right now or even wants to touch it. Last major release was iin 2018. It is a nightmarish cludge. Nobody is forcing anyone to upgrade their software but the rest of us want a future without X11.

It's not just the internals of X11 that are the problem, it's that the entire concept was baked in a different time. The major innovation of the X11 server was that, well, it's a server. It can be completely decoupled from the client, even physically if you use it over tcp. That was kinda nice, but then came GPUs, and direct rendering. The name of the game is now violating every single abstraction that stands between a userland app drawing directly to the display with only a GPU and a single graphics api in between. It was definitely not junior developers who rewrote the entire kernel graphics stack to move from frame buffers to direct rendering.

Computer graphics are pretty tough if you think about how many bits/s are being transferred to your 4k display at 60hz and how little latency we will tolerate. It's not like network data where we can afford to encapsulate it five times over and abstract it and forget about the contents.

Any criticism of Wayland should be with regard to what is next. Hell I'm not even convinced we need a display server, let's talk about that. I'm not going to take anyone seriously who says X11 is better, and because of a few insignificant issues like taking a damn screen cap (really? and that works fine now btw).

And by the way, that whole "never rewerite software from scratch"... that might be what they teach you in your startup accelerator or your CS classes, but in the real world, hardware changes fast, your clients change fast, and you will do well to start from scratch sometimes when fundamental assumptions change and you no longer want to support legacy hardware or legacy features that slow you down and everything can be drastically simplified with your new assumptions in hand.

Take for example, Mac OS 9 -> 10. Complete rewrite. One of the best decisions in computing history. And especially relevant here because the display server was one of the babies they threw out the window or whatever, and the quartz compositor was born.

This is not a rewrite. It's a new product that has overlapping functionality with X11.

Rewrites don't work when the following two statements are both true:

- the rewrite should achieve feature parity at a higher generaly quality

- the people who're doing the rewrite don't have most or all the knowledge that people working on the legacy system had (this could be written docs, automated tests, or just actual people hanging around)

Let me tell you an anecdote: A big, old, crusty online retail company wants to bring their web shop up to par with the competitors. Due to many years of technical debt, feature development speed has come to a halt and it is determined that the web shop must be rewritten to remain competitive. Over a period of months, requirements are gathered from user focus groups and all the employees who maintained the content on the previous shop. Development starts and 3 years later, still not having implemented all the requested features, the project is deemed a failure. Another 3 years later, a new consulting company is brought in to attempt to realize the project. But this time, instead of trying to replace the old shop, a completely new shop is built iteratively and independently. Domain experts in the company complain: there is no way to review products, they can no longer put text wherever they want in the shop and users have to call the hotline to unsubscribe from newsletter because there is no settings menu. Still, the new shop is already outperforming the old one, despite having far less features. It turns out that many of those features weren't needed after all.

The lesson here is that writing a direct replacement system rarely succeeds because the new system will hardly be able to implement all the features in a reasonable time. Instead you should take a step back and develop a completely new system that follows actual user requirements and gets rid of all the dead code.

Everything you said is correct. But, there are surely cases where even though rewriting everything from scratch almost never works, the status quo doesn't work either.

I'm afraid that's where the Linux desktop is today. Linux as a platform actually sucks for running "untrusted" software. And "untrusted" doesn't just mean proprietary games. It also just means "can I please run the alpha version of this cool open source project without being afraid that it'll fuck up my whole home directory?"

Android does a hacky thing where each program is its own "user". But then, having multiple (human) users is confusing (I don't know how Android does this, actually).

I don't know if Wayland will succeed. In fact, I'm rather pessimistic about it. But I'm also pessimistic about desktop Linux "succeeding" (staying reasonably useful even to nerds) if Wayland doesn't.

Android does a thing where it has its own display stack and very strict sandboxing so X11 isn't really a thing :)

And for the sandboxing it uses SELinux which is available on desktop as well. It's just a royal PITA to configure. This is why many people don't bother with it. But in a highly restricted environment like a smartphone it's a lot easier.

I wouldn't call that a 'hacky' thing, it's just using it in a very different environment.

The Android thing was a bit of a tangent. I did know that it doesn't use X.

The point was intended to be that Linux is becoming more and more lacking as a personal computing platform, relative to the gains elsewhere in the space. The display server is one part of that- the entire user/group permission model is another part.

The part of Android that is "hacky" is using a separate user for every app. That's obviously not what the Linux/Unix guys had in mind for the user mechanism, thus it's a "hack". It's not necessarily a bad thing and it's totally hidden from the UX of your typical Android user, so it's fine. Just interesting.

> And for the sandboxing it uses SELinux which is available on desktop as well

I used to think that, and then I started using Fedora. They have put a lot of effort into their SeLinux policies. I do all sorts of things with my workstation and very rarely have to care. In the last 6 months the only thing I have had to do is add ":z" to a bind mount running a podman container so that labelling happened correctly.

It doesn't ?

Maybe we've worked on different projects, but sometimes the legacy is just that things were done differently in the past, and the APIs available were crap.

>It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues.

The Wayland developers are the same people who have been building all these workarounds for xorg for decades. This isn't a new thing coming out of nowhere. When the old guard is telling you that their own work needs to be replaced, I'd listen.

>Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.

Good thing nobody forces you to use it and it's just one click away on the login screen from switching to xorg. In the meantime people who want to hack on the project can do so and ship their changes to users to test them plus those who do suffer from xorg issues( because yes, xorg doesn't do well on a lot of things that aren't even that modern despite all the workarounds for the "real world" issues it has) can use wayland right away.

> Reducing technical debt by rewriting everything from scratch (almost?) never works.

Agreed but this is one of those "almost" exceptions.

1. Is the code built to 40+ year old requirements, many of which are irrelevant today?

2. Is it hard to make it work for today's requirements without widespread fundamental changes?

3. Is the code a huge pile of foo that's damn near impossible to navigate, much less understand, much less debug?

4. Would a hypothetical program that solved today's requirements (with an architecture where the most important backwards compatibility features could be hooked in as needed) be smaller, simpler, and easier to maintain by newcomers?

If the answer to all of the above is "hell yes!", you might want to think about a wholesale rewrite.

> Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn.

Problem is, ever so often what should reduce technical debt ends up also reducing "technical assets" even more.

Firefox is a perfect example of this, they reduced technical debt by selling of so many features that it was sometimes hard to see a single unique selling point except not being owned by what I think is the worlds largest data miner (and quitter)!

For someone who used to use and advocate Firefox this hurts.

What is left is certainly better than Chrome on a number of points (except being bug compatible with Chrome) but the differences are now so small on every point except "not being owned by Google" that they are hardly visible to non tech folks.

Edits: a bunch above, mostly to soften and clarify. Also:

IMO the current management at Mozilla inherited a fortune of goodwill, a best in class web browser and significant tech debt.

They supposedly traded goodwill and features for reduction in tech debt but a few years later I suspect they squandered most of it on coolness because if there was less tech debt now, some of the old features should now be trivial to add back.

Firefox has treesyle tabs which has zero good alternatives on chrome. Tridacyl, vim like bindings for your browser + ability to bind javascript or native shell is more powerful than chrome alternatives. Chromium is losing google sync and chrome and chromium are Effectively destroying adblocking sooner or later courtesy of manifest v3.

Ublock origin and treestyle tabs alone make a compelling case and are visually and functionally distinctive.

Tridactyl is extremely quircky due to the limitations imposed to Web extensions though. I remember good old Vimperator to be more reliable.

I get why they did it though, allowing extensions to effectively take over the browser sounds like a recipe for disaster. Too bad there isn't a way to opt into it when it's actually what you want.

I'm experimenting with Pale Moon now.

It actuall feels snappier than the latest Firefox, but a profile reset on my main Firefox might change that (traditionally with my usage patterns there's little improvement to be seen from that.)

So for now the advantages of Firefox vs Chrome are:

- not Google

- less RAM usage

- slightly better extensions

And for Palemoon vs Firefox:

Pro Palemoon:

- snappier (?)

- extensions work

- looks better (subjective) and can be skinned

Advantages Firefox:

- more secure (maybe, Palemoon unlike Mozilla doesn't have a history of abusing extension bundling for various promos)

Firefox me robot wasn't a real threat to your security whereas security holes patched in firefox but not palemoon certainly are.

Your browser is your number one vulnerability and you have selected poorly.

https://www.howtogeek.com/335712/update-why-you-shouldnt-use...

> and you have selected poorly.

Note that I write "experimenting with".

I'm fairly aware that my browser is the main vulnerability, thank you, which is why I run different (mainstream) browsers for different sites already and actually want even more lock down for certain use cases than what IT currently privides.

I'll also add that in the last 20 years I've had one infection on a machine that I alone used (a drive by exploit in a banner ad on a developer blog I read) so a combination of carefulness/paranoia certainly helps ;-)

And no, I'm not suggesting anyone should uncritically download a random browser and start exploring the dark corners of the web.

Also: I agree, the robot thing was harmless, but that said: do you remember Superfish? The little thing that Lenovo added to their laptops? Which turned out to be a giant easily exploitable hole?

As for the robot extension:

- when I noticed it in between my own extensions it scared me quite badly until I managed to look it up

- companies that does such things aren't trustworthy. The robot thing was harmless. Superfish wasn't. Do you trust marketing executives to know the difference?

Its a garbage product run by heinously rude people

https://github.com/jasperla/openbsd-wip/issues/86

If you run it you are choosing poorly

It's limitations aren't really quirky it's extremely predictable that its bindings doesn't work on special tabs example reader mode

TreeStyleTabs absolutely work but is crippled compared to what it used to be.

In fact I asked yesterday and it was an interesting experience: https://bugzilla.mozilla.org/show_bug.cgi?id=1332447#c170

You can get rid of the top tab bar is your user css file other than that it seems kind of identical in functionally to me save for the keybinding gui for it being in a different screen under extension bindings if I recall correctly

Yep. Only Mozilla makes it harder year by year. Here's from January last year, another hoop to jump through: https://github.com/piroor/treestyletab/issues/2450

For all the talk about UX, why cannot someone be bothered to sit down and talk to the actual people who use the product and ask what the ux problems are?

At this point is there anyone left using Firefox except stubborn power users like me?

Sometimes things don't need to be feature packed and is a negative

The author obviously hasn’t tried plugging a high dpi monitor in to a laptop if they don’t understand what’s wrong with X. Wayland solves so many of my problems and so far the only thing it breaks is screen capture in electron apps. And not even all electron apps. Discord has no problems.

> The author obviously hasn’t tried plugging a high dpi monitor in to a laptop if they don’t understand what’s wrong with X

This is the only actual, honest, problem that I've ever seen about X. Still, it does not seem a really fundamental problem, it must surely be solvable from within X? Do we really need a full-rewrite of X, unstable, with new bugs and less functionalities? (many of us don't use "desktop" applications and it will break screen capture tools, and other things that are dear to us like xwit, xdotool and the like). Just for that silly mixed-resolution screen problem? I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.

The problem has been crippling the Linux desktop for many years now and it still remains unsolved in X which must indicate that either it is not realistically possible or it is so much work that no one is willing to do it and likely never will.

The transition to Wayland is largely finished now. Electron added support last year and eventually the last of the electron apps will update and everything will be done other than nvidia proprietary driver support.

There are so many minor improvements from wayland that are less noticeable like the lack of screen tearing, the possibility of sandboxing apps.

Wayland has existed since more than 10 years and it has still not been able to release a usable system. I'm not willing to lose things that I use everyday just because some idiots want to move their windows between screens and see that they don't change their apparent size. Seriously, this is not a crippling problem. You can easily change the size of one program once it is on the desired screen. What kind of savage keeps moving their windows through different screens?

>Wayland has existed since more than 10 years and it has still not been able to release a usable system.

Fedora has has it on by default for about 4 years now and its perfectly usable. I use it every day.

The problem is much more serious than you are explaining. While using X, on my main monitor, UI and text becomes so small I can not even read it or click the icons. I'm not talking about the window size, but the UI and text size. With wayland the app can switch from 200% scale to 100% scale as it crosses the window border. On X you must pick either 100% or 200% and stick with it on all monitors.

My display scalings aren't 100% and 200%, however. They're 125% and 160%.

Can Wayland handle this? If not, what's it really solving?

> Can Wayland handle this?

Yes.

You think that having to close an application in order to move it to a different screen is no big deal, but you think that wayland is lacking critical features? Features more critical than being able to move windows freely?

I really am curious what features you think wayland is lacking. I've been using wayland for years, both using Sway and Gnome, and the thing I've missed the most is xdotool, and perhaps there will be a standardization effort to replicate its functionality securely, but for now it's an understandable omission.

Maybe it's not fair to say that X is broken for mixed-DPI configurations, since I have managed to get it working with X, but it was quite unreliable, whereas on wayland it just works, save for some incompatible electron apps.

> Still, it does not seem a really fundamental problem, it must surely be solvable from within X?

X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable.

Or you can do, as the Xorg does: use multiple screens on a single display. Here, the limitation is, that all screens have to have same DPI.

Neither of those are acceptable for modern display server.

> it will break screen capture tools,

It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Just like it is unacceptable to integrate user address book to your app by going through its internal files, it is unacceptable to screen grab by snooping windows of other apps. In both scenarios, your app must go through API, which puts the user in the control, whether the app is allowed to do that. Wayland enforces such protocol for screen grabbing and input handling; those app who do not bother... well, the train will leave the station without them.

> other things that are dear to us like xwit, xdotool and the like

Same as previous, but for input handling.

> Just for that silly mixed-resolution screen problem?

No, there are multiple problems. For another, surely you would like screen lock that doesn't flash your desktop on unlock?

> I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.

See even here on HN, it is important for many. Just few days ago there was a discussion under article about i3 and how to drag it into hidpi world in 2021. On the other hand, the mainstream user doesn't even know why they would use xwit, even if they knew it exists.

> It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them.

Don't want to derail this discussion anymore, but this argument is nuts. If you are so concerned that programs that you run can spy on other programs that you run, how do you deal that the fact that all of these running programs have full read-write access to all files on your $HOME?

EDIT: I agree that being able to run selected programs inside a sandbox would be a good thing (maybe even all programs). But attacking the problem of visible display before that of hidden files seems ridiculous. Moreso if it cripples copy paste, screen capture, and similar basic stuff (which to me are just like unix pipes: ways to make programs work together!)

> t all of these running programs have full read-write access to all files on your $HOME?

They don't necesarilly do; if you are running flatpak, chances are that they don't.

For example, there is a flatpak for MS Teams. For application like this, you want it to be able to share your screen, but it doesn't have any access to your $HOME (in this specific case, only to ~/Downloads).

More importantly, if you want to tight up your desktop, why do you criticize something that starts attacking it from one angle, that it is not 100% solution? It is not; others are working on the other angles, and then together it will be the 100% solution. In this case, Wayland is only one piece of puzzle, not the entire puzzle.

> [Xorg] limitation is, that all screens have to have same DPI.

The limitation is not true. Yes, the core protocol gives you a single, global DPI value. However, who cares about the core protocol? You have XRandR, which gives you a per-screen DPI. Alternative, you could have a freedesktop standard/convention where the DPI is stored as a global property of the root window, in a array of values, one for each display, so that you can override them.

Problem solved! I am actually running Gtk+ slightly patched to support that... trouble is, most of the toolkit is hardcoded to assume a fixed display or even process-wide global DPI, or at least it was when I last looked at it. Dunno what they did for wayland.

I really don't understand why we need to throw away an entire 30 years of software development just because the current property for storing the DPI only has space for 1 value instead of 1 array of values, one per monitor. Just use a new property.

> Problem solved!

Not so fast!

Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol.

How the compositors are supposed to handle that?

If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years of development by making it unusable anyway.

How are you going to change those decade old binaries to work with Wayland??? At least if you don't throw X11, those decade old binaries still work. If you throw X11, they will not!

You need to put in some type of kludge which is the reason this article exists in the first place (e.g. copy paste will work randomly).

And if the toolkit is linked dynamically, you are very lucky... Not to mention that a more realistic scenario is that you have to update a 20 year old toolkit to support multiple DPIs, in which case it is much easier if you just have to read the property from a different place rather than having to target a different display protocol entirely. You made the program vendors life easier at the cost of making yours harder...

With Xwayland. On hidpi display they will be upscaled and blurry, but at the right size and they will work in the first place.

Even window grabbing will work, albeit only with other Xwayland clients.

Xwayland is the kludge I was talking about (and this article).

No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs

X11 is the kludge. Xwayland is the symptom. If anything, Xwayland is too nice and too seamless; it should get Xquartz treatment.

The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, which is which, which needs to be scaled and which doesn't. So Xwayland lies to them all about real dpi, and upscales everything.

For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years ("it works in the current Ubuntu LTS, we are fine, no need to add anything").

> The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. I

Just make a new property, and make those DPI-aware clients set it!

You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". This would be trivial to write in X11, but becomes again Mission Impossible in Wayland (you have to edit every display server -- Gnome's, KDE's, etc. -- in existence).

> For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years

Yes, exactly. But it is going to be much harder to make anyone support Wayland within the next 10 years, since it brings its own share of problems and because of "the devil you know". E.g. can Firefox already screen grab from Wayland these days? From non-Gnome Wayland? Will Zoom ever do it? And work with any Wayland display server other than Gnome's? It is a mess, and has been so for a decade already. And that is why we get this article.

> Just make a new property,

That's the easy part.

> and make those DPI-aware clients set it!

That's the difficult part. You are welcome to try, though!

> You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it".

Yes, another hack to keep on piles on other hack. Why would anyone want nice, clean solution, when a hack does?

> E.g. can Firefox already screen grab from Wayland these days?

Firefox can do screen recording/screen sharing under Wayland these days. Hardware encoding for WebRTC is in the works; that's something they would not be able to efficiently do under X11 at all.

> Will Zoom ever do it?

That's the question for Zoom. If we kick them as Apple does, they will. If we lay down and keep piling hacks on top of other hacks, they won't see the point.

> And work with any Wayland display server other than Gnome's?

That's a question you have to ask the authors of any Wayland display server other than Gnome's.

> It is a mess, and has been so for a decade already. And that is why we get this article.

It is a mess, because some people are too hung up on their current ball of mud and cannot see further than their personal desktop. Then they write articles like this and try to drag down others to the level of their ball of mud.

> That's the difficult part. You are welcome to try, though!

I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack" (despite the fact users likely want to do this, as evidenced by Windows offering this setting); but on the other hand throwing everything away and changing everything to support an entirely new display server protocol with its on set of problems is ... a nice, clean solution?

What I see is another manifestation of the "backward compatibility is a hack" mentality. Well, this annoys me to no end, but what can I do.

> I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, but changing them to support an entirely new display server protocol with its on set of problems is ... nice, clean solution?

Because if it was just setting a new property in a toolkit, we would not have this discussion now.

Ultimately, it is not just that; if it were, all clients would be Wayland native already as the toolkits have had Wayland backends for years.

It is just setting a new property. The discussion here I thought was what is required to distinguish a client that is DPIaware versus one that it is not, for use by the compositor to decide whether to scale it transparently or not.

It's not just setting a new property. Meanwhile, today, you have clients that are dpi aware and are not setting the property. And they all will be out in the wild for an undetermined amount of time (because stuff works for the application developers, why bother?). If you do not handle them anyway, your users will complain that your desktop is broken.

It is just setting a new property. I am not sure we're on the same page here, but if your existing client is DPI-aware, and you just want to let the compositor know it, then it is a one-line change in your client.

As for the "Meanwhile" part, again, how is that better with a new display stack? Unless the point here is that it will be better to just break all those (DPI-aware) clients unconditionally, rather than actually offering them a way forward that does not involve targeting an entirely new display server API.

Because that "meanwhile" takes years. There are still clients that use libX11 ("it works for them") instead of libxcb. libxcb was introduced in 2003.

So "meanwhile" you would have apps that are not DPI aware without flag, DPI aware without flag and DPI aware with flag. And even crappier desktop as you have now for years to come.

The new API is not just for DPI; it is for many reasons, DPI is only one of the issues.

> I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack"

Most issues could probably solved by a variety of hacks. Several issues that don't concern yourself couldn't. The problem is that X consists of 40 years of hacks piled up on each other. THe X.org devs actively chose to stop further development and continue their work on wayland.

You are on the same side as the people bemoaning IPv6 and asking why we couldn't just use one of the unused flags in IPv4 to solve the address depletion issue. It sometimes makes sense to make incompatible changes.

> Hardware encoding for WebRTC is in the works; that's something they would not be able to efficiently do under X11 at all.

And this is a not true, as evidenced by the fact even software ported from Windows (OBS) does it.

I specifically qualified it with efficiently. As in, when the surface is in the GPU memory, the software doesn't have to read it over PCIe bus and then put it back into another buffer for the encoder; but that the encoder can do zero-copy encoding in the GPU memory.

Here, Firefox uses dma-buf. Unless X11 exposes a special extension for exposing dma-buf, your client won't be able to do that.

You said it yourself. I even believe that extension already exists since it must be going on inside DRI3 for some EGL/VK extensions to work right now. Don't think it worth to create an entirely new display server API for just this.

And in practice, XShm-using OBS actually works better right now than this specific apparently Gnome-only dma-buf API. https://www.youtube.com/watch?v=kD70ur_xTmE

dma-buf is linux-specific, not Gnome specific. It is buffer management on GPUs; it is the low-level API that Mesa and libva, and yes, DRI too, build on top.

Just because some specific application works better (for some values of better) on the Xshm does not say anything. In year or two, the situation can be very different, permanently.

> Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998?

The same way Apple handles a PowerPC-compiled application from 1998.

By incrementing to a new major version number, and stating in the changelog that users are free to keep running the older version if their software won't be patched.

Does Wayland provide a better solution than that? No, and in addition it also breaks a lot of newer applications. We don't need to do a lot of math to figure out more people would miss Xorg than Wordperfect.

> The same way Apple handles a PowerPC-compiled application from 1998.

It doesn't handle them at all. There was a transition mechanism, to get users updated, but it wasn't maintained long term. You could not run PowerPC binaries from 1998 in 2005.

Apple expected their users to update the binaries for new architecture in the long term. In many cases, not only ISA and ABI changed, APIs too; good luck if your application used Quickdraw.

(Yes, I still do have coasters in the basement).

So compared to that, Wayland's Xwayland is too nice and too longterm.

I think that the reasons go beyond this one issue, tbh.

I've never used xwit before, but just looking at the description, I believe at least under sway the same should be achievable using sway's ipc protocol (I wouldn't be surprised if other compositors have similar options).

I think the difference to xwit is that it does not work across windowmanagers/compositors, because much of what X11 used to do is now the job of the compositor, but I assume the users who script xwit likely also have a very tuned windowmanager, so it's unlike they switch window managers all the time and they could therefore just tune their environment for the same functionality as xwit.

I believe if you want linux to be competitive as desktop OS you need to cater for the average user. I would wager that need for multidisplay support is much more common than need for xwit, no?

This is not the only challenge

What do you mean by high DPI monitor? I have a 32" 4K monitor, is that high DPI? It works perfectly in X for me.

I don't see any screen tearing when moving a window fast across the entire screen either, if that was the concern.

I also could set up large enough font sizes in cinnamon and browsers.

The laptop part is important. Your laptop likely has a 1080p screen which needs to be at 100% scale while 4K monitors usually need to be at 200% scale. X does not allow this.

X does allow this, but it needs cooperation from clients, which in practice means that Gtk and Qt need to implement it, and they decided to only implement this for Wayland (which also needs clients to implement this!) because for them, X is dead and not worth supporting. It's not a problem of X per se. It's a deliberate decision to not implement a feature for X.

Save the obvious distance, I kind of see a bit of similarity with the Python 2 to 3 transition; it breaks downstream programs and processes that shouldn't break.

Another similarity I see is that Xorg is like the Linux Kernel of GUI applications. Ideally, you just shouldn't break "userspace".

I agree that some stuff is definitely broken in Xorg, like High DPI setups. But I also believe that's no reason to break a myriad other setups that are working well, right now.

This constant "1 step forward, 2 steps back" (from the point of view of the final consumers, who really only care about the result, and not the means) is so common in the ecosystem of GNU/Linux based O.S. It's also why I see the mantra of the Linux kernel so utterly fascinating and inspiring. It takes real work to build something and keep it working for decades with a minimum of breakage; starting from scratch looks then like child's play in comparison.

I guess the problem is the same as always: money. In a parallel universe where Xorg is at the base of Windows, Microsoft would just throw millions at it to improve the architecture and fix issues, while at the same time trying to limit breaking changes as much as possible... but that requires willingness to do it, and deep pockets.

Exactly this: Wayland solves no issues I have

(It is very similar to systemd, and the motto on page https://nosystemd.org/ that is what I think about systemd also: If this is the solution, I want my problem back.)

If one doesn't use multi-GPU setups or high DPI they don't need Wayland, yet (later they will either have no options (like with systemd) or will buy better screens).

For me e.g. I don't know if I have a problem that Wayland may solve - I have not issues with Xorg, I don't like using more than one screen (I forces me to move my head left-right, I prefer single large screen, with full sized window) and I don't have high-dpi screen (I think, at what DPI does it start? My laptop has full-hd with 14", so probably not).

But later when such high-dpi screens will be the norm it would be nice to use them.

I feel the same. Xorg just works. My dev machine has intel onboard gfx with two screens attached and an old gefore 8 (I think) to drive a third screen, using nouveau. Zero config required, X just combines them as if it were one card with three outputs. Wayland? No chance. Screen sharing in Jitsi in Firefox? X doing just fine, Wayland not a chance (using Sway). So X just works fine out of the box no matter what, while Wayland is a broken mess that reminds you of X 15 years ago. Oh but Wayland solves screen tearing, which I guess would boost my productivity while coding by 500% so maybe it's worth the hassle.

Notice that you can use hidpi screens with Xorg and it works perfectly. The only problem occurs when you mix screens with very different pixel sizes on the same display and you want to move windows between these screens.

Also, mixed-DPI works pretty well here on X. I just scale my low DPI displays at 50% with XRandR. It looks just as good as on Mac.

This only works for people who don't care about precise font rendering, either because they just don't care, or because their visual acuity is bad and they simply don't see the difference. (People who arguably don't really need HiDPI displays in the first place.)

As a complete outsider - ok, I'm a developer, but I haven't had the pleasure (?) of writing something that interfaces directly with Xorg yet - I have been reading for years about Wayland being the way forward and how Xorg is dragged down by a long history of dubious design decisions and features nobody needs anymore, and I was secretly wondering: if this is really the future of desktop Linux, why doesn't it gain more momentum?

This post is a bit too ranty for its own good, but it has a valid point, and one that is unfortunately common in the open source community: because you have no monetary obligation to your "customers" (=users), there's not really a lot that forces you to maintain backwards compatibility. And because a Linux distro is made up of thousands of applications, many of them not in active development anymore, changing such a fundamental component (without providing a "compatibility layer", which I have no idea if it would be even possible) will break a lot of applications that may never be "fixed".

>if this is really the future of desktop Linux, why doesn't it gain more momentum?

Nvidia is the major blocker here and there is very little wayland devs can do to fix this. Fedora has actively discouraged using the proprietary nvidia driver for a while now and they ship wayland by default since the open source driver works fine. I saw that ubuntu is also shipping wayland by default soon for amd and intel users.

How is the open source driver when it comes to compute and 3d gaming?

Just interested if it works OK.

Its extremely slow and does not support CUDA. I think the problem is nvidia blocks them somehow from changing the clock speed on the gpu so it gets stuck running in its slowest speed.

That's a shame, I enjoy playing with ML so having no CUDA available is a bit of a showstopper there.

For graphics I'd like to switch to AMD, but right now you just can't buy their higher end consumer cards.

To be fair you can't buy any 3000 series Nvidia card either.

Quite true! Let's be balanced about it.

In this case I already have a 2080Ti, which gives my previous comment context. If I was starting from scratch then, well, I'd be stuffed either way :)

> Nvidia is the major blocker here and there is very little wayland devs can do to fix this

I know, but it can be difficult to understand. I mean, how come we currently have Nvidia drivers for Linux, which work pretty well, and they can't be used for Wayland?

Because the entire linux graphics community uses the same API (GBM) and wayland is mostly built around that, but Nvidia insists on not using it for some reason.

As I understand it, they’re not allowed to use it - the APIs are GPL only. They would have to open-source their entire driver.

Yes, but why is it not a problem for X.org? Can't Wayland be made to work using whatever Nvidia is currently providing? I guess I read it is, and even something (KDE maybe?) made it possible to run Wayland under proprietary Nvidia, so I don't really understand what's the problem.

Aren't GTK and Qt the compatibility layers for most applications?

How does the OS move forward then? When is it appropriate to say "this is so badly outdated that we need to throw it away and move to something new"?

> This post is a bit too ranty for its own good, but it has a valid point, and one that is unfortunately common in the open source community: because you have no monetary obligation to your "customers" (=users), there's not really a lot that forces you to maintain backwards compatibility.

And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then considered as it works, we don't have to fix anything, Ubuntu will keep things broken for us. Due to this attitude, they have slowed down Linux desktop by years, by not switching to Wayland by default in the past LTS release.

Compare with Apple: in the same timeframe they've deprecated and removed support for entire architecture (i386) while Ubuntu just thinks about doing one step. Apple breaks compatibility at much faster rate than Linux world, and everyone is fine with it. The difference is in signaling: Apple decides and does. In Linux world, we have articles like these, that try to slow down everyone.

I don't know if everyone is fine with Apple making so many changes. I think it's because they have no choice, being stuck with whatever Apple decides.

eg. for years you couldn't resize a window from the left edge and everybody was "fine" with it. When they actually bothered to implement it, it was astounding to think you couldn't do it before!

As for me, I await each Apple release with trepidation and fear.

Will my audio hardware continue to work? (They break the utilities most releases).

Will I need to buy a new version of Parallels or VMWare because Apple changed the virtualisation API? (This happened a few years ago).

Will my apps no longer work? (Goodbye useful 32 bit apps that I can't find a 64 bit version of).

Will they just break random things? eg. PDF viewing, Quickview of multiple files (both of these happened to me).

Will they change random things for the sake of it? eg. Giant spacing between icons on the menubar on Big Sur. Behaviour of the maximise button into "full screen" button just because they could (a few releases ago).

Will my machine be slower for no apparent reason? HFS+ to APFS makes my machine start up TWICE AS SLOW.

The best bits are due to the Objective-C message passing, old apps will make a "call" to a function that no longer exists and it won't break - it'll just do nothing. You literally have no idea if your app will continue to work between releases, even if it runs and the certificate for the app hasn't expired...

And I say this as a daily user of macos! It just isn't reliable between releases.

My point is exactly as yours; it was addressing comments as the GP one, where the FOSS community is being shown as the one constantly breaking compatibility, while commercial vendors are being shown as example worth to follow. My example intended to show exact opposite -- I'm also Mac user (Windows user and Linux user too), and while I understand the rationale for some steps (i.e. deprecating i386 was in order to not overly complicate Rosetta2), it doesn't mean it won't hurt the users anyway.

I abandoned Mac OSX for Win 10 (manager half of brain) and Linux (dev half of brain) years ago.

It got really tiresome rebuilding my dev environments in particular with every new release. Butterfly keyboard, touch bar, and other hardware choices were additional hindrances. Infuriating design choices like doing away with 'Save As' were the last straw. I don't really care about UI improvements, to be honest. OSX Leopard was usable for everything I do in normal life.

I forgot the "Save As" removal! I type this on a Macbook with an irritating noisy butterfly keyboard where the left shift key works 40% of the time and I get duplicate "i" inputs periodically, with a touchbar that has a fault so the F12 region is constantly flashing in my face...

I remember Snow Leopard being a deep joy to use.

>And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then considered as it works, we don't have to fix anything, Ubuntu will keep things broken for us. Due to this attitude, they have slowed down Linux desktop by years, by not switching to Wayland by default in the past LTS release.

How can you complain about Ubuntu LTS keeping Xorg as default in an LTS when RedHat itself had Xorg as default at that time. Isn't this hypocrisy or irony? (same thing of idiots complaining about upstart being shit while RedHat and Goole were still using and supporting it.

IMO let RH use Wayland as default for a few years , then hopefully they can't ignore user bugs and fix them.

> How can you complain about Ubuntu LTS keeping Xorg as default in an LTS when RedHat itself had Xorg as default at that time. Isn't this hypocrisy or irony?

RHEL8 uses Wayland as default. RHEL8 was released in May 2019. Ubuntu LTS was released in April 2020. What hypocrisy you are talking about?

> (same thing of idiots complaining about upstart being shit while RedHat and Goole were still using and supporting it.

Redhat uses systemd since RHEL7; Upstart was used in RHEL6.

Story time: Redhat management didn't see the point of systemd originally; Poettering did it in his spare time, and Redhat management has seen the point only after Fedora and Arch adopted it. Meanwhile, RHEL6 was already deep into its release cycle.

So did you check the show stopper bugs that Ubuntu found? or they should ignore the bugs to please RH and it's fanbase ? Maybe the next LTS could profit by the fact that RH recently was forced to fix the bugs in Wayland (though not sure how many paying customers started using it yet and submit tickets for the devs to fix)

Show stopper for Ubuntu was screen capture. So screen capture works today, and if they switched, if would be difficult only for the first few weeks, when Ubuntu is buggy anyway.

But they didn't and the long-term consequences of delaying it will be felt across all linux distributions for years to come. So much for appeasing RH and it's fanbase.

I disagree, this happened before with pulseaudio, it was not ready and for years people would recommend to remove it, so the leason is not replace something that works now with something that is shiny but might work next year.

I also think NVIDIA had a role in this default display issue, Ubuntu has to use something that actually works on all hardware combinations,competent users can install and try a Wayland implementation or all of them.

There are still people who uninstall pulseaudio, because "bloat" and then harass authors of audio applications to support their snowflake system.

The forced PA brought some pain. but it forced swift improvement in audio drivers. Without it, we would still have half-buggy drivers that do not really work.

Regarding Nvidia: all distributions that switched to Wayland default switched that only for supported hardware, so Nvidia users are still getting X11. I don't expect Ubuntu doing it differently.

I still think is terrible for the users but probably great for some developers. So you would force the casual user that has no issue with X to suffer so the Wayland and GNOME/KDE developers would hear better the pain and fix the bugs and add the missing features. This is the job of bleeding edge distros to offer you the latest bugs and features.

I understand that when you work on your free time you want to work on shiny stuff that maybe you created and not on someone else old code, but for good results we see all the time that serious money need to be spend and developers need to be made to work on users feedback and not on what they like. Red Hat is pushing this, they have the money so they need to find more competent developers and do it right.

There is no split "terrible for users, great for some developers". Casual users do have issue with X; see this thread recently on HN: https://news.ycombinator.com/item?id=25970690. Would you consider that normal for users to handle?

Of course not. Casual users having no issue with X is a lie.

The fact is, that some subsytems on Linux are pile of hacks piled upon something built on assumptions that are no longer true. X11 is one of such subsystems. It is a dead end. When you are stuck in the dead end, you can either back up and once you are out, continue in your ride, or keep being stuck in the dead end.

Wayland is backing out of the dead end; yes, it is short-term, high intensity pain, when you are not going forward, and even have to go back for a while. Piling new hacks on top of X11 is trying how to continue going forward without backing out of that dead-end. You will be stuck in that place for a long time, and ultimately you will move nowhere. That is long-term, low-intensity pain. Some people do not take the long term view (or do want to avoid high-intensity pain), being stuck in a place works for them (and chronic low-intensity pain is fine to them).

These two approaches still clash, it is this https://www.youtube.com/watch?v=ZTdUmlGxVo0, all over again, 10 years later.

I agree that Xorg has issues, I disagree that Wayland was the best solution. Creating a protocol that specifies a subset of the features and then taking mroe then 10 years to get decent implementations for the subsets and then still having no unique answer on how to do global keyboard shortcuts and that pathetic delay until we got some kind of screenshot and screen recording solution...

If RH were actually competent would have had a roadmap and Xorg would be replaced with some Wayland implementation only when all X featues are ready. Until then RH can label it as Beta.

I don't like how you propose this unfinished stuff is pushed on users so maybe someone would get frustrated enough and make RH job, like WTF RH has tons of money, they could fins competent people to implement the missing stuff 10 years ago, and while at it they could have fucking fixed GTK or maybe buy Qt and the dev team .

> Apple breaks compatibility at much faster rate than Linux world, and everyone is fine with it.

That's news to me. I have yet to read or hear the sentence "removal of magsafe was a great idea", or "I love carrying around this bag of $50 USB-C adapters". Or "this touchbar sure is a gamechanger, who needs the F-row on a Pro device anyway".

> Apple decides and does.

And Linux decides not to break everything just because they got a new favorite technology. I am not sure why you complain so much about Ubuntu when you can just use another distro that does things differently. Because unlike with Apple, you actually can choose, and without buying new hardware.

Which is also the reason I'm not that invested in the whole Xorg vs. Wayland debate; I am certain one distro or another will still support Xorg for a long time, and who knows, maybe one day Wayland is actually mature enough for me to use out of the box.

> That's news to me. I have yet to read or hear the sentence "removal of magsafe was a great idea", or "I love carrying around this bag of $50 USB-C adapters". Or "this touchbar sure is a gamechanger, who needs the F-row on a Pro device anyway".

I'm not talking about hardware. I'm talking about software. How they changed the network filtering several times in last 5 years. How they deprecated and removed i386 support during the same timeframe that Ubuntu only considers switching to Wayland. Heck, my ~2015 Samsung MFP in office doesn't scan with MacOS anymore, apparently the latest driver from September 2020 is too old now. And bazillion other examples, see them in sibling thread.

> I am not sure why you complain so much about Ubuntu when you can just use another distro that does things differently.

I do use another distro that does things differently. To problem with Ubuntu is, that application developers do target Ubuntu, not those another distros. So when Ubuntu doesn't need Wayland (or Pipewire, or whatever), they won't allocate manpower for Wayland (or Pipewire, or whatever) support.

Then we get stuff like "Wayland is still broken after 10 years".

> I'am certain one distro or another will still support Xorg for a long time,

That's certainly fine

> and who knows, maybe one day Wayland is actually mature enough for me to use out of the box.

In order to mature, it has to be used by critically-sized amount of users. If you just push it aside, it will stay aside. It is not just Wayland's problem, for another example see ARM support under Windows.

why doesn't it gain more momentum?

It has plenty of momentum. The two main desktop environments have wayland ports. Several distros ship wayland by default.

without providing a compatibility layer

Wayland does provide a compatibility layer, XWayland, which runs an X server that does all the internal processing that Xorg does, and then send the final frame to wayland to put on the screen. It works very well, just with some quirks around mixed-DPI setups, which X can't handle well to begin with.

When people complain about wayland breaking their set-ups, they're talking about tools like xdotool, which Wayland deliberately does not allow because they're security risks. Old applications, the kind that put a window on the screen, rather than manipulating other applications' windows, work just fine.

xdotool isnt the only issue. FFS read the attached article.

Screen capture is a recently solved problem on wayland. Yes, existing screen capture software that doesn't implement a new backend is broken, because the X model of screen capture was fundamentally broken, and one of main goals of Wayland to fix. But Firefox and OBS can do screen capture on wayland just fine, regardless of compositor.

The gnome global menu thing is a problem with gnome's implementation of wayland. The functionality could surely work if Gnome decided to support the same standard as wlroots does for allowing custom panels like waybar. Perhaps the complaint is that wayland give the gnome despots too much power, but if you don't like gnome, then complain about gnome, not wayland.

I don't know enough about KDE or AppImage to comment on those complaints.

> It has plenty of momentum. The two main desktop environments have wayland ports. Several distros ship wayland by default.

Do they have a common screen capture and automation API yet?

Screen capture yes https://news.ycombinator.com/item?id=26000812

Automation no https://news.ycombinator.com/item?id=26000740

Though I would say that standardization of screen capture is far more important than standardization of automation, since screen capture software needs to work for all compositors, but my automation scripts only need to work on the compositor I actually use.

> But more to the point, that the problem is that moving away from Xorg as a display server really needs to happen eventually

Yeah, to a "better Xorg". The problem is people don't believe Wayland is a "better Xorg".

I don’t agree that what we need is better Xorg. Xorg was a client-server based display server design from back when bitmapped displays and their respective UIs were in their infancy. And although it was certainly good for a time, I really think the idea of client-server UI has aged about as well as Polio. Even at the time it was computationally expensive (especially compared to say, Windows basically just jamming the UI into the kernel) but now it’s just crufty, inefficient, and weird. I don’t think there are many design decisions from X11 that you really want to keep anymore. Seriously, dig into the X11 protocol, what would you want to keep? If you want it to be feature compatible, a lot of cruft is going to need to come along for the ride.

There are some aspects of X11 that aren’t so bad, especially more recent bits. Personally, I think XI2 is relatively nicely designed. But on the whole, I just don’t think what we want is better Xorg.

And for me, this is the main Issue:

belief

People are flaming and screaming about their beliefs, demonizing systemd, Wayland and what-not with FUD, baseless arguments and non-arguments, because they "believe" these things are bad and must die.

If I want to talk about what runs on my workstation as if it was religion, I install Temple OS.

If I want a modern (and basically following sane/safe architecture decisions) display protocol, I run Wayland.

The linked post is just one thing: superfluous. It helps no-one, a waste of energy and time for everyone involved.

systemd adds a concrete and substantial set of features for me. I eagerly embraced systemd for that reason - there are things I don't like about it, but it gave me lots of new benefits that justified the effort.

Moving to Wayland would force a bunch of changes on me for the sake of no functionality I care about.

That's the big difference. Given it provides no benefits to me that I care about, I won't move until staying on Xorg is more effort than replicating my current setup on Wayland, and as it stands it seems that's likely still years away.

But that's the thing though. For _you_ systemd had a concrete and substantial set of features, while wayland doesn't for many others it was the other way around. (I don't mind either, but there are annoyances in both).

The problem is that many are complaining that _their_ specific set of functionalities is no longer being catered for, or better not being actively developed. The great thing about linux is that you can do what you are doing and continue running Xorg as long as you want, it might be more work however.

Regarding your wayland would force a bunch of changes on you for no functionality, what are those specifically?

I would encourage you to try out wayland, for me moving from i3 to sway has largely been a seamless experience and I (tell myself that) see notable performance improvements for example.

The point is not that nobody sees benefits in Wayland, but that the case for switching is a lot more ambiguous. There's a substantial proportion of people for whom it is a loss of functionality or effort for no benefits. With systemd there was no loss of functionality - it is compatible enough that if you don't make use of the new functionality you don't lose anything. With Wayland, if you depend on any number of different functionality aspects, you either lose functionality or have to pick specific compositors that implement additional protocols.

With respect to my time investment, it's down to having to switch window manager. I'm using bspwm, and rely extensively on the API it provides. I could probably transition that to sway if I had to. But I have no incentive to. It gives me no new functionality and solves no problems I'm having.

So I'll stay on Xorg until an incentive appears to justify the fairly significant time cost of reworking my workflows and/or a bspwm compatible compositor arrives (there's been an issue open for 5 years, and at least one - abandoned - attempt).

The time investment required to switch also means I'd be prepared to invest quite a lot in getting Xorg running if the situation is the same down the line at a point where I can't get an "off the shelf" dpkg of Xorg.

At the pace Wayland efforts are moving, I suspect I'll still be on Xorg in 5 years, and wouldn't be surprised if I still was on it in 10.

But really, the main point of my earlier comment was that there are real, concrete reasons for people not to move to Wayland that has nothing to do with belief. It would take time I don't have to make the move, and it doesn't provide me any benefits to justify putting aside other things to invest that time. Maybe one day it will, but it won't be any time soon.

Please let’s not get on to systemd.

I haven't seen many desktop apps emerging in the last decade, so whom is that "legacy is holding back the Linux desktop" argument addressed at? X may not be the most modern architecture, but it's still the API almost all F/OSS desktop apps are ultimately written and tested against. For many apps, wayland doesn't bring a new perspective, but end of life with no new apps taking their place. For other apps, wayland means additional testing and porting effort. And wayland, like gnome and almost every other "innovation" by RedHat, brings fragmentation into the free desktop world also for BSD and Mac OS ports. Desktop app development, being starved off developers anyway, doesn't need a "Python 2" moment, that is, a decade+ long phase of transition in the name of dubious progress, or other impediments getting thrown in its way. The end result is simply that less usable software will exist.

We (desktop devs) eventually gave up on it and are enjoying our Windows/macOS/Android/ChromeOS setups instead.

It would be funny that at the point where it seems that Linux desktop hardware support is at its peak, the actual use of Linux desktop would be at its lowest. I don't think that's the case, though.

GNU/Linux gets used alright, on IoT, servers and VMs, where the desktop is irrelevant.

While Linux community can pat themselves on the back for having Linux kernel as part of ChromeOS and Android, they tend to forget it is hardly exposed to userspace frameworks used by app developers.

Chrome OS straight up lets you install Linux desktop apps. It runs a wayland compositor.

Crostini only works in some models, and follows the same approach as WSL, running GNU/Linux in a virtualized Linux kernel, completely unrelated to ChromeOS Linux kernel.

ChromeOS vNext could be based on Fuchsia and still offer Crostini.

Point is that, like Android, it eschews the typical Linux Desktop stack, because it is a garbage pile that reasonable people don't want to deal with.

> because it is a garbage pile that reasonable people don't want to deal with.

I mean to be fair now that Wayland and PipeWire are there it's finally starting to look like a modern OS.

This would be more believable if there was a surplus of new Windows/Chrome OS desktop apps. Even macOS which is doing a little healthier basically gets a couple of indie commercial apps that people care about them.

The rest of the new desktop apps are electron which doesn't care about X vs Wayland

There are plenty of desktop development jobs, broaden your horizons beyond indie shops.

Besides, tablets and laptops are desktops as well, specially when parked on a docking station.

You are overestimating the difficulties of porting old stuff to wayland. XWayland doesn't have a prespecified EOL, it's just going to sit there indefinitely to support all the legacy apps. This means that there is no need to hurry with migration.

And the issues in X that wayland aims to fix are much bigger than the issues that python2 had when it got replaced.

“You are overestimating the difficulties of porting old stuff to wayland”

The same is true for moving away from win32 GUI API. How many times has Microsoft tried?

I have experimented with wayland and considered submitting patches for various 30-bit color issues, but the community is so catty. Everything is met with snark. It reminds me so much of trying to help a damaged person who doesn’t trust me, which is so weird and off-putting, in this context.

> The same is true for moving away from win32 GUI API. How many times has Microsoft tried?

I'm not very familiar with this example, but experience from proprietary systems rarely applies to FOSS because the way free software is developed is so different. Furthermore, Qt and GTK apps work out of the box with both wayland and X. The same applies to many other toolkits and libraries.

> I have experimented with wayland and considered submitting patches for various 30-bit color issues, but the community is so catty. Everything is met with snark.

What part of the ecosystem did you attempt to contribute to? I got a couple of patches merged into Sway and some of its utilities and the community always felt rather welcoming.

I have to agree about client side decorations. But my biggest issue (I use gnome) is that it is now the compositors job to remember window sizes and positions, and they are not doing that. I understand and agree with the reasoning that an app can't influence its environment and position itself. But someone has to do it. And automatic placement is not a substitute for remembering the users placement.

> Clipboard is weird.

Hopefully you are not referring to the fact that there are two clipboards in X, because I really like that "weirdness", and I'm really used to it.

> Also, it’s worth noting that since there is not one Wayland server the way there is one Xorg server, that not all of this applies evenly.

This is what killed XMPP and it's likely to kill Wayland too.

> Wayland solves no issues I have

Indeed, it's funny they would think it was meant to solve issues they had. The justification for it was never X11 doesn't work. It was always "it's becoming impossible to work on".

As it happens, Wayland does solve a problem I have. The HDMI port doesn't work under X11 on my Lenovo X1 2nd gen laptop. It does under Wayland. Granted, that's because no one wants to work on X11 any more, so new or unusual stuff doesn't get added. (The X1 gen2 is indeed unusual: the HDMI port comes off the Nvidia card rather than the intergrated graphics. The X1 gen3 fixes that nit.)

Which brings us the full circle: Wayland may fix no issues he has now, but the X11 code base being so much of a pig will mean he has issues with it in the future.

I've now moved to Wayland, and it was under sufferance. It's forced me to use Gnome3. The Gnome3 taskbar and I are not compatible ("what a complete waste of space" springs to mind), so I'm not that happy about it. Debian's alternatives system for selecting a Window Manager (now the compositor under Wayland) seems to be completely broken.

But Wayland itself: a few paper cuts, touchpads not working after suspend and things like that - nothing serious. But my god it's fast, and amazingly remote X11 connections (ie, "ssh -X") still just work. And the code base is much smaller.

People are comparing Wayland to systemd, to me it's not at all like systemd. Systemd was more complex, in lines of code literally 100's of times larger than then things it replaced, and never delivered on it's speed promises, and seeks to replace everything with Systemd. On all those metrics, Wayland is the reverse - it even encourages mutiple implementations.

I agree with probonopd on many things, but I will concede that the benefits of this rewrite for hidpi and likely other features is needed. The dependencies for things may shift more however to the DE layer and that is ok - but it will make things more complicated for many developers as they will have to test against DE's more methodically than what they had been is what I suspect.

I am picking up on this from writing app that cares about the currently focused app and with x11 that is easy to deal with. Wayland explicitly denies it from happening, only the DE can give me that information and I have to work out how to work with all of them individually if I want to retain parity. There are definite cons to that as it limits the DEs that I can support vs having the capability retained in Wayland.

Though as developer you should already be aware that programing against 1- different incompatible targets is extremly painful, so why the hell they did not implement a Wayland server too, is seems a cheap excuse "wayland is just a protocol, all the issues are in the implementation you use".

I am expecting someone would comment that browsers are a good example, and my answer is go check the contenteditable and for example how text selection works and all the issues people had creating a rich text editor that works on all browsers using it.

> moving away from Xorg as a display server really needs to happen eventually

"It has to happen because it has to happen" is classic logical fallacy anti pattern.

> The legacy is holding back desktop Linux quite a lot.

But I'd rather have it be replaced by something that's like X but supports higher resolution then (4K works for me with X though, no issues), rather than with something that doesn't allow screenshots, xdotool automation, clipboard, ... in the name of "security".

Wayland seems like a move to take away control from the user to me.

There's no 'winning' this discussion. The users clearly want faster horses.

I for one prefer the multiple "weird" clipboards in X.

I'm guessing you prefer the selection "clipboard" and the primary clipboard. There are a couple more clipboards that nobody uses.

I agree the selection is sometimes handy, but I've accidentally hit the middle button where I didn't mean to just enough times that I'm ready to give it up. I rarely use them to hold two different things.

I use SELECTION and PRIMARY all the time

Reply on news.ycombinator.com