I’ve been using the beta version of Kubuntu 22.04 for a few weeks now on my daily-use machines (both Dell laptops; a G3-15-3579 gaming laptop and an XPS-13-9310 ultrabook). Its final release, along with that of its Ubuntu sibling (which uses the GNOME desktop), is set for tomorrow as I write this. This will be the next release of the Ubuntu LTS core that forms the basis of the popular Linux Mint distro, as well as many others, like Pop! OS and KDE Neon.
These few weeks have been relatively uneventful and boring. That’s not a bad thing… not in the least. Boring means the OS is doing its job, which is to allow the user to run applications and to get out of the way and let them take the spotlight. I’ve run pre-release Kubuntu in older versions, and there have been minor issues (some of which managed to persist well beyond the eventual release date, unfortunately), but not this time.
It has become fashionable to bash Ubuntu these days, and while some of that is (for want of a better phrase) digital hipsterism, that is far from the only factor at work. Canonical, Ubuntu’s developer, has made some well-publicized missteps over the years. While these things have not been even remotely as nasty as what has become the norm for Windows, they’ve been “in that direction” enough to blur the distinction between the “monetized” Windows and the “pure” Linux, which only allows the Windows apologists to engage in some (not completely unfounded) “whataboutism.”
Ubuntu’s ill-fated Amazon search tie-in is long gone, and so are some of their other, more ambitious projects. The Unity desktop was abandoned in favor of a customized GNOME 3 desktop, and their Mir compositor/windows manager has been abandoned in favor of its chief rival, Wayland. The latest such thing, the Snap application distribution system, is still very much present, and has caused some controversy in the past. That will only increase with the release of Jammy, as now Firefox will be distributed by Ubuntu as a snap (the first time a default btowser will come packaged in such a way in a major distro).
A lot of people don’t like Ubuntu’s “go it alone” tendencies in these matters (rather than having them turn their developmental resources toward improving existing projects), but I don’t have a problem with that. Some of the reasons Ubuntu chose to “go it alone” rather than supporting an existing project are valid, and while they have yet to catch on with the broader Linux community, they might have, if enough people saw the merit in what was being done.
The Snap packaging system is an attempt to address the well-known fragmentation problem that holds back a lot of development of native Linux applications, particularly when the publishers of those applications do not intend to open up the source code. Snaps, like Flatpaks and AppImages, can be installed and used easily in any Linux distribution, and if one of them caught on, it would make it much simpler for publishers to release one product that works across all of Linux.
None of the three competitors are perfect, and one glaring issue that many have with Snaps is that they take update control for the application installed as a Snap outside the hands of the Linux user. From Canonical’s perspective, where the primary hurdle is trying to convince software publishers to use the Snap format, it makes sense; application developers would generally prefer to have updates happen automatically. So would a subset of users… but not all of them. We didn’t begin using Linux because we wanted less control over updates on our PCs. Nearly all of us came from the Windows world at some point in the past, and many of us did so because it didn’t do things like this.
Canonical decided to start packaging the Chromium web browser as a Snap some time ago. Chromium, of course, is the open source bit of Chrome that is developed by Google to be its basis. Users who had the traditional non-Snap Chromium installed in Ubuntu and its derivatives would find that one of the updates would remove Chromium as a native package and replace it with a Snap. That caused some controversy, which was emphasized when lead Mint developer Clem Lefebvre spoke out against the practice… and removed Snap support from Mint so that its users would not have to suffer the loss of control over updates that was being pushed on them from upstream.
I supported Mint in that effort, and while I see the benefit in a unified packaging system that would eradicate the fragmentation and dependency issues that have plagued Linux, I don’t see it as something that should be happening in a major distro’s main repository.
With Jammy, Firefox will now be published solely as a Snap too, and that’s the default browser in Ubuntu.
There are traditional builds out there, as you might expect. If you download Firefox from Mozilla itself, it comes in a distro-agnostic .tar.gz format (the Linux version of a zip file, essentially). Mint has taken it upon itself to start hosting non-Snap versions of Chromium and Firefox, and there are PPAs (third party repositories) that do so for the rest of Ubuntu’s users. One of them is the Ubuntu “Mozilla Team,” the same team of people who used to maintain Firefox as a native package in Ubuntu. By using this PPA, you get Firefox that is built as a native installer package (.deb) by the same people who packaged your Firefox in Ubuntu before.
One of the reasons Ubuntu has claimed for going to Snaps for Chromium and now Firefox is to reduce the maintenance burden. So in the name of reducing maintenance costs, they’re now doing the same work they used to do (packaging Firefox as .deb installers for each supported Ubuntu version), but are also packaging it as a Snap. Er, that’s more work, not less, is it not?
For the time being, yes. The question is one of what the future holds. Will people reject the Snap as Mint has, or will it catch on?
Personally, I’m going the Mint route. I have uninstalled all of the Snap packages from my PCs, and then i uninstalled Snap support itself. The thing is, if I let Firefox update, it will just reinstall all of the Snap support stuff as dependencies of Firefox. Fortunately, it is not hard to set it up to ignore Firefox from the Jammy repo and use the one from the “Mozilla Team” PPA.
Other than that, there is not much different about Kubuntu 22.04 and the KDE Neon I have been using. Neon is the latest LTS version of Ubuntu with all of the latest and greatest KDE software (and related stuff, like Qt, where it differs from what Ubuntu offers) on top. While Ubuntu LTS is not a rolling release, the KDE software in Neon very much is, with each KDE release being pushed to Neon as soon as it is released.
That was the reason I moved to Neon in the first place. I always wanted to like KDE Plasma, their desktop environment, but there was always some rough edge here or there that pushed me away. That was when I was using Mint with Cinnamon, several years ago. KDE used to be known for their buggy, bloated, resource-hungry software, but they have dramatically improved it in the last few years. It’s more stable, leaner, and faster than ever before, and I didn’t want to have to wait for the bug fixes. There was one particular bug for users of the nVidia proprietary graphic driver (which I use on my G3 and desktop PCs) that was fixed in Neon for quite a long time, but was still present in every version of Ubuntu (even the more cutting edge short term releases) that was then available. That bug is thankfully vanquished from the current versions of Kubuntu now, but it took something like a year to get to that point after the fix was released by KDE.
Thankfully, Jammy is very much up to date with the latest KDE stuff, with the same version of Plasma as Neon, and with the other stuff (KDE framework and Qt) being very close. The rest of the stuff (the non-KDE stuff) in Jammy is more up to date than the 20.04 LTS base of Neon, which is why Kubuntu is my daily driver for the moment. Neon will surely catch up… each time a new Ubuntu LTS comes along, KDE moves to that version in the subsequent months (called ‘rebasing’), and I may quite well switch back to Neon when that happens.
I used to be a lot more conservative with updates. I came from the Windows world, where the usual pattern was me wanting to stick with the old, tried and true rather than the new shiny thing. I used XP for more than a decade, for example… when Vista was the new shiny, I stayed with XP. When 7 was the new shiny, I still stayed with XP initially, but I moved to 7 when the limits of Windows x86 became too confining. By that time, 8 was available as the new shiny, and I avoided that too. When 10 arrived, of course, I avoided that so hard that I wasn’t even using Windows anymore.
That kind of thing made me appreciate the Ubuntu release cadence, as opposed to a fully rolling distro like Arch, Manjaro, OpenSUSE Tumbleweed, or Fedora Rawhide. Even so, by the time each Ubuntu LTS release was approaching two years of age, I was already bristling with the frustration of the old packages in LTS, and I often would grab newer packages from newer Ubuntu releases or from Debian SID (the unstable rolling-release version of Debian that is not meant as a daily-use OS). I invariably would find some newer version of something in the Ubuntu repo that required newer libraries, so I’d want those newer libraries too.
That made me think that I’d been looking at this whole thing the wrong way, and that maybe a fully rolling distro was the way to go. I did give OpenSUSE Tumbleweed a try on my XPS, and it’s quite good… but having the newest versions of everything isn’t always beneficial. OpenSUSE Tumbleweed is currently on kernel 5.17, the latest one released at this point, but my chosen backup program, Veeam, is only good for 5.15 and lower (as well as a few of the 5.16 RCs, but surely no one is using those now that 5.18 is in RC status).
That highlighted one of the great things about Ubuntu. There is no shortage of kernel versions for you to choose from! Right now, kernels 4.15, 5.4, 5.13, and (as of tomorrow) 5.15 kernels are all actively supported by Ubuntu, in both standard (generic) and low-latency versions. There are also OEM kernels, which get patches for various OEMs like Dell that come with Ubuntu as an option before those patches work their way out to the broader kernel. Right now, the OEM kernel for 20.04 Focal Fossa is 5.14, but in the past few months, there have been as many as four different versions in development (20.04 OEM, 20.04b OEM, 20.04c OEM, 20.04d OEM). There are kernels for virtual machines, and there are kernels for specific virtual environments like AWS and Azure. There are even aftermarket kernels like Xanmod that have specific changes that can improve Linux gaming (I am using Xanmod on my G3 at the moment).
On the other end of the spectrum, if you just want the kernel as it was released by the Linux Foundation (where Linus Torvalds heads development), without any Ubuntu modifications, you can get those too, from the Ubuntu-maintained mainline PPA.
All of these kernels are available not just in their newest revision, but in every version ever released (even including the eight or so release candidates in mainline that precede each release, as well as each incremental release). They’re all there, available for testing or whatever other reason you might want an older version.
OpenSUSE Tumbleweed has… the latest version, currently 5.17.something. That’s all that’s there. Old ones are not archived anywhere that I know of. If, for example, you wanted to use 5.15 so your backup program would work (rebooting back to the fully supported version when that is done), you can’t easily do that.
When I used Fedora, it was almost like that. There were two or three kernel versions in the repo, but they were all the last ones released chronologically, not older revisions. There was an archive repo somewhere that had the previous releases, but they were not in the main repo.
These kinds of things don’t often come up when people debate the merits of one distro over another. If you never have a program that refuses to work with too new a kernel, it probably won’t matter to you at all, but one day you could find yourself in one of those niche use cases where you want a specific kernel, or a specific variant, for some reason, and if that happens, Ubuntu is by far the most likely to have your needs covered. That filters down to derivatives like Mint, Pop! OS, and Neon too, and perhaps forward to Debian as well.
Xanmod is only built by its devs for Ubuntu (maybe Debian too; I think I read something to that effect, but I don’t use Debian proper, so I can’t say for sure). In tests at Phoronix, switching to Xanmod alone resulted in ~15% more FPS in the game that was used as a benchmark compared to the stock generic kernel. The improvement in the minimum frame rate was just as good.
For a simple kernel swap (you can choose any installed kernel you want to use at boot time), that is a pretty decent boost for minimal effort.
If any given Linux program is only packaged for any one distro, it’s probably Ubuntu. There are exceptions, of course. It’s the same thing you run into if you have a problem and decide to search the web for a solution. You are more likely to find a directly relevant result with Ubuntu than the other distros. While you can use advice for one distro on another, you have to know what the differences are to be able to translate it to something relevant for what you are using, and that’s not something everyone can do.
The bottom line for all of this is that despite the well-publicized negatives, I still think the Ubuntu family is the best choice overall for general-purpose Linux computing. Ubuntu is not the 800 pound gorilla of Linux for reasons unrelated to its quality. It used to be that it was THE friendly distro for beginners, with no real competition at all, and that’s not the case anymore, but it’s still a good distro. This latest release (judging by Kubuntu, not the flagship Ubuntu product which uses GNOME, unfortunately) is a solid entry in my estimation, and users of downstream distros like Mint will, I think, be pleased with it when it reaches them in time.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
