←back to thread

49 points 1una | 1 comments | | HN request time: 0.203s | source
Show context
not_your_vase ◴[] No.35928051[source]
> Yes, not every random app and feature you use on Xorg will have a Wayland equivalent. Deal with it.

In general this sentence is why the Year of Desktop Linux won't come in this millennia. Not only XOrg vs Wayland. Many such cases. Sad!

replies(8): >>35928066 #>>35928112 #>>35928157 #>>35928221 #>>35928227 #>>35928231 #>>35928305 #>>35928559 #
imiric ◴[] No.35928227[source]
That quote is exactly why Linux will never reach mainstream adoption. Arrogant Linux developers who pick a hill to die on because they feel technology X is "better". They refuse to acknowledge that none of it matters if it negatively impacts user experience. This "deal with it" attitude is beyond obnoxious.

User experience is ALL that matters. Apple has this ingrained in their ethos. While the OSS communities are bickering over X vs Y, they chose to pick what's usable and polish it until it delivered great UX.

Last time I checked, Wayland was broken in fundamental ways on my NixOS/KDE machine. So I went back to Xorg, that for all its ancient faults, delivers a better UX _today_. I'll keep trying Wayland every few months, and when it becomes an improvement, I'll consider switching to it. No, I won't "deal with it". Why don't YOU fix it?*

*If you tell me that it's not up to you, but to application developers to add support for Wayland, I'll drop kick your sticker-infested laptop, and curse whoever came up with this ridiculous system.

replies(2): >>35928649 #>>35928996 #
sgtnoodle ◴[] No.35928649[source]
I thought the last paragraph of the main article was interesting. They admit that they chose to default to xorg over wayland in the distro because it worked better without hardware acceleration. Now they're ranting that their users are using xorg?

At work I have deprecated many older software components in favor of implementing newer, less painful to maintain ones. Lots of other software engineers use those components, so a big part of it is documentation or training. Rather than harp on the flaws of the old thing, I try to objectively present the lessons learned from it, with an emphasis on all the good aspects of the original that carried forward into the replacement. That generally makes the transition smoother, especially for getting buy-in from the folk that were involved with developing the original implementation. I also wouldn't tell someone not to use an existing component that works, unless I have a concrete recommendation for a better alternative.

replies(1): >>35929785 #
imiric ◴[] No.35929785[source]
> At work I have deprecated many older software components in favor of implementing newer, less painful to maintain ones.

That's great, but know that you're optimizing your QoL over the users'. If and when that new shiny thing becomes an objective improvement of the user experience, only then will users share your joy of switching to something easier to maintain. Just don't expect, or even worse, force users to switch just because it makes life easier for you.

> I also wouldn't tell someone not to use an existing component that works, unless I have a concrete recommendation for a better alternative.

Yes, this is key. And precisely what the person in TFA is failing to do. UX >>> DX, always.

replies(1): >>35933785 #
1. sgtnoodle ◴[] No.35933785[source]
I work on embedded systems that are rarely user facing, so ease of maintenance tends to directly improve the customer's experience for the overall system.