Quoting: Liam Dawe

Quoting: slaapliedje

Quoting: missingnoI recognize the importance of Proton to help bridge a gap we sorely need right now. The state of native ports is not good, and it's unlikely to get better any time soon.

But I firmly believe it's important in the long run to actually push developers to support the platform instead of relying on a third-party compatibility layer that could break at any time and be met with "Well that's not our problem, we only develop for Windows."

And I just find it so very tiring how much backlash I constantly see towards the apparently radical idea of wanting to be supported.

Proton exists for those who don't care about official support and I'm fine with that. But I care and it's not what I want. And I'm tired of being told I'm wrong to care.

I 100% agree on this. If we allow it to continue down this road... eventually MS will release a new DirectX that requires Windows 1#, Wine/Proton will be beack to playing catchup, and potentially there could be something built into it that specifically targets non-windows for breaking, and it will be a constant back and forth getting things to work.

Getting developers to support native Linux builds is the ultimate way around this...

While true, this is something I believe I mentioned in a comment somewhere - it takes game developers multiple years to switch to a newer graphics API. Look at DX12, it's only really just now coming into its own and it was released in 2015.

I don't really see it as a big issue personally. There will be time needed for Proton to catch up for sure but it won't make anything before it suddenly stop working, and of course if / when it happens Valve will have people on it to build it. Microsoft couldn't really lock it down to Windows like you think due to the way it works, it's an API with an SDK for developers to use - just like anything else would need to be reimplemented.

Right, but depending on how MS do it, they could make it really difficult to re-implement. Let's take .NET for the perfect example. While most of it is indeed open source, there are tool chains and libraries that have not been ported to Linux. Look at the Launchbox project and their reasoning behind not releasing a Linux native version of it (they released a port for Android, but that was because it was a port to a different language / set up. Basically a completely different program, for Linux they've outright said they've tried getting it to run via Mono, but too many libraries they are tied to keep them from making a Linux version).

Amusingly, Proton/Wine is already far better at compatibility to legacy software than Windows is. As far new software / DX stuff is concerned though, we just won't be able to tell until it gets here... hell, no one really saw Redhat being bought by IBM, though at that point the writing was kind of on the wall, it just needed them to translate the message what their intentions were...

Look at the moves MS is doing with Windows 10/11. They randomly will change your browser to default to Edge, or force certain things (like searching through the bar on the bottom of your screen) to open Edge. They've patched out registry hacks to move around it. I'm sure if they can find a way to make our lives more difficult because we don't want to run their operating system, they will...

Quoting: slaapliedjeSomeone want to fix / recompile the original XKobo?

Quoting: GroganSo yes (point taken?), open source software can be just as broken if nobody capable is willing to fix it :-)

In this particular case somebody actually cared and made Kobo Deluxe. Though yes, plenty of old projects around that are left to rot. I'm not sure how well Kobo Deluxe works these days.

Quoting: GroganP.P.S Nah, I got imake to generate a working Makefile, but the source is chock full of class definitions and stuff (e.g. string to char conversions and such) that just aren't valid in C++ anymore, the compiler just isn't going to do it and while you could override it with flags and attempt to proceed, it just can't work anyway. Someone could certainly fix this, but that someone isn't me. It's not just that it would be laborious, I can't do it. Again, wouldn't know until I looked at it though.

I guess there's a reason why distributions like Gentoo keep the old GCC versions around for a while

Quoting: AnzaI guess there's a reason why distributions like Gentoo keep the old GCC versions around for a while

I haven't done that since they broke the ABI with gcc 3.x. I used to have gcc 2.95 for kernel compiling and for stuff that has to interface with stuff built with the old gcc. This was more of a problem for c++ (For example, you couldn't compile a KDE component with gcc 3 if the rest of it was built with the distro's gcc 2.95).

Nothing like that has ever happened again with gcc, since that change, but newer versions are more persnickety in what they'll accept.

Quoting: Grogan

Quoting: slaapliedjeSomeone want to fix / recompile the original XKobo?

I thought to take a look at that but the original "unix" sources are only available as naked .C and .h files, with no project files or anything. Kind of like the bare minimum for providing sources.

So I'm not going to waste my time trying to poke at it because it's non-trivial to figure out the order the files need to be built in, just to get started. It may have been over my head anyway, but not always. I don't really know until I get poking, sometimes it's just a matter of taking a look at includes and finding the right way to define things, or it could have been as trivial as distros not providing a full SDL 1.x package (I have it).

P.S. Actually the above is not true in this instance. I found an Imakefile... gotta get macros and templates in order first to see about that though.

P.P.S Nah, I got imake to generate a working Makefile, but the source is chock full of class definitions and stuff (e.g. string to char conversions and such) that just aren't valid in C++ anymore, the compiler just isn't going to do it and while you could override it with flags and attempt to proceed, it just can't work anyway. Someone could certainly fix this, but that someone isn't me. It's not just that it would be laborious, I can't do it. Again, wouldn't know until I looked at it though.

So yes (point taken?), open source software can be just as broken if nobody capable is willing to fix it :-)

Ha, yeah, you ran down the same rabbit hole I did, and sounds like you got a little further than I did. As I started looking at the code / errors, but not knowing C or C++., I did not get past that.

I'm on your side on that though, I figured it shouldn't be terribly difficult with the source to get it working again...