As long as I've been a Linux user, I can remember one of the biggest issues being firmware support on the kernel.
The issue has been notorious, with a lot of new users being discouraged immediately after joining, and the benevolent dictator Linus Torvalds himself giving the bird to Nvidia, a sentiment shared by almost every user who had tried to make Nvidia work on Linux a few years ago.
Things have been getting better recently, though, especially with LVFS (Linux Vendor Firmware Service) on the scene now, providing hardware vendors a portal to upload firmware updates, which can then be downloaded and installed by users through clients such as GNOME Software or fwupdmgr.
Why does LVFS matter?
The relief and effort of LVFS cannot be understated, as before a central secure portal for firmware, the users only had the option to trust some random third party upload on the internet, often breaking or worse, infecting their systems. LVFS fills a space where the vendors can provide secure firmware, with Linux-specific .cab files.
The roadbloack...
The issue, however, obviously, had been funding with the largest contributors being the usual suspects, Framework and Open Source Framework Foundation, at $10K a year. Recently, however, Lenovo and Dell joined suite as Premier sponsors, which is the highest tier at $100K a year each, making the project more sustainable and manageable. These companies contributing makes a lot of sense, considering they are two of the bigger computer companies which offer Linux by default in some cases, especially with Lenovo's ThinkPads being the Linux users' favorite for decades.
Welcome the newcomer!
And now, as you'd have it, HP has followed suit as a Premier sponsor, also providing $100K a year, right alongside Dell and Lenovo. This is already being reflected on the homepage of LVFS, with a quote from HP's Senior Vice President as well:
“LVFS enables quick, easy and timely BIOS updates, so countless customers can enjoy the flexibility of open source Linux-based systems.” — Xavi Garcia, HP
This calls for a celebration as users, of course, and also a major bout of appreciation for HP will be well deserved. I'm delighted as an HP user on Fedora myself, this is a remarkable day.
The question still remains, however, where are the other vendors? What are they waiting for?
Where are the others?
The image of Linux as a "niche" user community, left to their own devices (literally) to figure out the solutions to the hardware problems the vendors are unwilling to solve, is a view as outdated as it is ridiculous. It is like they expect us to unlock a door of which they have the only key.
This major move by these three companies should not only be seen as a sign of relief and wider acceptance of the usage of Linux, but as a beacon for other vendors to follow, who ought to make their hardware more accessible to the open-source community. This change is only in their best interest, as every year shows the percentage of Linux's desktop market share going upwards.
Wrapping Up
HP, Dell and Lenovo all being the highest possible contributors to Linux firmware inspires a lot of confidence among the users, a sign of better support and easier updates. Their efforts are much appreciated and applauded, and we hope that more companies show up to the party. Hope this brightens up your day a little bit, if you're a Linux user on HP. Cheers!
The Fedora AI Developer Desktop initiative that passed unanimously is now blocked. Two council members retracted their votes after community pushback, with contributors arguing the CUDA focus contradicts Fedora's free software foundations and that significant kernel policy changes hadn't been cleared with the right people.
Someone got Lightroom CC running on Linux via Wine without writing a single line of code themselves. An AI agent did the whole thing autonomously, fixing DLL gaps and Wine incompatibilities.
LibrePlan is a self-hosted open source project management tool that just got its 1.6.0 release. The additions worth noting include email workflows, per-project document repositories, an issue and risk log, and traffic light status indicators in the project list view.
If you've ever wanted to run BleachBit over SSH without touching the CLI directly, the TUI is shaping up well. You get keyboard navigation throughout, two preview modes for checking what would be cleaned before committing, and full backend parity with the existing GUI.
Bitwarden got a new CEO in February, a new CFO in April, briefly removed "Always Free" from its pricing page, and quietly rewrote its core values. For most software, this would be unremarkable. For the app that holds your passwords, the bar for transparency needs to be much higher.
ONLYOFFICE Docs 9.4 lands with a mix of features and a licensing update that's hard to read as coincidental given the Euro-Office fork dispute. It offers users a dark mode for spreadsheets, 25 new presentation themes, 20 new slide transitions, and form recipient tracking.
Mission Center and Resources are both polished libadwaita system monitors, and both are genuinely good. But what makes them different from each other? A lot. We have a detailed writeup that should clear your doubts.
Splitting a string in Bash isn't as intuitive as it should be. The trick is setting IFS to your delimiter and using read -ra to split the string into an array. Here's a short explainer with a working CSV example and a breakdown of what each part is actually doing.
If cmus or MOC never quite clicked for you, Kew is worth trying. Written in C, it displays album art in the terminal, can search your music library with a single keyword, and handles playlists and shuffles without fuss.
Desktop Linux is mostly neglected by the industry but loved by the community. For the past 13 years, It's FOSS has been helping people use Linux on their personal computers. And we are now facing the existential threat from AI models stealing our content.
If you like what we do and would love to support our work, please become It's FOSS Plus member. It costs less than the cost of a McDonald Happy Meal a month, and you get an ad-free reading experience with the satisfaction of helping the desktop Linux community.
Tired of AI fluff and misinformation in your Google feed? Get real, trusted Linux content. Add It’s FOSS as your preferred source and see our reliable Linux and open-source stories highlighted in your Discover feed and search results.
In the Bitwarden desktop app and browser extension, you can set a pin instead of using the master password to log in. To do that, go into the Account Security settings and turn on the "Unlock with Pin option."
Remember to turn off "Require master password on browser restart," and set the session timeout to "On browser restart" for securing your vault against unauthorized access.
Though, do not forget the master password, since the PIN is not a replacement, and you will need it when signing into new devices.
🗓️ Tech Trivia: On May 21, 1952, IBM announced its first electronic computer, the Model 701, at a time when the company was better known as the world's largest supplier of punched card equipment, with chairman Thomas Watson Sr. so resistant to the idea that engineers had to rebrand it a "Defense Calculator" just to get it built.
Greg Kroah-Hartman was at RustWeek 2026 in Utrecht this week, and he talked about a Rust-based proposal still in development that could wipe out around 80% of the CVEs the Linux kernel generates.
That is not a small claim. This is coming from someone who has personally reviewed every kernel security bug since the Linux kernel security team was formed in 2005.
C's blind spot
Greg's presentation starts at 14:27.
The core problem, as Greg sees it, is untrusted data. Every time data arrives from user space or from hardware, the kernel should treat it with suspicion. C has never had a reliable way to enforce that.
Once data gets copied from user space into the kernel, it becomes a regular pointer and loses all context about where it came from. It gets passed around freely, and the external checkers that should catch issues do not always get run.
Hardware adds another layer of the same problem. The kernel was designed assuming hardware is trustworthy, and that assumption is getting harder to hold as malicious hardware becomes a real and growing threat.
What Rust already fixes
Before the new proposal even ships, Rust is already making a difference. Failing to check error return values and forgetting to release locks are two notable contributors to kernel CVEs, and Rust handles both at compile time.
Greg estimates those two fixes alone cover around 60% of kernel bugs.
And it doesn't stop there. Writing Rust bindings for existing C code has quietly pushed kernel maintainers to actually document and think through their APIs, working out ownership semantics, lock rules, and const-correctness.
Enter, the "untrusted" type
Greg's proposed solution is a Rust type called Untrusted<T>, developed with kernel contributor Benno Lossin. It attaches to data coming in from user space or hardware as a compile-time marker, with no runtime cost.
And you cannot access the underlying data without going through a validation step that explicitly converts it to trusted. That pushes all validation code into one visible, reviewable spot.
What this means for you as a Linux user? A significant number of the CVEs that currently trickle down to your distro as security updates simply would not exist in the first place.
But, it is not merged yet. Changes are still needed in the Rust compiler, and related work on field projections is running alongside it. Greg concluded his presentation by asking for more Rust kernel developers, and pointed towards the Rust for Linux mailing list as the starting point.
Fedora's Engineering Steering Committee (FESCo) has voted to retire all Deepin-related packages from the distribution's repositories.
The vote passed with +7, 0, 0 at a May 19 meeting. On top of that, the release engineering team has been told not to reinstate any of these packages unless they go through a fresh review.
A year in the making
The story starts with openSUSE. In May 2025, their security team published a detailed report on Deepin's packages, stating that they had pulled them from their repos after a review had flagged serious problems across multiple components.
The deepin-file-manager daemon had significant D-Bus interface issues, some of which stayed unfixed even after partial patches. Both deepin-api and deepin-system-monitor were found using deprecated Polkit authentication in an unsafe way.
That report prompted Adam Williamson of the Fedora QA team to open a ticket with a pointed question attached. If SUSE's security team found all of this, what did Fedora's situation look like?
Turns out Fedora had been shipping these packages without any meaningful security review, and the project's own package review guidelineswere found lacking without any requirements, tools, or instructions for reviewers to consider security issues.
A thing to note here is that some security-related guidelines did exist at one point but were deleted years ago.
Was already on life support
By the time FESCo cast its vote, the Deepin packages were already in rough shape on their own. Core packages had been failing to build across Fedora 42, 43, and 44.
The desktop environment had already been pulled from Fedora spins and fedora-comps months earlier because essential packages simply could not build.
The ones who were supposed to be the stewards of this effort in Fedora, the DeepinDE SIG, lost many of its key members over time. One of the original maintainers, Zamir Sun, who had served as the SIG's coordinator, confirmed as much in a reply to FESCo's outreach email:
To make a long story short, all the initial packagers of the Deepin DE packages(namely felixonmars, mosquito(no longer with Fedoraproject) and cheeselee in FAS, and me as the coordinator) are being too busy for the vast amount of work in maintaining DeepinDE. And we never got active packagers to take the effort so we have to see it going away from Fedora.
That left a certain Felix Wang (topazus) as the one person still actively touching the packages, who has not been replying to bug reports, maintainer pings, or direct emails.
And whenever Fedora's build failure policy automatically orphaned a package, topazus would simply reclaim it without fixing anything.
FESCo sent its formal outreach on May 5 and gave four weeks for a response. With nothing substantive coming back, the committee moved to retire the full package set. Release Engineering has also been told not to reinstate any of these packages unless they go through a proper review first.
So that is the end of line for Deepin on Fedora, for now. If, in the future, some people step up and take the packages through a fresh review, maybe this desktop environment will make a comeback.
But given the state things were left in, that is not a bet anyone should be making just yet.
ONLYOFFICE has been putting out fairly consistent updates to its open source office suite. The previous release focused heavily on the PDF editor, adding new signature options, password-protected PDF editing, and a multipage view for documents.
Since then, things got a little complicated for the project. Nextcloud and IONOS launched Euro-Office, a European fork of ONLYOFFICE, citing concerns about the project's Russian development roots, lack of transparency, and resistance to outside contributions.
ONLYOFFICE hit back, accusing the fork of violating the additional conditions attached to its AGPLv3 license.
Now, the developers have released ONLYOFFICE Docs 9.4, which covers a fair bit of ground across all the editors and introduces a licensing update.
🆕 ONLYOFFICE Docs 9.4: What's New?
Starting with form management, you can now assign specific recipients and track their filling status directly within the editor. Previously, that meant going outside the editor entirely, making the whole experience more clunky than it needed to be.
Horizontal lines in documents are in too, which was apparently a frequently requested feature on their social media pages. You can insert them to visually separate sections via the "Borders" button in the Home tab.
Similarly, the signature field in forms now defaults to the last image you used. Thanks to this, you don't need to dig around for the same file each time you sign a batch of documents.
Then there's the Presentation Editor, which picks up 25 new ready-to-use themes, covering a fairly wide range of styles, accessible from the Design tab. There are also 20 new slide transitionsunder the Transitions tab for adding a bit more polish to your next pitch.
The new presentation themes (left) and the 'Dark Document' mode for spreadsheets (right).
The Spreadsheet Editor gets a dedicated Dark Document mode. With the general dark theme on, the spreadsheet canvas can be switched to a dark background as well via the View tab.
The community version (for self-hosting) also sees some structural work. The code is no longer minified, making it easier to read through, and it now runs as a single process with no reliance on RabbitMQ or databases.
That trims down what the host machine needs to run, and starting with this release, the 20-connection cap is gone.
Finally, the licensing terms have been updated. ONLYOFFICE has clarified its AGPLv3 conditions, with clearer language around attribution, copyright notices, labeling of modified versions, and trademark rights under a separate Trademark Policy (was error 404 at the time of writing).
If you recall, the Euro-Office dispute was specifically about whether a fork could drop those additional Section 7 conditions. The developers haven't said this update was a response to that, but we can confidently infer that from what has happened so far.
📥 Download ONLYOFFICE Docs 9.4
Like usual, you will find there are two main flavors. One is for self-hosting users who want to deploy ONLYOFFICE on their infrastructure, and the other one is for people who want a reliable office suite on their computer.
For more details on this release, you can refer to the changelog.
For a lot of people, Bitwarden became the go-to password manager after the LastPass fiasco. Free, open source, and trustworthy, it has gained a reputation by offering a free tier, keeping the code open, and not pulling the rug.
But that comes at a cost; any hit to its image matters a lot when we are talking about software that holds extremely sensitive information.
So when things start looking a little off, people pay attention. And over the past few months, a few things have looked a little off.
Some things changed at the top
The first change worth noting happened in February. Bitwarden's longtime CEO, Michael Crandell, stepped back to an advisory role. The company said nothing about it publicly, and one would have to check his LinkedIn profile to find out.
The new CEO is Michael Sullivan, who was previously CEO of Acquia and, before that, InsightSoftware. What got people worried was his experience of working across "all facets of mergers and acquisitions," with named private equity firms, including Hg, Vista Equity Partners, and TA Associates.
That is a very particular background for someone to be stepping into a head honcho role at a password manager company. Bitwarden's CFO also changed, where Stephen Morrison left in April and Michael Shenkman, who previously ran InVision, came in as his replacement.
None of these major executive changes were officially announced.
Quiet changes
The term "Always free" has been restored (left), but it was missing for quite some time (right).
I referred to the Wayback Machine and found that the term "Always free" had been on Bitwarden Personal's product page for a long time, sitting inside the plan comparison table.
It disappeared sometime in mid-April and was only restored sometime after May 14.
According to a company employee who posted on the r/Bitwarden subreddit, all of that was supposedly due to an oversight by the Bitwarden marketing team.
Then there's the other issue of values being quietly changed. Bitwarden has used the GRIT acronym to describe its company culture for years, standing for Gratitude, Responsibility, Inclusion, and Transparency.
I again checked the Wayback Machine, and the values were still intact as of March 14, 2026. At some point after that, they were quietly changed. GRIT now stands for Gratitude, Responsibility, Innovation, and Trust.
The 2022 blog post Crandell wrote laying out the original GRIT values was edited to reflect the new ones. Except the editing stopped halfway. The explanatory paragraph further down in the same post still describes Inclusion and Transparency as the values.
Sullivan published a blog recently, laying out his first 100 days at Bitwarden and also hashing some things out.
The free tier is not going anywhere. He ruled out a trial model or bait-and-switch and said that the open source foundation and the ability to audit the code, self-host, and verify are what make Bitwarden different from everything else in the space.
He also acknowledged that changes are coming, but those would be explained properly.
Should you be worried?
The post referenced above is the most direct on-record statement Bitwarden has about the free tier. But a pattern of ambiguity has already been established.
For such a sensitive piece of software, unannounced leadership changes and a values rewrite are the kind of thing that should make you nervous. But unless Bitwarden does something drastic like axing the free tier or pulling a Cal.com, there is not much to act on just yet.
At the Open Source Summit this week, Microsoft announced a range of open source-focused updates, ranging from new Linux distro releases to agentic AI tooling.
Brendan Burns, co-founder of Kubernetes and Corporate VP for Azure OSS and Cloud Native at Microsoft, delivered a keynote on their technological shift from cloud native to what the company is calling the "AI native era."
The announcement covered quite a bit of ground, so here's a breakdown.
What was announced?
The Linux part of the announcement has two updates. Azure Linux 4.0 is coming to Azure Virtual Machines as a public preview, though it is still in active development and no downloads are available yet. Microsoft has a sign-up form open for early access.
Azure Container Linux is now generally available, with a full rollout planned during Microsoft Build on June 2. It is an immutable, container-optimized OS, which by design means no package manager and a read-only system image.
This is aimed at teams handling regulated or security-sensitive deployments, with the intent to keep the attack surface relatively limited while Microsoft maintains the supply chain end to end.
For agentic AI, Microsoft is pushing several building blocks for what it calls an open agentic stack. The Microsoft Agent Framework is an open source SDK and runtime for multi-agent systems, consolidating earlier work from Semantic Kernel and AutoGen into one foundation.
Alongside that is the Agent Governance Toolkit, which covers identity, policy, and audit controls for AI agent deployments and A2A (agent-to-agent) protocols for cross-vendor, cross-framework agent communication.
We saw this coming
The announcement doesn't mention Fedora once, but the Azure Linux 4.0 branch on the project's GitHub paints a different picture.
The README file for 4.0 explicitly describes Fedora as an "upstream base" for Azure Linux, describing the distro as a set of TOML configuration files and targeted overlays applied on top of Fedora.
Likewise, packages come straight from Fedora's upstream repositories, with any deviations from that kept minimal and clearly documented.
Last month, we reported on discussions from a Fedora ELN SIG meeting where it became clear Microsoft was backing a proposal to build x86-64-v3 packages for Fedora 45.
Kyle Gospodnetich, a Linux engineer at Microsoft, was co-authoring the change proposal, with the motivation tied directly to Azure Linux's need for x86-64-v3 performance gains.
There was also talk of Microsoft forking the distribution entirely at one point, but they were guided toward working within the Fedora ecosystem instead. We called it "a big if" at the time.
Now, the 4.0 branch confirms it. 🤓
As for why Microsoft stayed quiet about the Fedora connection in its announcement blog post. Fedora is effectively Red Hat's upstream, and Red Hat is both an Azure partner and a competitor in the enterprise Linux space. I presume that it would make for an awkward read in that context.
It is a matter of preference to use system cleanup utilities on a computer or smartphone. On Linux, we have many such tools that handle everything from clearing browser caches and old package archives to shredding files and wiping free space.
They range from quick CLI scripts to full-blown graphical applications. Some focus on browser data; others go deeper into system logs, package caches, and temporary files.
One of the more popular offerings among those is BleachBit, which is a free and open source system cleaner for Linux and Windows that handles all that. It's developers have now given everyone an early look into how its text-based user interface (TUI) is shaping up.
BleachBit TUI works well
The TUI is simple to navigate. The space bar toggles cleaning options on or off, and Enter expands a category to show the file list underneath.
For previewing what would be cleaned, there are two options: lowercase p runs a full preview across all selected items, while uppercase P previews just the focused component.
📋
You can use either Shift or Caps Lock for switching to uppercase.
The two preview options (full, focused) on the alpha TUI of BleachBit.
Once done, d handles deletion for everything selected, and D deletes the focused component specifically. On my first attempt, the deletion failed because I had not launched the TUI with elevated privileges.
Re-launching with sudo python3 bleachbit_tui.py fixed that. Once initiated, I had to press Y to confirm the action, and when it completed, a dialog appeared in the bottom-right showing the files deleted and space recovered.
Using sudo fixed the errors I was getting.
There is also a palette menu, accessible via Ctrl+P. From there, you can search commands, maximize a selected component, quit BleachBit, save a screenshot, and bring up the keys/help side panel.
Since the TUI shares its backend with the regular BleachBit GUI, it picks up all the same settings automatically. That covers your selected cleaning options, keep list, custom cleaning list, and cookie keep list.
It also supports changing display themes and some mouse interaction alongside keyboard navigation, including the scroll wheel. On Windows, the TUI ships as both an installer and a portable package, compiled as a native 64-bit binary, unlike the 32-bit stable GUI and CLI builds.
If you want to try it out on Linux, the official announcement has quick-start instructions for running the TUI on Ubuntu, and if that doesn't suit you, then you could build from source.
🚧
This is still being developed. If you go ahead with testing it, expect things to break.
If you have not heard of LibrePlan before, then you wouldn't be alone. When they sent us a press release, I was wondering what this project was for. Then I read up on it, and it turns out to be an open source, self-hosted, web-based project management tool that has been around since 2009.
It can handle project planning, resource allocation, time tracking, and progress reporting, and its target customers are organizations that want full control over their own infrastructure and data.
Now, they have introduced a new release that adds some useful features around collaboration, project tracking, and a pretty notable expansion of language support.
What's new?
The demo of LibrePlan as a placeholder.
The 1.6.0 release arrives with email support for major user groups, per-project document repositories, and configurable email templates with notification support.
Project managers also get a few new visibility tools. There is now an issue and risk log, a pipeline overview, project margin tracking, and traffic light-style status indicators in the project list view.
The last addition in particular should be handy, letting you spot which projects need attention at a glance without you needing to click through each one.
Moving on to the highlight of this release, we have the expanded language support, which takes the earlier four languages supported number all the way to 19.
These include Czech, Chinese, German, Persian/Farsi, Russian, Italian, Norwegian Bokmål, Dutch, Polish, Portuguese, Brazilian Portuguese, Swedish, Ukrainian, and Simplified Chinese.
None of these new additions have been through manual review, though. They were put together using AI tooling, and the project is counting on the community to spot mistakes and tighten things up.
Get LibrePlan
LibrePlan 1.6.0 is available now, with Docker images for the Community Edition available on Docker Hub, and a live demo environment is accessible on the official website.
There's also a separate enterprise-focused version called LibrePlan Enterprise for organizations looking to deploy this release, and the source code for the Community Edition lives on GitHub.
Someone has managed to make Adobe Lightroom CC run on Linux via Wine. Don't get it confused with the other Adobe offerings though; this is the cloud-syncing desktop version of Lightroom.
Sander Hilven, a developer, has put together a working recipe that works on Wine 11.8 staging with Lightroom CC 9.3.1. Interestingly, they have not done any of the actual work themselves.
The dev just told Anthropic's Claude Opus 4.7 what the goal was and left it to figure out the rest, while providing an Adobe Creative Cloud subscription for the AI to work with.
The AI dug through crash logs and Wine compatibility issues autonomously, figuring out what needed fixing. It verified its own work by screenshotting the running Lightroom instance and clicking through the interface to confirm whether each fix held up.
Though, several fixes were needed to get things going. Some Windows APIs that Wine doesn't implement were bringing down the entire Creative Cloud process on launch, some DLLs Lightroom depends on simply did not exist in Wine, and there were naming mismatches between how Lightroom looks for its files and how Adobe actually ships them.
The Remove/Heal tool was the trickiest fix. It kept crashing mid-use, and the AI traced it back to a dependency that Wine ships in the wrong place.
Currently, browsing, editing, exporting, and the Remove/Heal tool all work. Not everything is perfect though; tutorial videos don't play, some GPU-accelerated effects may not render correctly, and there's a bug with double-clicking thumbnails.
I won't touch it
The sole human developer's GitHub has no bio to speak of, and outside this repo, there is nothing that tells you much about who they are.
The entire project, including the patched DLLs and the assurance that they work, was produced by an AI agent. No human has looked at those binaries independently.
That is a lot of trust to put in AI-generated Windows DLL patches running inside your Linux computer.
I won't be testing this due to all that and because I don't have an Adobe subscription. But if you have one and have a spare machine lying around, why not give it a try and post your findings on our forum?
Yeah, that is a not-so-subtle nudge to visit it and interact with the other FOSSers. 😉
If you are someone who has to tackle many emails throughout the day, an email client is most likely part of your workflow. For the uninitiated, these desktop applications let you manage one or more email accounts from a single place without having to open a browser tab for each one.
Think of them as a local home for your inbox that comes equipped with the necessary tools for composing, organizing, and syncing your content. 📥
I had one of my earliest experiences with these through Thunderbird, which I used at a previous workplace. It did the job well enough at the time, and I have no real complaints about it from back then.
Eventually I drifted toward just using the web apps of whatever email service I was on. So, when I came across Aerion, I thought to myself, why not give email clients another shot?
Aerion: A Home For Your E-Mails
This is an open source, lightweight desktop email client maintained by a team of developers that is sponsored by 3DF, which covers the infrastructure and human resource-related costs.
The project takes inspiration from GNOME's email client Geary, with a focus on being resource efficient and offering a clean interface without the baggage that tends to weigh down the older solutions on Linux.
Before you blurt out "Electron!," know that Aerion uses Wails and Svelte under the hood. It also comes with a CASA Tier 2 certification, which was assessed by TAC Security, a Google authorized assessor under the App Defense Alliance.
This means that the app's codebase has been scanned and verified against the OWASP ASVS standards by an independent third party. For a small indie project that handles your email credentials and account access, that is a big reassurance.
Feature-wise, it covers the essentials like support for multiple accounts, conversation threading, a WYSIWYG composer powered by TipTap, contact sync (via CardDAV, Google, and Microsoft), multiple color themes, and keyboard navigation with vim-style shortcuts.
For email providers, Aerion works with Gmail, Microsoft 365/Outlook, Proton Mail (via paywalled Proton Bridge), iCloud Mail, GMX Mail, and generic IMAP/SMTP setups.
Yahoo, Fastmail, Zoho Mail, AOL Mail, and Mail.com are listed as well, though these were marked as untested at the time of writing.
📋
Keep in mind that Aerion is still pre-release software, so things may not always go smoothly.
I Used It
Getting started meant adding my Gmail account, and that process was smoother than I expected. Aerion hands you off to the browser for the OAuth flow, where you go through Google's usual permissions and disclaimers routine, at the end of which you land back in Aerion, authenticated and ready to go.
Adding a new Gmail account to Aerion.
There's a nasty catch here, though. If you accidentally click somewhere outside the "Add Email Account" window while it is open, the whole thing closes and discards whatever progress you made. You won't get any warning or confirmation popup; it will just f*ck right off.
Mails being fetched on the left, a filled inbox on the right.
When Aerion finishes fetching your emails, you will notice that remote image loading is blocked by default. You can manually allow loading per email or add specific domains to an allowlist to avoid having to do it every time.
With Gmail connected, I spent some time sending and receiving mail, and the basics work as you would want them to. The composer has all the tools you need to put together a well-written email, and new messages are delivered with proper sync happening with the Gmail servers.
Below is a quick example of me sending a test mail from Aerion to my Proton Mail account. It landed without issue, showing up in Gmail's sent folder and in the Proton Mail inbox.
Checking the mail I sent using Aerion on the web apps for Gmail and Proton Mail.
Where things got a bit less clean was with notifications and sync. When I received new mail, I received no notification in Aerion's interface or GNOME's notification dropdown.
I had to manually hit the sync button to get the mail to appear, though Aerion does auto-sync in the background. The catch is that there is no way to configure how often it syncs, at least for Gmail, so if you are used to mail showing up the moment it lands, adjust your expectations accordingly.
And if you like keeping your mailbox clean, Aerion has you covered. You can mass delete emails that land in the "Bin" first, or you can go the extra step and permanently wipe them to free up cloud storage. Either way, the changes reflect on Gmail's servers without issue.
Though there's one more inconvenience that some of you might not like. Before you can start using Aerion, you are asked to agree to its Terms of Use and Privacy Policy.
The terms are fairly standard. It is pre-release software, so bugs and shifting features are part of the deal, there are no warranties, and the whole thing is provided under the Apache 2.0 license.
On the privacy side, things are more reassuring. Aerion does not collect or transmit any of your data to external servers, so no telemetry, no analytics, and no ads to worry about. When it connects to Google or Microsoft APIs, that access is limited strictly to the email functionality you configured.
Install it Now
People running Linux-powered distributions can get Aerion from Flathub. Those on platforms like ARM64, Windows, and macOS will have to visit the releases page to get the relevant packages.
If neither of the options are your thing, then you could always build from source.
What looked like a done deal for Fedora is now very much on hold.
The Fedora AI Developer Desktop Initiative, a proposal to build an official platform for AI and machine learning workloads on Fedora, has been blocked after two Fedora Council members retracted their earlier approval votes.
The initiative was proposed by Red Hat engineer Gordon Messmer, aiming to deliver an Atomic Desktop with accelerated AI workload support, covering developer tools, hardware enablement, and building a community around AI on Fedora.
Why the withdrawal?
As you already know, at the May 6 council meeting, the members unanimously voted to approve this new initiative. After which a short, lazy consensus window was left open until May 8 to accommodate absent members, after which the decision was to be ratified.
But that last bit never happened, as council member Justin Wheeler (Jflory7) was the first person to change their vote to -1. He pointed to the LTS kernel component of the proposal as a "massive structural shift" that had not been cleared with the relevant legal and engineering parties.
He also noted that feedback from Fedora kernel subject-matter experts had not been properly incorporated into the plan and that new developments, particularly the Nova driver work (for NVIDIA GPUs), would introduce technical and legal complexities that need proper vetting.
Following that, fellow council member Miro Hrončok (churchyard) put in his -1, saying that he had originally assumed the proposal was purely additive and therefore uncontroversial.
But seeing the community's response, he realized that he was mistaken about that. As an elected representative, he felt the need to reflect on this major proposal before signing it off.
A community divided
Over 180 replies have piled up in the proposal's discussion thread, with many well-known Fedora contributors pushing back on things like kernel policy, proprietary software, and project identity.
Hans de Goede from the packaging team called out the proposal's emphasis on CUDA support as going against Fedora's foundational commitment to free software, arguing that open alternatives like AMD's ROCm and Intel's oneAPI should be the focus instead.
Another Fedora contributor, Tim Flink, questioned whether the initiative amounted to little more than a mechanism to get CUDA onto a Fedora-adjacent system.
Neal Gompa raised similar concerns, saying Fedora has historically leveraged its stance on proprietary software to push vendors toward open solutions and that this proposal would undercut that effort.
What happens next?
Part of what made this blow up the way it did was a communications gap. Fabio Valentini of the FESCo noted that he only became aware the proposal was being voted on after stumbling across the council meeting on Matrix accidentally.
The initiative is now listed as blocked in the council ticket, with a new escalation deadline of May 22. Gordon (the proposal submitter) has said a revised draft is coming, telling the thread he plans to have a few people look it over before posting it.
For the longest time, I assumed running LLMs locally needed a decent GPU. That’s what most guides implied, and honestly, that’s how the ecosystem felt not too long ago. But after digging into recent tools and actually trying things out on CPU-only setups, that assumption doesn’t really hold anymore.
Newer model formats like GGUF and aggressive quantization (think 4-bit variants) have made these models much smaller and lighter. At the same time, runtimes such as Llama.cpp have become efficient enough that CPUs (yes, even older ones) can run them without completely falling apart.
That said, I quickly realized something more important: just because a model runs doesn’t mean it’s usable.
While testing, I found that the real metric that matters isn’t model size or even RAM usage, it’s actually tokens per second. A model providing a response at 3–5 tokens per second technically works, but it feels painfully slow in practice. On the other hand, once you get into the 15–30 tok/s range, things start to feel responsive enough for everyday use.
So instead of just listing models that can run on CPU, I focused on ones that are actually usable on low-end machines. This list is based on my own experimentation.
If you're working with an older laptop, Raspberry Pi, or basic desktop, this guide would be helpful for running your local AI model successfully and speedily.
What “Runs well on CPU” actually means
CPU performance varies wildly depending on model size and quantization. Formats used by tools like llama.cpp let you run models in reduced precision. Q8 offers better quality but is slower than Q4_K, which is much faster but comes with slightly reduced quality.
I found models ranging from ~40+ tokens/sec for tiny models all the way down to ~4 tokens/sec for larger 4B models. It completely changes how usable a model feels.
I would say, 1B-2B models consistently offer the best balance. They're small enough to fit comfortably within 8 GB RAM (with quantization) and maintain decent token speeds. Additionally, they are capable of handling basic reasoning and producing useful responses.
From my experience, Q4_K_M quantization usually hits the best balance. It provides fast response times, consumes low RAM, and produces acceptable output quality for most tasks. It significantly improves tokens per second, sometimes enough to move a model from painfully slow to actually usable.
My hardware on which I'm performing these tests
I'm performing these tests on an Intel i5-generation CPU laptop with around 12 GB of RAM. I’m not running these tests on a workstation or anything close to “AI-ready” hardware. This is a fairly typical older laptop. It's the kind many Linux users already have lying around.
Though the device comes with an Integrated Intel UHD Graphics 620 GPU, it is irrelevant for LLMs here. While some tools experiment with iGPU acceleration, in practice, all meaningful inference in my tests is CPU-bound.
I deliberately stuck to this machine because it reflects a realistic baseline. If something runs well here, it will likely run on older laptops and low-end desktops without any upgrades.
With around 12 GB RAM, 3B–4B models fit comfortably (especially with Q4 quantization). Anything beyond that requires compromises, including swap, resulting in slower performance.
While testing, I kept asking: Would I actually use this daily on this machine? If a model felt sluggish, I treated it as impractical. Whereas if it responded smoothly, even at smaller sizes, it made the cut.
Quick reality table
Model
Eval Rate
Disk Size
Qwen 3 0.6B
~34–36 tok/s
~500 MB
TinyLlama 1.1B
~25–28 tok/s
~638 MB
Gemma 3 1B
~18.6 tok/s
~815 MB
Gemma 4 E2B
~9.9 tok/s
~7 GB
Granite 4 3B
~8.5–9 tok/s
~2 GB
Phi 4 Mini 3.8B
~6.90 tok/s
~2.5 GB
OpenHermes 7B
~4.1–4.3 tok/s
~4.1 GB
Ministral 3 8B
~3.16 tok/s
~6 GB
8 LLMs that actually make sense on CPU
Let's dive into the LLMs. I used Ollama in this setup.
Qwen 0.6B
I started with Qwen 3 0.6B, mainly to establish a baseline for how fast a tiny model can run on a CPU. Qwen models are known for being efficient, and this 0.6B variant is about as lightweight as it gets while still being usable.
The --verbose flag exposes detailed metrics like token evaluation rate, total duration, and prompt processing speed. I only used it for this initial run to get a clearer picture of performance.
The results were honestly impressive. I consistently saw ~34–36 tokens/sec eval rate. In practical terms, this feels instant. Responses stream smoothly without noticeable delay.
Of course, this comes with tradeoffs. The model is fast, but limited in depth and reasoning. Still, as a baseline, it clearly shows what’s possible on CPU when the model size is kept small.
TinyLlama 1.1B
After establishing a baseline with Qwen 0.6B, I moved to TinyLlama 1.1B to see how much capability you can gain without sacrificing too much speed.
TinyLlama is a 1.1B parameter model trained on the Llama 2 architecture, but heavily optimised for efficiency. It was trained on ~3 trillion tokens, which is unusually high for a model of this size. That large training corpus is what gives it a noticeable edge over most sub-2B models.
Architecturally, it sticks to a decoder-only transformer design, similar to Llama. TinyLlama is not just small but is also efficiently designed to run well on limited hardware.
I run it locally using:
ollama run tinyllama:1.1b --verbose
From the benchmark, it feels slightly slower, but still very responsive as compared to Qwen 0.6B.
What surprised me here is how well TinyLlama holds up despite being just 1.1B. It’s much more coherent than ultra-small models. It also handles basic coding prompts better than expected.
Gemma 3 1B
Next, I tested Gemma 3 1B, which sits in a slightly higher class than sub-1B models like Qwen 0.6B. The expectation here was simple: a bit slower, but noticeably better output quality.
I ran it using:
ollama run gemma3:1b --verbose
Ollama benchmark for Gemma 3 1B
The performance landed at around ~18.6 tokens/sec, which puts it firmly in the “usable” tier. It’s not instant like the smaller Qwen model, but it’s still responsive enough for real interaction. You can feel a slight delay when generating longer responses, but it never becomes frustrating.
What stood out to me was the tradeoff. Compared to 0.6B models, Gemma 1B produces more structured and context-aware responses. It handles prompts more thoughtfully, especially when you ask for explanations or multi-step answers.
So while you give up some speed, you gain a noticeable bump in quality, making this a solid middle ground for CPU-only setups.
Gemma 4 E2B
After testing smaller models, I wanted to see how far I could push things on this CPU-only setup. That’s where Gemma 4 E2B comes in, a significantly larger and more capable model compared to the earlier ones.
I ran it with:
ollama run gemma4:e2b --verbose
The performance drop was immediately noticeable. I was getting around ~9.9 tokens/sec, which places it right on the edge of what I’d call “slow but workable.”
That said, the quality jump is real. Responses are more detailed, better structured, and noticeably stronger for complex prompts, especially coding and multi-step explanations. It feels closer to what you’d expect from a “serious” assistant.
The tradeoff becomes very clear here: you’re exchanging speed for capability. On a low-end CPU, this is about as far as you can reasonably go before the experience starts to feel sluggish for everyday use.
Granite4 3B
Next, I tried Granite 3B, expecting it to land comfortably in the “sweet spot” range like most 3B models. On paper, this size usually delivers a good balance between speed and quality on the CPU.
I ran it using:
ollama run granite4:3b --verbose
In practice, the performance came in at around ~8.5–9 tokens/sec, which was a bit surprising. That puts it closer to the “slow but workable” tier rather than the typical 3B expectation of ~15–20 tok/s.
Responses aren’t painfully slow, but there’s a noticeable delay, especially compared to lighter models like Qwen 0.6B or even Gemma 1B. It feels usable, but not snappy.
Phi4 3.8B
After poking around with various small models, I was curious about Microsoft's entry into the sub-4B space. Phi 4 Mini carries a reputation that punches above its parameter count, particularly for reasoning and structured tasks. Let's see what it actually feels like on a CPU-only setup.
I run this with:
ollama run phi4:3.8b --verbose
Ollama benchmark for Phi4 3.8B running with CPU inference
The prompt eval rate at 20.06 tokens/sec is respectable. The model processes your input quickly. The CPU showing its limits is during generation: 6.90 tokens/sec for 876 tokens means you're waiting just over two minutes for a long, detailed response. That's consistent with what you'd expect from a 3.8B model doing real work on CPU.
Phi 4 Mini comes in at around 2.5 GB on disk, compact enough to sit comfortably on systems with 8 GB RAM. The default pull uses Q4_K_M quantisation, which is the sweet spot most models land on for balancing quality against memory footprint.
If reasoning quality matters more than raw speed for your use case, Phi 4 Mini makes a strong argument for itself in this size class.
Openhermes 7B
OpenHermes is a fine-tuned variant built on top of the Mistral 7B architecture, designed to improve conversational quality and instruction adherence. Instead of focusing purely on raw model capability, it’s trained to produce cleaner, more aligned, and more usable outputs right out of the box. In practice, this means better formatting when you ask for explanations, summaries, or step-by-step answers.
Under the hood, it inherits Mistral’s efficient transformer design, which is already known for performing well relative to its size. The difference here comes from the instruction tuning layer, which makes it feel more like a polished assistant rather than a raw base model.
I run it locally using:
ollama run openhermes:7b-mistral-v2-q4_K_M --verbose
Ollama benchmark for Openhermes 7B in CPU inference mode
From the benchmark, the eval rate consistently stayed around ~4.1–4.3 tokens/sec, with total response times ranging between ~13 and 29 seconds depending on output length. Prompt processing itself was relatively fast, often exceeding ~180–280 tokens/sec, but generation is where the slowdown becomes noticeable.
What makes OpenHermes interesting is its output quality. It provides more structured, better formatted, and easier-to-follow responses.
Ministral 3 8B
After testing smaller models, I wanted to see how far a CPU-only setup can realistically go. That’s where Mistral 3 8B comes in.
Ministral models are well known for delivering strong performance relative to their size, and the 8B variant sits in an interesting spot. It’s significantly more capable than 3B models, but still just about runnable on a 10GB RAM system with quantisation. It feels close to a full-scale general-purpose LLM designed for conversational tasks, coding assistance, and structured reasoning.
This is a big drop compared to smaller models, and that’s expected. In practical use, you’ll notice a delay before responses start, token generation is steady but slow, and longer answers require patience. It’s not unusable, but it’s definitely not “interactive” in the same way as 1B models.
One interesting thing I quickly noticed, with 8.9 billion parameters, ministral-3 comes within a size of around 6 GB disk space, while Gemma 4, with 2B billion parameters, takes around 7 GB.
Upon close inspection, it turned out Ministral 3 is using Q4_K_M quantization.
Conclusion
Model
Params
Eval Rate
Disk Size
Quantization
Speed Tier
Best For
Qwen 3 0.6B
0.6B
~34–36 tok/s
~500 MB
Q4_K_M
⚡ Fastest
Quick lookups, basic tasks
TinyLlama 1.1B
1.1B
~25–28 tok/s
~638 MB
Q4_K_M
Very fast
Coding help, coherent chat
Gemma 3 1B
1B
~18.6 tok/s
~815 MB
Q4_K_M
Fast
Structured explanations
Gemma 4 E2B
2B
~9.9 tok/s
~7 GB
Q4_K_M
Moderate
Complex prompts, coding
Granite 4 3B
3B
~8.5–9 tok/s
~2 GB
Q4_K_M
Moderate
General-purpose use
Phi 4 Mini 3.8B
3.8B
~6.90 tok/s
~2.5 GB
Q4_K_M
Slow
Reasoning, structured tasks
OpenHermes 7B
7B
~4.1–4.3 tok/s
~4.1 GB
Q4_K_M
Slow
Aligned, formatted output
Ministral 3 8B
8.9B
~3.16 tok/s
~6 GB
Q4_K_M
Slowest
Long-form, async tasks
After running all eight models through their paces on the same CPU-only hardware, a few things became clear.
First, the assumption that local LLMs need a GPU is outdated. Tools like Ollama, combined with GGUF quantization, have genuinely changed what's possible on modest hardware.
Second, smaller doesn't mean useless. Qwen 0.6B and TinyLlama 1.1B surprised me consistently. For quick lookups, basic coding help, or conversational tasks, they hold up well and feel genuinely responsive. If raw speed matters most, these are hard to beat.
Third, the 3B–4B range is where things get interesting. Gemma 4 E2B, Granite 3B, and Phi 4 Mini all sit in a space where you're making a conscious trade: slower responses in exchange for noticeably better reasoning and output quality. Whether that trade is worth it depends entirely on your use case.
Beyond 7B, local AI models like OpenHermes and Ministral 3 8B both produce impressive output, but at 3–4 tokens/sec. They're better suited for tasks where you ask a question, step away, and come back, not for back-and-forth conversation.
If I had to pick one model for daily CPU-only use, I'd land on something in the 1B–2B range for speed, or Phi 4 Mini if I needed structured reasoning and could tolerate the wait.
The honest takeaway: local AI on CPU is real, practical, and improving fast. You don't need to wait for a GPU upgrade to start experimenting.
