4 ms·

Surely that's an OEM and driver support issue and not a Linux issue? The two don't equate if the OEMs and drivers they produce are actively supporting windows a

Surely that's an OEM and driver support issue and not a Linux issue? The two don't equate if the OEMs and drivers they produce are actively supporting windows and the developers on Linux get no support, meaning reverse engineering drivers, or late support. Yeah it's shit Linux takes longer to support newer hardware but it's hardly linuxs fault.

jeroenhd 4y ago
Linux and the Linux distros can hardly fix this problem, but for the end user it doesn't matter whose fault it is. They bought their laptop, they want it to work, and in such cases the only way to do that is through Windows. For example, the Linux kernel had a bug that caused the boot process to freeze after less than a second when you plugged in a display through an HDMI-to-DislayPort-converter on systems running Intel GPUs, caused by a change to the Intel driver that somehow interacted badly with another change in the NFS system if I recall correctly. Not your normal use case, but definitely a problem that shouldn't have taken half a year to get fixed for normal users. I ran into it when I helped a colleague upgrade to a newer version of Ubuntu (LTS to LTS) and the only way I could find to work around the issue was to pin the old, unmaintained kernel package and keep and eye out for updates on the bug tracker. If I hadn't known some deeply technical details about the system, he would've probably had to reinstall (or more likely, install Windows) and lose several days getting his dev environment set up again. There's nothing the Linux project could've done to prevent this issue and I'm not blaming volunteers for not spending their days debugging this, but for the end user such problems are unacceptable.
- sys_64738 4y ago
  > For example, the Linux kernel had a bug that caused the boot process to freeze after less than a second when you plugged in a display through an HDMI-to-DislayPort-converter on systems running Intel GPUs, caused by a change to the Intel driver that somehow interacted badly with another change in the NFS system if I recall correctly. Not your normal use case, but definitely a problem that shouldn't have taken half a year to get fixed for normal users. Ah, the cable pull test. That is a pretty standard test for QA for supported platforms.

jeroenhd 4y ago

Linux and the Linux distros can hardly fix this problem, but for the end user it doesn't matter whose fault it is. They bought their laptop, they want it to work, and in such cases the only way to do that is through Windows. For example, the Linux kernel had a bug that caused the boot process to freeze after less than a second when you plugged in a display through an HDMI-to-DislayPort-converter on systems running Intel GPUs, caused by a change to the Intel driver that somehow interacted badly with another change in the NFS system if I recall correctly. Not your normal use case, but definitely a problem that shouldn't have taken half a year to get fixed for normal users. I ran into it when I helped a colleague upgrade to a newer version of Ubuntu (LTS to LTS) and the only way I could find to work around the issue was to pin the old, unmaintained kernel package and keep and eye out for updates on the bug tracker. If I hadn't known some deeply technical details about the system, he would've probably had to reinstall (or more likely, install Windows) and lose several days getting his dev environment set up again. There's nothing the Linux project could've done to prevent this issue and I'm not blaming volunteers for not spending their days debugging this, but for the end user such problems are unacceptable.

sys_64738 4y ago
> For example, the Linux kernel had a bug that caused the boot process to freeze after less than a second when you plugged in a display through an HDMI-to-DislayPort-converter on systems running Intel GPUs, caused by a change to the Intel driver that somehow interacted badly with another change in the NFS system if I recall correctly. Not your normal use case, but definitely a problem that shouldn't have taken half a year to get fixed for normal users. Ah, the cable pull test. That is a pretty standard test for QA for supported platforms.