As well it should. Because now things that used to take three seconds will take 15 minutes for a month until you learn the new interface.
The designer will respond that yes, but then once you learn the new thing it will take two seconds. And if you save one second twice a day then you'll have made back that 10 hours you spent learning the new thing in less than 50 years!
Except that they're going to change it again in less than 50 years.
And that's assuming that the new design is actually better and not just different or worse, because also, this:
https://news.ycombinator.com/item?id=25950351
Rule of thumb: If the new thing isn't better enough to cause people to switch to it voluntarily without any prodding or the removal of the option to use the old thing, it isn't better enough to be worth it.
Not saying it is right or wrong, but a lot of the upsetting changes for existing users are for the benefit of new users.
Also, "users" are "people" and the average adult lifespan (18-78) is around 60 years. That implies that the time for the "new users" to become half of the user base is around 30 years, so what does that say about how often it makes sense to do this?
But suppose you're right. Then the solution is competition. Don't take away the old thing, provide both. If the new users want to use the new thing and the old users want to use the old thing, great.
And then if the new users still want to use the old thing you've got a pretty good red flag that you messed it up.
That doesn’t add up at all... you’re implying that users are gained and lost at exactly the same rate, consistently, over a span of at least 30 years.
It doesn’t invalidate your other point about competition, but it’s a flawed argument to base any reasoning upon.
The point at which "new users" are the majority of the user base never even happens.
Your new UI might be garbage, but there's no red flag here. A new user will likely need to make use of tutorials, troubleshooting, and other help online; most or all of which will be based on your old UI (and possibly coupled with comments like, 'Don't use the new UI, it's trash. Here is how to switch...'). Having been such a new user, I only pick the new UI when forced or when it's clearly better; the former being the more common case.
Sure, you can make your official documentation use the correct UI (or design your UI in such a way that the documentation can be agnostic—but then what is this big change that makes lives better?), but unless your documentation is very good, people are still going to need to reference all these other sources.
Recently ran into this issue when submitting an app to Google Play. New interface didn’t even match up to Google’s own instructions. Frustrating.
Edit: unless there is a majority of unsatisfied customers (:
Most of them are too frequent, automatic, plus they are not actual improvements.
https://support.google.com/mail/answer/15049?hl=en
Old gmail is faster and normal things like opening a link in a new tab actually works like any other page and its actually a lot easier to read because of it.
In the new interface you are only given a fraction of the horizontal space for the actual mail, and I actually have to scroll sideways to see the pop out in new window control which for aesthetic reasons is only a graphic with no text label except on mouse over. Popping it out gives you a window that you may or may not need to resize or move for optimal reading and as far as I can see there is no way to just read the mail in a new tab in the same window at all which breaks most people's methodology for managing multiple tabs.
It's not merely bad its actively hostile.
It seems like the developers and product managers want to show progress but the uses just want you to fix boring bugs. It will help if the product folks think of memory, perf and stability as very important features and stop chasing new features for the sake of it.
Memory performance is not too big of a deal, IMHO given the last decade of hardware, but stability is.
Lost mental state is generally as painful as data is. People hate it viscerally.
I have seen 4 figure software get replaced by 5 figure software over that alone. 5 figure stuff runs for weeks to months at a time. 4 figure can crash daily or more often.
Stability was a primary selling point for me, and I used to maintain a session for that purpose. "My session has been active for months and 10's of projects, lets open your sample data and walk through it...." Did that on a reasonable, but not great Lenovo. Hibernate, sleep, hibernate, sleep...
Win 7 too, lol.
I came from IRIX. I would go the better part of a year, apps running, system up, all ready to go. Spoiled. Win 2k was good, Win 7 matched it, and Win 10 is solid, except for forced updates.
I would never, ever devalue stability. People who are focused, task intensive, live it, love it, will argue they need and are worth it.
Not sure they are wrong.
This is hugely underappreciated. Last fall I decided I would get back into making videos for YouTube after 7 years away. But two videos into the new series, and the constant crashes of my video editing software I just paid $$$ for have reminded me why I stopped making videos in the first place.
Ultra painful. And anytime I hit flow, I am either gambling by not saving and disturbing flow, or leaving flow trying to save... agreed.
Scriptable may find a lot of use.
Play it how you will, of course. I will pass hard personally. Lack of stability is very high on my qualification list.
To be blunt, where it exists there are other priority problems.
One may just be flashy speed and other sizzle done at the general expense of the solution being robust.
May only take an event or two needed to cancel out potential gains from those things. Turn that crank a time or two and many will just get back to work.
An attempt or two again? Many will ignore the solution and or have adopted something else.
Net result? The team that did not make stability a priority likely did a lot of market building for the ones who did.
I personally am very frustrated by this constantly, but there is no way around it that will always work. Someone has to pay the cost of market building, it is a separate cost from stability, and sometimes you can't afford both.
But, what does work far more frequently is to get the solution robust early. The longer it gets put off, the more difficult doing it is, both in time, cost, users being requited to do things along the way to support it all.
If so, they can pay now, or pay later, just make sure you manage expectations so they actually do pay.
If, somehow that ended up on you, of course they refuse! Why pay for a free lunch?
So don't allow that. Seriously.
Maybe the customer finds someone hungry enough to pay for them.
Or, maybe that customer pays hard going through this cycle a few times too.
Not my problem and it does not have to be yours.
Can definitely be robust and should be.
In this scenario, it is a mutual problem. Nobody has to use the software, true. However, it again is all about managing expectations.
If it is oversold, people will end up with bad experiences and that does impact who delivered them.
This has already happened. Will again too.
On a short timeline, maybe no big. On a longer one, higher order impacts may actually be painful.
Say a decade of negative public sentiment sees a brutal regulation kind of painful.
Entities putting billions in the bank can and should make reliable software.
There is a YUGE diff between Gmail, Excel and friends, and rando OSS.
This discussion ranged far away from the initial premise.
So, let us take it back a bit.
Weyland. Wants to be the defacto display solution. Does not have the same priorities many users have. Also does have priorities many users have.
Replacing X11 was made an explicit intent too.
Well, if it does not actually do that?
"All that Weyland shit talk" is the outcome.
Maybe subtract the replace X11 part, or maybe find a way to actually replace X11, or maybe just ignore the shit talk?
Because of that problem, I have always maintained we need a way to better fund some projects.
I would love to see the display system funded and all the good stuff worked out properly. For me, the network features and general flexibility of X is worth some money.
When I ran SGI machines, that money was paid and the display systems were flat out awesome.
If it does not do those awesome things? Meh, can just run Win 10.
I used Exceed a lot. Exemplary. That program did everything nicely. I even used a CAD app on Windows that actually was built for X and it was network transparent same as any Unix box!
There is a sub $100 one out there. Maybe a bit more now. Maybe gone too. It was very good.
The freebies are respectable and great for sysadmin.
Funding a first class X11 replacement that also does some new things people want for mobile and embedded makes a ton of sense to me, and I would sign right up too.
Maybe getting a bunch of us tossing a tenner a month at this would fund a project that just gets it all done.
And we need one.
It is obvious to me X11, used as it can be, sees way more than anyone may have thought today. When I was on IRIX, X11 was flat out awesome. Shit just worked, and was fast, and 3D graphics over the wire smooth, fast, performant.
It took a long time for the rest to get there and when they did, nobody really grokked it, unless they came from a solid implementation.
And nobody from the PC, Windows camp got it. Did not even understand what an app server even was.
No fault here either. People saw what they saw, worked how they could work. I get that.
But today, people still saw what they saw, work how they work and ripping all that up is painful enough to not make sense.
If it did, we would have seen this go differently.
So maybe this should not be a volunteer effort. Matters too much to way more of us than I also believe was expected.
If we fund something thwt does what X11 can do and that also will do the new, spiffy, lean things people want today, we would have a killer environment.
Having that be OSS?
Worth it to me.
Or, we can watch the carnage for another decade...
Good discussion, BTW.
People keep saying that Wayland needs to be more of an X replacement but it's never clear what that means. You want 3D graphics over the network, that currently means Vulkan, and if you were going to do that, there doesn't seem to be much reason to tie it to any particular window system.
In a general sense, Wayland is not Unix like, in the same way systemd isn't. X11 is, as were various init systems. And fact is, at the time those things were done, multi user computing was a thing, and it was all done with those ideas in mind too.
At the time, micros were on the rise, and apart from a few exceptions, were single user, and started out single tasking.
Two different roots of thought, now well grown into trees that share intermixed and intertwined branches.
I know that is an issue. Whether it needs to be addressed is an ongoing matter. A matter I am happy to discuss, but not currently one that impacts me too much right now.
My focus is pretty far away from a lot of that. Doing lower level stuff, and often with no OS, embedded. So, write it, include it, port it if need be, then compile and deploy it.
Minimum requirement is gcc, command line, terminal. In all other areas, Win 10 is fine. I really could give two shits what OS it is otherwise. Machines are all fast enough, big enough, etc... good times (for me) actually.
Again, not dismissive, just not a focus at the moment. That could change and I might care a lot too. This kind of thing happens to people. Sometimes often.
When I use X, I tend to make good use of the network capability. It is the primary reason to use it, along with ways, means, tools that have worked forever. I value stuff like that very highly because I much prefer learning and using new things to me, not always remapping stuff I know cold.
For example, in the past, I have enjoyed weaving a single desktop environment from a pile of machines and software. Did that to support, sysadmin, train and develop for advanced engineering software users of all types. I had the industry on my desktop and could run or do almost anything on a variety of platforms from that desktop and the time savings on that as well as my general potency 2as off the charts good. Beat a lot of other people who did not really grok X too.
Log in and just do stuff, and depending on what gets done, a few machines, or just one gets the job done, served up to me nicely, consistently.
For a long while after IRIX was done, I used a machine as my head end. Just worked great for that kind of work. Pretty much nothing was as good since, and apps have become far less flexible too. A pile of VM's are required for that kind of thing today and it is a lot more work.
But, it is also a lot more lean hardware wise too. That is significant right now, though I do not know how significant given how cheap stuff can be.
Anyway, back to the UNIX part. Small programs, smart data, pipes, all that stuff is UNIX. X11 allows all that to travel where it needs to and it is a very nice way to work.
If one wants, everything can be distributed too:
Fonts from one box, X Server from another, application on yet another, running on shared files from yet another, window manager on yet another, etc... An Indy used to serve up its nice window manager for my Linux for quite a while, just for shits and giggles.
And that is the UNIX way.
Sometimes it is powerful. I see people struggle with managed data, engineering software, etc. for example.
under X, I just made a beefy box, one copy of the app, one database on local disk, one backup system, and on IRIX that could be done live while people are working with just a few set and forget scripts too.
Then, serve 20 to 30 users. They do not have to know anything other than how to use the app. And they can't really break it either.
Admin on that thing was mostly cake and the users could run whatever they wanted as long as it had a respectable X server, they were good to go. Few of them would even notice or care, and it worked great over 100-T networks too. Kind of crazy to think about today.
The nice thing was those users could not touch the data except through the app. This saved so. Damn. Much. Pain. Worth the whole setup right there.
So that is one case. That case made me a ton of money too. Edit: That case still happens online, but alsonsuggers from being online. Outages, updates, fails on the part of the provider, data being leveraged in distasteful ways, sometimes expensive ways.
Done local, with X? Total control. It is nice.
Application servers. Loved them. And with super expensive 5 figure software? Making that available and performant to the people who need it without all the installation hassles is golden. Really do miss that.
All very UNIXEY.
Other cases include multi head machines. Beefy machine shared by two people. Was pretty easy with X. Not sure what the state of things is today. Probably not good. Probably not needed either. We got crazy amount of capable cheap hardware these days.
Basically, X is multi user graphical computing and all that can mean.
Current display systems are not.
We have moved quite far away from multi user systems, frankly. The basics exist and work, but we have no display systems that work in the same way. And very large numbers of people do not even know how they could work too.
Honestly, that is probably the core issue in play, boiled down!
"No reason to tie it to a window system"
Well, given a multi user graphical display system, "particular" kind of becomes moot. Run the window manager you want, etc...
In any case, here is what I think will happen:
X11 has always had this basic problem. People who did not use it, or who cut their computing teeth on single user dominant computing think very differently from those who did.
And it is not just about displays. The same thing is true for the command line too. Watching people come from DOS/Windows onto a proper multi user environment showed these differences in thought to be just as stark as those same differences remain stark today in the display context.
Most people know what multi tasking is and expect it. That is the dominant mode today.
Far fewer know what multi user computing is, and again I am speaking from the perspective of someone who took full advantage of multi user computing, and in the graphical as well as the general sense.
And that is the clash, in my view. A secondary one is breakage of a lot of little time tested, production proven ways and means of doing things.
Focus follows mouse + middle button paste is amazing when working across various windows that may overlap, or exist across multiple virtual desktops, for example. I can tell you, that is a super hard one to get away from. I did, and have, but it hurt.
There is a ton of this "noise" and given the state of discussion, appears to add right the fuck up. Still.
But I am rambling:
What will happen is we will either prove out the idea of multi user graphical computing is not useful, or we won't.
If not useful, all this stuff will eventually go away and we will bring up the next set of users on whatever that paradigm looks like in the end and that is that. The rest will be history.
Sort of like how we see mobile dominant users and desktop dominant users today. And that is far from settled. Mobile is nowhere close to displacing desktop. I use both hard too. No way.
But, if what gets made really is not so superior? Like those "precious use cases" really do hold significant value? Or, even if they could, but die off for a while?
Then we will do all this over again, reinventing X11 just like people tend to reinvent UNIX.
And look at the current trend to serve it all up via browser! Seems to me a lot of great 70's era ideas had real legs.
And this will happen because tech never, ever really dies. Someone, somewhere will see it and build on it to complete and it is game on. Or, they will think that way again because the line of thought has merit.
I plan on watching it all with great interest.
Personally, I believe in multi user graphical computing and have seen, applied, and profited nicely from the value it has. Everything should go over the wire, just like everything is a file. So I have something I want to run on my phone? Just ask for it on the display I am using and go. That's X11. I think that kind of thinking is compelling and I think that because I got to do that and it was sweet compared to the usual, find it, install it, configure it, move / copy data to it mess.
Cloud computing does that with a browser nicely. But, it also means a few people get to rule the world too.
Whatever one may think of that, if we were to build multi user graphical computing in from ground zero, I believe it will endure for a long time, just like UNIX itself has. And it will because the core ideas are strong, very generally useful, etc.
We have seen this kind of thing before too. Really great ideas tend to stick around.
And this is not about the people doing Weyland not having great ideas at all. They are trying hard to bring some new ideas into play, much like the X11 people did.
Cool!
It is more about trying to convince everyone that the great ideas behind X11; namely, multi user graphical computing, aren't great, or can be replaced with something that fundamentally is not multi user graphical computing.
Given all that, Weyland NOT replacing X11 may well have set different, and maybe less conflict laden expectations.
But that would also have begged the question: what value does multi user graphical computing have? We may be in a better place had it been asked and answered.
I think it has a lot. And I think, like UNIX, it is most important that it can all be done, not so much that everyone needs to, or will benefit from doing it, or being forced to do it.
We shall see!
I remember my early encounters driving me absolutely mad because I did cut my teeth on that 1 seat 1 user environment.I think where I've ended up going in a different way than most is that over the years I keep cracking away at it because I want to understand it. It's an intuition thing, and you never really appreciate the miracle of it until you sit down and come to terms with what X really did. It was the glue between app logic, state, and a constantly floating set of goalposts represented by every possible set of different hardware.
I haven't even torn into the source. It's taken me so long just to grok the other layers of the problem space. Personally, I think the space X11 occupied is one of the most enticing areas of research open to me, even if I never seem to make the time for it.
Abstraction-wise, we assume we carry context with us everywhere, but an X environment driven over a network breaks you of that quite handily, and I don't think the "Cloud"/SOA solves the real life dilemma jist by lifting everything into a browser.
Agreed.
At the least, risk will be higher than it needs to be, and that puts the other validation into question as well.
Often is right?
When does robustness end up a priority?
Could be a very long time, and or never, particularly given the core value proposition and or features intended to deliver it are not themselves validated by "the market" as you say.
One solution to this is to pay people to adopt the solution.
Another is to deliver features more specific to them.
Yet another is to cover it up, make recovery robust, transparent, etc...
These are all perfectly fine ways to approach beta type cases, initial userbase, seeding for growth.
After that process has shown what the market finds compelling, stability should be right there in the list with the core set of software to build on.
You can't omit stability in life-critical software for example.
On the other hand software's usefulness can outinfluence unstability, if there are no alternatives.
The point being made here is not that it always must be stable.
It is all about how often stability is not a priority when it could and or should be.
And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in.
When that happens, stability, robustness often stay in the back seat for a large fraction of the product life cycle.
For any given user, the impact may be just low enough to keep them on board too. New features, and asking more money for them, or offering them to make up for that impact can be an ugly cycle leading to users ripe for the picking later on.
Example: Steam cloud save. Countless time I have to force quit Steam's background service because Cyberpunk 2077 and GTA V freeze while saving.
Steam doesn't show the launch game button, even though the game is killed from task manager.
There are no heartbeat like mechanism to keep in check the game process state.
And there are no alternative to launch the game that I bought from steam, so the instability becomes little of nuisance.
But that's a minor issue where unstable features are unimportant ones.
> It is all about how often stability is not a priority when it could and or should be.
And I'm on your team too. That's why my argument is that stability IS A feature too. Countering grant parent's argument that says stability is ignorable as long as the features are validated by the market.
> And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in.
As a paranoid user I agree this has been a nightmare. I constantly have to make sure I wont get locked in to services that I pay for, and often time I find myself using open source solutions rather than paid one because of the same reason.
It absolutely is a feature.
Guess the externalities problem crops up in this context.
How to actualize those costs better so the equation makes more sense?
And yes! I hate lock in viscerally. Frankly, will avoid it at very considerable cost.
Which equation exactly? The balance between effort to stability and other stuffs? Sorry I'm a bit lost
There are competing paradigms now, and that is good, but they have not yet actually reached use value and productivity levels where it is appropriate to say the desktop paradigm is out of date.
At the worst, both will become more generally flexible to keep their value to the users.
Like you note, this isn't a problem unique to Linux/"free Unixy OSes". In some ways Linux is actually worse than others, consider Gnome/Gtk Updates for example. Or how things like having a library to read a particular image format are quite normal around here; except that library has like half a dozen incompatible but actively used versions and around 1000 released versions. The Linux environment is very volatile and everything constantly changes and breaks. Modern applications bitrot exceptionally fast in Linux, while the community points to "but look this Xchess binary from 1992 still works". That's neat but covers few real use cases. The same community is then bewildered that both people and enterprises opt for distributions which move at a glacial pace and only releases updated software once every five years or so.
Edit: glib not glibc
The GNU C standard library has binary backwards compatibility going back 20 years. They take great pains to preserve that. Are you thinking of glib instead of glibc? The former is from GNOME, and the latter is not.
glib 2.0 was released in March of 2002, and has preserved ABI compatibility since then.
So not the Linux community then. Outside it.
Do all the new GitHub-driven programmers who exclusively use MacBooks and constantly rev things with the same frequency not exist? Why is this still being presented as a freedesktop-related problem and not a general problem with creators' fickle and fleeting attention, when we have evidence that the category isn't as narrow as the pigeonhole you're trying to put things in?
Sadly, that ship has passed... long ago. When you encounter a random person about "Linux", they will think of the Linux ecosystem, not just the kernel. In other words, your and GP's definition of "Linux" is different, and they are both correct depending on how would you read it.
(And before you go almighty on definitions, the majority of linguists agree to just monitor - or "describe" - the words as normally and plainly used.)
This seems to point to the general situation of change fatigue. If you pick up a random Android device, what does the "settings" app icon look like? Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done.
I don't think there's an easy answer here when the developer needs to make fundamental changes, though.
One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development.
A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!".
I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read:
* List every change or commit message, especially without categorizing or simplifying the wording
* Don't properly highlight feature changes (eg with screenshots and/or reasoning)
* Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document
Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable).
[1] https://code.visualstudio.com/updates/v1_52
[2] https://confluence.atlassian.com/jirasoftware/jira-software-...
[3] https://about.gitlab.com/releases/categories/releases/
[4] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHAN...
But this is a real problem: it's not good that the Linux ecosystem has been reduced to "we shall eat whatever dogfood Redhat cooks for us". Wayland didn't even start as a RH project, iirc, and didn't really gain any traction for ages, but now it's a Big Deal because RH pushes it...?
That's how I see systemd and wayland. For systemd the consensus seems to be that's it's better than the previous init systems as most distributions have adopted it. It seems we're going in that direction with wayland but we'll see how it goes.
I think the parent comment was alluding to the fact that RedHat has the ability to manufacture consensus. All the distributions use systemd (and pulseaudio and ...) because GNOME and other core components were modified to work only with systemd. So everyone agreed to use RedHat's way because there was no other way. No matter how good RH's creations might be, that's the kind of tail-wagging-the-dog power that is bad for an ecosystem.
But the point remains that, even without any ill intent, the lack of competition and compromise can produce outcomes that look like malice -- people gradually get used to making decisions that go unquestioned, and unwittingly walk all over everyone who no longer has a voice in the discussion. This pushes more people out, and the cycle of the tail winning against the dog repeats and continues.
- Audio system that ignores all the foundations of ALSA and builds Yet Another Layer instead of improving ALSA.
- Display system that leaves way too much as an "exercise for the reader".
- 10+-year-long transition periods on the above, during which nobody's use cases work well.
- Decisions made by fiat rather than by consensus.
I'm not sure what you mean by consensus, if there was consensus on everything then we wouldn't have so many Linux and BSD distributions. We'd probably have just one or two, and you'd probably be more annoyed about "wagging the dog" if that was the case.
Just one point about ALSA; most of it actually lives in userspace. The ~/.asoundrc file can specify complex routing and mixing, including the use of LADSPA filters. What's done is done, and pulseaudio is reasonably usable now, but IMO we'd be much better off if the work that went into Pulseaudio and jackd instead went into the ALSA userland.
Nice try Google/Microsoft developer! I'm pretty technical, your sh*t change is still sh*t.
I remember a time when updates from gmail, outlook, or excel improved upon the previous version, sadly that was about 15/20 years ago for Google/Microsoft, respectively.
Details: Bluetooth headphones with microphones actually show up as 3 sound devices, one high quality output device and a pair of low quality input and output devices. Whenever a microphone is requested, the low quality pair is selected. Output quality goes to shit and any apps that don't get the memo will still send its audio to the high quality output device which has since become an inactive sinkhole. Since many apps request microphone access for non-obvious reasons, the symptoms are that you do something non-audio-related and sound in the rest of the system does some combination of {go to shit, stop working} on a per-app basis. The solution is to disable the low quality input and output devices, which keeps sound output functional and high-quality until Windows Update reverts your settings and sets the stage for the next microphone access to break bluetooth audio again. Ugh.
Interesting. I have what appears to be exactly the same bluetooth headset setup (Bose QuietComfort 35s), and use it all day every day while at work.
I have the slightly annoying thing that if I'm in a video conference all normal audio isn't heard (unless I switch the default audio output), but I only get that when actively in a VC. I have never had 'random applications requesting the microphone'.
See for example the pages of complaints about windows forced planned reboot features deemed unavoidable from the hn majority, let alone the common users.
Any one of {Bluetooth SIG, device manufacturer, Microsoft} could have independently fixed the issue. Every one of them should have forseen it. None of them foresaw it and none of them fixed it, and years later it still lingers. Yikes.
I see your comment's flagged, maybe because of the harsh language but other than that it all rings true to me.
This. I think it's incredibly inconsiderate to do that to a user who never asked for it.
As a user, I abhor this mentality, and respond to it by leaving. And if I have to stay, I boycott the nag dialogs and just leave them open, to embarrass the developer in front of anyone who may be watching my screencast.
As a programmer, I go out of my way to ensure that my software works the way the user wants, and an upgrade is never demanded.
I design for back and forth compatibility, so that I can go back and forward to any version I desire, as long as there's a commit for it.
It may not work perfectly going back a year, but if it's a stable version, it should run.
In this case it's people maintaining software that I don't use telling me I'm problematic for not switching to their stack, away from existing software that works perfectly fine and is also actively maintained by people who don't call me a flat-earther. Easy choice.
All the successful projects Linux users like to talk about nowadays (gaming now a practical thing, new kernel features, Wine getting really good) were all bankrolled by massive billion dollar corps like Valve and Google, because the community itself has no discipline to see things through.
At least GNU of the old days was organised enough to know not to break people's workflows - just look at how stable coreutils have been - but GUI software for regular people somehow doesn't deserve to get the same treatment.
"Linux"? We're discussing a category that includes Gmail UI changes. Is Gmail not popular?
Maybe discipline is a problem, but time, money and access to information is too.
On the Subaru, they are clutch controls. The result was downshifting into 1st gear going 70mph/100kmh+.
I don't think I can tell you immediately whether my laptop is running under Wayland or X (I only can because Wayland and FontForge haven't been talking for some time). Does it annoy me? Yes. Does it annoy me to the point of anger? I'm an adult. I have other things going on in my life besides graphical back-ends.
This is not how average people are AT ALL. Let someone use one of the above and give them something new and watch them be frustrated for at least the first entire day of usage with continuing friction happening for the next week-month every time they find a new task that they don't do that frequently but thought they knew how to do.
Asking the manufacturer would open the flood gates about how ungrateful you are about all the years put into designing the thing, and how other options were "confusing" to drivers, although said drivers should clearly be of some extraterrestrial species with a different set of sensory organs and appendages.
Imagine a screwdriver that would randomly switch to requiring a hammering motion instead of rotary motion, then the next day it only works if you hold it just right, then the day after that it freezes itself to the table to download updates and the update changes the shape of the tool bit so it won't even turn the screw you are now two days late on tightening. People would riot.
Probably not your point, but I absolutely do blame maintainers of proprietary software for changing my routine. Webapps, free software, and whatnot I can understand (even if I don't necessarily like it), but if I pay in full for a lifetime license to a specific version of software then I fully expect, at a minimum, for that software to not have auto-updating backdoors for any reason (looking at you Garmin/Navionics).
most software changes are unnecessary and are forced on users unnecessarily, and that,s why people hate software.
It's not just the FOSS community, look at how non technical people react every time gmail, outlook or excel makes a tiny change to the UI (not to mention big ones). It really makes people angry when things don't work the same anymore, let alone when it doesn't even work anymore for their use case.
> In my admittedly somewhat distanced opinion, Wayland's biggest mistakes were not launching with a coherent strategy for replicating functionality like screen sharing, screenshots, and to a lesser extent remote desktop/applications. They just punted and said "that's a compositor problem!"
My guess is that it wasn't a deliberate strategy, it just that like anything related to the Linux desktop, the project was underfunded so they had to focus on certain issues. In this case it was focusing on improving from xorg and making sure it doesn't break anything on the main use cases of whoever was funding the project (mainly redhat). Apple and Microsoft can afford to pour billions in their display server/protocol/windowing system. Not so much for Linux.