Canonical is about to release its interim version of Ubuntu, the Stonking Stingray, a.k.a. Ubuntu 26.10, and they are doubling down on security with the upcoming Linux 7.3 kernel series, a slimmed-down GRUB bootloader, and more.
Ubuntu 26.10 (codename Stonking Stingray) is scheduled for release next week, on October 15th, 2026, with the latest and greatest GNOME 51 “A Coruña” desktop environment, the unreleased Linux 7.3 kernel series (yes, Ubuntu 26.10 will ship with an RC (Release Candidate) kernel), OpenSSL 4.0, OpenSSH 10.5, and Rust-based core utilities.
To beef up security, Canonical implemented a signed, slimmed-down GRUB bootloader with a reduced attack surface, TPM-backed encryption support on machines that don’t have a hardware root of trust, and dbus-broker as the default message bus with AppArmor mediation intact, using an event-driven architecture with better accounting, reliability, and scalability.
On top of that, Ubuntu 26.10 will ship with ntpd-rs, a memory-safe time daemon that will be enabled by default in Ubuntu 27.04, certificate revocation with upki, authd support for MS MFA and identity-provider-based accounts, hardware-token VPN sign-in support in NetworkManager, and on-device speech recognition powered by AI.
“Ubuntu 26.10 introduces Myna, a desktop speech-to-text feature. It’s designed to bring cutting-edge accessibility, without compromising security,” said Canonical in a blog post. “Myna performs speech recognition locally through an inference snap. Once the required models are installed, dictation works without an internet connection.”
Linux kernel 7.3, which will be released later this month, will also bring numerous updates to the Landlock, AppArmor, SELinux, and Smack security modules for Ubuntu 26.10, along with TPM driver updates and BPF verifier fixes to prevent pointer leaks on speculative execution paths, NTFS3 security hardening, memory-safety fixes, and Rust support for PowerPC.
Last but not least, Canonical doubles down on firmware updates via fwupd, which now asks for a recovery key only when the running system uses TPM-backed encryption and a firmware update could affect the measurements used to unlock the disk, instead of prompting unnecessarily on systems where the update doesn’t affect the TPM-backed unlock policy.
As mentioned before, Canonical plans to release Ubuntu 26.10 (Stonking Stingray) on October 15th, but if you’re eager to try it right now on your personal computer, you can download the beta release. However, please keep in mind that it’s a pre-release version, not suitable for use in production environments.
I really like some of the direction Canonical is going, but very much do not like how they’re getting there.
Rust core utils sounds great, this sounds great, but practically I feel both need a lot of time in the oven to come out right and that’s okay.
I also i feel like snaps have lost and can be considered a mistake. I don’t use snaps, so I can’t explain why, but everyone is saying it.
From what I’ve seen, there are 4 core issues people complain with snaps:
Bonus: Some also complain about security, that snaps have had many vulnerabilities, and that malware was distributed as snaps, but the same has been true for Flatpaks too, so I don’t think it’s fair to point that out.
Snaps nor anything going into the Ubuntu Desktop is targeted for the average home user. It doesn’t make sense to say any of it is “losing” when Ubuntu Server has such a huge market share.
Snaps really shine in server deployments and support things Flatpaks cannot, like CLI applications or drivers. Really far from a mistake.
I think by extension though, this has made Ubuntu Desktop the best it ever has. You get debian package support, snaps and flatpaks, rust utils and first class support from third party software providers. And all of that is easily transferable to any server deployment.
the pushover licensing of ruat coreutils is a worrying development too.
Pushover licensing?
licensing that easily allows oligarchs to take the work and not contribute a single cent or line of code.
Most people hate Snaps because the Snapstore backend is proprietary (which is a valid reason to hate them).
I despise Snaps because their cold start times are dreadful (yes, even with LZMA compression, which Canonical wants you to believe solved this). When a Snap launches after first installation or after an update, you’re looking at anywhere from 15-60 seconds of unresponsiveness while your system appears to fail to launch the application, even though it’s actually because the shitty Snap needs to decompress the disk images and pollute your loopback devices.
Combine the terrible cold start times with the fact that the default behavior of Snaps is to phone home to the Snapstore whenever they want to check for updates and you’re going to create bad experiences for people (especially newbies) that think “Linux is garbage” because Canonical decided this was a great idea to force on people.
They also keep Snapifying core parts of Ubuntu like the kernel itself and GNOME, making them impossible to avoid if you want or need to use Ubuntu.
15-60 seconds, are you running it on a disk drive?
Its just dishonest to say its that bad. Its at most 1-2 seconds longer than a regular package in most scenarios. And only the first boot.
No, I am not running on a disk drive, obviously. I package a major application for Snap and have done extensive testing. I have way more experience with Snaps than I want. It is not dishonest and it is cold starts, meaning initial installation and updates, not just first boot.
And, as I said, when a given Snap autoupdates without making it obvious to the user, it’s gonna appear like it froze for no reason while you’re waiting for it to launch.
Snaps are a bad technology.
Is it? Or is that application just not meant for this tool? You can just deliver the application as a debian package, flatpak or appimage?
You made it seem like all snaps take 1 minute to cold start and thats why they are bad. Stuff like Firefox, Slack, Discord, Proton stuff, boot marginally slower. Steam takes a little bit (10s for me) but steam always takes a while to boot anywhere.
Most of these are also persistent. They can’t autoupdate unless they are closed, so that scenario wouldn’t be common.
Snaps are also really desirable for critical things like Docker or Tailscale. I want my images to roll back if the update fails. How long server apps take to boot kinda doesn’t matter.
Like they are not a bad tool because they don’t excel in a specific use case which happens to be yours.
I wouldn’t want to package say the Unreal Engine as a snap, because 1. its huge and would take forever to open and 2. I never want it to update. It would be a bad tool for that job.
I feel the same way about snaps. It’s the main reason why I do not use Ubuntu. If they didn’t make snaps mandatory, I would use Ubuntu instead of mine or Fedora
Wtf is a snap?
Unless things have changed, snaps are distributed from a closed source repository to high the Ubuntu creators control.
People have removed snap from the system, but when they installed Firefox with apt, Ubuntu silently reinstalllrd snap and the snap version of Firefox.
A package, meant to run anywhere and be sandboxed.
However, they are only properly sandboxed on Ubuntu. They have some downstream AppArmor patches that haven’t all been accepted. They’re decently sandboxed on other AppArmor distros. Basically no sandboxing on distros that don’t use AppArmor, like Fedora.
Imagine a flatpack but made by canonical