What a real LTS looks like: Kubuntu 26.04

Last year, Plasma developers canceled the long-term support (LTS) version of Plasma. Why?

We had a few reasons:

  • Almost nobody was using it; really only Kubuntu. Other discrete-release operating systems like Debian and openSUSE Leap generally ignored it.
  • It wasn’t a real LTS; we only backported some fixes for Plasma, and nothing for the Frameworks it was built upon, nor the Gear-aligned KDE apps it shipped with.
  • Our backporting of fixes was fairly blind since there weren’t CI resources to validate them, and nobody ever felt like testing them manually.

As a consolation prize for canceling the Plasma LTS product, we decided at the time to add an additional bug-fix release to the normal Plasma schedule, effectively lengthening the support period for each non-LTS Plasma version by 2 months — from 4 months to 6.

And as a result, there have been no Plasma 6 LTS versions.

…Until now!

Plasma 6.6 is now an LTS version. And not just Plasma 6.6 itself, but also a specific version of KDE Frameworks: 6.24, which will also receive backported bug-fixes. And Gear 25.12, too!

What changed?

It wasn’t a change to my or anyone else in KDE’s opinion of what a proper LTS product looks like. Rather, it was the Kubuntu Focus company stepping up to fund the creation of one, as announced today!

That’s right, Kubuntu focus is sponsoring a Plasma 6.6 LTS product for the next three years!

This consists of a couple of pieces:

First of all, Kubuntu Focus is sponsoring Techpaladin Software to fix bugs identified by Kubuntu 26.04 users. (full disclosure: I’m the CEO of Techpaladin Software). We’re not just backporting bug-fixes that happen to get made, but rather actively working with the Kubuntu folks to identify and fix pain points experienced by them and their users.

Plasma 6.6 will thus remain eligible for bug reports for the next three years, and we’ll do our best to get them fixed and backported.

Speaking of which, we’ll be backporting fixes for more than just Plasma 6.6 — relevant ones will also to Frameworks 6.24 and Gear 25.12, the versions that Kubuntu 26.04 ships with. The whole KDE part of the software stack!

Finally, Kubuntu Focus is sponsoring additional continuous integration resources owned by KDE e.V. to handle the load of validating changes made to these older versions. And they’ve been generous enough to sponsor more than was strictly speaking needed for the initiative, so KDE in general benefits from faster CI times even for non-LTS work!

We’re calling the whole thing the “Bullet-Proof KDE Initiative”.

This is what a real LTS initiative looks like, folks: people involved with an OS putting the resources into making a non-LTS upstream release into an LTS one, properly. With bug fixes — not just security fixes — backported to all levels of the software stack, not just the top one.

So I predict Kubuntu 26.04 promises to offer the best KDE experience of any Kubuntu release ever!

I know a lot of folks really enjoyed Kubuntu’s 24.04 release because of how it lined up with Plasma 5.27, which we made an LTS release for an extended period of time during the Plasma 6 transition. Well, this is the same thing, only with a great version of Plasma 6 included, and supported for even longer!

Aha, so you’re a sell-out who changed his opinions about LTS due to money!

My opinion remains the same: I don’t dislike LTS products — only fake ones that promise support but don’t actually deliver it. With this initiative, users of Kubuntu 26.04 get a real LTS product, with real support backed by a pair of commercial companies.

So this is all a commercial thing? KDE gone korporate?

It’s largely a commercial initiative between Kubuntu Focus and Techpaladin Software, yes — though KDE e.V. has signed off on the initiative and agreed to accept funding for the new CI resources.

Both companies are good citizens in the KDE ecosystem: KDE e.V. patrons, employers of engineers you’ve heard of, and providers of hardware and services to users of KDE software.

And the benefits accrue far beyond just the companies. Obviously Kubuntu 26.04 users benefit, even those who didn’t buy a computer from Kubuntu Focus. And as I mentioned earlier, all of KDE now has more general-purpose CI resources. Also, many of the LTS bugs that Techpaladin people have already fixed were affecting people on later Plasma versions, too! Everyone wins here.

So the commercial part is not a limitation on what anyone else gets for free or is allowed to do; it’s just an acknowledgement that creating a real LTS product costs money.

Wow, really cool! How can I help?

Anyone in the wider KDE community who’s interested in this kind of thing should feel comfortable backporting important and safe bug-fixes to the stable branches for Plasma 6.6, Frameworks 6.24, and Gear 25.12. There will be a Kubuntu CI runner that makes sure nothing breaks (at least, nothing that’s tested in the CI! So keep that test coverage high).

And if you happen to run discrete-release OS and would like to get in on the action, feel free to ship Plasma 6.6 and invest some of your own resources into it! It will be very welcome to see more people fixing bugs reported by LTS users that are still present on master, or backporting more recent bug-fixes to the LTS version. Again, everybody wins here!

Keep your community afloat with the right defense tokens

My favorite tabletop game of all time is Star Wars: Armada, a Star Wars themed ship combat wargame.

Armada has many deep and tactically interesting features, but one of my favorites is the unique suite of defense tokens available to each spaceship to protect itself against attacks, from among the following six options:

  • Scatter – the attack is completely canceled. “I wasn’t where you were shooting”
  • Evade – cancel an attack die at long range, or re-roll one at short and medium range. “I dodged your attack, so it missed or became a glancing blow”
  • Brace – halve the damage. “Ouch, you hit me! But it wasn’t as bad as it could have been”
  • Redirect – move some damage to an adjacent hull zone. “You hit me, but not where I was weakest”
  • Contain – downgrade a critical hit to normal damage – “My damage control efforts turned the potential catastrophe into just a normal crisis”
  • Salvo – return fire. “You hit me, but I hit back”

There’s way more information here for people whose military nerd curiosity has been piqued.

Anyway, this is well and good for games about spaceships, but what’s the relevance? Let’s imagine that we humans have these defense tokens, too. And today I’d like to talk about how they relate not to physical attacks, but interpersonal ones.

You negligent fool! You nit-picking jerk!

Someone has blindsided you with unexpected criticism! The monkey brain sees this as an attack:

Imperial Star Destroyer by topcat at Wallpapers.com — https://wallpapers.com/wallpapers/imperial-star-destroyer-hus8fir1xr6vldsn.html

Red alert! Shields up! All hands to battle stations! Your blood pressure rises. You see red and gear up for a fight:

Bull Image from FreePNGimg.com

And what’s the most satisfying defense token to use? Salvo, for sure. Hit back:

Oh yeah, that’s pretty rich coming from you given how you messed up that other thing last week!

The angry email. The “call-out” social media post. The sharp reply on chat. The hyper-critical blog post. They feel good, right?

But Salvo doesn’t actually avoid any damage. in Armada, if you Salvo every attack, your ship explodes, with the only other effect being that the attacking ship gets hurt too — usually a lot less.

From the perspective of minimizing interpersonal friction in a group setting, Salvo is the worst defense token. It didn’t end the conflict created by this unexpected criticism; in fact, now the conflict is bigger and louder, because the criticizer has also gotten hurt. Other people may leap to their defense, or yours, and pretty soon the battle lines are established. What started as a community soon feels like a war zone.

Redirect isn’t great, either; in a community context it’s basically blame-shifting, which similarly doesn’t prevent any damage; it just moves it around, and the community still suffers.

Neither is is not what we want for our community if the goal is to remain friendly and welcoming!

Prevent and reduce damage

If we want to keep our ship flying community alive, we need to prefer the defense tokens that prevent or reduce damage:

  • Scatter: prevent conflicts in the first place by meeting expectations, being mindful of other people’s feelings, and maintaining your relationships.
  • Evade: notice impending conflicts and help make them fizzle out early. Be humble.
  • Brace: mend fences and fix problems so the conflicts that do erupt shrink over time.
  • Contain: keep conflicts localized to the participants, and prevent them from spiraling out of control. Don’t let drama spill out into the larger team or the whole organization — or heaven forbid into the media! Accept valid criticism and let others have the last word.

These social defense tokens are harder and less satisfying to use than Salvo and Redirect. But over the long term, they do a much better job.

Which brings us to KDE

Today I think KDE is known as a pretty friendly place. And when I look around, I see a lot of examples of people ­— consciously or unconsciously — using defense tokens in their interpersonal relationships that reduce harm rather than moving it around or sending it back.

It’s not perfect, of course. We all mess up sometimes. And a culture like this takes years to develop. But I think the strong social bonds between contributors inside KDE are self-evident, and represent a significant part of the organization’s success today.

So I want to congratulate KDE and encourage us all to keep it up! I know times are tough and a lot of things in the world feel like they’re exploding, or getting ready to. Things suck more than they should, and there’s always more we can do to improve it. But as long as we maintain our relationships with one another, it becomes a lubricant that makes all those things so much more possible to survive or achieve.

Legal obligations vs social contracts

My post about responsibility for bug reports on old software versions the other day stirred up quite some discussion, and I wanted to drill a bit more into what I think is the crux of the dispute: the difference between legal obligations and the social contract.

When you package and distribute free open source software (FOSS), you legally have to comply with the terms of the license: “make the source code available,” “don’t change the license,” and so on.

You might also notice the absence of a warranty, or silence about responsibility for bug reports.

So let’s return to the question:

Who’s responsible for bug reports on old software versions?

An accurate legal reading is “Nobody, unless you’ve signed a work contract with a developer or purchased a commercially-sold OS.” But it’s also not the whole picture, because there’s another potential non-obvious legal obligation:

Trademark

Trademark law varies across the world, but at least where I live in the USA, “unregistered trademarks” are a thing, and in a professional context, you’ve got a legal obligation not to violate a product’s trademark — registered or unregistered — by referring to it as something that it isn’t, or changing it and saying it’s still what it originally was.

Ah, but how much to you have to change it before that kicks in? That’s definitely not something that I — a non-lawyer — am qualified to assess. And my understanding is that this varies a lot across the world’s legal regimes, too.

But my layman non-lawyer perception is that applying bug fixes (especially backports of the developer’s own bug fixes) probably doesn’t count, while making visual or functional changes not from the developer probably does press closer to that fuzzy line.

Which brings me to what I think is the most important part:

Doing only the legal minimum

“Follow the terms of the license agreement.” “Don’t mis-represent trademarks you don’t control.” “Don’t steal.” “Don’t murder.”

These are good places to start. But what if that’s all anyone ever did — the bare legal minimum?

I think the world would be a pretty miserable place. There’s no law requiring anyone to love you or soothe your feelings when you’re upset. There’s no law requiring you to find a source of joy or direction in life, or help others unbidden.

What makes life worth living is everything beyond the legal minimum: politeness, kindness, friends, love, pleasure, purpose, art, music, entertainment, faithfulness, professionalism, and so on.

Everything desirable but not required by law comprises the social contract: a set of unwritten rules that, the more people follow them, the better their society is to live in. It helps personally, too: follow the social contract, and you’ll end up calmer and happier, be perceived more positively, and things will just kind of start going your way, as if by magic. Break it, and the opposite starts to happen.

Applying the social contract to this situation

Let’s say that I write an app, and someone distributes it with a feature patched in that I didn’t write, or a visual change that I didn’t make. How mad at them am I going to be?

If we have a bad relationship due to previous perceived violations of the FOSS social contract, I might be very mad. I might complain publicly, or even threaten to enforce my trademark and demand they change the branding to reflect the fact that they’ve created what I believe to be a derivative work that reflects poorly on the original.

No matter what, we can be sure it will escalate into a fight with a winner and a loser. And that loser might be me.

But if we have a good relationship and view each other as pro-social upholders of the FOSS social contract? I might be really happy about this, or at least tolerate it. Maybe I’ll even reach out and ask them to submit their change upstream and help maintain it. There’s a 0% chance I’m going to threaten to invoke trademark law or give them a hard time about it.

That’s the power of respecting the social contract that exists between us.

But what is the FOSS social contract?

Like the definition of “derivative work”, it’s unsatisfyingly fuzzy and nebulous. But like a cloud, even if we can’t contain 100% of it in a jar, we can probably identify many of its features. So here are some pro-social behaviors that I hope we can all agree are squarely within the “FOSS social contract”:

Using FOSS

  • If you didn’t pay any money, appreciate what you’ve gotten for free. It’s a modern miracle.
  • Understand the basic software lifecycle of the OS you’re using, and choose the one that suits your needs the best.
  • Accept the “no warranty” clause. Understand that support may be slow, and that if you need it fast, you’ll need to pay for it.
  • If you don’t like the software you’re using, use something else.

Bug reporting

  • Endeavor to report bugs in the right place, to the best of your ability.
  • Phrase your bug reports gently, and articulate a real problem to be solved, rather than making demands or suggesting solutions.
  • Be understanding of the fact that your request might be a big ask that might not get done soon, or might be better done in a different place or in a different way.
  • Treat people kindly with the benefit of the doubt, even if they don’t respond to your bug report in a timely manner, or at all.
  • If your needs are urgent, pay a person or company to address them; don’t make demands of people working for free.

Software development

  • Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
  • If you aren’t distributing your own software in a way that’s suitable for 100% of your users, appreciate the free efforts of distributors who are doing it for you, even if they aren’t doing it in exactly the way you would prefer.
  • Work with your distributors to help them showcase your software in the best light. They don’t know it as well as you do.
  • Don’t piss off too many of your users. You’re doing this for them, not just for yourself.
  • Only make your software publicly available via a FOSS license if you’re willing to accept people using it or distributing it in ways you might not have expected or preferred.

Software distribution

  • Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
  • Respect the reasonable wishes of the developers whose software you distribute. Keep up good relationships with them as much as possible.
  • Clearly communicate your OS’s software lifecycle and release schedule. Curate your users so everyone using your OS is within its intended audience.
  • If you meaningfully change the software you distribute (outside of backporting the developers’ own bug fixes or similar), accept that you’ve created a derivative work that needs to be presented accordingly: At the minimum, change the name, icon, and metadata (like the bug report URL).
  • If you distribute software that you know is or soon will be outside of its developers’ support window, change the bug report URL to your own, or remove it entirely if you don’t have the resources to offer support for old software.
  • Only create an OS in the first place if you’re willing to take responsibility for the support needs of the people who will use and depend on it.

Hopefully we can all agree that if everyone considered the above ideas to be part of the social contract they follow, our world would be a very friendly and pleasant place! We’d end up with way fewer arguments and disputes, and could more and more get on with doing the fun part of what we do. And it’s my hope that we can all aspire towards these ideal with our actions and words.

Who’s responsible for bug reports on old software versions?

Consider this hypothetical:

An operating system (OS) ships version 1.5 of a piece of software.

Meanwhile, the latest version of that software is 3.0.

A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact?

This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them.

It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons.

This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress.

I think it’s an important topic, so I thought I’d share my take on the situation.

Are software developers responsible?

Software devs wrote the software. The software broke. End of story.

If only life were that simple!

Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating.

But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life.

Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broaden the system to cover our apps and frameworks, too.

It’s not perfect, but it mostly works out. I can tell because most of the new Plasma bug reports I see these days are from users of rolling-release OSs like Arch, OpenSUSE Tumbleweed, and Fedora KDE (which is not truly rolling, but it’s close enough), and I’d say most are actionable.

It kind of stinks for users of discrete-release OSs, who get a robot telling them that the work they just put in to report the bug was useless. But they also benefit from rolling-release users effectively being their free quality assurance (QA). Trade-offs.

Are distributors responsible?

If my car breaks, I blame the car company — not the vendor who sold them the part that broke.

(well, maybe I blame them too if I’m a car nerd, but that’s the exception!)

Ultimately OS distributors are the car company here, assembling the final product. It’s their job to do adequate QA and work with their vendors (upstream software devs) to make sure that final product sparkles.

Of course, a new car costs many months’ salary and includes a multi-year warranty, while most FOSS OSs don’t and are distributed for free. So expectations need to be tempered a bit.

This is where I think communication breaks down. A lot of free-of-charge FOSS OSs advertise themselves really positively, promising the sun, the moon, and the stars. Whereas the truth for many is that they’re assembled by a small team with a shoestring budget (or none at all) from years-old software offered by grumpy developers they don’t have a great relationship with.

Users then don’t understand the full picture of who’s responsible for what, or the level of support they should expect and from whom.

This is the reason why KDE Linux includes tons of qualifiers and provisos in its marketing material. We don’t want to over-promise! It’s a small project built by a small team. I think every piece of free software should be clear about who should use it… and who shouldn’t. Don’t over-promise! It’s a recipe for frustration and disappointment on all sides.

And if you want an OS with professional backing, you’ll likely need to pay for it.

So what’s the solution?

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it’s released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs can still have good relationships with their upstreams, of course. But it isn’t as critical.

Don’t want to be a rolling release? That’s fine. Then you need to work closely with your upstreams.

Communicate your users’ complaints and bugs upstream, help drive fixes, and then ship them. Many software developers already release bug-fix versions in addition to feature versions. If they do… ship them! Don’t ignore them; this will make your upstreams grumpier.

If any of your upstreams release a “long-term support” version of their software, ship that. If they don’t, you can even work with them to create one if they’re amenable to the idea, and help to support it.

This is more work, obviously. So if your team is small, it may not be feasible to do for every piece of software you ship. But you can try for the most important ones: the Linux kernel, systemd, Mesa, Libinput, PipeWire, NetworkManager, BlueZ, udisks, CUPS, and KDE or GNOME.

But that’s the important point: shipping a high-quality discrete release OS is more work than producing a competent rolling release. No way around it.

So a way to make this approach more feasible is to reduce your OS’s scope of concern.

For example, you can delegate app distribution to a third party like Flathub, the Snap store, AppImageHub, etc. This lets you focus on just the base OS and its desktop environment, while apps are rolling, which means they’ll accept bug reports about them. Personally, I think there’s a lot to like about this model.

It also helps if you don’t let the software get too out of date. Up to 6 months old? Your upstreams are likely fine with this, and will accept bug reports. 12 months? Mostly fine. 2 years? That starts to get painful for your upstream developers if users are still reporting bugs to them. 3 year or more? Very painful. We pretty much have to direct them to their OS vendor.

What’s not the solution?

Package 2+ year-old frozen releases of as much upstream software as you can, and then ignore the upstreams, their bug-fix releases, and their complaints about this.

This is the worst of all worlds!

  • Users get outdated software that’s full of bugs and security holes fixed long ago
  • Software developers get un-actionable bug reports from angry and confused users
  • Distributors get frustrated communications from software developers that damage or destroy important relationships

Please don’t do this. It isn’t sustainable over time, and will cause a leak of the most desirable users who make an active choice to use your OS.

How do I know this?

Well, I don’t, but I can make an educated guess based on some of the few statistics we do have. A big one is the OS market share on ProtonDB as compiled by BoilingSteam, which counts Linux gamers:

In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.

In 2026, they’re up to 71%.

This isn’t everyone, of course; only gamers using ProtonDB. But still, it’s quite a change. Clearly gamers believe rolling-release OSs cater to their needs better than discrete-release OSs do.

So, if you ship a discrete release OS, and you don’t want to or can’t switch it to a rolling or semi-rolling release cadence, please please please work with your upstreams! As a (sadly now only merely occasional) upstream KDE software dev, I can tell you my favorite distributors to work with are the ones who engage with KDE and help get problems solved. It’s a lot of fun when all parties focus on problem-solving.

The graveyard of being paid to use Windows 11, AKA “winning!”

I just finished reading Thom Holwerda’s hilarious article on OSnews about being paid to use Windows 11 for a month from the perspective of being a “switcher” moving away from Linux. It’s a great read; I encourage everyone to stop right now and go read it!

In a nutshell, it’s truly amazing how bad the modern Windows user experience is when you’re accustomed to anything else:

  • Missing drivers
  • Black screens
  • Broken sleep/wake
  • Ads and intrusive AI in apps
  • No visual consistency
  • An update experience that’s fragmented, slow, and frustrating

My extended family includes a lot of Mac users, and I can tell you it’s barely better there. They suffer from:

  • Limited hardware selection
  • Devices that deliberately skimp on storage space to push people towards paid cloud storage subscriptions from Apple
  • Ugly and low-contrast UIs
  • Terrible window management
  • Slow and unresponsive apps
  • Poor integration with 3rd-party services

We’re ready

I’ve been saying for years that Linux is ready for normal usage. We often lament our bugs and failures, but under-estimate just how bad the competition is.

The reason why Windows and MacOS are so prominent is not because they’re better, but rather because of their inertia and wide distribution on retail hardware. If people can’t buy Linux computers in Best Buy and Mediamarkt, we’ll never get there.

Inertia takes care of itself over time with success. But we can do something about distribution: we can continue to make our software pre-installation ready. I’ve been talking about this since my first Akademy talk in 2018, and KDE has made amazing progress in just 8 years.

It’s clearly working, too.

Successes

This is why I get so excited about Valve’s new Steam Machine console/PC running KDE Plasma. Five years ago, I got excited about the Steam Deck. And I’m excited about Tuxedo Computers and Kubuntu Focus for shipping KDE Plasma on all of their computers out of the box. For an up-to-date list, see https://kde.org/hardware.

I hope that in due time, I’ll be excited about Framework Computer and Slimbook shipping a Plasma-based OS out of the box, too. 😎 And someday after that, Razer. I think they’d be receptive. And then Lenovo, HP, Dell, and Asus. I don’t believe this is far-fetched.

When people buy one of these devices, are they going to experience some Linux-specific bugs and annoyances? Yes, it’s inevitable. Nothing is perfect. But what we offer is good. Better, even. Better for users and better for hardware vendors.

What’s left

Is there more to do? Yes. We need a stronger 3rd-party software ecosystem, including Linux versions of more popular pro apps. A bit more Wayland work to close the remaining gaps. Operating systems that are safe and full-featured out of the box. Better documentation. More companies capable of offering professional support. And so on.

But all of this is happening! Isn’t that amazing? I find it amazing. Here we all are, offering the world a better option as some of the world’s largest companies are in stage 2 or 3 of the enshittification process. And we can help. It’s so cool.

This month in KDE Linux: June 2026

Welcome to another edition of “This month in KDE Linux” — KDE’s in-progress operating system.

This month was pretty smooth; we had no build delivery drama, and all OS images we shipped were of satisfactory quality. The project is maturing, and we’re 78% of the way towards completing the beta milestone.

QA & testing

Bhushan Shah and Thomas Duckworth continued working on the project to build a robust and modern automatic QA system. It’s really really close to being integrated at this point, and will act as a full-stack integration test for all of KDE Plasma in addition to a test system for KDE Linux specifically.

More user-friendly installation

Hadi Chokr did the huge amount of work necessary to transform KDE Linux’s .raw image file into a hybrid image that’s also a valid .iso file! This allows KDE Linux to be installed more easily using VM software that often expects to be given an .iso file.

Remember that you’ll still need to turn on UEFI mode, as KDE Linux still intentionally doesn’t support the legacy BIOS system!

Better audio CD ripping

Harald Sitter, Jan Rathmann, and I completed a small project to get KDE’s Audex app up on Flathub as a replacement for the audiocd-kio software we had previously been pre-installing on the image.

The problem with audiocd-kio is that it included two System Settings pages of questionable utility that offered a fairly old-fashioned UX. Now we don’t include those things, and instead we document how to download Audex and use it to rip CDs. And this way, you get automatic metadata lookup, too!

Easier log collection

Felix Araújo built a tool to ease the collection of logs called collect-logs. It also does some data sanitization. This will be very useful for bug reporting purposes!

Rudimentary “Developer Mode”

I created a very simple system to show and hide developer tools, and they’re hidden by default until you run toggle-developer-mode, which is documented here.

This reduces clutter in the launcher widgets of users who aren’t software developers. In the future we’ll add more to this script, and we might consider moving more tools off the base image and into Flatpak apps or even downloadable meta-packages, thereby coming full circle by re-inventing packaging. Go figure.

Documentation

I wrote documentation for how to configure input methods for Chinese, Japanese, Korean, and Vietnamese text input, in consultation with several speakers of these languages.

And in the near future, we plan to pre-install some of these tools to make things easier for the world’s 1.7 billion people who use one of them to communicate on their digital devices.

Grab bag

Thomas Duckworth made Plasma Browser Integration continue to be enabled by default with the latest version of Firefox.

I fixed ydotool, which I had previously broken by trying to force to run as a systemd service. Turns out it can’t do that. So now it’s at least disabled by default.

Yago Raña Gayoso enabled shell completions for kde-builder.

Aleix Pol Gonzalez removed a few pre-installed GTK libraries that it turns out weren’t used for anything.

Vishal Rao prevented the live session from writing to the system’s real-time clock, which could be a nuisance for people who don’t end up installing the OS and go back to their already-installed OS.

Clément Villemur made the Calamares installer not bug you to connect to the internet, because it doesn’t actually need internet access.

And that wraps up June! There are a lot of projects in flight right now, from finishing up the new QA system, to building moving the base OS with BuildStream, to hardening the kernel, to improving each image’s changelogs.

So there’s still lots to do! If you’re a fan of the project, please help out; there are many ways:

The Steam Machine is here!

For a while now, my colleagues and I over in Techpaladin Software have been working on software support for the Steam Machine, so it’s so awesome to see the product released!

Like everyone else, I was surprised by the pricing… until I went out and looked at what other hardware costs these days. It seems like in the past 6 months, everything with RAM got 50-100% more expensive. It’s kinda nuts. In light of, shall we say, industry trends (ahem), the price seems reasonable to me.

…especially if you see it less as a single-purpose gaming console and more as a desktop computer that offers a 10-foot UI living room gaming experience. Its horsepower is competitive for the price, and it offers the flexibility of a well-integrated desktop PC user experience. But don’t take it from me; ask Linus Sebastian, who’s rapidly becoming one of the biggest KDE boosters on YouTube:

Some choice quotes from the video:

And from the moment I fired it up and said “goodbye Steam Big Picture Mode”, and started using it as a desktop, I went… “This is what I’ve been waiting for the whole time.”

– Linus Sebastian

Plasma’s great.

– Linus Sebastian

“Plasma on retail hardware” has been my long-term goal for KDE since I first got involved a decade ago. This product is another example that not only can it work, but it can be as good or better than competing offerings.

So congratulations to everyone in KDE and outside of it who helped make this a reality! I’m unbelievably happy at how well KDE software is working for this use case these days, and I see even greater things in the future.

Techpaladin is hiring again

Time to put on my Techpaladin Software had again: we’re hiring! David Edmundson has already posted it, so I’m here to boost the signal: we need you! Especially if you’ve got experience with Qt/KDE development.

We’re looking for someone with that plus an eye for UX & design, and another person with that plus deep tech skills, particularly around I/O and other “system plumbing” topics.

Check it out: https://techpaladinsoftware.com/joinus.html

Submit a KDE goal!

KDE has now started its fifth round of “goal-setting” — a process that began in 2017.

These goals are big, high-level goals. Think “focus on large strategic topic X” more so than “fix my pet bugs A, B, and C”.

And it’s up to the KDE community to choose the goals! Up to you, up to me, up to all of us. They will then be voted on, with the top three informing KDE’s overall direction for the next two years.

KDE needs you! Your fresh ideas, your contributions, your budding leadership talent. But not your imposter-syndrome-driven fear of coming out of your shell. 🙂 Overcome that!

I’ve now been the champion for two goals: “Usability & Productivity” and “Automate & Systematize Internal Processes“. I’d count the first as pretty successful; the second, less so. So at this point I feel like I have a pretty good idea of what works and what doesn’t, and I’d like to use that knowledge to help others submit their own high-quality actionable goals.

Here’s what works, in my experience:

  • Articulate an immediately obvious large problem or aspiration. If you’ve spent any time in KDE or using KDE software, you’ll have encountered stuff that could be better. Big stuff. That’s the topic to write a goal around! Not “Discover is too slow to refresh when I launch it” but rather “First-class software delivery UX” (you can steal that).
  • Have a technical lead and a communications lead. They can be different people, but you need both. Only have a tech lead? Not enough communication, people forget about it, don’t join, and the tech lead burns out. Only have a comms lead? Not enough work happens and the goal limps embarrassingly towards the finish line.
  • If you propose a goal, be the tech lead. You can be the comms lead too. But you should be prepared to be the tech lead. It’s much easier to recruit people to do other things than it is to recruit a tech lead to do a ton of work on your behalf that you can’t to yourself.
  • Don’t bite off more than you can chew. If you can’t be the tech lead on your idea, scale it back or change its scope so that you can be the tech lead. This doesn’t mean you have to know how to do everything. It just means you can do a big chunk of the technical work, and at least understand the concepts of the things you can’t personally do.

It’s really fun, and you end up having a huge impact on how awesome KDE is.

I’ve submitted a goal proposal about improving KDE’s documentation. Credible choices make voting useful, but right now we have as many submissions as goal slots, and that’s no fun. So get yours in too!