Open-Source / Linux Letdowns For 2018

While 2018 was a grand year for open-source and Linux as we've been recapping all of the highlights in recent days on Phoronix, it wasn't without some shortcomings or areas that have yet to pan out... As we end 2018, for some interesting New Year's Eve discussions in the forums, here is a look at some of the biggest Linux/open-source letdowns of the year.

Here are what I personally consider to be some of the biggest letdowns of the year. Feel free to chime in with your own open-source letdowns in the forums.

Open-Source NVIDIA / Nouveau - While it's not too realistic expecting NVIDIA to fully open-source their Linux graphics driver, there are two pain points for the year that could have been achievable with some support from NVIDIA. Those two I would argue are re-clocking / power management for newer (GTX 900 Maxwell and later) graphics cards on Nouveau and also having an open-source Vulkan driver. The Nouveau developers are still bound from re-clocking support for Maxwell/Pascal/Volta/Turing GPUs on their open-source driver due to PMU firmware issues that could be solved by NVIDIA but unfortunately no public progress to report... Without being able to up the core/memory/shader frequencies from their boot frequencies, the Nouveau driver is terribly slow as the cards under 3D load are not running at their rated frequencies but rather a fraction of where they should be. This is the number one pain point right now for the open-source NVIDIA Linux dGPU support. Likewise, Nouveau becoming less relevant until they have an open-source Vulkan driver with more games moving to Vulkan-only... But at least Red Hat is sort of working in that direction with their SPIR-V work that's ongoing. But damn, 2019 would be so exciting for open-source enthusiasts if there is re-clocking support for Maxwell and newer.

Linux GPU Driver GUIs - While the Intel/Radeon open-source Linux drivers are nearly at parity to the proprietary Windows drivers, one area still lacking particularly on the Radeon side is over a full-featured GUI control panel. AMD talked at one point of open-sourcing their Qt-based Radeon Software Settings, but that hasn't happened. More recently their developers basically expressed they'll let the desktop environments work on such settings panels. But besides monitor/multi-monitor management and other basics, there isn't any really good offering available... There are a lot of small, independent utilities from DriConf to different niche projects around the AMDGPU interfaces for overclocking and other bits, but no single really polished driver GUI configuration panel. Seemingly nearly all of what's needed for having a great GUI control panel for the Radeon Linux driver is already exposed via kernel interfaces to user-space, just no great user-interface to make use of all these tunables and other information exposed.

WireGuard Is Not Yet Mainlined - The WireGuard secure VPN tunnel continues being increasingly adopted across different platforms, receiving plentiful endorsements, and other praise, but sadly the kernel bits aren't yet in the Linux mainline tree. We hoped it would happen by Linux 4.20~4.21 but it has not yet. Seemingly this holdup is due to working on the Zinc crypto API portion that has received some criticism, but we'll see how much longer it takes before WireGuard is in the mainline kernel and then super easy to deploy from the Linux desktop.

Steam Linux Marketshare Is Under 1% - While there has been some increases to the Linux market-share on Steam since Valve rolled out Steam Play several months back to allow Windows games to run more easily on Linux, it's still embarrassing to say that the Linux gaming market-share is still sub-1%. Granted, the Steam user-base continues growing overall, but still ~1% is a big psychological milestone.

GNOME Wayland Performance Issues - The past two GNOME release series in particular have done a lot to improve the GNOME Shell / Mutter performance under Wayland, but a few lingering issues remain. In particular, my main gripe left is the GNOME multi-monitor performance with Wayland still being sluggish compared to using the same setup with an X.Org Server session instead. Hopefully this gets ironed out for the upcoming GNOME 3.32...

X.Org Still Ever Present On Linux Desktops - Wayland has now been in development for ten years and while the various Linux desktop environments continue working on their Wayland compositor support, in 2018, it seems the X.Org Server is still heavily relied upon by most Linux desktop users. We'll see in 2019 if Ubuntu switches back to a Wayland-based session by default ahead of Ubuntu 20.04 LTS, whether the NVIDIA EGLStreams back-end for KDE's KWin gets mainlined, and other roadblocks addressed.

Xfce 4.14 Not Released Yet - More Xfce components have seen new 4.13 development releases over the past year and there is more work on getting Xfce 4.14 across the finish line, but Xfce 4.14.0 still isn't out yet. Xfce 4.12 was released in February 2015 while Xfce 4.14 is working on the long overdue GTK3 transition.

GIMP 3.0 - Besides the current Xfce stable release still living in the GTK2 era, GIMP 3.0 didn't make it out the door. At least GIMP 2.10 debuted, but we're certainly looking forward to the GTK3-based GIMP 3.0.

Squeezing The Last Bits Of Linux Performance - Addressing security vulnerabilities took a hit on Linux performance with most distributions this year to the point it's down compared to a year ago. Sadly, this didn't cause much efforts by Linux distributions to invest in other performance optimizations to try to recover -- or even manage a net improvement -- in Linux performance. Most Linux distributions still leave a lot of untapped potential by not building their packages with link-time optimizations (LTO), exploiting function multi-versioning (FMV), better kernel tuning, and other ways to squeeze more performance out of the hardware that we've seen is very well possible by the likes of Clear Linux. Hopefully more tier-one Linux distributions will invest in performance optimizations next year, especially with 32-bit x86 Linux support finally becoming less of a concern, etc.

No Clear Next-Gen Linux File-System Front-Runner - Red Hat made clear they aren't putting their weight behind Btrfs and deprecated it on RHEL. Red Hat is now working on their XFS-based Stratis storage solution for RHEL8 and current RHEL users continue being seemingly happy on XFS. SUSE and others meanwhile are still backing Btrfs and its big feature set while being part of the mainline kernel. Ubuntu and others still seem happy on EXT4 until a better (and stable) solution is out there. Lots of independent users and companies are happy as well opting for ZFS On Linux even though that file-system support isn't mainlined and won't be unless Oracle re-licenses it. There are also other promising Linux file-systems in development like Bcachefs or even the recent successes of F2FS.

The GNU/Linux Smartphone - There still is no compelling GNU/Linux smartphone available and it's not clear that will change in 2019. Right now UBports' continued community work on Ubuntu Touch is arguably most successful but only is community-driven, limited app support, and somewhat limited device support. Purism's Librem 5 is running months behind their original schedule but still might ship by mid-2019 but rather pricey for the phone specifications and it's not clear if the software stack will be up to scratch in time. Plasma Mobile appears to be making some progress but still more work to be done. Other efforts like ReplicantOS for a free-Android are still based upon Android 6.0.

What else did you find to be a letdown for open-source Linux in 2018 or where you hope to see improvements in 2019? Let us know in the forums.