@BrodieOnLinux Oh, here's another:

Unixporn is just a collection of people who really, really, wish they were using MacOS.

@BrodieOnLinux My hot take is that the only reason Linux is actually succeeding on the desktop is not the community, but Valve and RedHat. Until the Steamdeck hit and Glorious Eggroll pushed proton even further... most people simply didn't care.

Although that's to say nothing about Microsoft cross-promoting Linux on accident by blowing up Windows with AI and ads.

Just my perspective... Linux user since 2002.

@BrodieOnLinux “Flatpak is not a distribution”

Source:

Hari Rana, “Developers are lazy, thus Flatpak” https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/

@BrodieOnLinux
People believe by optimizing compiler flags to their CPUs they can make bad code run better. That's why Gentoo exist.

The same people ignore the fact that compiling their own updates everytime converts hours of their lifetime into them staring at a console with endless scrolling lines of text output.

(Hi, I was a Gentoo user for 10 years and configured my own kernels from source)
@Madic

@BrodieOnLinux here's mine: Linux users are as lazy as Windows users - in fact, I'd go one step further and say that they're mostly the same.

You'll see the same kind of whining between both communities. They just whine about or ignore different stuff and for most of them, it's just arbitrary what they care or don't care about.

It's only when they encounter enough problems to stop being lazy and actually experience new stuff that they start to meaningfully change their opinions.

@BrodieOnLinux
When someone says that window managers are inherently superior to desktop environments (as a blanket statement)

- or that WMs are some kind of natural progression for advanced users while only beginners stay with DEs.

But then spend hours trying to recreate types of functionality that already just work automatically and integrated well in the DE that they were mocking.

@BrodieOnLinux
How some people will seek out discussions with news about distribution or application they apparently hate (they always have a list)

- but then it turns out the only valid criticisms they have are recycled from years ago and since addressed

-then it turns out they never tried it recently

@BrodieOnLinux wayland isn't really what it's cooked up to be, even though it has been decided it's the future of the linux desktop, and it could be eventually, if these issues are solved, because the fundamental architecture isn't flawed. The rest of the toot is elaborating that sentiment. This is a very long post because it also details a case I know well about trying to introduce new protocols to wayland, so if you're reading this, it's recommended you read it to the end.

First, differences in compositors and how they implement things, each compositor could implement a different set of protocols, and even what it implements from the protocols list could have its own quirks, which makes it incompatible with current implementations in other compositors.

Then, the effort required to build a wayland compositor from scratch is huge and wlroots isn't always an option because not everyone wants to be writing that in C, though I understand that's not so much of a problem, since so many xorg window managers are just forks of a previous project.

The biggest one though, accessibility took an enormous hit with the keybindings and the snooping on each other applications could do on x11 gone, so now overlays for specific disabilities are impossible to be done externally, and therefore tailored for each use case, they have to be built in the compositor, if the compositor maintainers even agree it's a necessity in the first place, which is also problematic because it's not always the case that our needs are understood, and as such, that our patches for such needs would be merged upstream, and as everyone knows, forking is costly, so that's not a better option either.

Of course, then we go on to more general issues, such as IMEs for japanese, chinese, etc not working properly anymore, and generally neesh software which a couple people used, or even made, to solve a problem, doesn't work anymore in wayland, and if we want it to work again, we have to go through a very specific, ahem, dance.

Well...first things first, making a protocol which should conform to a lot of unwritten dogmas about how security should be done in wayland, beyond the obvious, so then that means spending time around the wayland protocol trackers to learn what the community generally wants and is written nowhere, to increase the chance of the protocol being merged that is.
Then comes the only mildly annoying part, making the xml files for the protocol by hand, which isn't necesarily the most pleasent thing to do either, but not as bad as the next part.

Of course, the final part, getting the protocol in a pull request or an issue, only to find out that first, you gotta sort through a huge number of comments, and I'm sure you know what I'm talking about because you yourself saw what's in a typical protocol proposal, and then to hopefully find out that either your protocol is silently just not merged, it is but no one wants to implement it, or someone kindly telling you that there are lots of security concerns with your protocol and back to the drawing board you go.

A friend of mine went and did the whole dance, trying to find a solution for at least one problem in the screenreader accessibility case plagueing wayland users, the key event capturing, to then be sent to an assistive technology the user configured, like in, say, any other operating system with accessibility support that I can name.

He went to the gnome accessibility matrix room, and both of us along with some of the gnome people tryed to make a way to do it. It took the form of two meetings, I believe they happened last year or so, in one I was there, in the other it was the other way round.

So, we tryed with a portal first, modifying a bit the global shortcuts one to provide screenreader semantics better, for example to consider capslock a screenreader modifier. Then, that didn't work, so he went back to the drawing board, tryed to make a wayland protocol for this, which was kinda simplistic at first, but then gained in complexity.

He almost implemented it in mutter, except that xkb_common doesn't support capslock as a modifier, which is required for screenreaders, because that, aside from insert which is also not a modifier in the actual sense of the word, is the only other modifier applications and desktop environments don't use, that's why screenreader commands usually begin with that key.

The next step in this, of course, is to follow the chainin of events, and file an issue with xkb_common, which is exactly what he did.

In the above mentioned xkb_common issue, we found out it's actually very complicated, more so than we expected, it's not really closed but we know progress is hard to get done, if at all.

So then, probably odilia, the new linux screenreader which is in like less than alpha stage, will still use evdev for the time being, untill hopefully the new wayland based accessibility stack which is coming out will mature enough to replace at-spi, and will hopefully have the right extension points for us, even though it can be a way harder thing to support for wayland compositor developers, with yet one more thing they have to add every time they make a new compositor.

So yeah, I'll continue to use wayland from time to time, and some days use a plasma session entirely with wayland just because, however, these issues are a real bummer all round, worst of all when it comes to accessibility, which could make the desktop for some people, depending if they use lots of gtk4 applications, entirely impossible to use with any semblance of productivity.

@BrodieOnLinux

I use Artix Linux as my daily driver, which is basically just Arch Linux but without systemd. But I don't hate systemd tho, in fact I'm one of the developers of TROMjaro - a linux distro based on Manjaro. Oh yes, we forked Manjaro everyone! 😁 Here is the website - https://www.tromjaro.com

@BrodieOnLinux
It can look like there is much argument about design choices across Linux desktops.
Meanwhile for all the gripes about Microsoft (valid or otherwise) they did actually put some thought into Human/User Interface Guidelines for Windows (more apparent in earlier editions) and there are Linux / FOSS projects that would benefit from the same discipline.

Notably including the Principle of Least Surprise, when thinking about all the ways you could perform a task.