Obviously, a bit of clickbait. Sorry.
I just got to work and plugged my surface pro into my external monitor. It didn’t switch inputs immediately, and I thought “Linux would have done that”. But would it?
I find myself far more patient using Linux and De-googled Android than I do with windows or anything else. After all, Linux is mine. I care for it. Grow it like a garden.
And that’s a good thing; I get less frustrated with my tech, and I have something that is important to me outside its technical utility. Unlike windows, which I’m perpetually pissed at. (Very often with good reason)
But that aside, do we give Linux too much benefit of the doubt relative to the “things that just work”. Often they do “just work”, and well, with a broad feature set by default.
Most of us are willing to forgo that for the privacy and shear customizability of Linux, but do we assume too much of the tech we use and the tech we don’t?
Thoughts?
My experience has been filing a bug on a FOSS app, and having it almost immediately closed because it was a dupe of a bug reported ten years prior which remained open and unfixed. I’m not a programmer, so it’s just, “Well, I guess I’m out of luck on this ever being fixed.”
I’ve done a fair bit of UI/UX work in my career, so I have a lot of sympathy for naive users, and FOSS devs mainly do not. If there’s some functionality that is only exposed with a command line parameter, well, that’s good enough. Read the man page.
From what I have seen, KDE devs that I interacted with, had a higher tolerance for mistakes, than I would want to have for myself.
I once submitted a wish for Kate, which was also submitted multiple times before and marked as Won’t Fix, because: a) low demand; b) nobody to do it.
But when I started trying to implement it, I as given more help than I should have asked for.
So, it’s probably just about chance. Don’t let a few rejections stop you. If you consider it useful, even if it gets rejected now, someone will see it eventually. And some programmer might find it worth implementing.