I’d like to draw attention to a fairly new wiki page that might be of interest to both packagers and users of DIY-style distros like Arch Linux: our Packaging Recommendations. This page is a reference for how Plasma developers would like to see Plasma set up, and it goes over topics like packages to pre-install by default, packages to avoid, and recommended system configuration tweaks.
This data comes from years of experience with distros that didn’t ship a complete Plasma experience, not out of malice or neglect, but rather because it’s really hard to know the full list of things to do and install! Most of us have had the experience of distro-hopping, only to discover that some issue that was solved in one distro is present in another. Maybe you gained video thumbnails by default after switching, but KDE Connect stopped working, or maybe color Emojis started working but Samba sharing broke. Not fun! This page aims to solve that by providing a reference of how to ship and configure Plasma vis-a-vis these topics for an optimal user experience.
So if you’re a KDE packager, please have a look and adjust your packaging if you find that you’re currently missing anything!
We can ignore the argument to which this is a response, and forgive alcade for confusing the name of the community with the desktop environment. Regardless, “KDE is normal and it works” is in a nutshell what I think makes KDE Plasma such a unique and shining point of light in the FOSS world.
Plasma uses a normal, familiar layout: Panel on the bottom with an app launcher, pinned apps, system tray, and clock; desktop icons; visible buttons that mostly have text labels; minimize/maximize/close buttons on windows. You know, normal stuff. You can change everything, but it starts out normal, unlike other desktop environment projects that are explicitly abnormal–being controversially opinionated about matters of design or having an unusual component layout. This is fine! Their departures from what’s normal may in fact be better, and their developers and users they certainly think so. But tons of people out there don’t want “may be better”, they want “normal.” And that’s fine too. Our software is for them.
And KDE Plasma works. It has its bugs, but it is basically a solid and reliable piece of technology that isn’t missing major features, either because of a lack of resources or because design decisions preclude supporting them. It is not a hobbyist science project missing key functionality that might break entirely. It doesn’t re-invent itself every year or two and become something different that might stop meeting your needs or tastes. It has actionable plans for adapting to industry changes surrounding it that are actively being carried out; it is not on a path to become obsolete or a technical dead end. No, it’s just it’s an imperfect and boring piece of infrastructure you can nonetheless rely on.
I think the world needs something with those characteristics, and and that’s why I like it and work on it.
If you’re here for just the KDE-specific stuff, feel free to skip this post.
I used to have a desktop and a laptop. But in the end I found that having only a single machine greatly simplified everything and increased my productivity. This is it:
The biggest problem was always keeping files in sync.
Assuming you’re more than just a consumer of online content, you probably have local files for things that are important to you: school work; in-progress projects; creative pursuits; family photos; a personal music collection; source code repos; saved memes–you name it. With more than one computer, you need to figure out a way to keep these files in sync, and good solutions are elusive.
Cloud services are expensive and may compromise your privacy. Free non-cloud local sync services only work when both machines are on the same network. Any FOSS versions of these are unfortunately buggy and a chore to set up and maintain. Even if your chosen sync solution works perfectly (which it never does), you have to deal with the headaches of:
Inevitable sync conflicts
The set of files on one computer exceeding the storage capacity of another one
A necessary delay before you can work on files which the sync service is still updating after you turn on a computer that was turned off while changes were made on another computer
Resisting the temptation to pause syncing when something goes wrong, because you will forget to turn it back on, causing each computer’s files to drift out of sync and making reconciliation that much harder later
If you opt to forgo sync services and instead store common or shared files on a server (say, music or movies), this worsens the problem because now you have an additional location of files to manage, and you acquire the challenge of how to either safely access the files when not on the server’s local network, or automatically keep cached local copies in sync.
Giving up and keeping differing sets of files on each computers defeats one of the advantages of having multiple computers, and makes file management a real nightmare because you will somehow never have the file you want on the computer you happen to be using at any given time.
There’s just no good way out here, at least not that I’ve found.
In the end I settled on using a single computer–a powerful, top-of-the-line laptop. This can do everything a desktop can do–albeit more slowly–but it has the portability I need for travel and working from multiple locations. Interestingly, one really nice laptop that doesn’t need an external screen, mouse, or speakers turns out to be generally cheaper than two decent computers with all their associated peripherals. The only problem is finding one, because the range of high-end PC laptops kind of stinks, unfortunately. More on that tomorrow.
Bug triaging is a largely invisible and often thankless task. But it’s the foundation of quality in our software offerings. Every day, our users file between 30 and 50 bug reports on https://bugs.kde.org, and often up to 100 right after a big release! Many will be duplicates of pre-existing issues and need to be marked as such. Quite a few will be caused by issues outside of KDE’s control and this also needs to be marked as such. Many will be crash reports with missing or useless backtraces, and their reporters need to be asked to add the missing information to make the bug report actionable. And the rest need to be prioritized, moved to the right component, tagged appropriately, and eventually fixed.
All of this sounds pretty boring. And, to be honest, sometimes it is (I’m really selling this, right?). But it’s critically important to everything we do. Because when it’s not done properly:
Users don’t feel listened to, and start trashing us and our software on social media.
Critical regressions in new releases get missed and are still visible when reviewers check out the new version, so they also trash it in high-profile tech articles and videos.
Un-actionable bug reports pile up and obscure real issues, so developers are less likely to notice them and fix them.
Bugs that occur over and over again don’t accumulate dozens of duplicates, don’t look important enough to prioritize, and therefore don’t get fixed.
Easy-to-fix bugs don’t get fixed by anyone and it’s pretty embarrassing.
Do you see a pattern? Most of these results end up with KDE software being buggier and KDE’s reputation being damaged. It’s not an accident that KDE’s software is less buggy than ever before that that we enjoy a good reputation today. These positive developments are driven by everyone involved, but they rest upon an invisible foundation of good bug triage. And as KDE software becomes more popular, users file more bug reports. So the need for bug triage constantly grows. Currently it is done by just a few people, and we need help. Your help! And it will truly be helpful! If you are a meticulous, detail-oriented person with some technical inclination but no programming ability, triaging bug reports may just be the best way to help KDE. If this sounds like something you’d like to get involved with, go over to https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging and give it a read! I would be happy to offer personal bug triaging mentorship, too. Just click the “Contact me” link here or at the top of the page and I’ll help you get started.
This is a new rendering backend for Firefox that’s not yet on by default. Presumably there are some edge cases where it makes things worse or causes some instability, but so far I have not experienced anything bad. On the contrary, without it, I and some other people get terrible flickering in Firefox on Wayland. With it enabled, not only is the flickering gone, but scrolling performance becomes buttery smooth and CPU usage decreases noticeably on both Wayland and X11, resulting in increased battery life! Win-win-win.
To turn it on, visit the about:config page in Firefox, search for “gfx.webrender.all”, and set it to true. That’s all there is to it!
Howdy everyone! So many folks have asked me to set up a Patreon page that I’ve gone and done it: https://www.patreon.com/ngraham
By supporting me on Patreon, you’re helping me provide the focus, direction, support, and technical contributions that work to turn the KDE software suite into a lean, mean, bug-free productivity machine, and get it distributed well so that our users have great options for getting our software.
Of course, I’m only one man; what really matters is not me, but rather you! KDE’s greatest strength is its passionate community of developers and users, who work tirelessly to develop, improve, polish, promote, and use KDE software. I truly couldn’t do this without all of you, and in fact, I wouldn’t even want to! All of you are the reason why I work so hard on KDE software. Thank you, so very much.
Today KDE released Plasma 5.12 with Long Term Support–the culmination of more than a year of work. It’s really awesome, and we think you’ll love it!
But how do you get it!?
It all depends on your distro! Let’s look at Linux distros today.
What makes a distro a distro?
Today it’s mostly the choice of release model. “Stable release” distros like Ubuntu and Linux Mint lock everything to a specific version, only offering feature upgrades only when a new major version of the distro is released. “Rolling release” distros like Arch and openSUSE Tumbleweed give you everything as close to the developers’ schedules as possible.
Each model has drawbacks:
Stable release distros will often saddle users with ancient, years-old software. For example, users of Debian Stable might not get to experience KDE Plasma 5.12 for another 2 or 3 years–or even longer.
Rolling release distros expose users to the latest version of everything, turning them into QA. Underlying system libraries often change and break apps that use them. The breakage is usually fixed quickly, but users are exposed to it in the first place.
Certain distros additionally try to go beyond mere packaging and releasing, and actually try to ensure some QA and polish in the final product. Distros like Ubuntu, Linux Mint, Manjaro, and Elementary that follow this model quickly rocket up to the top of the popularity pyramid. Users are desperate for distros with better QA and polish!
But it’s exhausting; if you package all the software, you’re responsible for it too. It’s a huge job, even for distros that base themselves on others, as they find themselves having to patch on top of patches, and manage two release cycles (their own, and the parent distro’s). Turnover and burnout are common.
Flatpak and Snap to the rescue
Flatpack or Snap provide the solution: 3rd party packaging. Instead of the distros doing the packaging, it comes either straight from the developers, or from a 3rd-party intermediary like Flathub.
For distros, the benefits are enormous: liberated from the grunt work chores of packaging and patching software, distros will be free to step wholeheartedly into their natural roles as arbiters of the final user experience, concentrating on impactful tasks like integrating diverse components, managing hardware support, performing QA, polishing the final product, and delivering it to users in an easy-to access manner. Fixes and patches can be submitted upstream, instead of duplicated locally. This is KDE’s relationship to Qt, in fact. It works great.
Snap and Flatpak also improve things for users and developers:
Users get to choose whether they want each app to be stable, up-to-date, or cutting-edge according to their preferences, and they get a clear chain of responsibility when there’s a bug.
Developers get to package their apps only once to make them available to everyone, and get to determine for themselves their software’s presentation, branding, and release schedule–rather than hoping that packagers for 500 different Linux distros do it for them, and then having to deal with bug reports about versions of their software that are years old.
Ultimately, Flatpak or Snap liberate us from the tyranny of low-quality distros that make Linux software look bad because they don’t do QA, integration, or UX testing to make sure that the final product is of high quality. Many will rightly vanish because they’re not providing much value for users or generating enough developer interest to continue existing. Once this happens, developers and users will gather around the smaller number of remaining distros, increasing each of their levels of manpower and user bases.
So no, distros don’t go away. In fact, the distros that are worth keeping will be able to focus on tasks that offer more value to users than mere software packaging. Far from erasing diversity, this will empower real and meaningful diversity–where we have a handful of really good and strongly differentiated distros whose products embody different philosophies, instead of an overwhelming number of mediocre distros with often only minimal differences, none of which really work well once you dig deeply. We’ll all win, and all of these vastly superior distros will be far stronger contenders when compared to Windows, macOS, and ChromeOS.
How you can help
There are many ways for you to help enter this brave new world of actual QA and polished products.
Users: If your favorite app offers a Flatpak or Snap version, use it! Quite a lot do. If you find problems, file bugs! If you find an app listing in KDE Discover or GNOME Software that doesn’t look good, submit better information! If you find cases where duplicate apps appear when browsing, submit patches to fix it!
Distro developers: don’t fight Flatpak or Snap; embrace them (and Flathub) and liberate yourself from packaging chores. Focus less on packaging software for your users, and more on performing the QA necessary to make sure that that software actually works well.
This feature was implemented by one of our newer contributors, Andreas Krutzler, who’s already making a name for himself with some high-quality work on Dolphin. Great Job, Andreas!
Sometimes our labors can seem a bit abstract, but as the above screenshot shows, it makes a difference. Our software gets used every day by millions of real people with real needs, frustrations, challenges, and triumphs.
And for potential and current financial contributors: your donations make a huge difference, and we notice these kinds of messages. This support and encouragement is the wind in our sails.
A longstanding complaint about KDE Plasma is that it’s a pain in the butt to stream videos that are located on Samba shares. It’s a usability issue for sure. I’d like to talk a bit about the origins of the problem and how I helped drive a solution.
Background
For KDE Plasma and apps, the KIO framework is responsible for file access and I/O–including files on Samba shares. Software that uses KIO gets this for free; for other software, KIO can either download the file locally before giving it to the program, or else give the program a Samba URL (e.g. smb://share/path/to/file.avi) and let the program figure out what to do.
That leaves 3rd party software, like VLC and MPV. These two don’t use KIO, but they do have Samba clients built in, so they’re able to handle the Samba URLs that KIO gives them!
The problem
…Unless the share is password-protected. In this case, the password must be added to the URL, like this: smb://user:password@share/path/to/file.avi. KIO won’t do that because tossing around user passwords in plaintext is an obvious security problem. So it’s up to the video players to either ask the user for the password to the Samba share, or look it up in the user’s KWallet.
The solution
Ideally, KIO would mount remote locations like Samba shares to a local path using FUSE, and then provide that path to non-KDE apps, which is what GNOME’s GVFs does (and why it works without drama in most GTK-based desktop environments). This would let any video player work with with no modifications, but that’s a task I’m not qualified to tackle, so I decided to attack the problem from another angle: make the most popular video players integrate with KWallet so they can prompt for the password and store it in the user’s wallet.
Apparently I was the first person to test the feature in VLC 3.0 beta builds. The VLC developers were a joy to work with, and soon enough, both issues were resolved! I re-tested with later builds and verified the fixes.
Behold, the power of QA!
Once VLC 3.0 is out, KDE Plasma users should be able to play videos located on Samba shares accessed with Dolphin. The first time you do it, VLC will ask you for the Samba share’s password:
After that, VLC will look up the password in your KWallet and you’ll never need to think about it ever again.
Lessons learned
QA is important. If people don’t test features, apps could ship broken.
Users like us are the QA. Most Linux software is not developed and sold commercially, and even distros with commercial backing do not have the resources to test most pre-release software. If we don’t test beta versions of our favorite software, we’ll end up doing it after the release once users are disappointed by bugs and broken features.
The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be. All of this was made possible because the VLC developers provide an Ubuntu PPA with nightly builds, so testing pre-release versions was easy and painless. This is great for Ubuntu users like me, but what about users of Debian, Arch, openSUSE, Fedora, or distros based on them? Had I been one of those users, I probably would have given up on doing this kind of testing.
This is why our work in Discover to make it easy to switch app versions is so important for the future. When every app has beta builds available with only a few clicks in a centralized location with a consistent interface, any user can easily become a beta tester.
Like what you see? Please consider testing beta builds of your favorite software and filing high-quality bugs if you find any issues–even ones that seem so obvious that you can’t imagine that the developers could have missed them. They might only be obvious on your hardware or with your use case! We may not pay for most of our software with money, but that just means developers need our time instead. The price of freedom is eternal QA.
Adventures in Linux and KDE 