The Rust team released a new version Thursday — Rust 1.69.0 — boasting over over 3,000 new commits from over 500 contributors.

Phoronix highlights two new improvements: In order to speed-up compilation speeds, Rust 1.69 and moving forward debug information is no longer included in build scripts by default. Cargo will avoid emitting debug information in build scripts by default — leading to less informative backtraces in build scripts when problems arise, but faster build speeds by default. Those wanting the debug information emitted can now set the debug flag in their Cargo.toml configuration.

The Cargo build shipped by Rust 1.69 is also now capable of suggesting fixes automatically for some of the generated warnings. Cargo will also suggest using "cargo fix" / "cargo clippy --fix" when it knows the errors can be automatically fixed.

"The fact remains that Google Chrome is the arbiter of web standards," argues FSF campaigns manager Greg Farough (while adding that Firefox, "through ethical distributions like GNU IceCat and Abrowser, can weaken that stranglehold.")

"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally." Part of Google's official rationale for the deprecation is the following line: "There is not enough interest from the entire ecosystem to continue experimenting with JPEG-XL." Putting aside the problematic aspects of the term "ecosystem," let us remark that it's easy to gauge the response of the "entire ecosystem" when you yourself are by far the largest and most dangerous predator in said "ecosystem." In relation to Google's overwhelming power, the average web user might as well be a microbe. In supposedly gauging what the "ecosystem" wants, all Google is really doing is asking itself what Google wants...

While we can't link to Google's issue tracker directly because of another freedom issue — its use of nonfree JavaScript — we're told that the issue regarding JPEG-XL's removal is the second-most "starred" issue in the history of the Chromium project, the nominally free basis for the Google Chrome browser. Chromium users came out of the woodwork to plead with Google not to make this decision. It made it anyway, not bothering to respond to users' concerns. We're not sure what metric it's using to gauge the interest of the "entire ecosystem," but it seems users have given JPEG-XL a strong show of support. In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format.

As the response to JPEG-XL's deprecation has shown, our rallying together and telling Google we want something isn't liable to get it to change its mind. It will keep on wanting what it wants: control; we'll keep on wanting what we want: freedom.

Only, the situation isn't hopeless. At the present moment, not even Google can stop us from creating the web communities that we want to see: pages that don't run huge chunks of malicious, nonfree code on our computers. We have the power to choose what we run or do not run in our browsers. Browsers like GNU IceCat (and extensions like LibreJS and JShelter> ) help with that. Google also can't prevent us from exploring networks beyond the web like Gemini. What our community can do is rally support behind those free browsers that choose to support JPEG-XL and similar formats, letting the big G know that even if we're smaller than it, we won't be bossed around.

On Thursday patches were submitted for bringing Rust infrastructure to the Video 4 Linux 2 (V4L2) framework (within Linux's media subsystem) by Collabora's Daniel Almeida.

Phoronix reports: This provides just enough for working with a prototype VirtIO camera driver written in Rust along with a Rust sample driver. These initial patches are just intended to start the discussion around V4L2 Rust driver support and the actual upstreaming of the Rust support for these camera drivers may still be some ways down the line.

Further adding to the excitement of the upcoming Linux 6.4 merge window is the mainline kernel seeing the Device Tree (DT) additions for Apple's current M2 devices including the MacBook Air, MacBook Pro, and Mac Mini systems. From a report: The upstream kernel still has more work to go around the M1/M2 support compared to the downstream state with Asahi Linux, but at least now with this DT support will provide some basic level of upstream kernel support for the Apple M2. Asahi Linux lead developer Hector Martin today sent in the Apple SoC DT updates targeting the Linux 6.4 cycle for queuing into the SoC tree ahead of the merge window opening around the end of the month. The main addition with this pull request is adding the Apple M2 Device Tree series.

While Chrome 112 just shipped this week and Chrome 113 only in beta, there is already a big reason to look forward to that next Chrome web browser release: Google is finally ready to ship WebGPU support. From a report: WebGPU provides the next-generation high performance 3D graphics API for the web. With next month's Chrome 113 stable release, the plan is to have WebGPU available out-of-the-box for this new web graphics API. Though in that version Google is limiting it to ChromeOS, macOS, and Windows... Yes, Google says other platforms like Linux will see their roll-out later in the year. The WebGPU API is more akin to Direct3D 12, Vulkan, and Metal compared with the existing WebGL being derived from OpenGL (ES). From Google's blog post: WebGPU is a new API for the web, which exposes modern hardware capabilities and allows rendering and computation operations on a GPU, similar to Direct3D 12, Metal, and Vulkan. Unlike the WebGL family of APIs, WebGPU offers access to more advanced GPU features and provides first-class support for general computations on the GPU. The API is designed with the web platform in mind, featuring an idiomatic JavaScript API, integration with promises, support for importing videos, and a polished developer experience with great error messages.

This initial release of WebGPU serves as a building block for future updates and enhancements. The API will offer more advanced graphics features, and developers are encouraged to send requests for additional features. The Chrome team also plans to provide deeper access to shader cores for even more machine learning optimizations and additional ergonomics in WGSL, the WebGPU Shading Language.

Google today promoted the Chrome 112 web browser to their stable channel on all supported platforms. Phoronix reports: Starting as an origin trial with Chrome 112 is WebAssembly (WASM) Garbage Collection support. Yes, garbage collection to allow for efficient support for high-level managed languages with WebAssembly. This trial support allows for compilers targeting WASM to integrate with a garbage collector in the host VM. Also on the WebAssembly front with today's Chrome browser update is making WebAssembly tail call support available out of the box. This adds explicit tail call and indirect tail call opcodes. This support is useful for correct/efficient implementations of languages that require tail call elimination, compilation of control constructs that can be implemented with it, and other computations being expressed as WASM functions.

Meanwhile by default in Chrome 112 is now CSS nesting support as the ability to nest CSS style rules inside other style rules for increasing modularity and maintainability of style sheets. Chrome 112 also adds support for the CSS animation-composition property. Behind a developer flag is also the background-blur feature that allows using a native platform's API for camera background segmentation. This is intended for use with web-based video conferencing applications running within the web browser to make use of native platform APIs. A full list of changes is available on the Chrome Releases blog.

"With an 8-core Rockchip RK3588S SoC, the Orange Pi 5 is leaps and bounds faster than the aging Raspberry Pi 4," writes Phoronix: With up to 32GB of RAM, the Orange Pi 5 is also capable of serving for a more diverse user-base and even has enough potential for assembling a budget Arm Linux developer desktop. I've been testing out the Orange Pi 5 the past few weeks and it's quite fast and nice for its low price point.

The Orange Pi 5 single board computer was announced last year and went up for pre-ordering at the end of 2022.... When it comes to the software support, among the officially available options for the Orange Pi 5 are Orange Pi OS, Ubuntu, Debian, Android, and Armbian. Other ARM Linux distributions will surely see varying levels of support while even the readily available ISO selection offered by Orange Pi is off to a great start....

Granted, the Orange Pi developer community isn't as large as that of the Raspberry Pi community or the current range of accessories and documentation, but for those more concerned about features and performance, the Orange Pi 5 is extremely interesting.
The article includes Orange Pi 5 specs:

• A 26-pin header
• HDMI 2.1, Gigabit LAN, M.2 PCIe 2.0, and USB3 connectivity
• A Mali G510 MP4 graphics processor, "which has open-source driver hope via the Panfrost driver stack."
• Four different versions with 4GB, 8GB, 16GB, or 32GB of RAM using LPDDR4 or LPDDR4X. "The Orange Pi 4GB retails for ~$88, the Orange Pi 5 8GB version retails for $108, and the Orange Pi 5 16GB version retails for $138, while as of writing the 32GB version wasn't in stock."

In 169 performance benchmarks (compared to Raspberry Pi 4 boards), "this single board computer came out to delivering 2.85x the performance of the Raspberry Pi 400 overall." And through all this the average SoC temperature was 71 degrees with a peak of 85 degrees — without any extra heatsink or cooling.

An anonymous reader shares this report from Phoronix: For over a half-decade ASUS has been selling the Tinker Board devices as their line of Raspberry Pi alternatives. To date the ASUS Tinker Board single board computers have all been Arm-based while now they have launched their first RISC-V board, the Tinker V.

The ASUS Tinker V is their first RISC-V single board computer and intended for the industrial IoT (Internet of Things) developer community. The ASUS Tinker V is set to officially run Debian Linux and Yocto while surely with time more Linux distributions will be supported.... Being IoT focused, there isn't any display support. Those interested in learning more about the ASUS Tinker V can do so via tinker-board.asus.com.
The Register notes that Asus "is offering at least five years of support for Tinker V... Dedicated on-site technical support is also available to shorten customer development cycles and accelerate application deployment." The move shows that the RISC-V open-source instruction set architecture continues to garner support. The last RISC-V Summit in San Jose saw the launch of a family of datacenter-class processors based on the architecture from Ventana Micro Systems, while XMOS unveiled new high-performance microcontrollers using RISC-V.

According to Asus, Tinker V samples will be available in Q2 of this year, but it did not disclose a date for full availability or pricing.

An anonymous reader shared this report from Phoronix: A pull request of early AMDGPU kernel graphics driver changes was submitted for DRM-Next on Friday as some of the early feature work accumulating for the Linux 6.4 kernel cycle.

Among the AMDGPU kernel driver changes this round are a number of fixes affecting items such as the UMC RAS, DCN 3.2, FreeSync, SR-IOV, various IP blocks, USB4, and more. On the feature side, mentioned subtly in the change-log are a few power-related additions... These additions are largely focused on Van Gogh APUs, which is notably for the Valve Steam Deck and benefiting its graphics moving forward.

First up, this kernel pull request introduces a new sysfs interface for adjusting/setting thermal throttling. This is wired up for Van Gogh and allows reading/updating the thermal limit temperature in millidegrees Celsius. This "APU thermal cap" interface is just wired up for Van Gogh and seems to be Steam Deck driven feature work so that SteamOS will be better able to manage the thermal handling of the APU graphics....

These power features will be exposed via sysfs while Steam OS will wrap around them intelligently and possibly some new UI settings knobs for those wanting more control over their Steam Deck's thermal/performance.

Today, DreamWorks published the open-source code for MoonRay, their production renderer used for films like The Bad Guys, Puss in Boots: The Last Wish, and other animation films. "OpenMoonRay is available via DreamWorks Animation's GitHub," reports Phoronix. "This professional-grade renderer is available under an Apache 2.0 license."

From the README: "MoonRay was developed at DreamWorks and is in continuous active development and includes an extensive library of production-tested, physically based materials, a USD Hydra render delegate, multi-machine and cloud rendering via the Arras distributed computation framework."

More details can be found via OpenMoonRay.org.

Formerly known as LinuxBIOS, coreboot is defined by Wikipedia as "a software project aimed at replacing proprietary firmware (BIOS or UEFI) found in most computers with a lightweight firmware."

Phoronix is wondering if there's about to be a big announcement from AMD: AMD dropped a juicy tid-bit of information to be announced next month with "openSIL" [an open-source AMD x86 silicon initialization library], complete with AMD Coreboot support....

While about a decade ago AMD was big into Coreboot and at the time committed to it for future hardware platforms (2011: AMD To Support Coreboot On All Future CPUs) [and] open-source AGESA at the time did a lot of enabling around it, that work had died off. In more recent years, AMD's Coreboot contributions have largely been limited to select consumer APU/SoC platforms for Google Chromebook use. But issues around closing up the AGESA as well as concerns with the AMD Platform Security Processor (PSP) have diminished open-source firmware hopes in recent years....

For the Open Compute Project Regional Summit in Prague, there is a new entry added with a title of OSF on AMD — Enabled by openSIL (yes, folks, OSF as in "Open-Source Firmware").... [H]opefully this will prove to be a monumental shift for open-source firmware in the HPC server space.
From the talk's description: openSIL (AMD open-source x86 Silicon Initialization Library) offers the versatility, scalability, and light weight interface to allow for ease of integration with open-source and/or proprietary host boot solutions such as coreboot, UEFI and others and adds major flexibility to the overall platform design.

In other words, this library-based solution simply allows a platform integrator to scale from feature rich solutions such as UEFI to slim, lightweight, and secure solutions such as coreboot.
The description promises the talk will include demonstrations "highlighting system bring-up using openSIL integrated with coreboot and UEFI Host Firmware stacks on AMD's Genoa based platforms."

Phoronix reports: While Ubuntu Linux hasn't provided Flatpak support out-of-the-box due to their preference of using their own Snap app packaging/distribution format, Ubuntu flavors/spins have to this point been able to pre-install Flatpak support if they desired. However, for the 23.04 "Lunar Lobster" cycle and moving forward, Ubuntu flavors will no longer be permitted to install Flatpak packages by default.

Flatpak support for Ubuntu and its flavors will remain available in the Ubuntu archive so those wanting to install Flatpak support can easily do so post-install.

This change going into effect with the 23.04 cycle is making it so no Ubuntu flavors will have Flatpak support installed by default / out-of-the-box: they are supposed to center around Debian packages and Snaps for their out-of-the-box packaging support to align with Ubuntu.
From the blog OMG Ubuntu: Ubuntu developers have agreed to stop shipping Flatpak, preinstalled Flatpak apps, and any plugins needed to install Flatpak apps through a GUI software tool in the default package set across all eight of Ubuntu's official flavors, as of the upcoming Ubuntu 23.04 release.

Ubuntu says the decision will 'improve the out-of-the-box Ubuntu experience' for new users by making it clearer about what an "Ubuntu experience" is....

As far as Ubuntu is concerned, only deb and snap software is intrinsic to the 'Ubuntu experience', and that experience now needs to be offered everywhere. Flavor leads (apparently) agree, and have all agreed to mirror regular Ubuntu by not offering Flatpak features in their default install for future releases....

Flatpak will not be uninstalled or removed when user makes the upgrade to Ubuntu 23.04 from a version where Flatpak is already present.

A Rust-based re-implementation of GNU core utilities like cp and mv is "reaching closer to parity with the widely-used GNU upstream and becoming capable of taking on more real-world uses," reports Phoronix: Debian developer Sylvestre Ledru [also an engineering director at Mozilla] began working on uutils during the COVID-19 pandemic and presented last week at FOSDEM 2023 on his Coreutils replacement effort. With uutils growing into increasingly good shape, it's been packaged up by many Linux distributions and is also used now by "a famous social network via the Yocto project...."

The goals with uutils are to try to create a drop-in replacement for GNU Coreutils, strive for good cross-platform support, and easy testing. Ledru's initial goals were about being able to boot Debian, running the most popular packages, building key open-source software, and all-around it's been panning out to be a great success.... [M]ore performance optimizations are to come along with other work for compatibility against the GNU tools and implementing some still missing options in different programs

Linux 6.1 was widely anticipated to be a Long-Term Support (LTS) kernel with normally the last major release series for the calendar year normally promoted to LTS status. Greg Kroah-Hartman as the Linux stable maintainer went ahead today and formally recognized Linux 6.1 as the 2022 LTS kernel. From a report: Greg KH was planning on Linux 6.1 being LTS given its December debut. But he was waiting on feedback from kernel stakeholders over their test results with Linux 6.1 and plans around using Linux 6.1 for the long-term. He's finally collected enough positive responses -- along with co-maintainer Sasha Levin -- that there is confidence in maintaining Linux 6.1 as an LTS series.

As of now the plan is on maintaining Linux 6.1 through December 2026, which is just a few months longer than the current Linux 5.15 LTS series that will be maintained through October 2026. We'll see over time if Linux 6.1 ends up potentially being maintained for the longer six-year LTS period that would put it through 2028. However, the number of Linux LTS series being maintained in tandem is growing and will ultimately depend upon how much these kernels are used by major industry players and how much commitment there is for testing of the point release candidates, etc.

Phoronix reports: A proposed Linux kernel patch would provide a new Kconfig build time option of "CONFIG_DEFAULT_CPU_MITIGATIONS_OFF" to build an insecure kernel if wanting to avoid the growing list of CPU security mitigations within the kernel and their associated performance overhead.

While risking system security, booting the Linux kernel with the "mitigations=off" option has been popular for avoiding the performance costs of Spectre, Meltdown, and the many other CPU security vulnerabilities that have come to light in recent years. Using mitigations=off allows run-time disabling of the various in-kernel security mitigations for these CPU problems.

A patch proposed this week would provide CONFIG_DEFAULT_CPU_MITIGATIONS_OFF as a Kconfig switch that could optionally be enabled to have the same affect as mitigations=off but to be applied at build-time to avoid having to worry about setting the "mitigations=off" flag.

Phoronix compares the performance of Firefox and Chrome on the Linux desktop. They used recent releases (at default settings) for both browsers on an Intel Core i9 13900K "Raptor Lake" system with Radeon RX 6700XT graphics, concluding "out-of-the-box Google Chrome continues performing much better overall than Mozilla Firefox."

One area where Firefox does better out-of-the-box is around the HTML5 Canvas such as measured via the CanvasMark test case. For the demanding JetStream 2 benchmark as one of the most demanding browser tests currently, Chrome on Linux was 67% faster than Firefox on this same Intel Raptor Lake desktop.

Firefox did have a small win in the rather basic JavaScript Maze solver benchmark. Firefox at least was in a competitive space for the WebAssembly (WASM) benchmarks, but aside from that Google Chrome continues holding strong on Linux in the performance department.

Phoronix reports: With the next Linux kernel cycle we could see upstream disable their driver support for Microsoft's Remote Network Driver Interface Specification (RNDIS) protocol due to security concerns.

RNDIS is the proprietary protocol used atop USB for virtual Ethernet functionality. The support for RNDIS outside of Microsoft Windows has been mixed. RNDIS isn't widely used today in cross-platform environments and due to security concerns the upstream Linux kernel is looking to move the RNDIS kernel drivers behind the "BROKEN" Kconfig option so they effectively become disabled in future kernel builds.

Ultimately once marked as "BROKEN" for a while, the drivers will likely be eventually removed from the upstream source tree.
Greg Kroah-Hartman wrote in a commit: "The Microsoft RNDIS protocol is, as designed, insecure and vulnerable on any system that uses it with untrusted hosts or devices. Because the protocol is impossible to make secure, just disable all rndis drivers to prevent anyone from using them again."

Google announced today that moving forward they will be allowing Rust code into the Chromium code-base, the open-source project that ultimately served as the basis for their Chrome web browser. Phoronix reports: Google is working to introduce a production Rust toolchain into their build system for Chromium and will be allowing Rust libraries for use within Chrome/Chromium. The timeframe for getting this all together is expected within the next year following a slow ramp. Google is backing Rust for Chromium to allow for simpler and safer code than "complex C++" overall, particularly around avoiding memory safety bugs. In turn using Rust should help speed-up development and improve overall security of the Chrome web browser. Initially they are focused on supporting interop in a single direction from C++ to Rust and for now will only be supporting third-party libraries for their Rust usage.

Michael Larabel writes via Phoronix: While Mesa's development has been very vibrant this year, the X.Org Server development pace has continued pulling back greatly from its late 00's and early 10's highs. This year saw just 156 commits to the xserver Git master branch, down from 331 last year and well off the highs of 2,114 as the most ever back in 2008. This jives with the downward pace over the past decade of the number of new commits continuing to slide. But it's not just on a commit basis but in overall code churn, 2022 was another low for the X.Org Server. With the 156 commits this year, there were just 3,618 lines of new code added and 888 lines removed.... Compared to last year with its 331 commits seeing 31.4k new lines and 179k lines removed.

The X.Org Server development this year on a commit basis hasn't been as low since 2003 when there were just 125 commits under their old development model and even back then meant there was +865k lines /680k lines removed across that span of commits. There hasn't been so little code churn to the X Server since 2002. [...] This year saw commits from just 32 different email addresses, down from 48 in prior years and that number of different authors hasn't been so low since 2003 when there were just 10 recorded. Olivier Fourdan of Red Hat was the most prolific committer to the X.Org Server this year with nearly a quarter of the commits. Following Olivier was Jeremy Huddleston Sequoia, Peter Hutterer, Michel DÃnzer, Alan Coopersmith, and Sultan Alsawaf. This year's X.Org Server development metrics can be found here.

Phoronix checks systemd's Git activity in 2022 (and compares it to previous years): If measuring a open-source project's progress by the commity activity per year, while not the most practical indicator, systemd had a very good year. In 2022 there were 6,271 commits which is under 2021's all-time-high of 6,787 commits. But this year's activity count effectively ties 2018 for second place with the most commits in a given calendar year.

This year saw 201k lines of new code added to systemd and 110k lines removed, or just under one hundred thousand lines added in total to systemd in 2022....

Systemd continues to grow and is closing out 2022 at around 1,715,111 lines within its Git repository.
Also interesting: "[W]hen it comes to the most commits overall to systemd over its history, Lennart Poettering easily wins the race and there is no competition. As a reminder, this year Lennart joined Microsoft as one of the surprises for 2022."