Linux Kernel Development and NVIDIA Graphics

• Micron's HSE Open-Source Storage Engine Ticks Up To v1.7.1

  Announced at the end of April was Micron's HSE as a new open-source storage engine designed for offering speedy performance and lower latency on modern solid-based storage, especially for systems employing 3D XPoint technology. Version 1.7.1 of HSE was released today as their first open-source release since going public with this technology. HSE 1.7.0 was released a week prior to Micron announcing this open-source project in April while has now been succeeded by v1.7.1. This heterogeneous-memory storage engine over the past month has seen a number of fixes throughout, cleaning up code as a result of code review, fixing up some of the examples, and other work.

• Linux 5.8 Feature Queue Has Multiple Performance Optimizations, Intel Rocket Lake, Other Hardware

  If all goes well Linux 5.7 should reach stable this weekend and that in turn will mark the start of the Linux 5.8 merge window. With our monitoring of the various "-next" branches for weeks already, here is a look at some of what is on the table for this next version of the Linux kernel.

• NVIDIA 440.66.15 Vulkan Linux Driver Offers Up More Fixes

  NVIDIA has been quite aggressive recently with their new Vulkan beta drivers for Windows and Linux with today marking another such release. NVIDIA over the course of May is now on their third Vulkan beta series after the prior two added new Vulkan extensions and different fixes, including improvements to their KHR ray-tracing support. Today's release is focused squarely on delivering more fixes to users/developers.

"Contributing to KDE is easier than you think" and KIO FUSE Beta (4.95.0) Released

• Contributing to KDE is easier than you think – Websites from scratch

  This is a series of blog posts explaining different ways to contribute to KDE in an easy-to-digest manner. The purpose of this series originated from how I feel about asking users to contribute back to KDE. I firmly believe that showing users how contributing is easier than they think is more effective than simply calling them out and directing them to the correct resources; especially if, like me, said user suffers from anxiety or does not believe they are up to the task, in spite of their desire to help back. Last time I talked about websites, I taught how to port current KDE websites to Markdown, and this led to a considerable influx of contributors, since it required very little technical knowledge. This blog post however is directed to people who are minimally acquainted with git, html/css, and Markdown. We will be learning a bit of how Jekyll and scss work too.

• KIO FUSE Beta (4.95.0) Released

  It’s a great pleasure to announce that KIO FUSE has a second Beta release available for testing! We encourage all who are interested to test and report their findings (good or bad) here. Note that, the more people who test (and let us know that they’ve tested), the quicker we’ll be confident to have a 5.0.0 release. You can find the repository here. To compile KIO FUSE, simply run kdesrc-build kio-fuse or follow the README. If your distributor is really nice they may already have KIO FUSE packaged but if they don’t, encourage them to do so!

Firefox Nightly, Mozilla Localization and "Browsers are not rendering engines"

• Firefox Nightly: These Weeks in Firefox: Issue 74

• Mozilla Localization (L10N): How to unleash the full power of Fluent as a localizer

  Fluent is an extremely powerful system, providing localizers with a level of flexibility that has no equivalent in other localization systems. It can be as straightforward as older formats, thanks to Pontoon’s streamlined interface, but it requires some understanding of the syntax to fully utilize its potential. Here are a few examples of how you can get the most out of Fluent. But, before jumping in, you should get familiar with our documentation about Fluent syntax for localizers, and make sure to know how to switch to the Advanced FTL mode, to work directly with the syntax of each message.

• Stuart Langridge: Browsers are not rendering engines

  An interesting writeup by Brian Kardell on web engine diversity and ecosystem health, in which he puts forward a thesis that we currently have the most healthy and open web ecosystem ever, because we’ve got three major rendering engines (WebKit, Blink, and Gecko), they’re all cross-platform, and they’re all open source. This is, I think, true. Brian’s argument is that this paints a better picture of the web than a lot of the doom-saying we get about how there are only a few large companies in control of the web. This is… well, I think there’s truth to both sides of that. Brian’s right, and what he says is often overlooked. But I don’t think it’s the whole story. You see, diversity of rendering engines isn’t actually in itself the point. What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good? Historically, when each company had one browser, and each browser had its own rendering engine, these three layers were good proxies for one another: if one company’s browser achieved a lot of dominance, then that automatically meant dominance for that browser’s rendering engine, and also for that browser’s creator. Each was isolated; a separate codebase with separate developers and separate strategic priorities. Now, though, as Brian says, that’s not the case. Basically every device that can see the web and isn’t a desktop computer and isn’t explicitly running Chrome is a WebKit browser; it’s not just “iOS Safari’s engine”. A whole bunch of long-tail browsers are essentially a rethemed Chrome and thus Blink: Brave and Edge are high up among them.