My statement "quite a few are having trouble" was only meant to apply to using Wine in Mint 19, apologies if I did not make that clear.

Again, the problems with wine are due to poorly written instructions at winehq. People seem to go there without even checking the repositories. Many wine problems are due to those shoddy instructions. We get left with cleaning up the mess.

The main problems (I seem to be having this discussion a lot for some reason) probably (guessing) stem from the base change. In 18.04 you can install both x86 and x64 versions of various packages including wine at the same time except that no one seems to have properly looked at making sure that this never causes clashes.

Then there were early bugs actually running things that I completely forgot because currently I only have LM19 in a VM and don't actively use it.

Then there is POL which since sometime in LM 18.x got completely useless when it comes to many of it's scripts which most people that have used it for a long time missed because they stopped using the scripts themselves.

The one giant obvious bug relating to LM19 specifically though is the wine links (the wine specific one's like uninstaller, regedit and config) in the menu applet NEVER auto generate, Q4wine is needed to manually generate them in a separate Q4wine submenu. This leads to obvious discomfort for many but for the less experienced leads them to think Wine never actually installs in the first place.

All this is true whether using the LM or winehq ropo's which is why I personally think it's most likely a 18.04 problem in some way. Either which way wine in LM19 is an utter mess for many.

All this is true whether using the LM or winehq ropo's which is why I personally think it's most likely a 18.04 problem in some way. Either which way wine in LM19 is an utter mess for many.

Why would that be a 18.04/LM19 problem? Ubuntu doesn't create Wine, they've got nothing to do with it. If you don't like Wine3, there's also Wine1.6 in the Ubunturepositories (which is what LM18 had), you're free to use to that. As always, the choice is yours.

This is not a WINE version issue, in LM18.x I used wine 2+ absolutely fine (apart from the outdated POL scripts issue which incidentally mostly used v1.6) but in LM19 there were problems right from the start NO MATTER WHAT VERSION WAS USED.... however 1.6 had slightly less issues comparatively speaking, you make too many baseless assumptions my friend.

Compartmentalization is fine for app development however it becomes less important for distribution development because distributions by their very nature exist to combine and harmonize compartments (with the optional distro-specific developed apps).... thus individual package problems potentially become distribution problems especially if they are important to the success of the particular distribution.

WINE is very much an important package, in fact it is critical to some. It is so important that for many it's ease of use out of the box is one of the big reasons for whether or not to use a distro. Remember that as a long time linux user you seem to be YOU are automatically NOT the "common user", even among common long time users WINE is a must but for new users it is absolutely critical. Since LM bills itself as a more user-friendly Ubuntu the discovery that WINE does in fact not work properly out of the box can have disastrous (subjectively mind you) consequences. The same argument can be made for GPU drivers or office suites.

LM is not a DIY kit type of Linux, it's a pre-built type using DIY kit material, tweakable but tweaking should not be mandatory.

This is not a WINE version issue, in LM18.x I used wine 2+ absolutely fine (apart from the outdated POL scripts issue which incidentally mostly used v1.6) but in LM19 there were problems right from the start NO MATTER WHAT VERSION WAS USED.... however 1.6 had slightly less issues comparatively speaking, you make too many baseless assumptions my friend.

Compartmentalization is fine for app development however it becomes less important for distribution development because distributions by their very nature exist to combine and harmonize compartments (with the optional distro-specific developed apps).... thus individual package problems potentially become distribution problems especially if they are important to the success of the particular distribution.

WINE is very much an important package, in fact it is critical to some. It is so important that for many it's ease of use out of the box is one of the big reasons for whether or not to use a distro. Remember that as a long time linux user you seem to be YOU are automatically NOT the "common user", even among common long time users WINE is a must but for new users it is absolutely critical. Since LM bills itself as a more user-friendly Ubuntu the discovery that WINE does in fact not work properly out of the box can have disastrous (subjectively mind you) consequences. The same argument can be made for GPU drivers or office suites.

LM is not a DIY kit type of Linux, it's a pre-built type using DIY kit material, tweakable but tweaking should not be mandatory.

This is not a WINE version issue, in LM18.x I used wine 2+ absolutely fine (apart from the outdated POL scripts issue which incidentally mostly used v1.6) but in LM19 there were problems right from the start NO MATTER WHAT VERSION WAS USED.... however 1.6 had slightly less issues comparatively speaking, you make too many baseless assumptions my friend.

Well, Wine2+ don't create menu entries on LM18, either, so maybe the assumptions are yours. Those menu entries are not created on purpose. The files are actually provided, but they are disabled until you manually enable them. Partially for security reasons, to prevent accidental execution of Windows malware, partially so you go look up the instructions - their argument is that you will have to tweak many programs to run correctly with Wine, anyway, so they don't want users to just click an icon, see it fail for most of their software and think Wine is broken. And last but not least, because links would have to be created for each WINEPREFIX, which can get very messy depending on your setup.

There are also Wine front-ends available in the repositories, like Playonlinux.

Anyway, I don't believe the two of you are genuinely interested in any solutions, so let's leave it at that. Feel free to direct any suggestions on how to improve Wine at the WineHQ team, at Ubuntu or the Mint team (https://github.com/linuxmint/linuxmint/issues).

This is not a WINE version issue, in LM18.x I used wine 2+ absolutely fine (apart from the outdated POL scripts issue which incidentally mostly used v1.6) but in LM19 there were problems right from the start NO MATTER WHAT VERSION WAS USED.... however 1.6 had slightly less issues comparatively speaking, you make too many baseless assumptions my friend.

This is not a WINE version issue, in LM18.x I used wine 2+ absolutely fine (apart from the outdated POL scripts issue which incidentally mostly used v1.6) but in LM19 there were problems right from the start NO MATTER WHAT VERSION WAS USED.... however 1.6 had slightly less issues comparatively speaking, you make too many baseless assumptions my friend.

Compartmentalization is fine for app development however it becomes less important for distribution development because distributions by their very nature exist to combine and harmonize compartments (with the optional distro-specific developed apps).... thus individual package problems potentially become distribution problems especially if they are important to the success of the particular distribution.

WINE is very much an important package, in fact it is critical to some. It is so important that for many it's ease of use out of the box is one of the big reasons for whether or not to use a distro. Remember that as a long time linux user you seem to be YOU are automatically NOT the "common user", even among common long time users WINE is a must but for new users it is absolutely critical. Since LM bills itself as a more user-friendly Ubuntu the discovery that WINE does in fact not work properly out of the box can have disastrous (subjectively mind you) consequences. The same argument can be made for GPU drivers or office suites.

LM is not a DIY kit type of Linux, it's a pre-built type using DIY kit material, tweakable but tweaking should not be mandatory.

Yes that is what sends newbies screaming back to Windows. WINE needs to work, and work right with minimal tweaking to make it run right.

Yes, I had some issues with Mint 19, mainly because I'm not Linux literate enough. As mentioned, I'll stick with 18.3 for the moment, but thank goodness we have a viable alternative to Windows 10, free as well, excellent.

Just my two cents - I never upgrade without thorough testing. I run Mint18.3 Mate as my primary OS but try out new versions (19x) by dual booting. So far, my trials with Mint19 have spawned only one problem - can't get shared folders to work.

As for those of you who want to try an upgrade I strongly suggest that you use caution, - backup everything you can and leave your current OS alone. Try dual booting.

One thing I like about Mint is that, with proper backups, one can reinstall and have your system up and running in less than an hour - try that with windows!

I was going to write a line here about RANTERS but it's not worth the effort.

I have tested 19 out on my wife's PC - she just dosen't know she is a test bed - it is a pretty good test because she doesn't want to be bothered with her PC. She just wants to do her research and write her documents, maintain her spreadsheets, write emails and so on.
So far no complaints. I know I'm playing with fire.

I'm liking everything the Min 19.1 so far, except for the behavior of the grouped windows panel when I want to restore all the minimized windows in the group. But I already found a workaround, so I treat it as a feature I could disable instead of a bug.

If you're looking for a greener Linux pasture, you won't find any that is greener than Linux Mint. ;)

I'm liking everything the Min 19.1 so far, except for the behavior of the grouped windows panel when I want to restore all the minimized windows in the group. But I already found a workaround, so I treat it as a feature I could disable instead of a bug.

I'm liking everything the Min 19.1 so far, except for the behavior of the grouped windows panel when I want to restore all the minimized windows in the group. But I already found a workaround, so I treat it as a feature I could disable instead of a bug.

I don't understand the excitement about that feature, anyway. MATE's panel could always do that:

grouped-mate-panel.png

It doesn't restore all the minimized windows in the group. Only one window in the group gets restored when clicking on the panel to restore. I have to hover the mouse over the specific window (which doesn't get restored automatically), then click on it to restore. It's like navigating the menu to go to an app you want to launch. This is time-consuming to me when I have a lot of Nemo windows open.

If you're looking for a greener Linux pasture, you won't find any that is greener than Linux Mint. ;)

I have tested 19 out on my wife's PC - she just dosen't know she is a test bed - it is a pretty good test because she doesn't want to be bothered with her PC. She just wants to do her research and write her documents, maintain her spreadsheets, write emails and so on.
So far no complaints. I know I'm playing with fire.

I have tested 19 out on my wife's PC - she just dosen't know she is a test bed - it is a pretty good test because she doesn't want to be bothered with her PC. She just wants to do her research and write her documents, maintain her spreadsheets, write emails and so on.
So far no complaints. I know I'm playing with fire.

You are both diplomatic - when I told my brother he used a different adjective than brave. Although I have to admit I ran 19 from a live USB on my own similar configured HP PC so I had a pretty good idea how things would/should go.