For many years now, I and others have been working on getting plasmashell’s open bug reports as accurate and actionable as possible.
We’ve made tremendous progress, driving down the number of unconfirmed bug reports to its lowest levels in over a decade, and mostly keeping it there:
In case you’re worried about the “confirmed” count rising, it includes almost 800 feature requests. The actual number of known and confirmed bugs is about 1,100, and is not consistently rising. Also, the big spike was from a mass move of bug reports into plasmashell to make it easier to centrally track shell bugs over time.
Right now we’re at a point where we’re down to about 160 unconfirmed reports, and we need your help to get that down as close to 0 as possible.
Why do we need your help?
Because most of the remaining unconfirmed bugs are really hard to reproduce and confirm. They can only be understood or reproduced by someone with specialized hardware, uncommon software, specialized configurations, specific VPN setups, domain-specific knowledge, and so on. Others were reported in a state where the author doesn’t know how to reproduce the issue and none of us has been able to, either.
The addition of your valuable eyeballs and brains can help figure out what the heck is going on in these reports!
Figure out the pattern for issues that are reported to happen “randomly” or “sometimes”.
If you have the hardware, configuration, or specialized software necessary to try to reproduce an issue described as specific to it, try.
If you’re familiar with upstream software like the Qt, PipeWire, Bluez, graphics drivers or the Linux kernel, help identify bug reports whose issue is upstream of KDE.
What it takes
Use the latest released version of Plasma. that’s 6.7.4 as of the time of writing. A distro that uses git master versions of things is even better.
Use a distro that ships KDE software as “vanilla” as possible, with a minimum of distro-specific customizations. Either as your daily driver, or in a VM. Arch Linux and KDE Linux are good options here, and Fedora KDE is okay too. Highly opinionated distros can still work, but are not as ideal for bug triage.
And that’s it! Bug triaging help is really appreciated here.
I would absolutely love it if we could get the number of UNCONFIRMED plasmashell bugs down to 0, and then keep them that way by pouncing on every single new one as it comes in.
You can help make that possible! Thanks, everyone.
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!
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”
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:
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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!
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.
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.
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.
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:
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.
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.
Adventures in Linux and KDE 