Updates wine 7 times a week

>updates wine 7 times a week
>glibc still from 1.5 years ago
what do they mean by this?

Attached: 1626152781958.png (1242x1024, 62.72K)

>Void focuses on stability, rather than on being bleeding-edge.

>void

Attached: afde8813-8526-4266-affe-59d2115271f0.png (734x971, 381.74K)

ummm sweaty, not every void user is bound to be a tranny
there are a lot of problems getting other packages to work on such old libc

>tinker tranny distro only care about bing bing yahoo
shocking

>uses wine
opinion eternally invalidated

>not every void user is bound to be a tranny
yet*

>such old libc
The latest glibc is 2.34. Void packages 2.32.2. The difference between them is practically nil. glibc 2.34 is 6 months old. glibc 2.32 is 17 months old. If you wanted to make a real point you'd bring up that they're packaging gcc 10.2.1-pre1. It's a bigger issue as far as building newer packages is concerned. If you need bleeding edge software, use a bleeding edge distribution.

Yeah because Void is well known as a gaming platform you fucking clown.

Estrogen can fuckup your sense of priority. Many such cases.

>there are a lot of problems getting other packages to work on such old libc
Meanwhile on windows, you can mix and match software and operating system from 10 years ago and most of it still just werks.

linuxbros... not like this

>pass user
>is retarded and doesn't understand how chroot and/or multilib works
pottery

>there are a lot of problems getting other packages to work on such old libc
What the fuck relies on libc features introduced in the last year? Provide a real world example or gtfo

>thinks chroot is a solution to shitty binary compatibility
>thinks having liburMom-3.9.4.so and liburMom.so with the latter being a symlink to the former actually works when every program links against the symlinked .so, so updating the link breaks everything anyway lmao
>whereas on Windows all the dlls are numbered (e.g. d3d11.dll) and/or binary compatible (user32.dll/kernel32.dll/etc) and/or appropriate versions bundled with the application
>and on Windows dlls can be loaded from the EXE's folder, so you don't have to tell users to type LD_PRELOAD into the terminal
>literally just click the EXE and everything. just. fucking. WERKS.
Linux build systems are incredibly fragile, nonstandard and shit. I would hardly be surprised if some massive piece of shitware like systemD, gnome, rust or whatever depended on some modern feature because the dev is an asshat.
It's easier to work with binaries on Windows, patching EXEs and proxying DLLs and all that, than to figure out the massive complex maze of #ifdefs and circular dependencies and shitty 100000-line build scripts which are auto-generated by some ancient GNU tool, including code to check for 50-year old Unix mainframes with not enough memory to even load the script.
Fucking with Linux build systems is unironically more tedious and difficult than patching machine code on Windows. And I've done both so I should know.

It sounds like you've never heard of Nix, which has solved all those problems.

nix is cool but also infected by systemdicks

>85456645
you can feel the NEET Any Forumstard larp in this post, it’s amazing

>develop software and make package for nix
>have to tell user to install some literally-who package manager and type shit in the terminal
if anything, appimage or whatever it's called is a better solution.
appimage is an equivalent to the windows EXE where you just run it and it werks.
unfortunately, you still have to tell the user to open the terminal and chmod +x because linux is shit

>NOT MY HECKIN TERMINAL!
kys winfag

Pretty sure even Nautilus has a GUI for making a file executable. Either way you can just build an AppImage from a Nix closure, which is trivial because the closure is already self-contained. It'll also be much more reliable than your average AppImage because it will rely on no system libraries whatsoever, while generic AppImages at the very least depend on a specific libc.