The road to 3.0 has not been a short one. Much of the Qt5/KF5 porting was done in 2015 already, but finishing and polishing everything up has been a slow, sometimes ongoing and sometimes stalled process ever since. 3.0 Alpha was released in February 2021 and has been since used by many people, as have been nightly builds of git master available for various distributions. Now in the past few months, an effort was made to get everything ready for a proper 3.0 release.

Common usecases should work quite well, and in addition to fixing KF5 port related regressions reported in pre-releases, 3.0 features many bugfixes and implemented features for longstanding issues, the oldest such documented being from 2009. However, with more than 20 years of development history, it is likely that not every feature Amarok has been tested thoroughly in the new release, and specifically some Internet services that have changed their API in recent years are not available, at least for now. It might well be that getting them in better state wouldn't require huge effort, however, so if you know your way with Qt and KDE Frameworks and your favourite Internet music service does not work with Amarok 3.0, you are extremely welcome to join in and help!

On April 21, a group of anonymous authors and non-anonymous signatories published a lengthy open letter to the Nix community and Nix founder Eelco Dolstra calling for his resignation from the project. They claimed ongoing problems with the project's leadership, primarily focusing on the way his actions have allegedly undermined people nominally empowered to perform various moderation and governance tasks. Since its release, the letter has gained more than 100 signatures.

The Foundation has a reserves policy which specifies a minimum amount of money we have to keep in our accounts. This is so that if there is a significant interruption to our usual income, we can preserve our core operations while we work on new funding sources. We've now "hit the buffers" of this reserves policy, meaning the Board can't approve any more deficit budgets – to keep spending at the same level we must increase our income.

Things continue to look pretty normal, and nothing here really stands out. The biggest single change that stands out in the diffstat is literally a documentation update, everything else looks pretty small and spread out.

Update: 6.1.89 was released two days later to fix a build problem in 6.1.88.

On April 11, Brandt Bucher posted PEP 744 ("JIT Compilation"), which summarizes the current state of Python's new copy-and-patch just-in-time (JIT) compiler. The JIT is currently experimental, but the PEP proposes some criteria for the circumstances under which it should become a non-experimental part of Python. The discussion of the PEP hasn't reached a conclusion, but several members of the community have already raised questions about how the JIT would fit into future iterations of the Python language.

This release continues Ubuntu's proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution. The team has been hard at work through this cycle, together with the community and our partners, to introduce new features and fix bugs.

The list of changes and enhancements is long; click below for some details. More information can be found in the release notes; see also this page for a summary of security-related changes.

BleepingComputer reported on April 20 that some malware was being distributed via GitHub. Uploading files as part of a comment gives them a URL that appears to be associated with a repository, even if the comment is never posted.

A GitHub flaw, or possibly a design decision, is being abused by threat actors to distribute malware using URLs associated with Microsoft repositories, making the files appear trustworthy.

While most of the malware activity has been based around the Microsoft GitHub URLs, this "flaw" could be abused with any public repository on GitHub, allowing threat actors to create very convincing lures.

For several years, contributors to the Rust project have been working to improve support for asynchronous code. The benefits of these efforts are not confined to asynchronous code, however. Members of the Rust community have been working toward adding explicit existential types to Rust since 2017. Existential types are not a common feature of programming languages (something the RFC acknowledges), so the motivation for their inclusion might be somewhat obscure.