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

[the_scx]

It's extremely difficult if you have to integrate them with the system libs, aka "the Linux way".

If you just don't care and bundle all libs you need with the application ala Windows it's not particularly hard. At most you need to hard-code some library paths or something.

Only pain point is the integration in the systray, or maybe into the system notifications.

How many packages have you created in your life? I've created hundreds of them (maybe even thousands), and I know what is doable and what is not.
Your method is feasible if you have only a few simple dependencies. For example, I had to build my version of libtiff4 for RawTherepee, then use rpath, because the system library was too old.
However, it is not the case when your app have requires half of GNOME libraries. Then you literally create your own distribution. Flatpak (Freedesktop and its derivatives: GNOME and KDE) and Snap (Core 16, Core 18) do this, but it's not a job for just one person.
And it is even worse when the program requires key components that are not included in the system, such as PulseAudio, PipeWire, systemd or some of kernel capabilities (e.g. cgroups). Then you are grounded.

Of course, Flatpak and Snap can help in some cases, but none of them is a magic cure for Linux problems. In addition, they are not available for older systems.

[the_scx]

I think you need to look again. LSB was not a complete failure.

So please provide LSB-compliant RPM packages for the aforementioned software or be silent.

[starshipeleven]

Your method is feasible if you have only a few simple dependencies. For example, I had to build my version of libtiff4 for RawTherepee, then use rpath, because the system library was too old.

As I said, if I'm making a comparison with Windows I'm not giving a flying fuck about system libs, I compile the application with a chroot using old packages, and then ship all libraries the application needs in its own folder, using a script to force-load and then launch he application in its own chroot or with libraries loaded. (and yes I've done this enough times already for shitty server applications)

If the application is opensource it's even easier as I can just hard-code the lib paths instead of relying on the system.

However, it is not the case when your app have requires half of GNOME libraries. Then you literally create your own distribution.

or add 200-300MB of shit in your application folder. Problem?

Flatpak (Freedesktop and its derivatives: GNOME and KDE) and Snap (Core 16, Core 18) do this, but it's not a job for just one person.

That's the "proper way" to do it, the way that might be somewhat safe. But is that what Windows does? No it isn't, so why should we limit ourselves to higher standards?

And it is even worse when the program requires key components that are not included in the system, such as PulseAudio, PipeWire, systemd or some of kernel capabilities (e.g. cgroups). Then you are grounded.

You can workaround most userspace issues with a chroot, and installing even more shit in the folder (it basically becomes more like a poor man container than anything else). Of course you can't workaround kernel feautures.

But anyway this is outside of the scope of the comparison, you can't usually take a native Windows 10 application and expect to run it on XP without breakage either, especially if it does talk with system like that.

[the_scx]

As I said, if I'm making a comparison with Windows I'm not giving a flying fuck about system libs

On Windows, you have at least a standard toolkit (see: WinAPI, especially comctl32.dll). On Linux, literally nothing is guaranteed. Neither Gtk+2, nor Motif/Xaw/OLIT, nor even Xt (X Toolkit Intrinsics).
On Windows, you have GDI/GDI+, which can handle fonts and palettes. You can use it for drawing lines and curves as well. On Linux, you can't be so sure that fontconfig, FreeType, Xlib/XCB, Cairo will be available.
On Windows, you can use Windows API (GDI+ or WIC) to open bitmaps, for example PNG files. On Linux, libpng, libjpeg, libgif, libtiff are not guaranteed.
On modern Windows, you don't have to worry about .NET Framework. It is a pre-installed component. On Linux, neither Mono, nor Java are guaranteed.
On modern Windows, you don't have to worry about DirectX. It is a pre-installed system library. On Linux, even OpenGL and Vulkan drivers are not guaranteed, not even mention SDL2 or OpenAL.
Damn, the latest Ubuntu drama showed us that even 32-bit glibc is not guaranteed. Beyond the kernel, literally nothing is guaranteed.
https://www.phoronix.com/scan.php?pa...op-Issues-2018

https://gitlab.com/probono/platformissues

I compile the application with a chroot using old packages, and then ship all libraries the application needs in its own folder, using a script to force-load and then launch he application in its own chroot or with libraries loaded. (and yes I've done this enough times already for shitty server applications)

A CLI application is not the same as a GUI application. In the case of a console app, you don't have to worry about system tray, notification system, GNOME Printing UI, GNOME Help system, PolicyKit, PackageKit (see: gImageReader), etc. Even bundling games is much easier, than creating packages for GUI programs.

If the application is opensource it's even easier as I can just hard-code the lib paths instead of relying on the system.

For binaries, you can use chrpath and patchelf, or even some kind of wrapper. However, it does not change anything about the main problem - you have to provide all necessary dependencies, in one way or another.

or add 200-300MB of shit in your application folder. Problem?

Rather a few GB. And yes, that's a problem, because you have to maintain this on your own.
And if you think that you can re-use packages from e.g. Fedora 30, then you are wrong. You can't. Everything here is compiled against Linux 3.2.0. EL6 provides Linux 2.6.32 and EL5 provides Linux 2.6.18.
What's worse, glibc 2.26 (used in Fedora 27 and Ubuntu 17.10) requires at least Linux 3.2 on all platforms. There is no way to get around this requirement.

Anyway, as a software developer, you definitely won't waste your time on this. Most users won't either.

That's the "proper way" to do it, the way that might be somewhat safe. But is that what Windows does? No it isn't, so why should we limit ourselves to higher standards?

Try to use any IDE (maybe except GNOME Builder) on Flatpak and you will find out why it is not suitable for everything.
https://github.com/mono/monodevelop-...ment-362921797
Anyway, as I said, neither Flatpak, nor Snap are available for EL5/EL6.

You can workaround most userspace issues with a chroot, and installing even more shit in the folder (it basically becomes more like a poor man container than anything else). Of course you can't workaround kernel feautures.

No, you can't. If your program needs systemd, you have to install systemd on your host. If your program really needs Wayland (i.e. not compatible with X.Org), you have to install Wayland on your host. If your program needs Pipewire, you have to install Pipewire on your host. You can't just put this inside the chroot/LXD container. It won't be enough.

But anyway this is outside of the scope of the comparison, you can't usually take a native Windows 10 application and expect to run it on XP without breakage either, especially if it does talk with system like that.

Windows 10 is the latest version of Windows. However, almost all Windows applications will work on Windows 8.x (2012/2013) or even Windows 7 (2009). What's more, quite a lot of modern programs will work on Windows Vista (2007) and maybe some apps can even work on Windows XP (2001).
RHEL 8 is the latest version of RHEL. However, none of EL8 packages will work on RHEL 7 (2014). Fortunately, you should still be able to install quite a lot of modern GUI application on it, in one way or another. It is not always easy, but it is doable. Unfortunately, this is not the case for EL6 (2010 - BTW, newer than Windows 7). Most current apps won't work here, no matter how much you try. And for EL5 (2007), you won't be able to deliver literally anything released in recent years, at least when it comes to GUI applications. The kernel is simply too old.
Do you see difference?

[oiaohm]

So please provide LSB-compliant RPM packages for the aforementioned software or be silent.

Really you need to shut up. LSB is not the current standard. Even so GUI applications from different printer makers still come out LSB DEB and RPM and still work on current Debian/Ubuntu.

Also what you have requested with current versions of those programs built for old versions of Linux does not work under windows either some of the applications in the same class.
https://theblog.adobe.com/upcoming-c...ndows-and-mac/

Pitivi is in the class of Adobe premiere being video editing. So running current version on old versions of libraries bundled with an OS can be next to impossible with video editing software and this is normal under Windows yet you are asking for that to be done under Linux. So the list of applications you wanted old Linux distribution to support many in that list a old version of Windows cannot work either.

Under Linux I can install chroot and still run those newer applications while having the core OS the old version..

In Windows, you have at least a standard toolkit (see: WinAPI, especially comctl32.dll). In Linux

Yes I will give you here that only recent with portals with flatpak and snap are you seeing something like a comctl32.dll.

literally nothing is guaranteed. Neither Gtk+2, nor Motif/Xaw/OLIT, nor even Xt (X Toolkit Intrinsics).
In Windows, you have GDI/GDI+, which can handle fonts and palettes. You can use it for drawing lines and curves as well. In Linux, you can't be so sure that fontconfig, FreeType, Xlib/XCB, Cairo will be available.
In Windows, you can use Windows API (GDI+ or WIC) to open bitmaps, for example PNG files. In Linux, libpng, libjpeg, libgif, libtiff are not guaranteed.
In modern Windows, you don't have to worry about .NET Framework. It is a pre-installed component. In Linux, neither Mono, nor Java are guaranteed.
In modern Windows, you don't have to worry about DirectX. It is a pre-installed system library. In Linux, even OpenGL and Vulkan drivers are not guaranteed, not even mention SDL2 or OpenAL.

If you are covering every version of Windows 10 include IoT versions. Everything listed there in the Windows 10 IoT version can be complete missing.

Modern windows not having to worry about .NET framework what a laugh as well.
https://answers.microsoft.com/en-us/...d-7a4e5b947771
People are working out how to uninstall the provided .NET Framework in Windows 10 so they can get old applications to work. ,NET framework might be pre-installed in windows nothing says it the right version for your application and nothing say that someone did not change it to a different version so other applications work.

Damn, the latest Ubuntu drama showed us that even 32-bit glibc is not guaranteed. Beyond the kernel, literally nothing is guaranteed.

32 bit support under windows can be disabled by register as well and it optional to be installed in IoT versions of Windows 10 and can be registry disable in current server and desktop editions of Windows by group policy. So 32 bit support is not guaranteed under windows either.

So far every you have said is in fact the same on Windows IOT.

A CLI application is not the same as a GUI application. In the case of a console app, you don't have to worry about system tray, notification system, GNOME Printing UI, GNOME Help system, PolicyKit, PackageKit (see: gImageReader), etc. Even bundling games is much easier, than creating packages for GUI programs.

You are listing a lot here that Libreoffice, Firefox and Wine don't stuff about. System tray and notification are a protocols so they can be implemented in your own libraries. You don't have to use the Gnome parts either. The list comes very short once you cut it down.

And if you think that you can re-use packages from e.g. Fedora 30, then you are wrong. You can't. Everything here is compiled against Linux 3.2.0. EL6 provides Linux 2.6.32 and EL5 provides Linux 2.6.18.
What's worse, glibc 2.26 (used in Fedora 27 and Ubuntu 17.10) requires at least Linux 3.2 on all platforms. There is no way to get around this requirement.

LD_ASSUME_KERNEL= its a interesting loader option. Yes you can force the linux kernel version reported to glibc to be newer than what you in fact have. This does not always work either. Of course there is the option of running EL6 and EL5 on newer kernels that Redhat does provide. I don't know why you are talking about RHEL5 and 6.

https://access.redhat.com/support/policy/updates/errata

Because all it says you have not read the Redhat support policy. Notice the using Virtualization after you enter Maintenance
Support 2. This is full blown VM or containers. After a RHEL gets over 8 years old you are no longer meant to install it as the primary OS.

https://www.redhat.com/cms/managed-f...807-en_0_0.pdf

By the way you don't buy RHEL by version. You buy it by subscription that gives you access to all versions. So yes having RHEL5, RHEL6 and RHEL7 on the same system is legal. Of course RHEL7 will be the host and by now RHEL5 and 6 should be guests of some form chroot, containers or vms.

Anyway, as I said, neither Flatpak, nor Snap are available for EL5/EL6.

Neither EL5 or EL6 are you meant to have installed on real hardware if you are paying a subscription to use EL5/EL6 you have already paid for EL7 and EL8.

Windows 10 is the latest version of Windows. However, almost all Windows applications will work on Windows 8.x (2012/2013) or even Windows 7 (2009). What's more, quite a lot of modern programs will work on Windows Vista (2007) and maybe some apps can even work on Windows XP (2001).

If you look at the bundled applications with windows 10 the issue here is not as black or while.

RHEL 8 is the latest version of RHEL. However, none of EL8 packages will work on RHEL 7 (2014).

Redhat does this intentionally. When RHEL8 released RHEL7 is under year to maintenance 2 mode. Once a RHEL is in maintenance 2 mode it should no longer be installed directly baremetal.

Fortunately, you should still be able to install quite a lot of modern GUI application on it, in one way or another. It is not always easy, but it is doable. Unfortunately, this is not the case for EL6 (2010 - BTW, newer than Windows 7). Most current apps won't work here, no matter how much you try. And for EL5 (2007), you won't be able to deliver literally anything released in recent years, at least when it comes to GUI applications. The kernel is simply too old.
Do you see difference?

You missed the differences. Windows provides full kernel updates for 10 years from release. Redhat provides full kernel updates to a release for about 6 years and 10+ on the userspace used in chroot, container, vm.

Notice what you said about kernel being too old. It absolutely true that RHEL5 and RHEL6 kernel is too old and if you are obeying Redhat documentation you would not be using those kernels at this point you would be using RHEL7 or RHEL8 kernels now.

the_scx complaining about kernel trouble with RHEL means you have not read the documentation on what you should be using to be secure. maintenance 2 mode you are not promised all the Linux kernel security patches in that RHEL release either so running those kernel on baremetal is fairly much like walking around with your pants down around your ankles. Yes the_scx what you are complaing about is the same as a person running around with pants down around your ankles and you fall over and hurt yourself and attempt to blame others for your stupidity.

Yes it is stupidity thinking the subscription you pay to use RHEL5 and 6 include 7 and 8 so you can use those kernels at no extra cost.

PS before the_scx says using these newer kernels will break old hardware support the reality is when Windows XP, Vista, 7, 8.1 and 10 have done kernel updates they have broken old hardware support as well. I still remember having motherboard I could not update to Windows XP SP1 because its drivers broke due to the kernel update in XP SP1. Yes you then had windows programs demarding that you have Windows XP SP1. Redhat method is lot more clear when you are stepping over the cliff into possible broken hardware support.

[the_scx]

Really you need to shut up.

No, you should, because you are talking nonsense all the time. You was recommending QEMU-based Hangover and Virgl for gaming purposes and saying that RISC-V SoC with the open hardware Vulkan accelerator will be suitable for hi-end smartphones in a few months. People are so sick of you, because almost everything you say is a bullshit!

LSB is not the current standard.

A few moments ago you said something completely different.

Even so GUI applications from different printer makers still come out LSB DEB and RPM and still work on current Debian/Ubuntu.

I don't care about a few drivers. I care about multimedia, programming and productive software. Neither LSB 4.0 (2008), nor 4.1 (2011), nor LSB 5.0 (2015) were able to run anything useful on desktop. The LSB-complaint system was not enough to run Steam, Skype, WPS Office, Chrome, not even mention the current open source software. It was a completely failure, because no one cares about it. Only a few software vendors decided to provide validation for theirs apps, and none of them was a desktop software.
http://web.archive.org/web/201108110...ir.php?by_date
Even Windows 10 Mobile and UWPs are currently more successful than LSB even was.

Also what you have requested with current versions of those programs built for old versions of Linux does not work under windows either some of the applications in the same class.

Such cases are a total rarity. You are still able to install and run latest OpenShot, Kdenlive, LibreOffice, VLC, Steam, etc. on Windows 7.
Google has drooped support for Chrome on EL6, when it was the latest version of RHEL. We had dozens of examples when the software developers did not care about the latest version of RHEL.
Not even two years have passed, and the system is already ignored! On the other hand, Windows releases are relatively good supported for even 10+ years! You have to be blind to not see it.

Pitivi is in the class of Adobe premiere being video editing.

LOL! And GIMP is the same class software as Photoshop? Oh sorry, I forgot. You already said that Photoshop is a legacy software and GIMP is modern. It was you, right?

So running current version on old versions of libraries bundled with an OS can be next to impossible with video editing software and this is normal under Windows yet you are asking for that to be done under Linux. So the list of applications you wanted old Linux distribution to support many in that list a old version of Windows cannot work either.

OpenShot and Kdenlive are still supported on Windows 7, but we don't even have native RPM packages for RHEL 7! AppImage packages won't work either! In this particular case, you can use flatpak packages, but Flatpak is not available for EL6 (2010), which was released a year after Windows 7 (2009).

Under Linux I can install chroot and still run those newer applications while having the core OS the old version..

And on Windows you can install another Windows inside the Hyper-V VM. Problem solved!
Chroot is not suitable for end users. They want RPM/DEB/TGZ or Flatpak/Snap/AppImage packages if it make sense. Not fucking chroot or LXD container!
What is more, I've already proved that you can't use current Fedora (FC28-F30) in chroot on EL5 or EL6, because of too old kernel.

Yes I will give you here that only recent with portals with flatpak and snap are you seeing something like a comctl32.dll.

Again, bullshit. What's more, xdg-desktop-portal-kde requires Qt 5.12, while EL7 provides Qt 5.9. And of course xdg-desktop-portal* is unavailable on EL6.

If you are covering every version of Windows 10 include IoT versions. Everything listed there in the Windows 10 IoT version can be complete missing.

We are not talking about embedded system/IoT solutions, nor servers, nor mainframes, nor routers, nor smartphones. We are talking about desktops/workstations, so I don't fucking care about Windows IoT here!

Modern windows not having to worry about .NET framework what a laugh as well.
https://answers.microsoft.com/en-us/...d-7a4e5b947771
People are working out how to uninstall the provided .NET Framework in Windows 10 so they can get old applications to work. ,NET framework might be pre-installed in windows nothing says it the right version for your application and nothing say that someone did not change it to a different version so other applications work.

.NET Framework 4.8 is backward compatible with 4.0-4.7.2, while .NET Framework 3.5 is backward compatible with .NET Framework 2.0 and 3.0. Both should be pre-installed on Windows 10 v1903.
https://en.wikipedia.org/wiki/.NET_F...elease_history
On the other hand, you are unable to install RPMs for Mono 2, Mono 4 and Mono 5 at the same time, at least until you create your own packages.

32 bit support under windows can be disabled by register as well and it optional to be installed in IoT versions of Windows 10 and can be registry disable in current server and desktop editions of Windows by group policy. So 32 bit support is not guaranteed under windows either.

I don't care about IoT and servers! WoW64 is enable by default on desktops, and even if it wasn't, users would still be able to install it without any problems.

So far every you have said is in fact the same on Windows IOT.

Windows IoT is the successor of Windows Embedded and it has nothing to do with the end-user desktop!

You are listing a lot here that Libreoffice, Firefox and Wine don't stuff about.

Because they are not GNOME software! Pitivi, Abiword, GNOME Builder, GNOME Disks, Cheese, NetworkManager, etc. - it is GNOME Software.

System tray and notification are a protocols so they can be implemented in your own libraries. You don't have to use the Gnome parts either. The list comes very short once you cut it down.

Will you rewrite the current software to make it independent of GNOME? No? So shut up!

LD_ASSUME_KERNEL= its a interesting loader option. Yes you can force the linux kernel version reported to glibc to be newer than what you in fact have. This does not always work either.

I don't fucking care about "interesting" solutions! I care about working solutions, like most users do! Stop this nonsense about proof of concept software and options that will never work!

Of course there is the option of running EL6 and EL5 on newer kernels that Redhat does provide.

Then you break the compatibility with binary drivers, so you won't be able to install any kmod module from e.g. ELRepo.

I don't know why you are talking about RHEL5 and 6.

Because it is still supported software, at least in theory. Moreover, EL6 is a newer system than Win7.
Linux will never gain significant popularity on the desktop until it starts to care about backward and forward compatibility.

Because all it says you have not read the Redhat support policy. Notice the using Virtualization after you enter Maintenance
Support 2. This is full blown VM or containers. After a RHEL gets over 8 years old you are no longer meant to install it as the primary OS.

It has nothing to do with the current installations. You can't install Windows 7 on KabyLake+ neither (or at least iGPU is not usable here), but it doesn't mean that 30% of PC users are using Windows 7 on virtual machines.

By the way you don't buy RHEL by version. You buy it by subscription that gives you access to all versions. So yes having RHEL5, RHEL6 and RHEL7 on the same system is legal. Of course RHEL7 will be the host and by now RHEL5 and 6 should be guests of some form chroot, containers or vms.

This is how Microsoft group licenses work. Now tell me why all companies have not yet migrated on Windows 10. Or better don't talk because you are completely clueless about it.

Neither EL5 or EL6 are you meant to have installed on real hardware if you are paying a subscription to use EL5/EL6 you have already paid for EL7 and EL8.

Nobody will get rid of current installations just because a new version of the system has come out! What is more, there is a plenty of software written for EL6 that won't work on EL7 and EL8. Installing a new system, then running the old one in VM is completely pointless in this case.

If you look at the bundled applications with windows 10 the issue here is not as black or while.

Nobody cares about this crapware. People vomit when they see UWP apps.

Redhat does this intentionally. When RHEL8 released RHEL7 is under year to maintenance 2 mode. Once a RHEL is in maintenance 2 mode it should no longer be installed directly baremetal.

I live in the present, not the future. Today EL8 is barely usable on desktops and workstations. People are still waiting for EPEL and other repos, such as ELRepo and RPM Fusion or Nux Desktop. None of them will appear before 2020.
ELRepo, RPM Fusion and Nux Desktop depend on EPEL. And EPEL won't appear before CentOS will be finished. Optimally speaking, RHEL 7.2 may be suitable for use on the desktop. A lot depends on the 3rd party software vendors. They have to support this system. And as I said, nobody will replace the working solution just because a new one was appeared.

So, provide all of these software right now, or shut up.

You missed the differences. Windows provides full kernel updates for 10 years from release. Redhat provides full kernel updates to a release for about 6 years and 10+ on the userspace used in chroot, container, vm.

Again, bullshit. You won't be able to install Windows on the current hardware (or rather Win7 doesn't fully support KabyLake+ and Ryzen+). However, it is still supported on bare metal, because maintenance mode doesn't affect current installations. The same apply to RHEL 6 as well.

Notice what you said about kernel being too old. It absolutely true that RHEL5 and RHEL6 kernel is too old and if you are obeying Redhat documentation you would not be using those kernels at this point you would be using RHEL7 or RHEL8 kernels now.

Then tell Pixar and DreamWorks that they are clueless and they should switch to RHEL 8 immediately!

the_scx complaining about kernel trouble with RHEL means you have not read the documentation on what you should be using to be secure. maintenance 2 mode you are not promised all the Linux kernel security patches in that RHEL release either so running those kernel on baremetal is fairly much like walking around with your pants down around your ankles. Yes the_scx what you are complaing about is the same as a person running around with pants down around your ankles and you fall over and hurt yourself and attempt to blame others for your stupidity.

Yes it is stupidity thinking the subscription you pay to use RHEL5 and 6 include 7 and 8 so you can use those kernels at no extra cost.

You are fucking moron. The RHEL6 kernel is fully supported by security patches. Stop talking about topics that you do not have a clue about!

Moreover, you can't mix packages across distributions. What's more, you have to activate subscription for each product. Without it, you won't be able to access any repo.

[starshipeleven]

A CLI application is not the same as a GUI application. In the case of a console app, you don't have to worry about system tray, notification system, GNOME Printing UI, GNOME Help system, PolicyKit, PackageKit (see: gImageReader), etc. Even bundling games is much easier, than creating packages for GUI programs.

As I said, only issues are integration with notification and systray, the rest works.

For binaries, you can use chrpath and patchelf, or even some kind of wrapper. However, it does not change anything about the main problem - you have to provide all necessary dependencies, in one way or another.

As is on Windows.

Rather a few GB.

More like 200-300MB, I'm not shipping full linux packages but raw libs I need.

And yes, that's a problem, because you have to maintain this on your own.

Maintain? I'm just shipping old libs. what is "maintain".

And if you think that you can re-use packages from e.g. Fedora 30, then you are wrong. You can't.
Everything here is compiled against Linux 3.2.0. EL6 provides Linux 2.6.32 and EL5 provides Linux 2.6.18.
What's worse, glibc 2.26 (used in Fedora 27 and Ubuntu 17.10) requires at least Linux 3.2 on all platforms. There is no way to get around this requirement.

As I said above, the statement was "you can compile applications for X OS from Linux", not "you can run newer applications on an older OS", that's an entirely different thing.

No, you can't. If your program needs systemd, you have to install systemd on your host. If your program really needs Wayland (i.e. not compatible with X.Org), you have to install Wayland on your host. If your program needs Pipewire, you have to install Pipewire on your host. You can't just put this inside the chroot/LXD container. It won't be enough.

Not true for systemd and wayland, don't know about pipewire.

Do you see difference?

That was outside of the scope of the statement I responded to, the statement was "you can compile applications for X OS from Linux", not "you can run newer applications on an older OS", that's an entirely different thing.

[oiaohm]

Such cases are a total rarity. You are still able to install and run latest OpenShot, Kdenlive, LibreOffice, VLC, Steam, etc. on Windows 7.

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.

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

Not even two years have passed, and the system is already ignored! On the other hand, Windows releases are relatively good supported for even 10+ years! You have to be blind to not see it..

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

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.

OpenShot and Kdenlive are still supported on Windows 7, but we don't even have native RPM packages for RHEL 7!

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

And on Windows you can install another Windows inside the Hyper-V VM. Problem solved!

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

.NET Framework 4.8 is backward compatible with 4.0-4.7.2, while .NET Framework 3.5 is backward compatible with .NET Framework 2.0 and 3.0. Both should be pre-installed on Windows 10 v1903.

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.

On the other hand, you are unable to install RPMs for Mono 2, Mono 4 and Mono 5 at the same time, at least until you create your own packages.

https://www.mono-project.com/download/stable/

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.

Mono in theory of horrible should everything from .net 1.0 though to 4.8 on on under the 1 runtime. This problem with mono is not Linux distribution problem this is the Mono project upstream design goals problem.

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

Windows IoT is the successor of Windows Embedded and it has nothing to do with the end-user desktop!

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.

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

Because they are not GNOME software! Pitivi, Abiword, GNOME Builder, GNOME Disks, Cheese, NetworkManager, etc. - it is GNOME Software. Will you rewrite the current software to make it independent of GNOME? No? So shut up!

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.

Then you break the compatibility with binary drivers, so you won't be able to install any kmod module from e.g. ELRepo.

I did not say this is without pain.

https://www.zdnet.com/article/new-windows-10-1809-block-microsoft-halts-update-if-you-use-flawed-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.

https://support.microsoft.com/en-au/help/3024777/error-0x800706f7-occurs-after-you-install-kb-3004394-and-then-run-wind

This is the windows 7 lets attempt to update kernel behind you back and get wrong so lock you out of your complete system. So kernel wise windows 7 is not as EL6.

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.

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

Because it is still supported software, at least in theory. Moreover, EL6 is a newer system than Win7.

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.

Nobody will get rid of current installations just because a new version of the system has come out! What is more, there is a plenty of software written for EL6 that won't work on EL7 and EL8. Installing a new system, then running the old one in VM is completely pointless in this case.

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.

Again, bullshit. You won't be able to install Windows on the current hardware (or rather Win7 doesn't fully support KabyLake+ and Ryzen+). However, it is still supported on bare metal, because maintenance mode doesn't affect current installations. The same apply to RHEL 6 as well.

Same does not apply to Redhat. This is you applying windows maintenance cycles to Linux. The maintenance cycle to be secure and current is different with redhat.

Then tell Pixar and DreamWorks that they are clueless and they should switch to RHEL 8 immediately!

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.

You are fucking moron. The RHEL6 kernel is fully supported by security patches. Stop talking about topics that you do not have a clue about!

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.

Really its about time you get a clue. The reality is 5-6 years most security patches will be backported. Past 5-6 years old Linux kernels the security patches don't come and you have got to the point where internal structure of the Linux kernel have changed too much to backport the patches. Redhat policy about using virtual when release gets 5-6 years old is about a serous practical limit. Doing it by virtual being chroot/container means you don't have the nasty not recoverable explode from hell.

[Scellow]

I keep saying it, Proton was a huge mistake

[the_scx]

As I said, only issues are integration with notification and systray, the rest works.

Integration with the environment may be stronger than you think. For example, GNOME Cheese depends on GNOME Totem for displaying thumbnails. What is more, desktop applications tend to talk to each other. For example, instant messenger may want to read the playlist or the current song from audio player. I am not saying that this is an important feature or not, but as package maintainer, you have to take this into account.

See also:
- Nautilus integration
- AccountsService
- Yelp
- GNOME Keyring
- SessionManager
- GnomeVFS vs GVfs
- GConf vs dconf/GSettings
- dbus-glib vs GDBus
- PackageKit (e.g. program wants to install a language specific module through PackageKit)

Some of these things are more important, some less. For me, integration with the file manager is important.

As is on Windows.

Definitely not. Building GNOME3 app on e.g. EL6 is almost impossible (or rather unrealistic). It is like porting an UWP app to Windows 7, where you have no Windows Runtime, or porting a WPF4 app to Windows XP, where you don't even have DirectWrite, on which Avalon depends on.
Have you ever wondered why a lot of GNOME applications are not really multiplatform? I mean, they are unavailable on Windows, and even building them on BSD systems is not always so easy. The reason is that they hugely depend on GNOME libraries, so it would lead to port almost the whole GNOME to Windows (or another platform).
Damn, in the past it was so hard to deliver KDE programs on Windows, for similar reasons - theses applications are not standalone.
My point is, these dependencies are so huge, that you can't even imagine. A typical Windows program doesn't have so many complicated deps. And even if it does, it depends on Windows components, that are guaranteed on this system.

Moreover, a typical way to deliver desktop software to RHEL is to build a RPM package. Usually, you use the Koji or COPR buildsystems, which use mock under the hood.
The problem is that packaging take a lot of time. You have to care not only about manually setting library paths and enforcing rpath, but also about things like filtering automatic dependencies.

https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies

https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/

You do not have to worry about it in Flatpak, but it has its price. It is just not suitable for everything.
Moreover, if you want to build a GNOME2 app in Flatpak, you usually have to rewrite some parts of it, because they are not longer exist in current GNOME, and building the entire GNOME 2 on your own is unrealistic. Moreover, old software usually doesn't build with the new GCC, and new software often requires the current GCC (at least GCC 5).

Anyway, you can build Qt, GTK+, Gtkmm, wxWidgets, FFmpeg, SDL2, etc. on your own, but building the whole GNOME is not a job for just one man.

More like 200-300MB, I'm not shipping full linux packages but raw libs I need.

Please take a look at the Freedesktop runtime:
- org.freedesktop.Platform/x86_64/18.08 - 486 MB
- org.freedesktop.Sdk/x86_64/18.08 - 1.4 GB
The SDK is needed when you want to deliver an IDE. GNOME and KDE runtimes are even bigger, because they are based on Freedesktop.
One of my flatpak package takes over 5 GB, and that's not counting the runtime. In addition to libraries, it also contained theme, icons, fonts, dictionaries and application data. I had to do this because there was no other way. Flatpak packages are isolated from the system and for this reason they can not use host deps.

Maintain? I'm just shipping old libs. what is "maintain".

Follow the CVEs and provide security patches for each component you included here.
For example, Red Hat provide security updates for Gtk+2, but this only apply to the official RPM packages. If you build Gtk+2 on your own, you have to take care of it by yourself.
The same applies to all other components. And Red Hat support even those ones that have already been abandoned by theirs original authors.

Not true for systemd and wayland, don't know about pipewire.

Sorry, but you need systemd on the host if you want to register a service. There is no other way to do this.
The same applies to Wayland - you need a Wayland compositor (e.g. Mutter or Kwin5) to run the application. Of course, most of current apps have support for X.Org too, but this may change in a few years.