Linux' Btrfs file system receives another bunch of goodness

 
Highlights of Btrfs for Linux 5.14 include: - Avoiding a full sync when truncation does not touch extents, which can reduce run-times by 12%. - Btrfs will also now avoid unnecessary logging of extended attributes during fast fsyncs, for around 17% greater throughput and 17% lower run-time on xattr stress workloads. - A sysfs control to limit scrubbing I/O bandwidth per-device. - Exporting device statistics via sysfs at /sys/fs/btrfs/FSID/devinfo/DEVID/error_stats. - New ioctls for cancellable resize and device delete. - Preemptive flushing improvements. - Preparations around sub-page blocksize handling.

The Linux file system Btrfs is on a really nice development trajectory and receives steady improvements for quite some time already. I switched to Btrfs on my desktop and do not look back to ext4 and actually won't go back as I would really miss the instant snapshot capability and the backup scenarios this feature enables.

Big G has launched an open-source vulnerability (CVE) interchange schema

 
In recent months, Google has launched several efforts to strengthen open-source security on multiple fronts. One important focus is improving how we identify and respond to known security vulnerabilities without doing extensive manual work. It is essential to have a precise common data format to triage and remediate security vulnerabilities, particularly when communicating about risks to affected dependencies—it enables easier automation and empowers consumers of open-source software to know when they are impacted and make security fixes as soon as possible. We released the Open Source Vulnerabilities (OSV) database in February with the goal of automating and improving vulnerability triage for developers and users of open source software. This initial effort was bootstrapped with a dataset of a few thousand vulnerabilities from the OSS-Fuzz project. Implementing OSV to communicate precise vulnerability data for hundreds of critical open-source projects proved the success and utility of the format, and garnered feedback to help us improve the project; for example, we dropped the Cloud API key requirement, making the database even easier to access by more users. The community response also showed that there was broad interest in extending the effort further.

This unified vulnerability interchange schema is supposed to simplify the consumption of the Open Source Vulnerabilities (OSV) database and other CVE sources might contribute to a higher automation in handling CVEs. This will help security solution vendors to release fixes much quicker than before.

Intel contributes much more code to OSS and specifically to Linux than AMD

 
The Intel® Graphics Compiler for OpenCL™ is an LLVM based compiler for OpenCL™ targeting Intel Gen graphics hardware architecture. Please refer to http://01.org/compute-runtime for additional details regarding Intel's motivation and intentions wrt OpenCL support in the open source.

Whoever thinks that AMD is this tiny little corporation that tries to compete the evil Intel, should also compare the OSS contributions of Intel vs AMD. Although AMD is good at multi-core and server workloads, for my developer workstation single-core performance matters a lot more.

LibreOffice on its way to the browser

 
This page describes the port of LibreOffice to WebAssembly (aka WASM) using the Emscripten toolchain, currently targeting the Qt5 VCL backend. The goal is to cross-compile LibreOffice to run in the Browser, maybe with some native UI using LibreOfficeKit. Eventually we can target some WASI runtime or node.js in the future.

Many apps today are build for the web and the browser. Google Docs is a really nice browser-native office suite. No, please do not mentioned Office 365 which is just broken in so many ways. So all of a sudden, in a while, LibreOffice might land with all its features inside your browser.

Rust programming language on its way to the Linux kernel

 
Google wants to see Rust programming language support within the Linux kernel so much so that they have contracted the lead developer working on "Rust for Linux" as the work aims to get mainlined. Google is going public today with their formal support for Rust in the Linux kernel to enhance memory safety and that they have contracted developer Miguel Ojeda to further his work on Rust for the Linux kernel and related security efforts. This contract is going through at least the next year.

I would not use Rust for web apps, microservices, and any other business logic heavy application but for things like Linux kernel it just makes sense. One drawback of Rust is that - because of its compile-time enforce memory safety - it brings some mental overhead to the development process and metal energy should not be spend on low-level issues but the actual problem at hand. This being said, it'll be great to see mor Rust in the Linux kernel.

The Btfs Linux filesystem is gaining popularity

 
Last month plans were published for Fedora Cloud 35 to use the Btrfs file-system by default, similar to Fedora Workstation using Btrfs by default for several releases. That plan has now been signed off on by FESCo allowing for this change to happen. Fedora developers along with engineers from Amazon, Facebook, and elsewhere have been for this move to use Btrfs by default with Fedora Cloud. Among the Btrfs features of interest to the Fedora Cloud folks are transparent file-system compression, copy-on-write (CoW) features, reflinks and snapshots, greater data integrity, online shrink and grow, and the other attributes usually trumpeted when talking about Btrfs.

After starting using Btrfs' instant snapshot capabilities I've never looked back to ext4 the was my previous filesystem of choice for my workstation. As a server fs, I was using XFS but now also considering switching to Btrfs.

The XFS file system is getting a boost with Linux 5.14

 
There are good performance numbers being seen out of this scalability work for the XFS file-system. The big numbers are seeing the transaction rate go up from around 700k to 1.7M commits per second and a reduction in flush operations by 2~x orders of magnitude less for metadata heavy workloads that don't enforce fsync.

XFS sees a great performance boost although I switched from ext4 to btrfs and never looked back. The backup capabilities with Btrfs' snapshot is just amazing.

Microsoft's Hyper-V DRM Display Driver Will Land For Linux 5.14

 
Last summer Microsoft engineers posted a DRM kernel display driver for their Hyper-V synthetic video device. One year later after going through a few rounds of code review, this Hyper-V DRM driver will be going mainline with the upcoming Linux 5.14 kernel cycle. This open-source Direct Rendering Manager driver is for supporting Microsoft's Hyper-V synthetic video device for display output within their virtualized environment. This is based on the company's existing frame-buffer (hyperv_fb) driver but now a DRM driver that can work with Wayland compositors and more.

Microsoft tries to be a better virtualization host for Linux than Linux itself. The well known embrace, extend, and extinguish strategy.

Java macOS/AArch64 Port will bring native Java 17 to Apple's M1

 
Motivation
Apple has announced a long-term plan to transition their line of Macintosh computers from x64 to AArch64. We therefore expect to see broad demand for a macOS/AArch64 port of the JDK. Although it will be possible to run a macOS/x64 build of the JDK on AArch64-based systems via macOS's built-in Rosetta 2 translator, the translation will almost certainly introduce a significant performance penalty. Description
An AArch64 port already exists for Linux (JEP 237), and work is underway on an AArch64 port for Windows (JEP 388). We expect to reuse existing AArch64 code from these ports by employing conditional compilation — as is usual in ports of the JDK — to accommodate differences in low-level conventions such as the application binary interface (ABI) and the set of reserved processor registers. macOS/AArch64 forbids memory segments from being executable and writeable at the same time, a policy known as write-xor-execute (W^X). The HotSpot VM routinely creates and modifies executable code, so this JEP will implement W^X support in HotSpot for macOS/AArch64.

Although it's possible to run Java on Apple's M1 ARM chip, as of today Java is still emulated just like any other x64 app on a Mac. This comes with a performance penalty that will be resolved once Java can run natively on a Mac. This being said, Java for ARM CPU powered Linux exists for quite a while already.

Wasmer 2.0, a Java Runtime Environment equivalent for WASM to enable OS-level resource access

 
Wasmer allows you to run WebAssembly modules either Standalone or Embedded within other languages such as C/C++, Rust, Python, Go, PHP, Ruby... By design, the environment within which a WebAssembly module runs is completely isolated (or sandboxed) from the native functionality of the underlying host system. This means that by default, Wasm modules are designed to perform nothing more than pure computation. Consequently, access to "OS"-level resources such as file descriptors, network sockets, the system clock, and random numbers is not normally possible from Wasm. However, there are many cases in which a Wasm module needs to do more than perform pure computation; they must interact with native "OS" functionality.

Looks like WASM could become the new cross-platform native target for building applications that run everywhere.