KDE: This week in Usability & Productivity and KBibTeX's Latest

• This week in Usability & Productivity, part 45

  Let’s have a bit more Usability & Productivity, shall we? The KDE Applications 18.12 release is right around the corner, and we got a lot of great improvements to some core KDE apps–some for that upcoming release, and some for the next one. And lots of other things too, of course!

• Running KBibTeX from Git repository has become easier

  A common problem with bug reports received for KBibTeX is that the issue may already be fixed in the latest master in Git or that I can provide a fix which gets submitted to Git but then needs to be tested by the original bug reporter to verify that the issue has been indeed fixed for good. For many distributions, no ‘Git builds’ are available (or the bug reporter does not know if they exist or how to get them installed) or the bug reporter does not know how to fetch the source code, compile it, and run KBibTeX, despite the (somewhat too technical) documentation. Therefore, I wrote a Bash script called run-kbibtex.sh which performs all the necessary (well, most) steps to get from zero to a running KBibTeX. The nicest thing is that all files (cloned Git repo, compiled and installed KBibTeX) are placed inside /tmp which means no root or sudo are required, nor are any permanent modifications made to the user&aposs system.

FreeBSD 12.0-RC1 Released, Fixes Ryzen 2 Temperature Reporting

Arguably most user-facing with this week's FreeBSD 12.0-RC1 release is updating the amdsmn/amdtemp drivers for attaching to Ryzen 2 host bridges. Additionally, the amdtemp driver has been fixed for correctly reporting the AMD Ryzen Threadripper 2990WX core temperature. The 2990WX temperature reporting is the same fix Linux initially needed to for a 27 degree offset to report the correct temperature. It's just taken FreeBSD longer to add Ryzen 2 / Threadripper 2 temperature bits even though they had beat the Linux kernel crew with the initial Zen CPU temperature reporting last year. Also: MeetBSD 2018: Michael W Lucas Why BSD?

GPU/Graphics: DRM/KMS and CUDA

• Google's Pixel 3 Is Using The MSM DRM Driver, More Android Phones Moving To DRM/KMS Code

  It turns out Google's recently announced Pixel 3 smartphone is making use of the MSM Direct Rendering Manager driver associated with the Freedreno open-source Qualcomm graphics project. Google is also getting more Android vendors moving over to using DRM/KMS drivers to power their graphics/display. Alistair Strachan of Google presented at this week's Linux Plumbers Conference and the growing adoption of Direct Rendering Manager / Kernel Mode-Setting drivers by Android devices.

• Red Hat Developers Working Towards A Vendor-Neutral Compute Stack To Take On NVIDIA's CUDA

  At this week's Linux Plumbers Conference, David Airlie began talking about the possibility of a vendor-neutral compute stack across Intel, Radeon, and NVIDIA GPU platforms that could potentially take on NVIDIA's CUDA dominance. There has been the work on open-source NVIDIA (Nouveau) SPIR-V compute support all year and that's ongoing with not yet having reached mainline Mesa. That effort has been largely worked on by Karol Herbst and Rob Clark, both open-source GPU driver developers at Red Hat. There has also been other compute-motivated open-source driver/infrastructure work out of Red Hat like Jerome Glisse's ongoing kernel work around Heterogeneous Memory Management (HMM). There's also been the Radeon RADV driver that Red Hat's David Airlie co-founded and continues contributing significantly to its advancement. And then there has been other graphics/compute contributions too with Red Hat remaining one of the largest upstream contributors to the ecosystem.

Endless OS Switching To The BFQ I/O Scheduler For More Responsive Linux Desktop

While Con Kolivas' kernel patch series decided to do away with BFQ support, the GNOME-aligned Endless OS Linux distribution has decided to do the opposite in move from CFQ as the default I/O scheduler over to BFQ. Endless OS has decided to switch to the BFQ (Budget Fair Queuing) I/O scheduler since it prioritizes interactive workloads and should make for a better experience for its users particularly when applications may be upgrading in the background. During heavy background I/O, Endless found that their launch time of LibreOffice went from taking 16 seconds with CFQ to just three seconds when using BFQ. Other tests were also positive for improving the interactivity/responsiveness of the system particularly during heavy background I/O.