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

[kpedersen]

I'm quite frankly sick of these comparisons. The amount of people that actually NEED Photoshop-only features can be counted on a couple hands.

Agreed. I believe it is because Photoshop managed to become the "industry standard" first. Many people like using brand names and want to look professional using the big name software.

That said, some software does manage to break through. It seems that Blender is replacing Maya as the "standard" in a few areas.

[the_scx]

In opensource world, most if not all applications have been migrated to 64bit years ago, installation and use of older binaries is not a thing and it's usually annoying because they rely on system libraries that don't exist anymore or were updated, sometimes in non-retro-compatible ways.

You have no idea what you are talking about. Valve already provides Steam Runtime which make the Steam client and games almost independent of any distro. However, it still depends on some basic components, like glibc or GPU drivers, because there is no sane way to do this otherwise. We don't want to back to DOS times, in which every single game developer had to deliver GPU drivers, because it is an extremely stupid approach.

https://www.phoronix.com/forums/forum/phoronix/general-discussion/1107050-ubuntu-19-10-to-drop-32-bit-x86-packages?p=1107452#post1107452

Because it would be the same mess that is already in Flatpak. They will have to support every single GPU driver. By that I mean every single version of the GPU driver, e.g. NVIDIA 304.134 (32-bit), NVIDIA 304.134 (64-bit), NVIDIA 304.135 (32-bit), NVIDIA 304.135 (64-bit), NVIDIA 340.101 (32-bit), NVIDIA 340.101 (64-bit), NVIDIA 340.102 (32-bit), NVIDIA 340.102 (64-bit), NVIDIA 340.104 (32-bit), NVIDIA 340.104 (64-bit), NVIDIA 340.106 (32-bit), NVIDIA 340.106 (64-bit), NVIDIA 367.57 (32-bit), NVIDIA 367.57 (64-bit), NVIDIA 370.28 (32-bit), NVIDIA 370.28 (64-bit), NVIDIA 375.26 (32-bit), NVIDIA 375.26 (64-bit), NVIDIA 375.39 (32-bit), NVIDIA 375.39 (64-bit), NVIDIA 375.66 (32-bit), NVIDIA 375.66 (64-bit), NVIDIA 375.82 (32-bit), NVIDIA 375.82 (64-bit), NVIDIA 378.13 (32-bit), NVIDIA 378.13 (64-bit), NVIDIA 381.09 (32-bit), NVIDIA 381.09 (64-bit), NVIDIA 381.22 (32-bit), NVIDIA 381.22 (64-bit), NVIDIA 384.47 (32-bit), NVIDIA 384.47 (64-bit), NVIDIA 384.59 (32-bit), NVIDIA 384.59 (64-bit), NVIDIA 384.69 (32-bit), NVIDIA 384.69 (64-bit), NVIDIA 384.90 (32-bit), NVIDIA 384.90 (64-bit), NVIDIA 384.98 (32-bit), NVIDIA 384.98 (64-bit), NVIDIA 384.111 (32-bit), NVIDIA 384.111 (64-bit), NVIDIA 384.130 (32-bit), NVIDIA 384.130 (64-bit), NVIDIA 387.12 (32-bit), NVIDIA 387.12 (64-bit), NVIDIA 387.22 (32-bit), NVIDIA 387.22 (64-bit), NVIDIA 387.34 (32-bit), NVIDIA 387.34 (64-bit), NVIDIA 390.12 (32-bit), NVIDIA 390.12 (64-bit), NVIDIA 390.25 (32-bit), NVIDIA 390.25 (64-bit), NVIDIA 390.42 (32-bit), NVIDIA 390.42 (64-bit), NVIDIA 390.48 (32-bit), NVIDIA 390.48 (64-bit), NVIDIA 390.59 (32-bit), NVIDIA 390.59 (64-bit), NVIDIA 396.24 (32-bit), NVIDIA 396.24 (64-bit), ..., NVIDIA 430.26 (32-bit), NVIDIA 430.26 (64-bit). The userspace driver version have to match the kernel driver version. Multiply it by every GPU vendor, including less known ones, such as VIA/S3G/Zhaoxin.

The only users of multilib in all Linux distros are binary-only applications. Steam and older games, Wine and Windows applications, old drivers for old printers, whatever.
Non-critical at best, and in most cases it's probably better if they bundle their own 32bit libraries themselves.

It is an extremely stupid idea to include glibc, ELF loader, and GPU drivers in every single application. This approach is awfully bad when it comes to maintenance, not even mention that it will be a security nightmare. What's worse, by going this way you will have to update the whole application each time when NVIDIA issues a new driver.

Yes. Canonical has already started the process for their own distro, Ubuntu.

No, they didn't. They have tried to, but then Valve talked them out of this insanity.

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Partial-32-Bit-19.10

Projects like Flatpak and Snap can already allow older applications to run

How many times I have to tell that Flatpak is not a solution here? It is just not suitable for everything.

https://github.com/flathub/flathub/pull/486#issuecomment-405826821

To expand on what TingPing said, Steam at least provides some common runtime that publishers/developers can base on, and even if that in mind, it doesn't really work. Just go through issues reported on Flathub's Steam repository – many games are broken because of dependence on external libraries or applications that are not correctly shipped. GameHub doesn't provide even that and it's impractical to add every missing dependency to Flatpak application itself.

GOG clearly states on their website that only Ubuntu is supported and even the release differs between particular games. Humble Bundle is even more trigger happy and I had even less luck with few games I bought there. Not to mention that some are 32-bit only, making it even harder to make everything work. All this results in bad user experience, especially for players with no technical Linux background and I can't see Gamehub being any different.

(On a side note, we are also considering removing Steam.)

Flatpak isn't a replacement for standard packages and never will be. There are too many cases where it just doesn't work well. And believe me, I know what I am talking about. I've created dozens of flatpak packages. Some of them are published on Flathub.

What's worse, multiarch in Flatpak is simple broken.

https://github.com/flatpak/freedesktop-sdk-images/issues/101

Creating package for Lutris in a modern distribution is relatively easy. However, they spent at least 5 months (probably much more, because they have talking about it since 2017, and the Flathub repo was created just two months ago) to provide the flatpak package that is still a half-working solution! What is worse, it is hard to maintain.
This is the future of Linux desktop you want? Transferring the burden of work from distribution developers to application developers/maintainers? It's one of the worst ideas I've ever heard.

with a static (in the sense of no more updated) set of 32bit libraries.

People don't want to use an ancient version of WINE. They want to use a modern WINE with DXVK, probably using PlayOnLinux/Phoenicis or Lutris to manage wine versions and wine prefixes. And if you stay with the current distribution/runtime for years, you will suffer from unresolvable dependency problems, sooner or later. Just like it is already hard to prepare packages for Ubuntu 14.04 LTS or CentOS 6, there will be a very similar problem with PlayOnLinux/Phoenicis and Lutris on Ubuntu 18.04 LTS in 2023 or 2028. As long as Microsoft has a majority market share in desktop operating systems, no one should even consider dropping multiarch/multilib support in desktop Linux distributions.

[the_scx]

Why would Linux need to care about old crap Windows applications.

Why should we care about ancient/legacy/obsoleted crap POSIX programs, when we can use modern UWP apps?
Jokes apart, almost every computer user will sooner or later need to run a Win32 application. It can be educational software required by school or university, driving license course, tax program, specialist application or just a small utility useful at work. I don't see the slightest reason to make it harder than it has to be. With such a small market share, Linux will never be supported by 3rd-party vendors at the same level as Windows or even macOS. And commercial software developers will never care about a system that is unable to provide a sane stable ABI.

BTW: if you hate commercial software so much, why don't you use Debian GNU/Hurd on a RISC-V based SBC with the Libre Vulkan accelerator? At least Hurd multiserver microkernel design (GNU Mach) is slightly modern (you love this word, don't you?) than Linux monolithic kernel.

[the_scx]

I'm quite frankly sick of these comparisons. The amount of people that actually NEED Photoshop-only features can be counted on a couple hands.

The only reason everyone uses Photoshop is because it's trivial to crack and has always been (on purpose, imho), but there are tons of graphic artists using Krita or other non-Adobe software and they are fine.

The point is that almost every Windows program depends on some 32-bit components. This applies even to applications and games released this year. If you call them "legacy", then you have to call every single POSIX program an "ancient". And because each Linux application depends on libc (directly or indirectly), then all Linux software is an ancient crap. At least according to what you already said here.

[the_scx]

Because they probably run far better under Wine then Windows 10. We should promote Linux's superior retro Windows support.

He was talking about all Windows software, including applications released this year. Unfortunately, many new programs are poorly supported by WINE. Some binaries crash immediately after launching.
That's why we should keep improving the WINE and related projects (e.g. VK9, DXVK, VKD3D) instead of sticking to the current version forever. However, it won't be possible if we freeze the compiler (GCC/Clang, Bison, Flex) and libraries (ALSA, AudioFile, CUPS, D-Bus, fontconfig, fontforge, FreeGLUT, freetype, gettext, giflib, glibc, glx-utils, GnuTLS, gsm, GStreamer, Gtk+, gvfs, isdn4k, libatomic, libattr, libcurl, libdbusmenu, libFAudio, libgphoto2, libieee1284, libjpeg, libpcap, libpng, librsvg2, libstdc++, libtiff, libusb, libv4l, libva, libvdpau, libX11, libXcomposite, libXcursor, libXext, libXi, libXinerama, libxml2, libXmu, libXrandr, libXrender, libXScrnSaver, libxslt, libXtst, libXxf86dga, libXxf86vm, LittleCMS, Mesa, mpg123, ncurses, nss, OpenAL, OpenCL, OpenCL ICD Loader, OpenGL, OpenLDAP, Perl, PulseAudio, Python, SANE, SDL2, unixODBC, Vulkan, WebKit2, zlib) on the current version.

[starshipeleven]

Valve already provides Steam Runtime which make the Steam client and games almost independent of any distro

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

[/QUOTE]We don't want to back to DOS times, in which every single game developer had to deliver GPU drivers, because it is an extremely stupid approach.[/QUOTE]In DOS times games were mostly operating the hardware directly. "drivers" are a later invention, as were GPUs.

It is an extremely stupid idea to include glibc, ELF loader, and GPU drivers in every single application.

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.

No, they didn't.

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.

How many times I have to tell that Flatpak is not a solution here?

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.

Flatpak isn't a replacement for standard packages and never will be.

Standard packages have failed already, older games on Steam are a crapshoot.

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.

What's worse, multiarch in Flatpak is simple broken.

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

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

This is the future of Linux desktop you want? Transferring the burden of work from distribution developers to application developers/maintainers?

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.

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.

People don't want to use an ancient version of WINE. They want to use a modern WINE with DXVK, probably using PlayOnLinux/Phoenicis or Lutris to manage wine versions and wine prefixes.

You need libraries for sound and other stuff that the game actually likes too. Those are going to be static, that's what I meant.
Wine, Mesa and the game management application are infrastructure that should stay outside of these little sandboxes. They are opensource already, why you place them inside?

As long as Microsoft has a majority market share in desktop operating systems, no one should even consider dropping multiarch/multilib support in desktop Linux distributions.

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.

[starshipeleven]

Why should we care about ancient/legacy/obsoleted crap POSIX programs, when we can use modern UWP apps?

Because I can recompile most of them to run anywhere, while UWP apps are shit and only run on Win10.

Jokes apart, almost every computer user will sooner or later need to run a Win32 application.

That's what Virtualbox is for.
Really, the chances that Wine will work with a random application are low and if you say otherwise you are wrong.

While a VM will work fine any time as long as you don't need 3D graphic performance (and if you do it's not THAT hard to use KVM instead and passthrough a GPU)

BTW: if you hate commercial software so much, why don't you

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.

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.

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.

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.
And actually one-upping Windows on this, because while it is sure better than Linux at retrocompatibility with old binary applications it still sucks.

[starshipeleven]

The point is that almost every Windows program depends on some 32-bit components.

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.

Doing otherwise is some ReactOS-level nonsense.

[dungeon]

You are wrong. Microsoft has no plans to end support for Windows 10.

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

Support for Windows 10 1507 (Threshold 1) will ended on October 14, 2025. However, Windows 10 1809 (Redstone 5) will be supported until January 9, 2029. Moreover, the next versions are planned for the coming years, and they will be supported even longer.
https://en.wikipedia.org/wiki/Window..._history#Rings

And every major ringing number there is different OS really

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

[Weasel]

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.

Doing otherwise is some ReactOS-level nonsense.

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.

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.