Ubuntu MATE creator Martin Wimpress has announced that he no longer has the passion he once had, nor the time, to work on the project:
As another development cycle passes, I find myself lacking the time I once had to work on Ubuntu MATE. And, to be frank, I don’t have the passion for the project that I once had. When I have time to tinker, my interests are elsewhere.
He is now looking to handover the project:
I’m interested in handing over the reins to contributors who do have the time and energy to work on Ubuntu MATE.
What happened?
Martin Wimpress created Ubuntu MATE back in 2014. A fork of the classic GNOME 2, MATE was preferred by people who liked the traditional desktop layout and disliked the newer GNOME 3 design.
Ubuntu MATE was made an official Ubuntu flavor in 2015 and soon gained a fairly decent sized user base.
Things were going well until they were not. Like many side projects created as a hobby, the passion can fade over time or the work may no longer feel challenging enough.
Eventually, Martin decided to step away.
Back then, Martin was working at Canonical as an Engineering Director. He no longer works at Canonical, the parent company of Ubuntu.
He has also switched to NixOS, which is clearly more interesting and challenging for someone with his technical skills.
Martin still makes cool stuff when he gets time. His GitHub repo is a proof of that.
Maintaining a distro takes more effort than most think
Lubuntu has struggled with a lack of contributors. The Ubuntu Unity lead also stepped away.
Not all distros are just a custom-themed desktop environment on top of a base distro. A well-established project like Ubuntu MATE requires significant time and effort. There is upstream code to track, features to test, and much more.
The complexity increases when it is associated as an official flavor of a larger project like Ubuntu. There are standards to follow, quality to maintain, meetings with other Ubuntu flavor developers, strict release schedules, and more.
Then there are additional responsibilities like maintaining documentation and managing the community. It may not seem obvious, but these tasks also take a considerable amount of time. I can relate, as we have to do the same for our forum and nearly ten social channels.
Another thing is that the MATE desktop itself has not seen as much active development as other mainstream desktop environments like KDE and GNOME. The last MATE release came out two years ago.
This could have resulted in a dwindling userbase for Ubuntu MATE. And if that's the case, then it is surely a demotivating factor for any project.
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.
For now, there will be no Ubuntu MATE 26.04 LTS release. Ubuntu 24.04 will be here till April 2027. So we still have a year left before the distro actually becomes unsuable, if it comes to that.
Hopefully, someone will step in. As long as MATE desktop is being developed, no matter how slowly, Ubuntu MATE should live on. I mean it's not the first time it has happened that a project lead moved away and someone else filled the spot.
PINE64 has built a reputation for delivering open source hardware to people who actually care about what runs on their devices. From single-board computers like the ROCKPro64 and the RISC-V powered STAR64 to Linux smartphones like the PinePhone, the company has been pretty consistent.
One of their offerings is the PineTime, which is a compact, inexpensive open source smartwatch that has been around since 2019. It started as a community side project, inspired partly by the simplicity of the old Pebble, and is priced at around $26.99.
Years later, PINE64 has revealed what comes next. Announced at FOSDEM 2026 and detailed in a new blog post, the PineTime Pro is the open source smartwatch's next step up.
PineTime Pro is Coming
Pics courtesy of the PINE64 team.
The PineTime Pro is a significant hardware upgrade over the original, and the spec sheet makes that known right away.
At its core is a dual-core Cortex-M33 SoC, with an application core running at up to 200 MHz and a separate dedicated Bluetooth core. RAM goes up from the original's 64 KB of SRAM to 800 KB of SRAM plus 8 MB of PSRAM. The display jumps from a 240x240 pixel 1.3-inch LCD to a 410x502 pixel 2.13-inch AMOLED panel with touch support.
Beyond that, the Pro comes with GPS, a heart rate sensor with blood oxygen measurement, a 6D IMU, Bluetooth 5.2 with both Classic and Low Energy support, a microphone, a speaker, and a vibration motor. It also has a digital crown that doubles as a button.
External storage is delivered via 8 MB of QSPI flash, and there is a 4-pin connector for power, debugging, and programming purposes.
Additionally, PINE64 is calling this one the PineTime Pro and not the PineTime 2 for a deliberate reason. The original is not being discontinued as it is still doing well.
The Pro is meant to sit alongside it as a more capable option, not replace it. If the original PineTime was built to be approachable, the Pro is built for those who want to push things further.
On the software side, developers from both InfiniTime and Wasp-OS are involved, with the groundwork for it already being laid. The extra hardware headroom also means features that were never realistic on the original could actually happen here.
When to expect?
As for where things stand right now, it is early. The first two watch prototypes arrived toward the end of 2025, but a non-functional SWD port made loading and debugging software harder than expected.
A second batch showed up just before FOSDEM 2026 but ran into a flash memory issue, which meant the demo at the event had to run on a development board rather than the actual watch hardware.
A third hardware revision is expected in early April, and the team is optimistic this one will finally clear the remaining hurdles.
There is no release date yet, and PINE64 is not claiming otherwise. But after years of hardware iteration, the PineTime Pro is finally starting to feel like something we might actually one day wear on our wrists.
Ubuntu 26.04 LTS "Resolute Raccoon" is not out yet, but its release notes have an unexpected change that missed my eyes completely. Canonical has bumped the minimum RAM requirement for Ubuntu Desktop to 6 GB for this upcoming LTS release.
While it is a major shift for desktop users, on the server side, things remain far more flexible. Ubuntu Server's documentation lists a minimum of 1.5 GB for ISO installs, with a suggested minimum of 3 GB to account for real-world workloads.
Ubuntu 26.04 LTS system requirements on the left, Ubuntu 24.04 LTS' on the right.
Ubuntu 24.04 LTS, the current long-term support release, lists 4 GB of RAM alongside a 2 GHz dual-core processor and 25 GB of storage as its minimum requirements. Those requirements were carried over to Ubuntu 25.10 as well. So the jump to 6 GB in 26.04 marks the first time Canonical has raised the desktop RAM ceiling in a while.
But Windows requires less?
Microsoft lists 4GB as the minimum required RAM for Windows 11, which on paper looks more generous than what Ubuntu 26.04 is asking for. But that number is worth looking at a little more closely, though.
I say that because it is also mandatory to have Trusted Platform Module (TPM) version 2.0 to run Windows 11. If you didn't know (or care about), TPM is a dedicated security chip built into your motherboard that handles cryptographic keys used by features like Windows Hello and BitLocker.
The thing is, most computers that have shipped with TPM in the past few years (at least the Windows-focused ones) come with at least 8 GB of RAM, and if you draw a parallel with how badly 4 GB of RAM performs (check the comments) on a Windows 11 install, you will see that the claim sounds sloppy.
Canonical appears to be taking the more straightforward approach here. Ubuntu with GNOME has been known to be fairly hungry on RAM once you start actually using it.
Open a browser, load a handful of tabs, and the available memory starts to disappear quickly. The 4 GB figure that covered Ubuntu 24.04 seems closer to a technical floor than a practical ceiling, and moving it to 6 GB in 26.04 reflects that reality more honestly.
The TLDR is that both operating systems need headroom well above their listed minimums the moment you start doing anything beyond light use; one lists in clearly, while the other doesn't.
What about systems with 4 GB of RAM?
If your machine has 4 GB of RAM, Ubuntu 26.04 LTS should still be a decent fit, but if you are a power user who likes to multitask, then Lubuntu, the official Ubuntu flavor can be a better fit for you. It is built on the LXQt desktop environment, runs relatively comfortably with a minimum of 1 GB of RAM and 2 GB recommended. Xubuntu is also a good candidate here.
For systems where even that is a stretch, opting for a window manager like i3 or bspwm instead of a full desktop environment will give you a functional Linux setup on hardware that a standard Ubuntu install would likely struggle with.
You try to perform a basic task, like adding a custom script to /usr/bin or creating a global configuration directory, and the terminal throws an error: Read-only file system.
It’s a frustrating moment. You chose an immutable OS for the stability, the atomic updates, and the "unbreakable" nature of the system. But now you feel like a guest in your own house.
The traditional fixes, manually mounting an overlay filesystem or using rpm-ostree to layer packages, either require a reboot or complex manual management.
systemd-sysext was built specifically to solve this problem. This often-overlooked utility uses OverlayFS under the hood but adds compatibility checking, systemd integration, and a standardized format, allowing you to dynamically merge binaries and libraries into /usr at runtime, without touching the underlying read-only image and without a reboot.
Quick Look at Immutability
To understand why we need sysext, you first have to understand why the Linux world is moving toward immutability. In a traditional "mutable" distribution like Ubuntu or Arch, the root filesystem is a giant, writable scratchpad. Any process with root privileges can modify any file in /usr or /bin.
While this gives us total freedom, it’s also a major source of system drift. Over time, manual changes, conflicting libraries, and failed package installations make the system unpredictable.
Immutable distributions solve this by treating the operating system as a read-only image. When you update the system, you aren't just changing individual files; you are switching to a completely new, pre-verified version of the OS. This makes the system "atomic", it either works perfectly, or it rolls back to the previous version.
The Problem: Seeing the "Read-Only" Barrier
While immutability is great for stability, it’s a nightmare for "on-the-fly" troubleshooting. On a standard system, if I need to see why a network port is blocked, I might quickly install nmap or tcpdump. On an immutable system, I’m stuck.
You can see this in action by trying to manually add a file to your system binaries:
sudo touch /usr/bin/test_file
Instead of creating a file, you’ll get a rejection message: touch: cannot touch '/usr/bin/test_file': Read-only file system. This proves that even with sudo, the core of your OS is locked.
To add a tool "the official way" (layering), you’d have to run a command like rpm-ostree install and then restart your computer. For a quick task, that's a massive interruption. And this "rpm-ostree" is more of a Fedora Silverblue thing, it won't work on non-Fedora atomic distros.
How System Extensions Actually Work
I'd like to think of systemd-sysext as a digital "overlay." Instead of fighting the read-only filesystem, we are going to build a small directory structure that contains our tools and tell the system to virtually "merge" it on top of the existing /usr.
This uses a kernel feature called OverlayFS. It takes your base (read-only) system as the "Lower" layer and your extension as the "Upper" layer. The result is a "Merged" view that the user interacts with. To your applications, it looks like the files were there all along.
Step 1: Building Your First System Extension
You don't need complex build systems to create a system extension. At its simplest, a sysext is just a directory structure that mirrors the Linux root. Let's build a workspace for a custom tool.
Next, let's create a simple test tool. In a real-world scenario, you could drop a compiled binary like ncdu or htop here, but for this guide, a script works perfectly:
echo -e '#!/bin/sh\necho "Sysext is active on Fedora!"' > my-tool-ext/usr/bin/foss-tool
chmod +x my-tool-ext/usr/bin/foss-tool
Step 2: The Metadata "Passport"
This is the most critical step and where you can get stuck. systemd-sysext acts as a gatekeeper. It will not merge an extension unless it knows exactly which OS version the extension is built for. To find out what your system expects, run:
cat /etc/os-release | grep -E '^ID=|^VERSION_ID='
On my setup, this returns ID=fedora and VERSION_ID=43. If you are following along, make sure to replace these values with whatever your specific system reports. If you are on Silverblue 39, use those numbers.
Before we merge anything into the live system, it’s worth double-checking our work. A systemd-sysext image is essentially a mirror of your root directory, so the file hierarchy must be exact. You can verify your layout by running:
ls -R my-tool-ext
You should see your binary sitting in usr/bin and your metadata 'passport' tucked away in usr/lib/extension-release.d/. If these aren't in the right place, the system simply won't know how to 'map' them during the merge.
Step 3: The "Merge" Moment
Now that our extension has its "passport" ready, we move it to the system's extension path and trigger the merge. This is the moment where the read-only barrier is bypassed:
Next, confirm the binary location. The system should see it as a standard system tool:
ls -l /usr/bin/foss-tool
foss-tool
You can verify the status and run your new tool:
systemd-sysext status
Your system is still technically read-only, but you’ve successfully injected new functionality into it without a single reboot.
Troubleshooting: When the Merge Fails
One of the most common frustrations is seeing the error: No suitable extensions found (1 ignored due to incompatible image). This isn't a bug; it's a safety feature.
If your extension-release file says you are on Fedora 42 but you actually just upgraded to Fedora 43, systemd will block the merge.
It does this because libraries often change between versions, and merging an incompatible binary could cause system instability. If you hit this error, simply update your metadata to match your current os-release and re-run the merge.
Reverting Without a Trace
The most powerful feature of systemd-sysext isn't just how easily it adds tools, it’s how cleanly it removes them. Traditional package management often leaves behind config files or libraries that clutter your system over time.
With sysext, unmerging is a clean break:
sudo systemd-sysext unmerge
If you try to run your tool now, the shell will return a No such file or directory error. The overlay has been lifted, and your /usr directory is exactly as it was when you first installed the OS.
Why This Beats the Container Approach
A common question is: "Why not just use Distrobox?" Containers are amazing for general applications, but they run in an isolated namespace. If you are trying to debug a kernel issue or analyze hardware peripherals, that isolation can get in the way.
systemd-sysext puts the tool directly on the host. It has the same permissions and visibility as a tool shipped with the OS itself. If you need a tool to "be" the system rather than just "run on" the system, sysext is the surgical choice.
Conclusion
The move toward immutable Linux shouldn't feel like a move toward a "locked-down" experience. Tools like systemd-sysext prove that we can have our cake and eat it too. We get the security of a read-only core and the flexibility to inject any tool we need instantly.
There is a new merge on the Wayland GitLab repo. This new merge (of an old pull request) adds xdg-session-management protocol to Wayland. This is a big development and certainly a feature Linux users will enjoy.
As per the brief message in merge request:
For a variety of cases it's desirable to have a method for negotiating the restoration of previously-used states for a client's windows. This helps for e.g., a compositor/client crashing (definitely not due to bugs) or a backgrounded client deciding to temporarily destroy its surfaces in order to conserve resources.
This protocol adds a method for managing such negotiation and is loosely based on the Enlightenment "session recovery" protocol which has been implemented and functional for roughly two years.
In simpler words, session recovery is finally coming to Wayland.
What is the xdg-session-management protocol?
Basically, it's a set of rules that is used by your desktop environment and applications for talking to each other for saving and restoring the window state.
With this fresh new protocol, written natively for Wayland, the concept of session management existed in the previous X11 display server but it is finally coming to Wayland.
If you are curious, XDG stands for Cross Desktop Group. The X could have been Xorg or X11 once upon a time. Actually, it's all under the freedesktop.org organization that creates standards that work across all desktop environments in Linux.
What kind of advantages can you expect?
I see two major benefits of the session management:
Restore your windows after a crash or restart
You'll be able to restore the previous state and size of an application. This is like the usual "do you want to restore last session" thing you see in web browsers. But this one is for all your apps and windows and works automatically.
Save the desktop layout
This will be interesting as well. Your Linux desktop will be able to remember window positions and sizes across restarts. So if you are meticulous about an organized layout where the terminal is on the left and the browser is on the right, it will be the same even after your system restarts. Note that session survives temporary app closures, too.
There is a demo of this protocol with Chromium shared in the video below:
It took 6 years, but the pull request finally got merged
If you look at the repo, you'll notice that the pull request was created on February 17, 2020. That was six years ago. The pull request was finally merged on March 23, 2026.
Linux users, or should I say Wayland users, waited so long for this feature to arrive. Note that session-management is not a new thing. If you use Xfce desktop with the classic Xorg display, it saves the session.
I think that KDE's KWin window manager already added this new protocol in one of the releases last year. Although I don't recall using it.
This change finally fills a gap that has existed ever since Linux distros started moving from X11 to Wayland. Session restore is now being properly implemented for the modern Wayland world. Hopefully, all desktop environments should be able to adopt it easily and Linux users get to enjoy the option of saving and restoring sessions.
For years, many Ubuntu users have felt that traditional .deb packages were being gradually sidelined in favor of the Snap ecosystem.
It started quietly. Double-clicking a downloaded .deb file would open it in Archive Manager instead of the installer. Then came controversial changes. Apps like Chromium, Thunderbolt and Firefox began defaulting to Snap packages, even when users tried installing them via the apt command in the terminal.
It continued further as Ubuntu introduced its new Snap Store. In Ubuntu 24.04, it ignored .deb packages completely. Double-clicking a .deb file would open the App Center, but wouldn’t actually install the package and just hang there. That behavior was later reverted after I highlighted it through It's FOSS.
While Canonical’s obsession for Snap isn’t going away anytime soon, there is some good news for debian package lovers.
With the upcoming Ubuntu 26.04 LTS, the App Center will begin displaying Debian packages installed from official repositories. Until now, it only showed Snap apps, making it unnecessarily difficult to manage .deb packages through the GUI. In fact, uninstalling a .deb from the App Center required manually searching for it and navigating to its listing page.
This change won’t end the Snap vs Deb debate, but it’s definitely a step in the right direction.
Manage deb packages from App Center
In the new app center, when you click on the "Manage" option from the sidebar, it shows all the installed packages.
On this screen, you can use the "Package type" filter to show only the debian packages, or snap or a combined list of both..
Manage Deb Apps in new app center
You can sort the packages based on date updated, name, etc. A good little feature.
Arrange Installed Deb Packages
Not only that, you can also uninstall Deb packages from the manage view. This is the main feature. Before Snap era, App Center used to show the installed (debian) packages and allowed people to remove them with mouse clicks.
Uninstall Deb packages from manage view
You can now update deb packages using App Center along with Snap updates.
Update all packages including deb packages
Snap continues to enjoy special favors
It is no secret that Canonica, Ubuntu's parent company, still prefers their Snap packaging. And thus it is not surprising to see Snap packages having extra features in the App Center than their deb counterparts.
For Snap applications, an ‘open’ button is shown on the listing page itself:
Open Snap App from App page
Or, from the managing page:
Open Snap app from manage section
On the app listing page of a snap app, a ‘revert’ option added to the drop down.
Revert Update in App Page
A merge request is open to add support for purging app data when uninstalling snaps through the App Center. This is indeed a good thing as it will help people recliam disk space.
Quick tip: Choosev Deb (or Snap) while searching for packages to install
Just so that you know, App Center already lets you search and install deb packages. When you search for an application, there is option shown to choose between the Snap and Deb versions.
Deb and Snap in Search results
Snap still is the first class citizen in the Ubuntu-verse. But it is still good to see the good, old Debian packages getting some space.
For regulars in the open source space, Ubuntu is kind of a household name that introduced many to the diverse world of Linux, where you have all kinds of flavors. Want some work done? You have Fedora. Want to earn the rights to say "I use Arch, btw," and get work done? You have Arch Linux.
We are now weeks away from Ubuntu's next long-term support release, and Canonical have now provided everyone with a beta build for testing purposes. Let's see what it delivers.
Ubuntu 26.04 LTS Beta: A Functional Upgrade
While the beta release offers variants like Server, WSL, and Cloud images, alongside the official Ubuntu flavors, I have only focused on Desktop here. We start with the new boot animation that looks clean but will be easy to miss if you have a decently powerful system.
Powering the release is Linux 7.0, whose development is still wrapping up, but it marks a significant jump from the Linux 6.8 kernel that shipped with Ubuntu 24.04 LTS. For the desktop, it ships with GNOME 50, which has finally managed to let go of X11.
0:00
/0:08
The new boot animation.
The shell picks up a power mode indicator in the top bar, better screen time controls, and fixes for some long-standing annoyances like deleted default folders reappearing after a reboot. Variable refresh rate and fractional scaling are now stable features and are no longer buried behind an experimental flag.
GNOME 50 demo and the Resources app on the left; on the right is the App Center.
The App Center has also been updated to show and manage Deb packages installed from Ubuntu's repositories, not just snaps. You can head over to the Manage section to find a new package type filter that lets you view them separately.
On the graphics side, Mesa 26.0 is on board, bringing OpenGL 4.6 and Vulkan 1.4 support along with a broad set of driver improvements across Intel, AMD, and NVIDIA hardware.
Docker Engine 29 is also included, which makes the Containerd image store the default for fresh installs and adds experimental nftables firewall backend support.
You can download the beta builds for x86 systems from the release portal (which is also where the stable release will go live), and for other platforms like ARM64, you will have to visit the image mirror.
Stay tuned to here and on our socials for more detailed coverage when the stable release comes out!
