MX Linux Forum

I saw that MESA is taking off. A lot of new stuff. Same with Wine. However, I don't want to mess up my Compiz!! I was wondering if you all would add it to the test MX for us! Is that possible? :-D

have u try latest wine 3.0? a linux newbie won't be able to figure out how to use it. i've try it (revert back to wine 2.22) which i find too complex to use. extras eg. install kconsole and set hdd/usb-stick mountings, not good for any newbies, unless u know how to handle it. if mx dev(s) team can set it as easy as wine 2.22 then by all means do it. i'm not sure about mesa, i believe the last time i did upgrade to 7.3.2 and some apps didn't work properly eg. kodi.

MX is based on Debian Stable, so the latest update to hit the market is not necessarily going to be chosen for inclusion. Stability comes through copious testing and refinement and in Debian terms, stable means server grade stability. We push the enevelope a bit by adding some later version packages from Debian testing, but it's a carefully calculated and thoroughly tested compromise. There are packages which have been backported for MX and Debian Stable due to their type and usefulness, e.g. OpenOffice 6, but they're typically not showstoppers if/when they have a bug because they operate in userland, are not usually critical system packages and are easily rolled back if necessary.

The latest Mesa however, being essentially a driver element that operates at a lower level than userland packages needs to be treated with a little more caution because a failure here could bork a system. That's not to say later versions of Mesa have not been pulled in to our testing repos, they have and I've used them many times, however, there is a caveat, the closer we get to upstream testing, the more likely we are to introduce bugs, therefore system stability can become an issue.

+1

For the record, I have used Wine and I use to compile it myself for old Ubuntu 10.10. However, Wine went through a dark phase where it wasn't able to support anything higher than DirectX 9 and just didn't work very well. I'm reading that 3.x is the magic number. Direct X 10 and 11, and it's smooth sailing. I read that through some articles but I haven't seen it. I have no idea how to add 3.x on MX unless I do it from source.

Oh, and compiling from source became more difficult with the whole 32bit/64bit thing. Otherwise, I would be doing that. :-(

Wine 3.0 is in the test repo, backported from upstream Debian. It was added last week. The wine-staging project we were using came to a halt after 2.22, though som people are trying to get it going again.

I do have a newer version of Mesa in a outside repo, though: https://build.opensuse.org/project/show ... h-backport

That is awesome! Alright, I'll give it a try. There's only 1 Windows game that I play and if that worked in Linux, I'd be super happy.

You know what I wish we had? Something no other distro has: An app that compiles just a few dozen essential libraries with -O3 and -march=native for optimal gaming. :-D

I compile SDL2 with those GCC options and then drop them into Steam game directories that use them, thus replacing the game's SDL2 version with mine, and it seems to speed up the games. If we had that, MX would be the ultimate gamer distro. Just sayin....

(it's still the best distro, but just adding that feature to the comment box)

Oh, and it looks like MXinstaller was updated. Whoever did that, thank you very much!

I have Mesa 17.3.6 backported from Buster, and I'll try the amdgpu, nouveau, radeon, and intel video drivers from Buster. These'll probably go into a separate experimental repo.

Someone at winehq has a successful wine-staging 3.3 build: https://dev.wine-staging.com/builder/job/19385/

More at Phoronix: https://www.phoronix.com/scan.php?page= ... 3-Released

Cooked up wine-staging 3.3 myself--added SDL2, Kerberos 5, and Vulkan support to see how much smoke comes out. So far the versions in vanilla Stretch are enough to make it happy. We'll have to see about what we have in MX 15.

I just chatted with a fellow Linux friend and he has been using Aura. It's a package manager but it also (or it does by default?) compiles everything from source before installing. Ummmm. If we could have that... wow. I would only ask that we could add -march=native and a choice of -O2, -O3, or -Ofast. Could you imagine that? It would make MX fast like Gentoo but without all the mess!

Oh, and to do that sort of thing, I believe we would need a whitelist. Basically, only allow those files to compile which are known to work. I use to use apt-build for Ubuntu but I found some things just unhinged themselves too badly.

Stevo wrote:Cooked up wine-staging 3.3 myself--added SDL2, Kerberos 5, and Vulkan support to see how much smoke comes out. So far the versions in vanilla Stretch are enough to make it happy. We'll have to see about what we have in MX 15.

This is incredible. Thank you.

roadapathy wrote:I just chatted with a fellow Linux friend and he has been using Aura. It's a package manager but it also (or it does by default?) compiles everything from source before installing. Ummmm. If we could have that... wow. I would only ask that we could add -march=native and a choice of -O2, -O3, or -Ofast. Could you imagine that? It would make MX fast like Gentoo but without all the mess!

Oh, and to do that sort of thing, I believe we would need a whitelist. Basically, only allow those files to compile which are known to work. I use to use apt-build for Ubuntu but I found some things just unhinged themselves too badly.

What about the packages that need 12-16 GB of RAM and 25-30 GB of hard drive space to compile, like webkitgtk2? I can't see people doing that on a inexpensive or older machine.

Stevo, that's very true but the app could check for the needed space. In fact, it would have to. Ohhhh but imagine how awesome that would be! Especially since some people are choosing to use and game with Linux FOR the speed. We often argue our OS is faster, more responsive, boots faster. That would be in-line with the Linux user ethos.

Oh, and if you wanted to go a step further, each file (SDL2 library, tar, X11 system files) could have their own options menu. I mean, that would be a pain but if you were a power user and wanted to see what all could be added or removed... that would be amazing. There could be an "auto" feature first though. Maybe auto, auto-safe, auto-debug, auto-nodebug (I hate debug options because I want my libraries running lean and mean, no tracing, no profiling, no debuging!), auto-performance. If no config file exists for a file- because who is going to do all of that, right? - then you could just run the build defaults and not have any options.