[paranoidrobot]

> What this ignores is that Linux driver support is generally fantastic, works out of the box in a way that desktop architects at MS dream about and is infinitely more current in practice since you go to one place to update all your software, including driver software, something MS hasn't been able to get right in a decade of trying.

Generally, yes, it's pretty decent on first go and there's a nice default happy path.

Unfortunately in my own experience, that path isn't particularly wide, and there's a huge number of gaps.

Version compatibility is a major issue, imo. One driver or package works great on one kernel version is completely broken on the next.

A few hours ago I tried to install the official AMD drivers for Ubuntu. It's not until the install script has already gone and screwed up my system that I get told that they don't support 19.04.

I just don't have that issue on Windows as a rule. I'm not claiming Windows is perfect by any means, it's got it's own set of issues.

[posix_me_less]

Version incompatibility is expected, because Linux kernel changes a lot. You need the correct driver for your kernel. The amdgpu driver is a part of Linux distribution, your best option is to install it from Ubuntu apt repository, not from manufacturer's website. Which now explicitly and clearly says the driver is for Ubuntu 18.04 only - did you not see that?

[paranoidrobot]

> Version incompatibility is expected, because Linux kernel changes a lot.

Expected by whom, though?

I could understand it if it was major kernel versions or something like that, but it seems that a whole bunch of things are really tightly linked.

> Which now explicitly and clearly says the driver is for Ubuntu 18.04 only - did you not see that?

I honestly didn't. I went back and checked - yep, it does say for 18.04[1].

I have to say though that I wouldn't have automatically assumed it was ONLY for 18.04 though without it being more explicit about that. If the official drivers are available within the repo from now on, then it'd be great for AMD to actually say that. (I realise this isn't Ubuntu's fault)

[1] https://www.amd.com/en/support/graphics/amd-radeon-hd/amd-ra...

[posix_me_less]

Of course, not expected by a basic user. But if you follow Linux, it is quite well known that the Linux project intentionally does not promise stable internal api in the kernel, they "run a tight ship" where if a program needs to use kernel api, it has to be maintained in the Linux tree. Given this modus operandi of the Linux project, breakage of the old drivers with the new kernel version is expected.

Advice to Linux users: one would best get their the graphics driver and a matching Linux kernel from the same source, either the Linux project, or the OS distribution. Mixing versions downloaded from AMD website with random kernel is supported by nobody and is testing your luck. That is a Windows model and kind of works with Linux only with nvidia drivers for their hardware, although it brings a lot of headaches too.

I agree that the installer should have warned you about the incompatibility at the beginning of the install, not at the end. That sucks.

With graphics, it is usually best to run the newest drivers with Linux, that means the newest kernel possible. Except for the older cards, which are not supported by AMD anymore (which sucks), where one can only use old drivers with appropriate old kernel.

[ndarwincorn]

Those are pretty old cards though (I've had amdgpu support for my six year old 7970 since kernel 4.9, and I think they've extended it back to a generation or two older architectures now), and you can use the open source radeon drivers with any kernel.

I think the folks using Catalyst for better 3D acceleration have probably moved on to cards supported by amdgpu by now.

[filmor]

Version compatibility is not an issue for in-kernel drivers, only for the few remaining external ones. On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista, on Linux, once a driver is in the kernel it's continuously adjusted to driver API changes and will keep working. You can still run a current kernel on a 386 if you want to.

I'm running a quite current Dell on an essentially unpatched kernel (just includes Gentoo's default patches) with no additional modules involved and everything I tested up until now works, even fancy things like Dell's mini-dock.

[paranoidrobot]

> On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista,

I think that's a bit of a difference though. Vista came out nearly ~13 years ago, and we're talking things breaking a year or less later.

Heck, for more obscure drivers[1], it seems necessary to recompile for every kernel patch. Perhaps that's the fault of that driver's developer for not following the correct way to build kernel drivers, or there's something unique about this particular device - I don't know.

[1] an example: https://github.com/milesp20/intel_nuc_led

[filmor]

> > On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista,

> I think that's a bit of a difference though. Vista came out nearly ~13 years ago, and we're talking things breaking a year or less later.

I'm not. I'm talking about the fact that drivers for devices older than me that have been merged into the kernel keep on working today while on Windows for some subsystems (like graphics or sound) you can't expect things to work after "just" 15 years. I admit that this is a long time, it's still a huge difference.

And yes, on Linux you are expected to recompile drivers for every new kernel version, that's intentional (https://github.com/torvalds/linux/blob/master/Documentation/...). Since the driver API is reasonably stable, the code doesn't need to be adjusted for every version, and if the driver has landed in the kernel, this is done while changing the API.

[mkesper]

Linux driver support is fantastic because it's not made by manufacturers.

[qplex]

This is not correct.

Many manufacturers contribute drivers to the kernel.