Huh? How did you narrow it down to just GIMP? Are you excluding all non-GUI software or something? GUI has never been a big focus for GNU (which I assume is what you’re referring to when you say FSF), though they do have a couple of projects like GIMP and GNUCash. Most notably as far as GUI is concerned, they instigated the GNOME project, though they later split off. But yeah, they still maintain extremely important tools, especially for developers and UNIX systems, such as glibc, coreutils, gcc, emacs, gdb, make, bash, grub, octave, guix, etc.

eh, still beats Discord as far as I’m concerned

This has actually been the most positive reaction to a Firefox announcement I’ve seen in a long time. I’ve yet to find a piece of open source software users act more toxic towards than Firefox. It is impossible to find any Firefox-related announcement in recent years that’s received broadly positive feedback. For a long time, the top voted comment would always be someone demanding tab groups or vertical tabs. Now they’re adding those, which is probably why the reaction has been a bit more positive. But of course, AI and UI changes have become the new things to complain about.

why did it insert and translate some random japanese phrase in the lede

?

can’t find any client by that name

No. all KDE config is in the home directory except maybe some SDDM stuff, which should be trivial to reconfigure if needed.

You learn significantly more from actually fixing the problems with your install as opposed to just constantly starting over every time. Doing it just to get rid of a couple of GNOME packages is especially not worth the trouble, considering it’s a rather trivial task.

Enlightenment is easily the lightest full DE. It is my recommendation.

The idea that a web application for screen recording is less bloat than OBS is absurd. As this was the idea presented by OP, atzanteol reacted by figuratively saying that the word no longer had any meaning. Given the context, this was quite clearly not an attempt to downplay the effects or severity of software bloat, but simply a figurative use of the phrase meant to point out how badly the word bloat had been misused. You completely misinterpreted their comment. Then, when this was pointed out to you, you proceeded to do the Reddit thing of mockingly editing your original downvoted comment, successfully making an ass out of yourself.

The D3D shader compiler has been open source for many years. This is just a new version of it.

How? D3D9 only needs HLSL 3. Perhaps you meant adding support for newer D3D versions? D3D10 and D3D11 support are certainly possible, though even still D3D11 only needs HLSL 5. As for D3D12, it would be impossible for the same reason Vulkan on Gallium is impossible; it’s too low level.

Anyway, I’ve used Gallium-Nine with RadeonSI. It works fine. It can even be faster than DXVK, sometimes. Other times, DXVK is faster. They’re about on par. Which kinda begs the question, what’s the point? Gallium-Nine isn’t substantially faster than DXVK and is much less portable, since it requires a Gallium3D driver to work, so it won’t work for Nvidia. The Nouveau Gallium3D driver is way too slow to come close to DXVK. Zink + Gallium-Nine probably works, but I also can’t see that beating DXVK. That’s the reason Gallium-Nine died. Not because they didn’t have the latest HLSL, but because DXVK killed interest in the project.

Elisa wasn’t really meant to be an Amarok successor, it just kinda turned out that way because Elisa popped up around the time of the Plasma 5 release while Amarok never made the Qt5 transition. There were other reasons for Amarok’s death (before its recent revival), though Elisa could be considered a factor.

I guess the main improvement is that the panels and sidebars don’t cover the desktop, so you can edit all of it more easily.

To me the most annoying thing with edit mode was that auto-hide panels would still hide in edit mode, making them difficult to edit, but that was also fixed a little earlier.

It’s not being packaged by distros yet. You need to build from source.

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.

Package management is probably the biggest thing a Linux user might need to use the terminal for. The graphical package managers used by default on most desktop environments are far too limited.

KDE’s Discover for instance is capable of installing (graphical) desktop applications, uninstalling packages and performing updates. Sure, it supports native packages on the majority of distros through PackageKit, as well as Flatpaks and Snaps, but it can only perform very basic package manager operations. I imagine most users will at some point need to install a package that isn’t a graphical desktop application, such as a driver or an optional dependency and they will need to use the terminal for it.

To my knowledge, this is also the state of most other graphical package managers that take the form of “software centers” like Discover. More powerful graphical package managers do exist, usually specific to a specific package manager such as Octopi for Pacman. Few distros ship with them, however. I believe one notable exception is OpenSUSE with YaST. There’s also dnfdragora on Fedora, which is pretty basic, but might be good enough for most purposes.

OnlyOffice is not based on LibreOffice. There might be a point in joining forces with OpenOffice if OpenOffice actually had forces to join with, but it doesn’t because it is a dead project.

Indeed, but GNOME is big enough to veto against anything they dislike getting into Wayland. And indeed, TWMs were brought up as a big reason why CSD sucks; window decorations primarily contain controls for the window manager and the form these controls should take depends entirely on the nature of the window manager, therefore the window manager should draw the controls. But GNOME doesn’t want to perform the oh so difficult task of providing window controls to apps that don’t provide their own under Wayland, so too bad.