Brief items

Security quote of the week

If we want to get serious about protecting national security, we have to get serious about data privacy. Today, data surveillance is the business model of the Internet. Our personal lives have turned into data; it's not possible to block it at our national borders. Our data has no nationality, no cost to copy, and, currently, little legal protection. Like water, it finds every crack and flows to every low place. TikTok won't be the last app or service from abroad that becomes popular, and it is distressingly ordinary in terms of how much it spies on us. Personal privacy is now a matter of national security. That needs to be part of any debate about banning TikTok.

— Bruce Schneier and Barath Raghavan

Comments (none posted)

Kernel release status

The 6.3 merge window is still open, it can be expected to close on March 5.

Stable updates: 6.2.1, 6.1.14, 5.15.96 5.10.170, 5.4.233, 4.19.274, and 4.14.307 were released on February 25.

The small 6.2.2, 6.1.15, 5.15.97, 5.10.171, 5.4.234, and 4.19.275 updates are in the review process; they are due on March 3.

Comments (none posted)

A Linux-on-M1 update

The Asahi Linux project has posted an update and reality check on the status of Linux support for Apple's M1 hardware.

We are continuously upstreaming kernel features, and 6.2 notably adds device trees and basic boot support for M1 Pro/Max/Ultra machines. However, there is still a long road before upstream kernels are usable on laptops. There is no trackpad/keyboard support upstream yet.

While you can boot an upstream 6.2 kernel on desktops (M1 Mac Mini, M1 Max/Ultra Mac Studio) and do useful things with it, that is only the case for 16K page size kernel builds. No generic ARM64 distro ships 16K kernels today, to our knowledge.

Comments (30 posted)

Ryabitsev: Fix your mutt

Konstantin Ryabitsev has a request for anybody who is using mutt for kernel work:

At some point in the recent past, mutt changed the way it generates Message-ID header values. Instead of the perfectly good old way of doing it, the developers switched to using base64-encoded random bytes. The base64 dictionary contains the / character, which causes unnecessary difficulties when linking to these messages on lore.kernel.org, since the / character needs to be escaped as %2F for everything to work properly.

The post includes a simple workaround for the problem.

Comments (31 posted)

Quote of the week

Since around 1996, Linux has carried sourceless firmware encoded as sequences of numbers disguised as source code. UTUTO and gNewSense pioneered the efforts of removing them. Cleaning Linux up is a substantial amount of work, so the existence of Linux-libre has alleviated one of the main difficulties in maintaining GNU+Linux distros that abide by the GNU Free Software Distribution Guidelines.

— The Linux-libre project celebrates 15 years

Comments (22 posted)

Godot 4.0 released

The waiting is done; version 4.0 of the Godot game engine has been released.

4 years of development. 12,000 merged pull requests. 7,000 fixed issues. 1,500 individual contributors across engine and docs.

The Godot 4.0 release is by all metrics our biggest release so far. No stone has been left unturned, all parts of the engine have been modernized, refactored, overhauled, rewritten, redesigned.

See the release notes for more information.

Comments (1 posted)

Rust Keyword Generics Progress Report: February 2023

The group working on adding keyword generics to the Rust language is foreshadowing what it plans to propose:

A main driver of the keywords generics initiative has been our desire to make the different modifier keywords in Rust feel consistent with one another. Both the const WG and the async WG were thinking about introducing keyword-traits at the same time, and we figured we should probably start talking with each other to make sure that what we were going to introduce felt like it was part of the same language - and could be extended to support more keywords in the future.

Comments (20 posted)

Development quote of the week

We found that participants with access to an AI assistant often produced more security vulnerabilities than those without access, with particularly significant results for string encryption and SQL injection. Surprisingly, we also found that participants provided access to an AI assistant were more likely to believe that they wrote secure code than those without access to the AI assistant.

— Neil Perry et al.

Comments (7 posted)