It's not an unpopular opinion that Apple is the only one that does sleep right. It is an unpopular opinion that this is only possible because they have a complete walled garden and that open platforms are fucked, especially considering it is easy and common to install applications from outside the App Store on macOS. We used to have sleep figured out, that's what S3 was. But then hardware vendors dropped it. So yes, drivers and hardware vendors are part of the problem. The Steam Deck is an example of an open platform where sleep works fine.

Wine doesn't wait for major versions to merge major features. Major versions like Wine 9.0 are considered stable and are preceded by a feature freeze and multiple release candidates. Minor versions like Wine 9.9 are not, they're just released every two weeks from the master branch. This means nearly all of Wine 9.0's killer features were already present in the final Wine 8.21 minor version. The same will be true with Wine 10. Wayland support will continue to improve incrementally in the coming versions.

Sure.

Wine 9.9 bug fixes:

#56000 Window title is not set with winewayland

Wine 9.8 minor changes:

winewayland.drv: Enable wglDescribePixelFormat through p_get_pixel_formats.
winewayland.drv: Set wayland app-id from the process name.
winewayland.drv: Implement SetWindowText.
winewayland: Get rid of the now unnecessary surface wrapper.

Wine 9.7 minor changes:

winewayland: Remove now unnecessary swapchain extents checks.
winewayland: Remove now unnecessary swapchain wrapper.

Wine 9.5 minor changes:

configure: Check the correct variable for the Wayland EGL library.
winewayland.drv: Implement wglCreateContextAttribsARB.
winewayland.drv: Implement wglShareLists.
winewayland.drv: Implement wgl(Get)SwapIntervalEXT.

Wine 9.4 major changes:

Initial OpenGL support in the Wayland driver.

Wine 9.4 minor changes:

winewayland.drv: Add skeleton OpenGL driver.
winewayland.drv: Initialize core GL functions.
winewayland.drv: Implement wglGetExtensionsString{ARB,EXT}.
winewayland.drv: Implement wglGetProcAddress.
winewayland.drv: Implement wglDescribePixelFormat.
winewayland.drv: Implement wglSetPixelFormat(WINE).
winewayland.drv: Implement OpenGL context creation.
winewayland.drv: Implement wglMakeCurrent and wglMakeContextCurrentARB.
winewayland.drv: Implement wglSwapBuffers.
winewayland.drv: Handle resizing of OpenGL content.
winewayland: Remove now unnecessary vulkan function name mapping.
winewayland: Remove unnecessary vkDestroySurfaceKHR NULL checks.

New minor versions of Wine are released every two weeks. Last major Wayland update was in 9.4. Smaller updates have happened every release since, except 9.6.

especially considering KDE already has an application with almost exactly the same name for the same purpose https://invent.kde.org/utilities/alpaka

is this flamebait? we really don't need this stale-ass debate revived for the millionth time. everything that had to be said has been said and no one is going to budge from their positions. there is nothing to be gained from reposting some old controversial 2021 blog post about this outside of more flaming. it's time to move on. this is a waste of everyone's time.

if you're a developer, support themes if you want to support them, don't support them if you don't. if you're a user, use the apps you want to use. if you care about theming, use the apps that support it. if you don't, good for you. there doesn't need to be anything more to it.

VP9 is AV1's predecessor and VP8 is VP9's predecessor. Dunno what the “264K 360° Surround sound 3D VR” thing is about, but AV1 is a good general purpose video codec and I recommend using it, with Opus audio.

EDIT: I should add, h264 and h265 are non-free because of software patents, for which there are licensing fees. There are free implementations and there always have been, but the extent to which these implementations can actually freely be used legally is limited by this. Cisco's OpenH264 is an exception, because there is a cap to the licensing fee and Cisco is already paying the max amount. This allows them to freely distribute binaries for their h264 implementation without having to pay additional licensing fees for every user. It's a clever loophole, but there are still limitations, namely that you have to be using Cisco's pre-built binaries. If you want to use the source code, you still need to pay for the licensing fee.

Because patents last twenty years and the initial release of h264 was made in August 2004, the key h264 patents should all expire within the next few years, which will eliminate the problem. h265 however was introduced in 2013 and its patents still have a good decade left in them.

Linux needed a universal package manager and it got three. Snap is not needed.

So just to clarify, there's no way to support the DualShock 3 without introducing a security hole? Or is the security hole only a problem with the current driver which could eventually be fixed, rather than something inherent to the device? Also, is there a list of affected devices outside the DualShock 3? Will the Wiimote still work, for instance?

The DualShock is old, but I've always appreciated how I could have all of my gamepads just work on Linux, from the Wiimote to the DualSense. On Windows, most of them needed third party unofficial drivers to be installed and/or would be missing functionality, like motion controls or Bluetooth support. Would be a big shame if it just stopped working wirelessly. Still, I have a lot of significantly better gamepads by now, including a DualSense, so DualShock 3 support isn't something I really need anymore unless I have a lot of people over and need to connect a lot of controllers.

For what it's worth, glibc is very much performance-critical, so this shouldn't be a surprise. Any possible optimization is worth it.

There are a ton of free software libc implementations outside of glibc. I think most implementations of libc are free software at this point. There's Bionic, the BSD libcs, musl, the Haiku libc, the OpenSolaris/OpenIndiana libc, Newlib, relibc, the ToaruOS libc, the SerenityOS libc and a bunch more. Pretty sure Wine/ReactOS also have free implementations of the Windows libc.

It never occurred to me before reading this comment that there actually is a use case for the execute permission. To me it was always just this annoying thing I have to do whenever I download an executable which I didn't have to do on Windows.

I mean, not really. You own the stuff you create regardless of who's hosting it. Microsoft doesn't own the copyright for the millions of projects hosted on GitHub either.

Oh boy, 102 comments. Knowing Phoronix, I bet those are a treat to read.