_hudj

There is only one course of action here and anything short of that is deeply sad and spitting in the face of Tolkien.

This card needs to be placed in a storage container somewhere randomly in the world and opened only 20 years from now at which point a group of individuals will attempt to take it to Tongariro which was the filming location for mount doom in the movies. They will each be offered 1 million $$ to sell the card at that point but if they accept it they will get the million in half off yogurt coupons. If they actually agree to cast it into the volcano of their own volition then a team will do that safely and film it well while the "fellowship" receives the actual million they were not promised if they agreed to do this.

To be fair...under the same conditions windows and even Linux a la Nvidia gracefully handles monitor assignment for matching serials so I think it's a bit disingenuous to say this is all on the monitor manufacturer...though I agree ultimately they are the primary party at fault.

Source: have this exact scenario and on windows/Linux Nvidia drivers it works and on Mac it flips everytime I come back from sleep. Same brand batch and serial, cables, ports, etc.

And I have an m1 pro with a simple HDMI to usbc and an HDMI direct so no hub/bus assignment funny stuff either it's directly plugged into dedicated ports.

This is a long standing question and has nothing to do with Linux or windows. It's a design philosophy.

Yes the win32 abi is very stable. It's also a very inflexible piece of code and it drags it's 20 year old context around with it. If you want to add something to it you are going to work and work hard to ensure that your feature plays nicely with 20 year old code and if what you want to do is ambitious...say refactor it to improve it's performance...you are eternally fighting a large chunk of the codebase implementation that can't be changed.

Linux isn't about that and it never has been, it's about making the best monolithic kernel possible with high level Unix concepts that don't always have to have faithful implementations. The upside here is that you can build large and ambitious features that refactor large parts of how core components work if you like, but you might only compile those features against a somewhat recent glib.

This is a choice. You the developer can link whatever version you want. If you want to build in support for glib then just use features that only existed 10 years ago and you'll get similar compatibility to win32. If not then you are free to explore new features and performance you don't have to implement or track provided you consider it a sensible use cases that someone has to be running a somewhat recent version of glib.

The pros and cons are up for you to decide but it's not as simple as saying that windows is better because it's focus is backwards compatibility. There is an ocean of contexts hidden behind that seemingly magical backwards support...

Seems like a big with MS help viewer more than 7z

I appreciate what you do truly, but It's also perfectly understandable that we consider it a major reason not to use your software and a perfectly fair criticism of the choices you have made. Your rebutal has not changed the main point of the original poster at all, If you want to ignore 70% or more of Linux users that is perfectly your right to do so, but it's also my obligation as a long time Linux user to recommend that people avoid your solution in favor of i3 on X11 or a superior solution such as gnome or kde which understands the basic problems the overwhelming majority of it's user base faces and is willing to work with them regardless of the hurdle.