Fedora Has Deferred Its Decision On Stopping Modular/Everything i686 Repositories

[starshipeleven]

VM is a pathetic solution since it doesn't integrate into your desktop, and you still need Windows, not to mention the resource costs with running one compared to Wine.

VM always works, Wine does not. End of the discussion.

To the contrary of you fappers I need to get a job done (or play a game) NOW.

You can't even pull off your usual "money talks" card here buddy, considering that CodeWeavers is financially backing Wine, and Valve pours a lot of money into it. Looks like they also disagree with your shitty VM or "just play on Windows" idea.

Money isn't talking enough, because VM always work, and Wine does not.

[the_scx]

Yeah, that in most distros regularly breaks and you need to go and delete stuff manually.

I don't have such problems at all. If you use a bleeding-edge distro, you can only blame yourself.

Seriously, Steam Runtime is the best thing that happened to Linux when it comes to games.
Let's take a look at Hotline Miami. The game created in 2012 was ported to Linux in 2013. However, the GOG edition doesn't even work OOTB on EL7 released in 2014. All because of missing libraries. They provide MojoSetup-based installers for their games and yet they are unable to provide basic deps. This is a fucking disaster!
So, when you try to run it, it will complain about the missing openal-soft library (a software implementation of the OpenAL 3D audio API). Although EPEL7 provides the x86-64 package, it lacks of the i686 package.

https://koji.fedoraproject.org/koji/buildinfo?buildID=749187

What's worse, there is no EPEL7 i686 repo at all.

https://lists.fedorahosted.org/archives/list/[email protected]/thread/BYEG52I2KRRLN5OVJQDOHSPNSMYRMSJ6/

BTW, this is one of the reasons why WINE developers have complained about EL7.

https://wiki.winehq.org/CentOS/RHEL#For_Release_7

It is not that it doesn't have multilib support. It does. However, it is just too limited. They already know it, because they fixed a thing or two in EL8.

https://pastebin.ubuntu.com/p/YcZ79Yyqpx/

What's worse, they don't even provide the epel-7-i386 config for mock. Because of that, it is hard to build missing deps using COPR or Koji.
You have to grab the centos-6-i386/centos-7-x86_64 config from CentOS Extras, then create your custom config based on an unsupported AltArch port. It is not always up to date, so you have an another problem here.

http://mirror.centos.org/centos/7/extras/x86_64/Packages/mock-1.2.17-1.el7.centos.noarch.rpm

https://wiki.centos.org/SpecialInterestGroup/AltArch/i386

Anyway, it should look something like this:

https://pastebin.com/raw/DLZsDf7E

If you think that rebuilding one package for i686 would be enough, you are simply wrong. The openal-soft requires portaudio that requires jack-audio-connection-kit that requires libffado that requires libxml++, dbus-c++ and scons to build. All of them are already included in EPEL7, so it should be enough to just rebuild them for i686 in the right order. Unfortunately, it's not that simple. You will figure out soon that some of these packages don't build correctly anymore even on x86-64. You have to fix source RPMs, then try again.
And because you are a nice guy, you probably want to share the result of your work.

https://copr.fedorainfracloud.org/coprs/scx/openal-soft/

https://copr.fedorainfracloud.org/coprs/scx/openal-soft/builds/

So, you spend literally half a day for that and when you finally finish it and try to start the game, it turns out that an another library is missing: libCg (NVIDIA Cg Toolkit). This library doesn't exist in EL and Fedora repos at all.
The best you can do is to rebuild an unofficial package from the RPM Fusion repo for Fedora. So, basically, you have to repeat the whole process that you have already done for OpenAL Soft. Fortunately, after that you can finally enjoy playing the game.
But you know what? There is a simpler way to do that. If you just use Steam Runtime, you don't have to worry about these dependencies. It just works!

LD_LIBRARY_PATH="$( "${HOME}/.steam/steam/ubuntu12_32/steam-runtime/run.sh" --print-steam-runtime-library-paths ):${LD_LIBRARY_PATH-}" "${HOME}/GOG Games/Hotline Miami/start.sh"

And if you use the Steam client (you bought this game on Steam), all you have to do is just to click the PLAY button. Isn't this fucking amazing?

If you think that this is an issue with EL or Fedora, you are wrong. Even in Ubuntu LTS, you have to setup multiarch first, then install libalut0 and libcg by yourself. The installer should not work like this. It should take care of these deps. Of course, it's fault of GOG, publisher or developer. But you know what? I don't give a shit who is guilty here. I just want things to work out of the box. Steam gives me a trouble-free experience and I am happy with that.

In DOS times games were mostly operating the hardware directly. "drivers" are a later invention, as were GPUs.

Call it whatever you want (although in my opinion you don't know the difference between GPU and 3D accelerator). In the DOS era, games had to support all GPUs by themselves (CGA, EGA, VGA, etc.).
Thanks to OpenGL and DirectX (DirectDraw, Direct3D), we have gained a sane abstraction layer. Anyway, as a developer, all you had to do is to support just one API (let's forget about 3dfx Interactive Voodoo and Glide for a moment).
And now you want to force developers and maintainers to take care of all these drivers. This would be a fucking mess.

Huh? Never said to include in each application. I said move it to a dedicated project, like integrate this in Wine wrappers like PlayOnLinux, or Flatpak packages.

There is no way that the PlayOnLinux team would support it.
As for Flatpak, it may be good enough to provide packages for Phoenicis and Lutris, just for limited gaming purpose. However, it is still to problematic in many ways, and people don't want to fight with it when it comes to using printers, scanners, webcams or tablets.

Yes they still did. They are dropping all 32bit packages that aren't part of a lucky few on a whitelist, which is a step towards obsoletion.

If you put it that way, then we should switch to RISC-V as soon as possible, because they have already dropped support for i486, which is a first step to completely abandon x86 (by x86 I mean x86-16 & x86-32 & x86-64)...

Until you find some flatpak-only issues, and not links of people that are complaining about the mess that is Steam or GoG "runtime" or idea of Linux support.
The linked comment applies regardless of Flatpak, a lot of games just don't work anymore in a newer distro even with normal Steam (and GoG games are worse), and require hacks, launching with environmental variables, forcing the load of libraries and all that crap.

First of all, not just a random person, but the Flathub member.
If you are looking for a buglist, then you should check this out:

https://github.com/flathub/com.valvesoftware.Steam/issues

https://github.com/flathub/com.valvesoftware.Steam/wiki/Frequently-asked-questions

https://github.com/flathub/com.valvesoftware.Steam/wiki/Tested-Games

So, as you can see, it is a half-working solution.

Of course, we can blame developers that they don't provide proper support for Linux, or blame Valve that they don't verify if the game actually uses only Steam Runtime without any system libraries (except glibc and GPU libraries). But as an end user, I just want the games to work, and Steam on the host already gives me a trouble-free experience.

Standard packages have failed already

If standard packages have failed already, then Linux desktop failed as well, because universal packages are not any better. Maybe we should end this madness and say that Linux is simply not suitable for desktop?

https://gitlab.com/probono/platformissues

older games on Steam are a crapshoot.

I didn't have any problems with games on Steam. Well, maybe except Windows games on SteamPlay/Proton, but this is understandable that they can cause some problems or even don't work at all.

Doing shitty hacks with chroot and scripting like PlayOnLinux does is probably more doable than doing a full Flatpak environment, but that's what is going to be as safe in the long run.

To support stuffs like Steam, WINE, PlayOnLinux/Phoenicis, Lutris or GameHub, you need multiarch/multilib support, either on the host (traditional packages, such as RPM or DEB) or in the sandbox (universal packages, like Flatpak). There is literally no other way to do that.
Fedora is supported by Red Hat (they pay people to work on it) and large community. On the other hand, Freedesktop is supported by a small company. I have created hundreds RPM packages for Fedora/EL and dozens flatpak packages, and I can tell you that Freedesktop quality is far behind the Fedora or any other major distro (e.g. Debian stable or Ubuntu LTS). Runtimes here are buggy as hell, pretty unstable (I mean ABI) and supported only for a short period of time. What's worse, they lack a lot of components that are hard to build on your own, and because of forced sandbox, it is always a pain in the ass.

The solution is simple, stop posting bullcrap here to try to convince a brick wall and and go fix it.

Why should I fix it? It is you who want to replace standard packages with universal ones, so maybe you should fix it.
Have you ever reported any problem on Flathub? Have you ever make PR? I did. It isn't a pleasant experience. You can assume that half of the issues will be completely ignored or dragged on for months.
Fortunately, in this particular case, they are going to fix it in the next runtime.

Flatpak is still in its infancy, half of its features are still on the fucking roadmap.

You know that Flatpak is in a very immature state and yet want to blow up right now the current solution which is working pretty well.
Does someone pay you for sabotaging Linux desktop or you do it of your own will?

What I want is for people who actually care about that to come out of the woodwork and do their part, which is what opensource is about.

And what is your role in this? Apart from trolling and sabotaging the current Linux desktop?
Have you done anything in this direction? Have you created any Flatpak or Snap packages? Or do you assume that others will do all the work, and spend an insane amount of time for creating pointless packages, just because you have such a whim?

Distro maintainers aren't your bitch, learn from the Arch 32bit community, that is maintaining the 32bit version of Arch now that core developers have dropped it.

But Arch supports multilib!

https://wiki.archlinux.org/index.php/Official_repositories#multilib

https://www.archlinux.org/news/the-end-of-i686-support/

Following 9 months of deprecation period, support for the i686 architecture effectively ends today. By the end of November, i686 packages will be removed from our mirrors and later from the packages archive. The multilib repository is not affected.

Anyway, I don't care about Arch or hundreds of other shitty distros. All I care is Fedora/EL, Debian/Ubuntu LTS and openSUSE/SLE (mainly because of OBS - the Open Build Service). But to be honest, I will not cry if SUSE just disappears. And if in the next 10 years Canonical will do something incredible stupid and be out of business or Debian maintainers will no longer be able to keep up with Linux development, I will be fine with it. Just one sane platform is enough to me.

You need libraries for sound and other stuff that the game actually likes too.

What about OpenGL or Vulkan? In your opinion, games don't need them?

Those are going to be static, that's what I meant.

If you mix system libraries with game libraries, there is a chance that you will hit the following problem:

Games built against one version of libstdc++ might not be able to tolerate the (often much newer) libstdc++ pulled in by a Mesa driver (such as i965_dri.so).

https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/README

https://github.com/NixOS/nixpkgs/issues/31189

The libcapsule is one of the possible ways to deal with this problem. You can also try to build everything from scratch or build game against one of the Flatpak runtimes (which sucks, because their lifespan is just too short). Unfortunately, libstdc++ is a source of many problems in Linux desktop, and currently there is no a sane solution to fix it.

https://gitlab.com/probono/platformissues#libstdcso6

Wine, Mesa and the game management application are infrastructure that should stay outside of these little sandboxes.

OMG, you are completely clueless on this topic. You don't even know how it works. What you describe is already done in Steam. But you have already said that this is not enough for you. You pointed to the Flatpak as a recommended solution. But it builds everything from scratch. And by everything I mean literally everything - glibc, Mesa and NVIDIA libs (EGL, GLES, GLX, OpenGL, OpenCL, Vulkan, CUDA, VDPAU, NVENC, etc.), of course as well as GNU Coreutils, libstdc++, libxcb, libX11, dbus, pulseaudio, alsa-lib, fontconfig, etc.

They are opensource already, why you place them inside?

What is this argument for? In Flatpak you generally can't use the host libs, so either you bundle OpenGL and Vulkan (to be honest, they are already included in the Freedesktop runtime and its extensions), or you won't be able to use them at all.
That's why Flatpak totally sucks when it comes to IDEs.

https://github.com/mono/monodevelop-flatpak/issues/1

And it sucks even harder because applications can't talk to each other, at least without providing the D-BUS interface.

I quite frankly enjoy all these tears, but I still don't think any distro should need to care about games and things like Steam that are a HUGE MINDBOGGLING mess and a ticking time bomb.

And I think that the Linux community should not pay attention to trolls like you.

[the_scx]

Because I can recompile most of them to run anywhere

Please provide RPM packages for EL5 and EL6 for the following software:
- Anbox
- Anjuta
- Ark
- Atom
- BirdFont
- Blender (with all extensions available in Fedora)
- Boxes (GNOME)
- Brackets
- Builder (GNOME)
- Calibre
- Code::Blocks
- CodeLite
- Darktable
- Discord
- Dippi
- Dropbox
- Evolution (GNOME)
- Flatpak
- ghostwriter
- Genymotion
- gImageReader
- GNOME 3
- GPick
- ImageMagick 7
- K3b
- KDENLive
- Krita
- LiVES
- MATE
- MyPaint
- Moonlight (Game Streaming)
- Neovim
- nomacs
- Notepadqq
- OBS Studio
- OCRFeeder with Tesseract support
- OpenShot
- Opera
- Peek
- PeaZip
- Pitivi
- Qalculate
- RawTherape
- Remmina
- ReText
- SageMath
- Shotcut
- Signal
- Skype
- Slack
- SMPlayer
- Snap
- SpiderOakONE
- Spotify
- Steam
- Subtitle Editor
- Telegram
- UberWriter
- Viber
- Visual Studio Code
- Vivaldi
- WPS Office
- Zotero
I expect that all of them will be available in the latest version and will not interfere with the base packages (including EPEL). Please start with Pitivi.
I believe that some of them can be built relatively easy. However, for most of them it will be extremely difficult.

It is extremely hard to support every distribution. They have different purposes and none of them are suitable for everything. For professional commercial software you would probably pick up RHEL, but for latest open source applications a more fresh distribution may be better. But that's beside the point.

while UWP apps are shit and only run on Win10.

UWP apps are modern and you can run them on any Windows platform. It's not Microsoft's fault that Linux is an ancient system.
https://docs.microsoft.com/en-us/win...s-overview.png

That's what Virtualbox is for.

It is extremely silly idea to run the whole system that requires at least 1 GB RAM (4 GB in the reality) for just one small utility. Moreover, it totally sucks when it comes to the GPU acceleration.

Really, the chances that Wine will work with a random application are low and if you say otherwise you are wrong.

I don't need WINE to support all applications. I'm totally fine with the current status, which means that WINE allows me to run massive amount of Windows programs. Of course, the more the better.

While a VM will work fine any time as long as you don't need 3D graphic performance

Hello! We are no longer in the 90s, where the only programs using GPU acceleration were games and CAD applications. Today, almost everything intensively uses the GPU. By that I mean that DXVA, VA API, VDPAU, NVENC are used everywhere. What's more, OpenCL and CUDA are widely used by a number of applications: algebra software, office suites (spreadsheet), 3D moddeling programs, non-linear editing systems, or even small image converting utilities.
https://streamhpc.com/blog/2013-06-0...a-can-be-used/

https://create.pro/blog/opencl-vs-cuda/

Even UI tents to use GPU acceleration today (Direct2D, DirectWrite, Direct3D, OpenGL, Vulkan)! Just take a look at GNOME. It runs like shit under Gallium on LLVMpipe.
So even if you are still able to run something on CPU, it doesn't mean that you want to, because it will be probably slow as fuck. People who buy computer with NVIDIA GTX or Quadro usually want to make use of its performance.

"(and if you do it's not THAT hard to use KVM instead and passthrough a GPU)"

It is, because it requires at least two separate GPUs, which is not always the case, especially in laptops. Moreover, GPU passthrough mean that you assign it to VM. You can't share it between host and guest system, which is a real problem for a lot of people.

The solution would be GPU virtualization, but at the moment it is in a very preliminary stage, at least for an average customers. Intel introduced GVT-g some time ago, but it is still in an experimental state and requires a bleeding-edge distro to work.

I don't. I just don't get this focus on the past. Don't you see that this endeavor is like ReactOS all over again? You are sacrificing the future in a failing attempt to relive the past, and in the meantime you get the worst of both worlds.

How is it (the proper multiarch/multilib support) sacrificing the future? Maintainers have enough time and resources to fully support AArch64, PPC64LE and s390x (that means a selfie app, games and software for kids for mainframes), but they can't maintain about of a thousand packages in multiarch/multilib, which don't even require a lot of patches? Damn, Debian even supports shitty Alpha and Motorola 68k, which are super dead for a long time!
Anyway, without a sane and stable API/ABI, Linux will never gain a significant market share on desktops. Just look at the mobile market. Android supports all its previous API versions. Google definitely opted for backwards compatibility, this is the fact. Did this stop them from developing? It is currently the best mobile Linux platform, at least when it comes to the feature set. And what others look like? They break API/ABI left and right, and where are they now?
In fact, the stable platform in the future.

I have a gaming rig with Windows, I accept that older games won't work anymore (even on Windows where according to some select people every win95 program works down to Win10), and I move on.

Nobody said that Windows 10 supports every Windows 95 application. But support for some Win95 programs is a fact.

I don't see why some people are so wound up with trying to run games that are 100% developed on Windows (or even for console) badly and with many handicaps on Linux. It's just not even remotely worth all the investment in developer time and effort (which in most cases is for free because none of them even pays for that), and in user effort to set up the system, while Linux is still in the stone age on so many actual fronts where it could be better than Windows IN THE FUTURE.

Linux does not stand a chance to be a system for the masses until it takes care of stable ABI, real long term support (sorry, but 2-3 years support is not a LTS) and backwards compatibility. Without this, it can be at most a garbage system for nerds.

Like for example implementing something like Flatpak, but properly, like Android did, and thus getting something resembling a stable API so commercial application developers can write native applications for it, that won't require people from the future to write again wrapper shit to keep running them.

Do you realize that this contradicts everything you said before? Android is about full backward compatibility. You can't have a stable ABI, and at the same time break it all the time.

[the_scx]

I don't give a crap about ports with handicaps, I play on Windows, and if I need to run Windows applications I spin up a VM.

Boom instant 100% compatibility (I can have any version of Windows) and 99% performance (for CPU), and also 100% safety (in theory) as it's a VM.
I'm also able to do GPU passhtrough and in my experience it is easier than debugging misbehaving applications in Wine.

Show me at least one thin ultrabook with GeForce GTX/RTX or Quadro equivalent. Sorry, but GeForce MX/GT doesn't support NVENC, while even low-end Intel Graphics support QSV.
Do I need to explain that GPU passthrough requires a separate GPU? I hope not.

Doing otherwise is some ReactOS-level nonsense.

Linux with WINE is a far better solution than ReactOS, because the second one is just a system at an early stage of development, which is not suitable for serious work.
Linux allows you to do your work, and WINE provides a few tools that are missing here. As I said before, most of the programs I use are open source, but I still need at least several proprietary programs, including those created for Windows.

[the_scx]

No, i am not wrong. I just thiink of these numbers in traditional way For Microsoft number 10 have no meaning other than to differenate it from existing 7, 8...

I don't even see a difference between Ubuntu LTS scheme, Windows scheme and Debian scheme... where just numbers are used differently.

One chooses to use stock number, second use date number and third increases numbers... but under all these numbers there is no difference - support still have its EOL thats for sure

Windows 10 minor releases are equivalent of a Linux distro (e.g. RHEL) minor releases. However, compatibility issues are extremely rare 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.
You must know that the EL7 ABI is not as stable as it was with previous releases. RHEL 7 tends to break 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

So as you can see, Windows 10 is more compatible with Windows Vista than RHEL 7.6 is compatible with RHEL 7.5.

And every major ringing number there is different OS really

It is still the same product.
It is like saying that RHEL 7 is already abandoned because Red Hat no longer supports RHEL 7.0.

Good that they seems started codenaming it as 19H2 and 20H1 or so... these Redstone, Greenstone, Purplestone plus numbers does not make sense

Oh yes, because names like Yarrow, Tettnang, Heidelberg, Stentz, Bordeaux, Zod, Moonshine, Werewolf, Sulphur, Cambridge, Leonidas, Constantine, Goddard, Laughlin, Lovelock, Verne, Beefy Miracle, Spherical Cow, Schrödinger's Cat, and Heisenbug are so intuitive! I have a small riddle for you: What is Psyche in the Linux world? Don't you dare to use Google/Wikipedia!

[the_scx]

VM always works, Wine does not. End of the discussion.

Windows on VM always works like shit if you don't have GPU passthrough or GPU virtualization, which are extremely rare setups. The first one requires separate GPU and second monitor to work. This is not the best solution for laptops.
What's worse, exchanging data between systems is often a pain in the ass. Don't even talk to me about fucking Samba!

BTW: Do you remember the experiment that Canonical did with GOG games under VirtualBox?

https://www.phoronix.com/scan.php?page=news_item&px=Trying-GOG-Games-64-bit-Ubuntu

The blank window was the best result!

[starshipeleven]

Please provide RPM packages

I already said what I do to get shit running, I'm an IT guy, not a developer. Chroot with the kitchen sink works well enough. Packaging is just a matter to have scripts on top of my hack.

That's what happens when development fails to solve the problem. SOMEONE has to "fix it" by throwing hardware at it. Because stuff must still work.

UWP apps are modern and you can run them on any Windows platform.

"Windows platform" still means Windows 10. You aren't going to be using productivity apps on an Xbox if you can avoid it.

It is extremely silly idea to run the whole system that requires at least 1 GB RAM (4 GB in the reality) for just one small utility.

1. Windows 64bit runs fine with 2GB for a single application

2. That's what we do when software developers can't fix their shit, I know it's bad but it works and that's what most of the world is doing right now to keep trucking on (yes this is an issue that isn't just for people on Linux)

I'm one among many that thanks VMWare as our god and savior.

I don't need WINE to support all applications. I'm totally fine with the current status

I don't. In its current status I have less than 50% chance of being able to run something in Wine unless it is some special well-known software.

Hello! We are no longer in the 90s, where the only programs using GPU acceleration were games and CAD applications. Today, almost everything intensively uses the GPU.

Bullshit, I've not seen significant differences outside of workstation software.

Even UI tents to use GPU acceleration today

It works fine even with Virtualbox's crappy virtual GL driver, with VMWare that supports actual DX11 too it's great. KVM also has similar drivers but I don't use them much so I don't know. It does not lag anymore, I can tell you this.

It is, because it requires at least two separate GPUs

But it works reliably once it is set up, and requires little if any mainteneance. The same can't be said for Wine or the whole goddamn circus of crap you need to keep to actually play on Linux, or god forbid, actually use some Windows work software.

How is it (the proper multiarch/multilib support) sacrificing the future?

Because it's basically turning Linux into a lowerl-evel Windows shim without providing any form of security and sanboxing, i.e. it's NOT an evolution but a sidegrade at best.
If I want a shit unsafe system to run Win32 applications I can just install Windows (or "not uninstall it" from the hardware I buy).

And even to get there you need a monumental amount of work on the Wine side that isn't really happening (and won't happen unless there is a sudden and mysterious influx of developers)

Damn, Debian even supports shitty Alpha and Motorola 68k, which are super dead for a long time!

You mean Debian compiles and offers packages/images for these archs. Who knows if that stuff actually still works at all?

without a sane and stable API/ABI, Linux will never gain a significant market share on desktops

That's exactly what I'm saying, I'm just advocating for a true modern solution that is implemented now with the lessons learned in the last two decades.

Wine and porting over the Win32 API is NOT what I would like to see. I would like to see something along the lines of Android, and Flatpak is where this is at.

Nobody said that Windows 10 supports every Windows 95 application. But support for some Win95 programs is a fact.

That's a statement that came from a moron called birdie, not you, these discussions remind me of him.

Do you realize that this contradicts everything you said before?

I'm not contradicting myself, you maybe should stop trying to twart what I said and read it better.

[starshipeleven]

Show me at least one thin ultrabook with GeForce GTX/RTX or Quadro equivalent.
blabla NVENC blabla QSV

If for some reason I have to use shit like Ultrabooks for purely esthetic reasons, I would be running Windows, period.

Also, wtf are you doing on an ultrabook that needs NVENC or QSV, they are toys for management (i.e. Office machines) not workstations.

Linux with WINE is a far better solution than ReactOS, because the second one is just a system at an early stage of development, which is not suitable for serious work.
Linux allows you to do your work, and WINE

runs decently only a handful of programs, while most don't run or run like shit.

I don't care about the theoretical list of API supported (like NVENC), IN PRACTICE it's a crapshoot to get anything to work with it unless you are in for a fun week of tuning and are half-developer, or happen to need one of the few applications that are in gold or better status (and later versions of Wine didn't break this status, as sometimes happens).

[starshipeleven]

Windows on VM always works like shit

Wrong. It works fine for applications that don't need strong 3D acceleration. 3D acceleration is available so the GUI works and does not lag, but it's not strong enough to do much more than rendering the GUI without lagging.

What's worse, exchanging data between systems is often a pain in the ass.

What if I told you that copy-paste works with Virtualbox and VMWare (and KVM too for that matter)?
There are also special shared folder settings that allow me to passthrough to the VM as a "network drive" all necessary folders (this is not SMB, it's using its own internal system for VB and VMWare, KVM uses 9P protocol). In many occasions I'm literally only reading and writing to this filesystem with the applications in the VM.

BTW: Do you remember the experiment that Canonical did with GOG games under VirtualBox?

That's because the Virtualbox 3D acceleration driver is basic. VMWare's one is better, but still gaming is outside of its abilities.

KVM is decent and they are developing that VirGL thing as a more powerful virtual 3D GPU, exactly for the desktop usecase https://virgil3d.github.io/

But really, as I said I have a dedicated rig for gaming, also to keep some separation for security reasons.

[calc]

Show me at least one thin ultrabook with GeForce GTX/RTX or Quadro equivalent.

ThinkPad X1 Extreme G2 / ThinkPad P1 G2 both use Nvidia Turing.