It's a question of getting the answer to your question, as opposed to getting an answer that you want to hear (read). And that's fine as far as it goes, I suppose - because it is, to some extent, human nature, and we've probably all suffered some form of it at one time or another. As an extreme example, the person who visits their doctor due to a cancer scare and who would be very likely to thank their doctor if told, "No, Tom, you can relax and go on home, you're fine" - but has no word of thanks to offer if the doctor, instead, says, "Tom, we're going to have to do a biopsy."

But we get new members here every day, people who don't "know" one member from another and have to depend much on others' responses to determine which of the members tend to give good, factual advice. One of those new members, upon seeing someone (in this particular case, you) make a point to thank one person directly after not giving the same courtesy to someone else who'd just done what they'd asked them to... Well, it can and does sometimes make others wonder about the accuracy of that first responder's statements.

Which, in this case, happen to be true - you just did not like what you read. Unfortunately, not everyone reading this thread in the future will immediately realize that.

Some folks offer their thanks regularly and often; others rarely, if ever, do. Either way is fine (at least if one disregards the politeness aspect) - because both are consistent behaviors. It's the inconsistency of the thing, and/or what happens when someone lets their own expectations color the perceived worth of the answer... that their behavior is judged to be "passive aggressive" behavior.

Better if you had thanked no one...

Regards,
MDM

Mint 18 Xfce 4.12.

If guns kill people, then pencils misspell words, cars make people drive drunk, and spoons made Rosie O'Donnell fat.

When assistance is requested, same should be offered if possible. What was offered to me was not assistance - it was lecturing. Much as you just did. My basic questions were never answered. Had I experienced same several years ago when starting out in Mint, I would merely have moved on.

Although I use Linux Mint, I do not recommend it any longer. What was at one time a very helpful cadre of experts, has devolved into lecturers. It was the friendly expertise of the forum that made Mint great.That is gone.Too bad, as you are giving Linux Mint a bad rap. And, of course, a bad rap causes explorative users to move on.

No need to answer this, as I see no reason to continue the charade of "available expertise" on this forum.

The three responses were definitely correct, though I can see how the first one can be seen as dismissive. You could almost hear the sigh.

So, I can see where Linux-Bill is coming from. But I always try to thank anyone who even tries to answer, if I'm naming those who reply.

But...

This is not a support announcement or thread. If there's a problem with Wine on the current 19, there are probably numerous answers that would help to fix the problem (which he apparently did find elsewhere). As for 19.1, only clem could answer if there is anything that needs to be adjusted re: Wine as it works with Linux Mint.

My thought is find the fix for 19 and see if it still works when 19.1 comes out.

Mint 19 is currently on 18.0. Those of us with Vega based APU's would be overjoyed if it would ship with 18.2+ :p

You do not want Mint 19.1 for that. Mint does not do its personal kernels.

four.17 and four.18 kernel collection are presently available within the repositories for upcoming Ubuntu 18.10. I endorse you use the ones instead of the uncooked mainline kernels that ukuu offers. individually i'm the use of the four.18 series. Make a new thread in case you need help with that.

once Ubuntu 18.10 is released subsequent month, the kernel from that release can be made to be had to Ubuntu 18.04 = Mint 19.x inside the ordinary repositories as well, that's what Ubuntu calls the hardware Enablement (HWE) stack. In case of doubt just anticipate that.

I've been using the cosmic kernels from the main cosmic and cosmic-updates repository for my fiance's Raven ridge build. I did have her on 4.18.0-10 but even that results in periodic hard freezes. Then I tried the 4.19.1 kernel, manually downloaded from the mainline kernel repository to test if it would solve this issue. My fiance told me she got another hard freeze after a couple of days.

It's almost a bit crazy to me that an APU that has been out as long as the 2400G has still doesn't have full reliable support. When I built this computer for her, I didn't even consider the fact that the 2400G would be too new to work properly on current kernels, based on the fact that the Ryzen architecture was launched in December of 2016, and the Vega based APU architecture was launched with the Vega 64 in August 2017. That's almost two years and more than one year respectively, and that at least used to be a bloody eternity in computer time, at least back when I was in college upgrading my CPU/Motherboard annually, and my GPU every 6 months.

AMD really needs to step up and get involved with the kernel dev teams early on before release. IMHO, if you don't have full hardware support in current distributions by 2 months after launch, you are done. PC product cycles may be longer today than they were 20 years ago, but even so, no one wants to buy hardware and have it depreciate in front of their eyes before they can even fully use it.

I never have this problem with either Intel or Nvidia. Stuff just works out of box on launch day.