Ubuntu 25.10 lands: Rustier and Wayland-ier, but Flatpak is broken The latest interim release of Ubuntu is here, showcasing some significant changes. This isn't a long-term release, yet many of its differences will be in 26.04 next year. At the end of last week, Canonical released Ubuntu 25.10 "Questing Quokka," along with nine of the ten official flavors. The release notes cover what's new …
The Ubuntu site describes that with the wording
>> We have upgraded the required RISC-V ISA profile to RVA23S64
Clearly, "upgrading" software is now used to mean "you can not run it on *your* oafish computer", although Ubuntu have gone one step further than Microsoft, by not even being able to point at suitable replacement hardware.
Sure, you can run it in emulation, but is that really useful to anybody trying to *use* RISCV?
The Ubuntu life cycle say 24.04 LTS (Noble Numbat) is in standard support until Apr 2029 so for now there is no argument that you can't just keep *using* RISCV unless you have some compelling reasons to upgrade.
The issue with RISC-V is that there have been no standards which a distro can follow. I don't know how closely you have followed the RISC-V situation with respect to Linux support, but Ubuntu had a list of boards they supported. Every board was incompatible with every other board to a degree that it required a different, custom version of Ubuntu to run on it.
This was not scalable or sustainable, and unlike ARM, there is no Raspberry Pi which dominates the market for low end (affordable) hardware and which OS suppliers can focus on. Despite this, Ubuntu's support for RISC-V has been outstanding relative to pretty much anyone else.
The situation with RISC-V is similar to that of the early days of ARM. Every ARM board required its own custom Linux distro which the vendor released with it, and support for that release seldom lasted beyond when the vendor came out with a newer board model. Mainstream distro support was almost non-existent.
The Raspberry Pi "solved" the ARM problem to some degree by simply becoming so popular and widespread that they provided a worthwhile target for third party distros to support. There are still loads of ARM boards which never seen mainstream distro support and for which the vendor releases a hacked version of Linux with it on release and then abandons so far as long term support is concerned as soon as they have a new board model, so this is not something unique to RISC-V.
ARM has since sorted itself out and there are now standards which board vendors who care can follow which allow standard distro images to boot and run, allowing users to mix and match boards and distros and allow for long term support which extends beyond when the OEM loses interest.
RVA23S64 is supposed to do the same for RISC-V. That is, it will provide a standard which board vendors to follow which would allow pretty much any RISC-V Linux distro to run on it without needing a special version just for that board.
Given that RVA23S64 is now the standard which RISC-V vendors are expected to follow, it makes sense for Ubuntu to focus on that. That also provides incentive for the board vendors to release hardware which follows the standard as they will then know there is immediate hardware support for it. For Ubuntu to spread its RISC-V support out thinly over multiple targets would mean diluting efforts to come out with a really good single version that would run on multiple standards following boards.
I have been in the market for a RISC-V board for some time now to do development on, but I've been waiting for either some sort of standards to shake themselves out, or for the RISC-V equivalent to a Raspberry Pi to arrive. When a low cost RISC-V board which boots and runs the RVA23S64 version of Ubuntu comes out, I'll buy it.
I don't know if you remember the early days of x86 PCs, but the situation there was very similar. While a lot of companies cloned the IBM PC, a number of important vendors came out with their own similar, but non-compatible versions. The result was that there were lots of x86 PCs which needed their own custom version of MS-DOS, their own version of Lotus 123, etc. Some of them were better than the IBM PC or clones (e.g. some used the 80188 or 80186 CPU, which was faster than the 8088 which IBM and most clones used), but performance was less important than common standards and so they eventually died in the marketplace.
I like your replies, but I feel obliged to fault-find, I'm afraid.
> The Raspberry Pi "solved" the ARM problem to some degree
How so? Its firmware is ThreadX running on the VideoCore. It has no UEFI, no standard Arm firmware of any kind. An OS for some versions of the Pi can't boot on others. E.g. the Pi 5 and later can't boot Arm32 code, so there is no RISC OS for them.
Pi OSes can't boot on anything else.
It solved no problems at all. If it had used UEFI, it might have. If, as discussed early in its development, it had used RISC OS, it might. If they'd used OpenFirmware (née OpenBoot) it would have. But it didn't. It uses a proprietary RTOS later bought my Microsoft.
In terms of standardising the market, all I can see that it's done is prompt a wave of similarly cheap SBCs. I suppose to a point it's standardised the physical form factor. That doesn't seem terribly important to me, TBH.
> ARM has since sorted itself out
Only to a very limited degree. It urges UEFI for Arm64 but lots of OEMs ignore that. Including the RasPi.
> I don't know if you remember the early days of x86 PCs
Quite well although it was largely before I entered the paid business.
The thing is that some of those early x86 machines were _before_ the IBM PC. You can't really be compatible with something that's not been released yet. After release, the effort became to do it _without getting sued_.
Apricot, Victor, Sirius -- all predated the IBM PC 5150, I think?
The 80186 appeared the year _after_ the PC, so wasn't an option for early cloners. It was only a little faster -- 10% of fsck all is not much -- and wasn't entirely compatible, as it wasn't really aimed at PCs. The NEC V20 was a more interesting option, IMHO.
Um. Liam.
I would like to point out that the Victor 9000/Sirius 1 were contemporaries of the IBM 5150 PC, but appeared after the PC was released (in the US at least, as the delayed release of the IBM PC in Europe meant that it was available there before the PC), and were not really 'compatible'. They were released with CP/M-86, MS-DOS only becoming available later when Microsoft differentiated the version they supplied from that which IBM shipped.
I don't think that you can pre-date the system for which the OS (PC/DOS) was written for, and you can't be compatible with a bus that was launched with the IBM PC, before the PC.
Any Intel based PCs which pre-dated the 5150 would probably have been running CP/M-86, and would almost certainly have had different memory maps, graphics capabilities, and no IBM BIOS, so could not remotely have been called IBM compatible.
I was in the industry (just) when the IBM PC was launched. Before the IBM PC, the two most important business systems, or maybe better described as families, were the Apple ][ and all of the mostly incompatible system running CP/M-80. I'm racking my brain to think of any other 8088 or 8086 computers that came to market before the IBM PC. There was also the PET, specifically the 8032, but I think you would have to be a bit of a masochist to use that as a business system, although people did.
Going back to my paper copies of the Personal Computer World Benchtest Specials, which were a compilation of the most important systems covered in the previous year, the first issue in 1982, which covered the reviews from the PCW issues from 1981, the IBM PC was the only 808X system reviewed, and in the "In Store" roundup table at the end, the only other 808X system listed was the ACT Sirius 1 (which didn't appear in a review until the following year), and which was being sold with CP/M-86 as it's OS.
No. The IBM 5150 PC, with PC/DOS and the 8-bit ISA, MDA/CGA, 180 or 360K floppy and BIOS invented the compatible personal computer market, not by design, but because it was the system businesses wanted to buy, and the one most other companies wanted to ape to get a part of that lucrative market.
With respect to the Raspberry Pi "solving" the standards problem "to some degree", note that in my original post I put "solved" in quotes and said "to some degree". They provided a de facto standard much like the original IBM PC provided one. The number of Raspberry Pis sold is enough to sustain interest from multiple distros and for them to release for it. There is no RISC-V equivalent to the Raspberry Pi in that sense.
As for early x86 PCs, IBM released the original IBM PC 5150 in mid 1981. TI released the TI PC (TI Professional Computer) in early 1983. It had an 8088 with optional 8087 and was one of a number of "near clones" (the rest were a lot more obscure). It ran a custom version of MS-DOS and custom versions of major applications. It was nearly compatible with the IBM PC, but not quite. It got good reviews in the PC press, but eventually sank in the market as the software for it was a bit more expensive than it was for a "standard" clone.
Some "near clone" makers used the 80186 or 80188, but faced the same problem of not being compatible enough. The main advantage of the 8018x was that it integrated a number of features into the CPU chip and so resulted in a simpler overall design. This was mainly an advantage from a manufacturing standpoint, and the companies who came out with them found out that following a standard, even a de facto one, mattered more than a "better" design. These chips had better luck in the embedded market where compatibility mattered much less.
You could buy the NEC V20/V30 from various mail order vendors who sold them as a speed upgrade for PC owners. They were faster, but not enough faster that very many people bothered.
> anybody trying to *use* RISCV?
My impression is that RISC-V is still mostly hype.
The performance of the handful of end-user machines I have seen is, frankly, rubbish. They are dog slow and also not that cheap or plentiful.
Bear in mind the only official Ubuntu _desktop_ is GNOME and it's also big and slow, because it's in Javascript not a compiled language. Result, GNOME on RISC-V is borderline unusable, and I am not fussy and still use 15Y old computers because I like the keyboards.
I have spoken with RISC-V industry people, including from silicon vendors, and it's always "jam tomorrow" -- soon, real soon, we'll be launching the fast versions. Yes, we know, it's a bit slow, but you want to be ready for when the _next_ generation comes.
There is kit. The Chimera Linux creator told me that one of the only reasons they did a RISC-V version was to make use of their RV board which was lying idle... and then they found it was a bit bottleneck and that edition was going to be cancelled until someone offered them remote access to a big enterprise box over the Internet for doing builds. Loads of dog-slow cores, but loads of storage.
In the meantime Arm is fast now. Apple has the fastest but many of the team who built "Apple Silicon" have left and work for other chip vendors now, and they are working on it.
The Windows world doesn't know because a large chunk of the OS runs under emulation. Then again, the Windows world is so completely used to bloated fat sluggish apps that it has no idea that it's missing anything.
You really need to hunt to find native Arm64 Windows apps. I did:
https://www.theregister.com/2023/03/21/lenovo_thinkpad_x13s_the_stealth/
Getting good speed and battery life from Windows on Arm is like using Linux 25 years ago, or Classic MacOS in the early PowerPC era. There aren't many native apps, you'll have to hunt hard for them, maintain them yourself, and be constantly vigilant for unwanted emulated stuff sneaking in -- and you have no option but to tolerate half the OS being emulated.
Whereas Linux on Arm64 is blisteringly quick, but most of the non-FOSS freeware we all have to use and tolerate don't work. No Arm Chrome for Linux, and in turn, that means that tons of the bloated fat Electron apps don't work, so no Slack etc. It's a bit like using Alpine Linux or FreeBSD on x86-64: it works, it's fast, but it really drives home to you that a lot of stuff ghas gone -- all those little comfort factors you've got used to on modern Linux, like a big devices driver collection, lots of proprietary freeware, and good high-quality Windows emulation for running essential proprietary things from Windows.
With Arm you have a choice: cheap cool-running battery-frugal chips, or relatively big hot ones that are screamingly quick. There are compromises on the software unless you run macOS, but you have a spectrum of choices with good tradeoffs.
With RISC-V, you don't. You get the worst of all worlds. Only FOSS OSes, poor choice of apps, and crappy performance -- and it's not cheap or plentiful either.
So Ubuntu is calling the RISC-V industry's bluff: OK, the fast kit is coming soon, is it? And you can emulate it today? OK, so we will target that emulated kit then. Anyone using it now for embedded stuff or whatever will want the LTS anyway, and they've already got that.
It's the next best compromise to just saying "you know what, your hardware is rubbish and we should never have supported it, so we're killing it."
Instead they're saying "all right, big mouth, here is one last chance."
I don't think the RISC-V industry is going to pull a rabbit from its hat. I think it will never catch up but it will stagger along, good enough for non-performance-critical embedded stuff where the fact it saves $5 a unit matters. There will be a few lacklustre showcase desktop boards but nobody who tries one will ever buy a 2nd one.
This is different from the comparable situation with Chinese CPUs, like Loongson and Zhaoxin. It doesn't matter if they're sluggish. The reason they exist is so it's OK for the PROC to invade the ROC. The PROC has its own domestic good-enough computers, so it can crippled the ROTW's supply and not be hurt by it.
The PROC has geopolitical reasons to tolerate and subsidise sluggish silicon.
The RISC-V industry doesn't. It is merely propelled by hardware OEMs who want to save a buck. It's a weaker proposition.
I have several Raspberry Pis, including a 3, 4, and 5. The performance of the 3 is quite frankly rubbish if you are trying to use it as a desktop PC. The 4 is acceptable. The 5 was faster than the x86 PC I had at the time that I bought it, at least in CPU performance terms.
There's no reason that there can't be good, affordable RISC-V boards. The problem has been that the affordable boards aren't good, and the good boards aren't affordable. There's no RISC-V equivalent to a Raspberry Pi. That is, there's no board which has the combination of good enough hardware combined with very good software support in order to reach the critical mass that it becomes the de facto standard.
RVA23S64 is supposed to address that, and I think that Ubuntu have made the right decision to focus on that.
So far as I am aware, Ubuntu only came out with custom versions for the specific RISC-V boards they support now because they wanted to get in on the ground floor of the RISC-V market, and those boards were available immediately and were affordable as development targets. Canonical's intention was to be ready when RISC-V standards solidified and they had a single target to aim for. So, focusing support on RVA23S64 isn't a change in plans, but rather it's what they have been waiting for all along.
Wow, there's a lot in there. Interesting stuff - I actually wondered why RISC-V is getting so much attention, and lots of the software world is devoting serious effort to it, if it's not even half-cooked yet. There must be something else in it? A burning desire to get away from proprietary ARM as well as getting away from cranky but ubiquitous x86? An underlying sense that it will one day still take over the world, just like Itanic was going to, back in 1999?! Whereas Linux was never going to take over the world, but accidentally did. Funny how things turn out...
There's some markets with high volumes and razor-thin margins where avoiding the ARM licence fee is worthwhile.
There's some zealots who really want fully open-source hardware, right down to the substrate.
There's also some people who just want genuine competition. PowerPC and MIPS are dead, PIC is dying and far too expensive. AMD64 and ARM are the only desktop-class game in town, and ARM is very nearly the only mid-range MCU.
I'd add Debian or preferably Devuan for anything.
But as a KDE user XFCE is too weird; I haven''t looked at Cinnamon for years but AFAICR it sets out to emulate older versions of Gnome so probably a bit weird too but could be worse. It's just a matter of what you're used to and long live the variety of FOSS desktops.
Devuan XFCE here since 2018. You also get the advantage of the fact it doesn't support snaps. I tried a couple of flatpaks just to try them, but for me they are meh. I'll take installed versions, and appimages for trying out newer versions. (e.g. GIMP, Kdenlive) I still read about other distros, but I can't help but shake my head as I read about unbuntu. I'm glad we have all different flavors of Linux, and especially glad i don't feel the need to keep searching for a distro.
> I haven''t looked at Cinnamon for years but AFAICR it sets out to emulate older versions of Gnome
Not really, no. It sets out to emulate the Windows desktop. Roughly the Win7 UI with a more Win10 look.
GNOME Flashback is the one that emulates GNOME 2 -- 2 panels and so on. Only Xfce can do the same in half the RAM and a tenth of the CPU and is far more customisable.
> They should at least offer some support for XLibre.
It is a hot potato. Few are willing to touch it.
Look at the stick Framework is getting merely for sponsoring Hyprland and Omarchy:
https://www.theregister.com/2025/10/14/framework_linux_controversy/
The backers of those projects are _far_ more moderate than Mr Weigelt of XLibre.
There's a regrettable trend among some political factions to call "anyone I disagree with" a Nazi. I've been called all kinds of Nazi and fascist before now myself: an eco-fascist for saying that preserving the environment is more important than any form of politics, for instance. Merely for recommending Linux and FOSS of course, from Microsoft apologists.
But some of Mr Weigelt's statements... eesh. And the chat channel, into which I very occasionally dip and really must delete. One loathsome little scrote posted a reword of the 14:88 slogan.
https://en.wikipedia.org/wiki/Fourteen_Words
I called them on it and they feebly claimed it was a joke. Those sending approval to the paraphrase didn't know WTF it meant. There are some horrible, vile, nasty people in there. I do not personally claim to be "woke" or anything, but frankly, anyone who uses things like "SJW" as pejoratives or uses "virtue signalling" is _at best_ of seriously questionable motivations.
> Those folks are doing some of the best work in Linux graphics right now.
[[citation needed]]
And I speak as someone who _likes_ X11.
Dear Liam,
Do xdotool, wmctrl, xrandr, devilspie and their ilk all work fine?
Cause last time I checked they don't cause they don't detect an X11 session.
So the statement "X11 apps work seamlessly" might not be correct?
When I get time, I will check again.
Thanks,
Bluck
xdotool, wmctrl, xrandr seems to work (obviously didn't check all functionality in the time that I had)
devilspie didn't but I do have it's source code (as some disto's don't have it) so I will remove the X11 check and see if it works.
The one major issue I see is wayland supports (at least on a couple of my main desktop systems) way fewer screen resolutions than X11 which is annoying as two of the lower res ones I use aren't there. Old eyes and all that.
Still, some progress from when I checked a couple of years ago.
Bluck
Do old Wine versions work correctly? I have a good library of old Windows games that won't go fullscreen on my Ubuntu laptop (22.04, IIRC).
And did they ever fix the problem of maximized windows extending to behind the taskbar when locking then unlocking the computer?
Honestly, how does Gnome keep up the bloatfest so effectively? They take out more and more, strip down the interface more and more, but it just keeps getting bigger and fatter all the same. Linux fundamentally suffers the same bloat as any other platform, though at least lightweight distros still exist.
So, sometime next year I will be spending a week or two in angst ridden indecision over upgrading to 26.04 or not. As much as I prefer Linux it always seems as if something is broken when you upgrade. A result of all the little customisations you end up doing that can't cope with the way things change. Will I be spending a 1,2 or 3 weeks getting everything working again? It wouldn't be so bad if I could remember what I did a year or two ago, but I can't and was in too much of a hurry to write it down!
Maybe I should stay on 24.whatever until forced off? My current system does everything I need it to so maybe I should curb my 'upgrade' inquisitiveness. I like the idea of FDE considering we now have thought police in the UK but I'm struck with fear at the potential for screw ups with that. Yes, I can back the important data up but that brings its own issues if some needs to be encrypted and usually still involves a painful recovery.
I know, I'll worry in 2029.
I get what you say. And TBH you're not alone. Many, especially those making money with their boxen, have the same considerations. Although it (of course!) depends on personal needs and preferences, think about the update possibilities you have with distros like for example Mint or Debian. I did it for some going from (I think) Vanessa to Zara and (for sure) Bookworm to Trixie. Debian had some more "inter version" changes, predominantly in additional packages the user installed specifically, where Mint looked with less prompts. However, in both cases the process was pretty smooth, painless, and done in an odd hour. Don't know of course whether this would work for you, but have a think about it if you are installing fresh anyway...
> it always seems as if something is broken when you upgrade.
This is the entire motivation behind Snap (and to a lesser extent the far more complicated and far more limited Flatpak).
There are no LTS editions of Fedora. You want LTS, you pay for RHEL.
But Canonical is currently supporting 20.04, 22.04, 24.04, 25.04 and now 25.10. And older ones in limited support. It offers current Firefox for all of them, for example.
Debian family OSes make version-to-version upgrades easy. RHEL doesn't: RH says you don't upgrade servers, you re-provision new ones.
But the price of upgrades is that things break. Everyone needs to add external packages. Snap makes that easy in a way that shouldn't break on version upgrades, or break version upgrades. No need for PPAs, no need for external repos, no need to disable stuff and then re-enable it and see if there are new repos for new versions and all that faffing about.
It's a clever solution. But Canonical didn't open-source the Snap Store, and the fanboys only care about that.
When using Ubuntu -- which is most of the time these days -- I generally prefer using Snap packages. The launch speed issues are mostly gone, and I have fast-enough hardware that it's not really an issue for me anyway.
But boy oh boy 25.10 has some issues in that regard. Case in point: the Snap version of Tuba (the excellent Mastodon version) simply won't launch. The Flatpak is fine. That seems... odd.
