Valve's Steam Survey Data Shows Linux Usage Pulling Back During June

[the_scx]

If you install a clean windows 7 as it was new 2010 and attempt to install most of those they don't work now they need the service packs so MSVC runtimes work.

So? Neither RHEL 6, nor RHEL 7 are constants. But at least Windows 7 SP1 is fully backward compatible with pure Windows 7.

Windows 7 is a brand for many different versions of it. Application compatibility does not match them all.

The compatibility issues are extremely rare here. Unfortunately, you can't say the same about RHEL 7, where minor releases break the ABI left and right, especially when it comes to the desktop.

Each version number of windows 10 has a support time frame. As applications update the in fact lose compatibility with the not currently support version of windows. This is kind of why you make sure to update windows before installing software in a rebuild.

Bullshit. Compatibility issues are extremely rare even on Windows 10. They usually don't affect normal applications and drivers. The only thing that users should really to be afraid of are shell extensions, such as a Menu Start replacement. I would say that the same applies to antivirus software, but both Microsoft and vendors take care to resolve any issues here, so end users are not affected.
What is more, Windows 10 releases from the LTSC channel are supported for at least 10 years!
On the other hand, normal releases of RHEL 7 are supported only for 2 years, and when you buy the Update Services for SAP Solutions Add-on, you have 2 years more.
Windows 10 1507 (AKA Threshold 1) was released at July 29, 2015 and it will be supported at least until October 14, 2025.
RHEL 7.6 was released at October 30, 2018 and it will be supported until October 31, 2022.
What's worse, RHEL 7 breaks compatibility left and right with each minor release.
- X.Org: 1.15 (VIDEODRV: 15.0) → 1.17 (VIDEODRV: 19.0) → 1.19 (VIDEODRV: 23.0) → 1.20 (VIDEODRV: 24.0)
- GNOME3: 3.8 → 3.14 → 3.22 → 3.28
- Gtk+3: 3.8 → 3.14 → 3.22
- Qt5: 5.5 (EPEL) → 5.6 → 5.9
- WebKitGTK: webkitgtk has been removed (there is no WebKitGTK for Gtk+2 anymore!), webkitgtk3 has been deprecated and webkitgtk4 has been added
The same applies to Linux kernel.
You have to rebuild your desktop apps and drivers for desktop hardware almost every year!

Again if you use original Windows 7 they don't work.

What is the point of using the system without any updates?!

That is exactly what Microsoft recommends for running 16 bit programs. Yet you have a problem when recommendation is chroot/container that is lighter.

16-bit programs are software from the 80's and early 90's! Now we have the 21st century! Windows 10 is able to run almost every software for Windows Vista/7/8.x, vast majority applications for Windows 2000/XP/2003, and even some programs for Windows 95/98/Me. No Linux distribution provides such good compatibility.
What is more, neither chroot, nor LXD containers are intended to deliver desktop applications.

People are force uninstalling .NET Framework 4.8 and 3.5 off of Windows 10 because they are not 100 percent backwards compatible and result in programs not working.

Again, issues here are extremely rare. On the other hand, Mono doesn't even care to provide compatibility libraries. There is no /usr/lib/mono/3.5, nor /usr/lib/mono/4.0 in Mono 4 and 5!

This is please point your finger in the right direction. Mono windows installer is also design to only really really support 1 version of mono installed at time because it nice overlaps registry keys. Linux the options of Linux you can get Mono 2, Mono 4 and Mono 5 installed at the same time. Windows not so lucky.

Again, bullshit. You can't install Mono 2, Mono 4 and Mono 5 at the same time using the official packages. They are conflict with each other! What's worse, they don't even provide Mono 2 by now.

Mono in theory of horrible should everything from .net 1.0 though to 4.8 on on under the 1 runtime.

And we already know that this is not true.

This problem with mono is not Linux distribution problem this is the Mono project upstream design goals problem.

It is a Linux problem, because this affect it as a software platform.

I noticed you did not talk about java because you can in fact install multi versions of that.

Java on desktop is almost dead. You have a few exceptions here (Eclipse, NetBeans, JetBrains products, Android Studio, Minecraft, and some legacy apps), but beyond these few examples you have practically nothing. JavaFX was the last attempt to change this, but it failed. No one is going to write GUI app in Java today. On the other hand, .NET Framework/Mono has been successful both on the desktop (WinForms, WPF, UWP, MonoMac, Xamarin.Mac, Gtk#) and the mobile market (Xamarin.Forms, Xamarin.iOS, Xamarin.Android).

Redhat distribution is for network storage servers that are very close to IoT also for server and also for desktop. Its install pattern is way closer to a IoT.

We are not talking here about network stuff or IoT solutions! We are talking about fucking desktops!

Linux distributions are not broken into market segments like Microsoft ships windows.

ROTFL!

Really most of that list of gnome applications are in flathub and when you update distribution to on a more current kernel it works well.

Bullshit. Flatpak is not available on EL5, EL6, Ubuntu 14.04 LTS, Debian 8.0, etc., and nobody is going to provide it.
To be honest, I don't really care about these distros. What is important here, compatibility issues affect the more recent systems as well. We had plenty of issues with Flatpak on RHEL7 when it was the latest stable release of RHEL (BTW: CentOS 8 wasn't released yet), and I was fighting with Flathub maintainers to provide proper support for it. But I don't want to fight anymore. I want everything to just work.

I did not say this is without pain.
https://www.zdnet.com/article/new-wi...intel-drivers/
Lets not forget that Microsoft with randomish updates can shot your drivers to hell. Redhat has basically one unified time when they are going to shot your legacy support in the head so you know when the shot it coming if you are having to run system secure or with current software. So every 5-6 years you know the hit coming with Redhat. Also the way you do it you keep old and new kernels so a fatal kill event does not happen as you can rollback to the old kernel report fault to redhat and get it fixed. Or plan to isolate that machine for security reasons.

What matters here is the scale of the problem. I was able to use some binary drivers for Windows XP on Windows Vista/7 (32-bit), as well as some binary drivers for Windows 7 on Windows 10. And it worked without any problem. On Linux, something like this is not possible at all. Of course, you can use dkms or akmod modules, but it is not the same thing. Moreover, you need to have a source code for this.
Anyway, I care more about applications than drivers.

If you are measuring from last major core kernel alteration windows 7 is somewhere around 2017 in age with EL6 for kernel being still around 2010 for core. Of course this causing problems when you want new software.

RHEL breaks the kABI (kernel ABI) all the time. You have to rebuild kmod modules with each minor release, at least when it comes drivers for GPU, network adapters, wireless adapters, Bluetooth adapters, tablets, etc.
Red Hat ports a lot of drivers and functions for each release. Sometimes entire subsystems have been backported.
Only the core part is really stable. Everything outside of kabi-whitelist is not guaranteed.

The update process between windows and redhat is different. Redhat you install a new version and chroot the old.

Again, bullshit. And even it was true, it only proves that Linux is not a good desktop platform.

Microsoft in fact broke driver support with windows 7 with SP1 and windows Updated MSVC runtimes will fail to work if you don't have SP1 on Windows 7. EL6 and Win7 sp1 is basically the same year. In fact you have MSVC runtimes checking for way newer versions of Windows and failing to work. This forces people to update their versions.

Red Hat breaks the drivers compatibility with every minor release, so stop this bullshit that the Windows model is unstable!

Chrooting/containing a installation on a newer distribution does not require reinstalling the complete thing. A full vm has you running multi kernels. Virtualised solutions from Redhat includes VM and containers and chroots. Chrooting a old EL6 using a EL7/EL8 kernel gives you a performance boost.

You have no idea what you are talking about. Nobody will replace the working systems just because of admin's whims.

Both Pixar and Dreamworks historically have chrooted their older RHEL to get the newer kernel to get higher performance. The percentage of performance gain by the better kernel is more than worth it to them.

Link or it didn't happen. Of course you can not give any source, because it's only your imagination!

This is being wrong. https://www.kernel.org/category/releases.html Linux 3.2.0 series of kernels no longer has massive effort to backport all the security patches.

I am not sure if you are a troll or just so stupid.
Ubuntu 18.04 LTS uses kernel 4.15 (EOL since April 2018). RHEL 8 uses kernel based on 4.18 (EOL since November 2018). Both are already unsupported by the kernel maintainers. And they do not have to be supported by them, because they are supported by the system vendor!
But fuck it! Go, tell companies that they are all wrong and instead of LTS distributions (like RHEL and Ubuntu LTS) they should use bleeding-edge systems (like Gentoo and Arch)!

[oiaohm]

So? Neither RHEL 6, nor RHEL 7 are constants. But at least Windows 7 SP1 is fully backward compatible with pure Windows 7.

That in fact a lie. There are many drivers and programs that will install on original windows 7 that will not work at all on Windows SP1.

The compatibility issues are extremely rare here. Unfortunately, you can't say the same about RHEL 7, where minor releases break the ABI left and right, especially when it comes to the desktop.

This is not exactly right.

- X.Org: 1.15 (VIDEODRV: 15.0) → 1.17 (VIDEODRV: 19.0) → 1.19 (VIDEODRV: 23.0) → 1.20 (VIDEODRV: 24.0)

People who try to run old graphics drivers on Windows find out this breakage rate is about the same on Windows. Just it not advertised.

What is more, neither chroot, nor LXD containers are intended to deliver desktop applications.

You find documentation in many Linux distributions using chroot to deliver desktop applications.

https://gitlab.gnome.org/GNOME/linux-user-chroot

At different times containers and chroot have be integrated into gnome and kde as mainline parts of what they are doing. So chroot and containers are tech to deliver desktop applications. Please note I said containers i am not referring to LXD. Start of the desktop containers: Bubblewrap, flatpak. snap... there are different container techs that have been developed for desktop usage.

On the other hand, Mono doesn't even care to provide compatibility libraries. There is no /usr/lib/mono/3.5, nor /usr/lib/mono/4.0 in Mono 4 and 5!

They don't provide that under windows either. This is a mono project design thing.

Again, bullshit. You can't install Mono 2, Mono 4 and Mono 5 at the same time using the official packages. They are conflict with each other

They don't conflict with each other if they are placed in individual chroot/containers right. The RHEL installer is design to make chroots. They only conflit if you attempt to place them into a single root tree. You are on Linux/Unix you don't have to have a single root tree.

We are not talking here about network stuff or IoT solutions! We are talking about fucking desktops!

No point swearing. Linux is designed to used a particular ways. Attempt to use Linux the same as windows it kicks you in tech

Bullshit. Flatpak is not available on EL5, EL6, Ubuntu 14.04 LTS, Debian 8.0, etc., and nobody is going to provide it.

Flatpak is no different to MSVC runtime mandating particular versions of Windows or newer. Too old of kernel they are not going to support that.

Of course, you can use dkms or akmod modules, but it is not the same thing. Moreover, you need to have a source code for this.

That a interesting one and a mistake on your part. akmod yes need source. dkms does not always need source. Dell has used dkms for closed source drivers where they check if current kernel provides compatible features if so alters signature on the .ko file so the new kernel will load it. Nvidia source wrapper over binary blob in dkms is another option.

RHEL breaks the kABI (kernel ABI) all the time. You have to rebuild kmod modules with each minor release, at least when it comes drivers for GPU, network adapters, wireless adapters, Bluetooth adapters, tablets, etc.

99 percent of that is not a break in the kABI. kmod ie .ko files have a marker in them that say what kernel and compiler was used to build them. CONFIG_MODVERSIONS stuff you see this as vermagic: when you do a modinfo on a module. Miss match with vermagic and Linux kernel just refuses to load the module at times even if there has not been a single kABI change.

Also these days you also have module signing as well that modinfo will also display again this has to match the system. Dell did a dkms tool that would update vermagic and signatures as required on modules.

Everything outside of kabi-whitelist is not guaranteed.

Every internal windows ABI not declared is not guaranteed either.

Red Hat breaks the drivers compatibility with every minor release, so stop this bullshit that the Windows model is unstable!

Redhat preferred policy is that drivers should be open source and integrated into the kernel. There are ways to use the same binary .ko file across multi kernel releases with only minor patches without any source. Basically updating the vermagic and signatures. Yes the kabi-whitelist from redhat exists to make this possible.

So yes it possible to release a binary .ko in a dkms package with a little update program that makes a update .ko to match the new kernel kernel vermagic and also make sure it correctly signed.

Link or it didn't happen. Of course you can not give any source, because it's only your imagination!

It was covered in a few of the movie making ofs I have. 3d movie houses care about performance more than stability.

Ubuntu 18.04 LTS uses kernel 4.15 (EOL since April 2018). RHEL 8 uses kernel based on 4.18 (EOL since November 2018). Both are already unsupported by the kernel maintainers. And they do not have to be supported by them, because they are supported by the system vendor!

Nothing like being caught by vendors messing with numbering. Ubuntu LTS 4.15 if you look at the ubuntu tree is in fact a 4.14 mainline supported to 2020 +ubuntu extra patches including bumping the version number. Really the RHEL8 being 4.18 has everyone scratching head of what the heck is going on 4.19 was expected. Yes it the redhat developer who it taking care of 4.19 mainline. Yes RHEL8 4.18 could be Redhat intentionally bumping the version number down by 1.

This is one of the hells I hate about distribution repackaging where distributions renumber stuff. Without question the Ubuntu 4.15 is 4.14 + ubuntu patches because you can check out the Ubuntu kernel git see this. RHEL8 does not have a open git of there kernel so I cannot tell you if it really a 4.18 or is a 4.19 shipping marked as 4.18 but I would be very suspect that RHEL8 4.18 is more 4.19 mainline than 4.18 mainline.

Working out EOL get really messy between Linux distributions and mainline Linux kernel due to these number changing games by distributions. Debian does not pull this crap.

[stiiixy]

Well, got my first ever (since it came out) Steam on Linux Survey the other day. surprised me so much I forgot why I even started it.

[the_scx]

That in fact a lie. There are many drivers and programs that will install on original windows 7 that will not work at all on Windows SP1.

Bullshit. Everyone who used Windows 7 knows that this is a lie. At most, there may have been minor problems with antivirus software that strongly interferes with the system, but these issues were quickly resolved by updates.

This is not exactly right.

I've already proven otherwise. RHEL 7 breaks compatibility on desktop left and right. What is worse, in some cases you had to wait literally weeks (more than a month) until some packages in EPEL are updated.

https://bugzilla.redhat.com/show_bug.cgi?id=1566338

https://bugzilla.redhat.com/show_bug.cgi?id=1578517

People who try to run old graphics drivers on Windows find out this breakage rate is about the same on Windows. Just it not advertised.

Another bullshit. These kind of issues on Windows are extremely rare. You can still use the Chrome9 HD driver from 2015 (VIA_VX900_Windows7_8_8.1_32-64-bit_241601j_VIAwSetup_LOGO.zip) in the latest version of Windows 10.

You find documentation in many Linux distributions using chroot to deliver desktop applications.

https://gitlab.gnome.org/GNOME/linux-user-chroot

Nice trolling.

THIS PROJECT IS REPLACED BY BUBBLEWRAP

It's primarily intended for use by build systems.

At different times containers and chroot have be integrated into gnome and kde as mainline parts of what they are doing. So chroot and containers are tech to deliver desktop applications. Please note I said containers i am not referring to LXD. Start of the desktop containers: Bubblewrap, flatpak. snap... there are different container techs that have been developed for desktop usage.

Bubblewrap is NOT intended for use by end users. Flatpak and Snap are, but they are no fucking suitable for everything! How many times do I have to repeat this?!

They don't provide that under windows either.

And Windows users don't give a shit about Mono, because there is .NET Framework. Even if some apps use Mono on Windows, they just bundle it. This is extremely rare on Linux, except for Unity-based games.

This is a mono project design thing.

Which is simply broken. Unfortunately, Linux users have no other choice. .NET Core is not suitable for GUI apps (or at least for Gtk#-based ones), and DotGNU is not better at this, besides it is dead for a long time (latest version was released on March 20, 2007, before .NET Framework 3.5 have appeared).

They don't conflict with each other if they are placed in individual chroot/containers right. The RHEL installer is design to make chroots. They only conflit if you attempt to place them into a single root tree. You are on Linux/Unix you don't have to have a single root tree.

I really don't want to hear this bullshit again.

No point swearing. Linux is designed to used a particular ways. Attempt to use Linux the same as windows it kicks you in tech

So Linux was not designed for use on the desktop. This explains why the "Year Of The Linux Desktop" never came.

Flatpak is no different to MSVC runtime mandating particular versions of Windows or newer. Too old of kernel they are not going to support that.

Visual C++ Redistributable Packages for Visual Studio 2017 are available for Windows XP (2001), Windows Vista (2007), Windows 7 (2009), Windows 8.x (2012/2013) and Windows 10 (2015).
Unified Visual C++ Redistributable Packages for Visual Studio 2015, 2017 and 2019 are available for Windows Vista (2007), Windows 7 (2009), Windows 8.x (2012/2013) and Windows 10 (2015).
What is more, Visual Studio 2019 is available for Windows 7. And it can targets not only Windows 7-10, but even Windows XP!

https://docs.microsoft.com/en-us/visualstudio/releases/2019/compatibility#-visual-studio-2019-support-for-windows-development

On the other hand, Flatpak is unavailable at all on EL5 (2007 ~ Windows Vista era), EL6 (2010 ~ Windows 7 era), Ubuntu 14.04 LTS (2014 ~ Windows 8.1 era) and Debian 8 (2015 ~ Windows 10 era).
And as I said, Flatpak had some issues even on RHEL 7, when it was the latest version of RHEL (BTW: CentOS 8 didn't come up yet).

That a interesting one and a mistake on your part. akmod yes need source. dkms does not always need source. Dell has used dkms for closed source drivers where they check if current kernel provides compatible features if so alters signature on the .ko file so the new kernel will load it. Nvidia source wrapper over binary blob in dkms is another option.

NVIDIA provides open source "glue" around the binary module - that is way it may works (unfortunately, not always - it is common that a new kernel breaks some things and NVIDIA have to prepare an update). There is no other way to do this. Without this kind of open source wrapper, you can do nothing. And some vendors provide only binary kmod modules. There are totally unusable on kernels other than those that are intended for.

https://elrepo.org/bugs/view.php?id=853

99 percent of that is not a break in the kABI. kmod ie .ko files have a marker in them that say what kernel and compiler was used to build them. CONFIG_MODVERSIONS stuff you see this as vermagic: when you do a modinfo on a module. Miss match with vermagic and Linux kernel just refuses to load the module at times even if there has not been a single kABI change.

Another bullshit.

https://elrepo.org/bugs/view.php?id=876

Every internal windows ABI not declared is not guaranteed either.

Nobody give a shit about the internal Windows kABI! What does matter here is the driver model: WDM (Windows Driver Model), WDF (Windows Driver Frameworks) and WDDM (Windows Display Driver Model).
KMDF 1.1, 1.5 and 1.7 supports Windows Windows 2000-10. The same applies to UMDF 1.7 and 1.9.
See also: Windows Driver Kit.
And of course, Linux has nothing like this!

It was covered in a few of the movie making ofs I have. 3d movie houses care about performance more than stability.

Were there dragons in this fairy tale?

Nothing like being caught by vendors messing with numbering. Ubuntu LTS 4.15 if you look at the ubuntu tree is in fact a 4.14 mainline supported to 2020 +ubuntu extra patches including bumping the version number. Really the RHEL8 being 4.18 has everyone scratching head of what the heck is going on 4.19 was expected. Yes it the redhat developer who it taking care of 4.19 mainline. Yes RHEL8 4.18 could be Redhat intentionally bumping the version number down by 1.

This is one of the hells I hate about distribution repackaging where distributions renumber stuff. Without question the Ubuntu 4.15 is 4.14 + ubuntu patches because you can check out the Ubuntu kernel git see this. RHEL8 does not have a open git of there kernel so I cannot tell you if it really a 4.18 or is a 4.19 shipping marked as 4.18 but I would be very suspect that RHEL8 4.18 is more 4.19 mainline than 4.18 mainline.

Working out EOL get really messy between Linux distributions and mainline Linux kernel due to these number changing games by distributions.

This is total bullshit. This is only your fantasy, which only proves that you are an ordinary troll.
There is absolutely no evidence of what you are talking about. What's more, Ubuntu 18.04 will be supported until 2023 (public patches) or even until 2028 (paid support via ESM), so even kernel 4.14 supported until Jan, 2020 is just not enough.
BTW, EL 7 uses a kernel based on 3.10, which reached EOL (End of Life) in 2017. RHEL 8 was release at May, 2019, and CentOS 8 has not appeared yet. If it were as you say, the best-supported Linux distribution would have an unsupported and insecure kernel. And don't you even dare say that it is some other kernel!

[the_scx]

99 percent of that is not a break in the kABI. kmod ie .ko files have a marker in them that say what kernel and compiler was used to build them. CONFIG_MODVERSIONS stuff you see this as vermagic: when you do a modinfo on a module. Miss match with vermagic and Linux kernel just refuses to load the module at times even if there has not been a single kABI change.

99% of what you say is just trolling. Please stop posting these nonsense statements. You clearly have no idea what you are talking about.

https://elrepo.org/bugs/view.php?id=567

As I said before, Red Hat updated the wireless stack in the 7.1 kernel from kernel-3.16, so I backported the rtl8723be driver from kernel-3.16 and as expected it builds fine against the RHEL-7.1 kernel.

This driver will only work for 7.1 - it will not work for older 7.0 kernels.

https://elrepo.org/bugs/view.php?id=582

The fix will likely to be selectively enable/edit several "if LINUX_VERSION_CODE" logicals in the Broadcom source (see below) to resolve the build failures, which are probably triggered by wireless stack updates in the new kernel.

The frustration here is that with each minor version release, red hat typically updates the wireless stack and we need to modify the srpm to accommodate the changes. Plus, we need to leave the srpm in a state that it can be built with both older (point release) and newer kernels or provide an alternative.

https://elrepo.org/bugs/view.php?id=593

You may be aware that Red Hat have recently released RHEL 7.2 as a beta test version. One of our colleagues has looked at the kernel (which will be part of that point release) and notes that the wireless stack (including the rtlwifi drivers) were backported from the upstream linux-4.1-rc6 sources.

https://elrepo.org/bugs/view.php?id=601

I've backported the driver from kernel-3.16 to match the wireless stack in RHEL7.1. Newer versions failed to build. The RHEL-7.2beta kernel updates the wireless stack to kernel-4.1 so we will likely need to update this driver for the release of RHEL-7.2, also from kernel-4.1.

https://elrepo.org/bugs/view.php?id=605

Will need to modify the nosrc.rpm to accommodate the updated wireless stack in the new EL 7.2 kernel.

https://elrepo.org/bugs/view.php?id=613

I have updated the driver from kernel-4.1.15 in line with the wireless stack in RHEL 7.2 which was backported from the 4.1 kernel branch. The driver is built against the 7.2 kernel and is not backward compatible with earlier releases.

https://elrepo.org/bugs/view.php?id=621

I tried to compile the driver from 4.4 but it seems it's a little beyond my skills when it comes to kernel development. As you said might be the case, some of the method signatures have changed so it looks like more of the bluetooth stack would also have to be updated. Alternately, it might be possible to adjust the specific patch for the 3.10 kernel but I didn't try.

https://elrepo.org/bugs/view.php?id=623

Also, there is no native EL7 .../kernel/drivers/net/wireless/wl.ko. My assumption is that your wl.ko is due to manually building the Broadcom driver, which will fail for EL7 kernels because the kernel version does not reflect the kernel wireless stack due to RHEL backporting. The wl-kmod.nosrc.rpm corrects that issue and allows a functional kmod-wl / wl.ko to be built for EL5/6/7.

https://elrepo.org/bugs/view.php?id=640

The wireless stack was backported from kernel-3.19 in RHEL6.7 so this driver will likely need rebuilding against the RHEL6.7 kernel.

https://elrepo.org/bugs/view.php?id=658

For example, much of the wireless stack was updated to kernel-3.16 in RHEL7.1 and then to kernel-4.1-rc6 in RHEL7.2.

You may well need package updates for each major upstream point release of RHEL as often Red Hat will update the wireless stack which may break existing wireless drivers, so keep an eye out for that and please do not hesitate to file a bug report should that be the case and hopefully we can look at getting that fixed.

https://elrepo.org/bugs/view.php?id=683

The current Broadcom hybrid driver anticipates usage with up to kernel 4.2. The EL 7.2 kernel used a wireless stack backported from kernel 4.1, whereas the EL 7.3 kernel contains a wireless stack backported from kernel 4.7.

https://elrepo.org/bugs/view.php?id=697

I think the breakage might be due to an updated USB stack, upon which kmod-xpad depends. I'd not really looked to hard at fixing it as no one reported it as an issue, so I assumed no one was using it. I'm not sure it's fixable, but I can take a look as and when I get time.

https://elrepo.org/bugs/view.php?id=741

The code does not build on RHEL 7.4, most likely because RHEL have backported the wireless stack in RHEL 7.4 from kernel-4.11 and the code believes it's a 3.10 kernel.

https://elrepo.org/bugs/view.php?id=786

I noticed it was broken as soon as RHEL7.4 was released. Red Hat rebased the wireless stack in 7.4 to that from kernel-4.11, and unfortunately the ath5k driver no longer compiles against the RHEL7.4 kernel.

https://elrepo.org/bugs/view.php?id=864

Trouble is, the RHEL (and CentOS) kernel is nominally a 3.10 kernel, but Red Hat have backported the WiFi stack from kernel-4.14.

So everywhere you encounter an error, you could start by checking the driver code of conditionals, and updating the code to reflect the fact the RHEL kernel more closely represents 4.14 than it does 3.10. Then be prepared to repeat the exercise for every new RHEL release, as Red Hat will most likely update the WiFi stack again for el7.6, and so forth.

As I mentioned above, keep in mind the code compiles against a vanilla kernel, it thinks the RHEL kernel is based on 3.10 but the WiFi stack is actually from kernel 4.14, and other bits could be anywhere in between.

https://elrepo.org/bugs/view.php?id=885

In contrast, the wireless stack of the standard el7 kernels have been backported so many times that the Broadcom hybrid driver needs patches related to the wireless stacks of kernel-4.7, kernel-4.8, kernel-4.11 and kernel-4.12 before the wl driver will build. Wireless stack changes are also the reasons so many elrepo wireless drivers need a rebuild at some point releases.

It is my assumption that similar things are happening in the other stacks, too.

https://elrepo.org/bugs/view.php?id=901

The driver souce code you referenced do not compile on RHEL/CentOS. Even if we could fix this, it will simply break again once el7.7 is released and Red Hat backport a new wireless stack and would need fixing again.

I can confirm that these backports are not limited to Wireless, Bluetooth and USB stacks. Do you know how I know this? Because I've been maintaining the driver for Wacom tablets for a long time. But I don't have to do this anymore, because Red Hat finally included a quite fresh driver in the EL7 kernel.

[oiaohm]

Bullshit. Everyone who used Windows 7 knows that this is a lie. At most, there may have been minor problems with antivirus software that strongly interferes with the system, but these issues were quickly resolved by updates.

Anyone who has handled old printer drivers on Windows knows this is not a lie. Windows 7 SP1 killed lots of different printers from working. There is other software like this as well userspace specialised and broken.

I've already proven otherwise. RHEL 7 breaks compatibility on desktop left and right. What is worse, in some cases you had to wait literally weeks (more than a month) until some packages in EPEL are updated.

EPEL is a third party repository out of alignment with what RHEL is shipping. They are not shipping their own runtime parts that are ABI unstable.
However, EPEL is maintained by a community of people who generally volunteer their time and no commercial support is provided.
Redhat is very clear the may host EPEL but they don't work on them and don't make sure those packages 100 percent obey the rules.

Another bullshit. These kind of issues on Windows are extremely rare. You can still use the Chrome9 HD driver from 2015 (VIA_VX900_Windows7_8_8.1_32-64-bit_241601j_VIAwSetup_LOGO.zip) in the latest version of Windows 10.

That driver stuck to stable windows KABI. Nvidia and ATI drivers historically did not. You can pick lucky ones that work I can do the same on redhat of course it requires the driver maker to have obeyed Redhat KABI rules.

Visual C++ Redistributable Packages for Visual Studio 2017 are available for Windows XP (2001), Windows Vista (2007), Windows 7 (2009), Windows 8.x (2012/2013) and Windows 10 (2015).
Unified Visual C++ Redistributable Packages for Visual Studio 2015, 2017 and 2019 are available for Windows Vista (2007), Windows 7 (2009), Windows 8.x (2012/2013) and Windows 10 (2015).
What is more, Visual Studio 2019 is available for Windows 7. And it can targets not only Windows 7-10, but even Windows XP!

What you quoted did not say Windows 8.x it only says Windows 8.1 because they numbered the service pack.

https://support.microsoft.com/en-au/help/2661358/minimum-service-pack-levels-for-microsoft-vc-redistributable-packages

Older versions of the documentation they use to state service pack numbers. Like Windows 7 SP1. Now they don't state service pack numbers and it means That version of windows all the updates to the point of release of that package.

On the other hand, Flatpak is unavailable at all on EL5 (2007 ~ Windows Vista era), EL6 (2010 ~ Windows 7 era), Ubuntu 14.04 LTS (2014 ~ Windows 8.1 era) and Debian 8 (2015 ~ Windows 10 era).
And as I said, Flatpak had some issues even on RHEL 7, when it was the latest version of RHEL (BTW: CentOS 8 didn't come up yet).

So all your years of compare here are wrong like it or not. because if you get a Windows 7 without update many new programs are not going to run because the Visual C++ Redistribute will error out due to updates missing. This is a nice counter measure to those why pirate and say I will not install updates. Microsoft system goes fine but you cannot use new software either.

NVIDIA provides open source "glue" around the binary module - that is way it may works (unfortunately, not always - it is common that a new kernel breaks some things and NVIDIA have to prepare an update). There is no other way to do this. Without this kind of open source wrapper, you can do nothing. And some vendors provide only binary kmod modules. There are totally unusable on kernels other than those that are intended for.

This is not true. NVidia is known not to always stick to the redhat document kernel-kabi-whitelist same with third party drivers.

Binary kmod modules work quite well on Linux as long as all the rules put down by redhat are obeyed. Using a single function not on the whitelist will ruin that.

Nobody give a shit about the internal Windows kABI! What does matter here is the driver model: WDM (Windows Driver Model), WDF (Windows Driver Frameworks) and WDDM (Windows Display Driver Model).
KMDF 1.1, 1.5 and 1.7 supports Windows Windows 2000-10. The same applies to UMDF 1.7 and 1.9.
See also: Windows Driver Kit.
And of course, Linux has nothing like this!

This is wrong what the Linux world has the same is the redhat kernel-kabi-whitelists that is highly ignored by driver developers.

There is absolutely no evidence of what you are talking about. What's more, Ubuntu 18.04 will be supported until 2023 (public patches) or even until 2028 (paid support via ESM), so even kernel 4.14 supported until Jan, 2020 is just not enough.

https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack

It is enough because before 2020 end of life of 4.14 Ubuntu will with the Hardware Enablement stack in fact change the Linux kernel version. You can see it on 16.04 where it started on 4.4 Linux kernel and it currently what ubuntu calls 4.15. Its basically 2 releases on the first kernel then kernel version change with Ubuntu. So at least the Ubuntu version numbers are staying closer to real than Redhat kernel version numbers.

BTW, EL 7 uses a kernel based on 3.10, which reached EOL (End of Life) in 2017. RHEL 8 was release at May, 2019, and CentOS 8 has not appeared yet.

All the elrepo bugs that you go on and point to for proving so called instability show that the redhat kernel version numbers are in fact bogus. KERNEL_VERSION value on a Redhat kernel has almost not meaning for what kernel tree its really based on. This is why those attempting to build from drivers from source on RHEL kernels and have not obeyed the kernel-kabi-whitelist is mega screwed and this is basically intentional by Redhat.

99% of what you say is just trolling. Please stop posting these nonsense statements. You clearly have no idea what you are talking about.

https://access.redhat.com/solutions/444773

I do know what I am talking about what do all those elrepo bugs have in common. They are using stuff that is not covered by the kernel-kabi-whitelists package of redhat.

I can confirm that these backports are not limited to Wireless, Bluetooth and USB stacks. Do you know how I know this? Because I've been maintaining the driver for Wacom tablets for a long time. But I don't have to do this anymore, because Red Hat finally included a quite fresh driver in the EL7 kernel.

Redhat does not make life easy for those making third party drivers who don't obey their kernel-kabi-whitelists. Like KERNEL_VERSION checks are next to worthless.

Basically in what is classed as stable Linux kernel abi there has not been a breakage in all those cases.

All the failures to build drivers against redhat kernel is more examples of those making drivers for Linux not choosing to want a stable ABI in kernel. Redhat is providing a stable ABI for the Linux kernel. Yes if you restrict your driver code to ABI whitelists of redhat you can do exactly what I described of changing the version information on the driver and had it work on a different kernel.

Of course Redhat does not care if they break you if you are not obeying the rules. The same way Microsoft does not care if your driver is using some internal feature not openly documented.

Basically all that elrepo trouble is you disobeying the maker. This is why the arguement that Linux does not have a stable kernel driver ABI is bogus. Redhat makes a stable kernel driver ABI for the Linux kernel then driver makers don't use it. There are not enough drivers using the kernel-kabi-whitelist to make it mainline Linux kernel documentation.

Basically like it or not the_scx the documented stable Linux kernel ABI by redhat is not breaking. The drivers you listed and the ones you were attempting to build were using the documented unstable ABI or what in Microsoft would be called internal only or what redhat wants you to get your driver merged Linux mainline to use(as in internal).

There are ways things are meant to be done.

Really its funny you hear if Linux had a stable Linux kernel driver ABI it would have more drivers. The reality Linux does have a stable Linux kernel driver ABI provided by Redhat and basically nobody uses it and instead uses the unstable ABI/API stuff.

[the_scx]

All the failures to build drivers against redhat kernel is more examples of those making drivers for Linux not choosing to want a stable ABI in kernel. Redhat is providing a stable ABI for the Linux kernel. Yes if you restrict your driver code to ABI whitelists of redhat you can do exactly what I described of changing the version information on the driver and had it work on a different kernel.

Of course Redhat does not care if they break you if you are not obeying the rules. The same way Microsoft does not care if your driver is using some internal feature not openly documented.

Basically all that elrepo trouble is you disobeying the maker. This is why the arguement that Linux does not have a stable kernel driver ABI is bogus. Redhat makes a stable kernel driver ABI for the Linux kernel then driver makers don't use it. There are not enough drivers using the kernel-kabi-whitelist to make it mainline Linux kernel documentation.

With every post you prove that are just a pathetic troll. This kabi-whitelist doesn't even cover the USB stack, which, of course, often changes, so how the hell the vendors can stick to it?! It's like saying that game developers don't want to stick to the POSIX standard, because they use OpenGL or Vulkan! Think, fool!
How the vendor is supposed to create a driver for a USB input device (i.e. gamepad, joystick, tablet, etc.) without symbols such as input_allocate_device, input_event, input_free_device, input_register_device, input_set_abs_params, input_set_capability and input_unregister_device?!
How the vendor is supposed to create a driver for a USB wireless adapter without symbols such as release_firmware, usb_bulk_msg, usb_control_msg, usb_deregister and usb_register_driver?! I don't even mention symbols like malloc_sizes or mcount, which are pretty common here.
How the vendor is supposed to create a video card driver without symbols such as capable, __free_pages, ioremap_wc, set_memory_uc and set_memory_wb?! I don't even mention symbols like screen_info or register_acpi_notifier and unregister_acpi_notifier, which are pretty common here.
What's worse, this kabi-whitelist only applies to a single major release of EL (so the kernel-kabi-whitelist for EL7 doesn't include all symbols from the kernel-kabi-whitelist for EL6, it isn't even close to this). And even this is not 100% guaranteed, because we already had cases when some symbols were removed (e.g. between EL 6.0 and EL 6.1, EL 6.2 and EL 6.3, EL 6.6 and EL 6.7, EL 7.0 and EL 7.1, etc.). Moreover, there are symbols that are platform-specific (e.g. i686-only or x86_64-only). And of course, all this applies only to RHEL and compatible distributions. It has no impact on any other Linux systems.
You know what? I don't want to waste my time discussing with you anymore. Go tell your fables to someone else.

[oiaohm]

With every post you prove that are just a pathetic troll. This kabi-whitelist doesn't even cover the USB stack, which, of course, often changes, so how the hell the vendors can stick to it?! It's like saying that game developers don't want to stick to the POSIX standard, because they use OpenGL or Vulkan! Think, fool!

Maybe it missing because there is another way that is abi stable for USB devices..

How the vendor is supposed to create a driver for a USB input device (i.e. gamepad, joystick, tablet, etc.) without symbols such as input_allocate_device, input_event, input_free_device, input_register_device, input_set_abs_params, input_set_capability and input_unregister_device?!

https://xboxdrv.gitlab.io/

There is not a requirement to ship a single bit of code in kernel space to support a USB input device on Linux this is because of the uinput module.

If you use what is provided stable in the kabi-whitelist and what is provided stable in the userspace ABI of the Linux kernel that is stable you can support a huge number of devices. This is not like sticking to the Posix standard and not having OpenGL/Vulkan.

How the vendor is supposed to create a driver for a USB wireless adapter without symbols such as release_firmware, usb_bulk_msg, usb_control_msg, usb_deregister and usb_register_driver?! I don't even mention symbols like malloc_sizes or mcount, which are pretty common here.

Another stack of stuff that is accessible by libusb from userspace and stable. Network device can be done in userspace by either tap or tun.

So these first two examples really you can implement both these driver types 100 percent stable done using the stable userspace ABI of the Linux kernel. Ok will not be the best performing on input device overhead is low enough it not noticed in most cases. Networking its under 10 percent hit. Yes these drivers could be complete static linked userspace binaries.

How the vendor is supposed to create a video card driver without symbols such as capable, __free_pages, ioremap_wc, set_memory_uc and set_memory_wb?! I don't even mention symbols like screen_info or register_acpi_notifier and unregister_acpi_notifier, which are pretty common here.

The work to do this as a usermode driver is not complete any more. This is one where you need to do a Nvidia and in fact work with redhat on making sure the functions you want are ABI stable.

What's worse, this kabi-whitelist only applies to a single major release of EL (so the kernel-kabi-whitelist for EL7 doesn't include all symbols from the kernel-kabi-whitelist for EL6, it isn't even close to this). And even this is not 100% guaranteed, because we already had cases when some symbols were removed (e.g. between EL 6.0 and EL 6.1, EL 6.2 and EL 6.3, EL 6.6 and EL 6.7, EL 7.0 and EL 7.1, etc.). Moreover, there are symbols that are platform-specific (e.g. i686-only or x86_64-only). And of course, all this applies only to RHEL and compatible distributions. It has no impact on any other Linux systems.

No this is a different problem. What is in the kabi-whitelist is made by third party driver developers who are working with redhat and informing redhat what ABI they are in fact using. Once all current versions of third party drivers of those working with redhat are no longer using something it disappears out of kabi.

Were you working directly with redhat no. Where you punished for not working with redhat kernel development team on your driver hell yes. Does this require you to pay some money to redhat yes it does.

You know what? I don't want to waste my time discussing with you anymore. Go tell your fables to someone else.

The problem here is sometimes there two ways todo something. One way will be insane hard. Like input devices there is no need to make a kernel driver under Linux for any of them. If you choose to go kernel driver for a input device you should be mainlining it under Linux. Otherwise be happy with uinput and libusb and the like the stable ABI. Attempting to stand as Linux kernel mode driver third party in an area where there is a stable userspace driver interface basically asking to get hurt badly.

If you are doing something that really need to be kernel mode driver and it has to be third party for years now its been work closely with redhat and pay money.

the_scx it will be really hard at first to accept your problem was that you are taking on the problem the incorrect way. Linux kernel provides a lot of stable ABI it does pay to check when coding something if you can stick to the redhat kabi-whitelist if you can this mean paying and working directly with redhat or if the truly stable userspace ABI for drivers from the Linux kernel will do the job.

There really was no reason todo watcom tablet support as a kernel mode module other than that you were seeing code being developed to be mainlined in future and it avoid you having to code up a usermode version.

Basically lots of the drivers I see in the third party repo are in fact making their life hard by making a kernel mode driver using unstable abi when there is no reason to.