Below is a brief look at recent changes in the KDE projects I work on and follow!
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
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:
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!
By now, many of you have probably seen Linus Tech Tips’ “Linux is Easy, right?” video?
The TL;DW version is that yes, things are mostly pretty easy, and the tasks they’re having trouble are becoming become less and less common over time… but pain points remain for the “prosumer/technology enthusiast” crowd: folks who are moderately to very technical, but aren’t software developers.
KDE comes out pretty well, with one exception: network shares.
Network shares.
Yes, network shares.
Still. In 2026!
What the heck is going on here? How is this not a solved problem? Let’s talk about it today.
When you access a network share from Dolphin’s built-in network share browser, it doesn’t get mounted as a local path somewhere; Dolphin is connecting to the share using its own communication protocol: smb://, nfs://, or similar.
This is fine for KDE apps; they can use those communication protocols to access files when you double-click them on network shares you’ve accessed using Dolphin.
Everything works.
When you double-click a file on a network share and it opens in a non-KDE app, at that point something called kio-fuse (that we did a ton of work to build a few years ago) secretly creates a FUSE mount of the share in the background, and passes the app a local path to the file on the secret FUSE mount.
This way, the non-KDE app opens the file from a local path as it expects, and everything still works.
You caught me! Everything works if you open the file from Dolphin… but what if you need to access a file on the share from the “open” dialog in an app, or save a file to the share using the “save” dialog in an app?
Well, then things get more complicated.
If it’s a KDE app, the standard KDE open/save dialog knows how to access the network share so you can open or save new files there. If you’ve created a bookmark for the share in your Places panel (which is our documented recommendation in KDE Linux), it’s already right there; simply click on it to connect to the share, and navigate to the desired file or location. Easy peasy, everything works.
Sounds great! So where’s the complication? Let’s move on.
If it’s a non-KDE app that uses the KDE open/save dialog, it’s the same deal: access the share from the dialog, everything works. Example apps are VLC and LibreOffice (when run with the Qt backend). Still no complication…
If it’s a non-KDE app that uses the portal-based open/save dialog, then everything is lovely here too. The app asks the XDG Desktop Portal for an open/save dialog; the portal offers up the KDE dialog; everything works. In this respect, Flatpak has been encouraging adoption of the portal-based open/save dialogs, which produces a really nice experience: KDE users get a KDE open/save dialog in almost every Flatpak app — something we’ve all wanted for years!
But now we come to the problem:
If it’s a non-KDE app that uses its own non-KDE open/save dialog… then everything becomes terrible. Its dialog will not see any bookmarks you’ve added to the KDE dialog, and will expect you to have the share mounted locally somewhere. Even if kio-fuse created a mount, the non-KDE dialog doesn’t show it nicely in its sidebar! You have to know the secret location of the mount (/run/user/1000/kio-fuse-[something]) and use the dialog to navigate there manually.
If these apps are packaged traditionally, that’s bad enough. If they’re Flatpaks, it’s worse: they have to be packaged with a hole in the security sandbox that allows them to access the kio-fuse mount, or else you can’t access it even if you know it exists and navigate there manually. Most do this for the location where GNOME’s own system mounts shares… but not for the location where kio-fuse mounts them — nor the location of any shares you’ve manually mounted, for that matter.
In addition, the GTK open/save dialog’s built-in network browsing feature is broken unless the app’s Flatpak packaging pokes another sandbox hole for network access — many don’t! And custom dialogs may not even have this feature at all.
What a mess. Unfortunately, as of June 2026 (if you’re reading this later, please verify), apps in this unfortunate situation include some important ones like Blender, GIMP, LibreOffice (from Flathub or with the GTK backend), OnlyOffice, Inkscape, Audacity, DaVinci Resolve, and Gedit.
So, that’s bad.
If it’s a command-line tool or daemon, then everything is terrible in the same way. All previous use cases involved GUI tools accessing or mounting the network share; until and unless that happens, there’s nothing for CLI tools to see. It’s as if the share doesn’t exist. Something would need to mount the share at login. That something usually ends up being driven by changes to /etc/fstab that a random internet tutorial walked you through.
Well, there are a few problems with this — the first one being that /etc/fstab is root-owned, so using it to mount a network share requires administrator privileges. That’s not gonna fly on multi-user or administrated systems.
You could work around this by using a GUI tool that can modify that file using Polkit, and then ship a Polkit rule to auto-allow this app’s requests to modify the file — even for non-admin users.
If it’s a password-protected share, you’ll also have to store the credentials in plaintext somewhere; there’s no provision for storing them in an encrypted password storage system.
This makes a mockery of security, but even if that’s acceptable, it turns out there isn’t just one way to mount a network share using /etc/fstab, but rather about twelve thousand ways. Every online tutorial gives you a slightly different set of steps, and if you don’t do it just right, you’ll end up with a mount that isn’t writable, or delays the boot process if it’s not accessible at that time, or causes apps to hang and freeze if it becomes inaccessible later, or other non-obvious problems that can be really “fun” to troubleshoot.
It’s not impossible to do this properly, but you have to know what you’re doing. So you really want this file to only be touched by a person or organization that qualifies, and to not make changes to it that you don’t fully understand.
All is not lost. Happily, KDE just received an investment of over €1.2 million from the Sovereign Tech Fund, and it includes funding for improvements to KDE’s network share handling!
Time for full disclosure: KDE e.V. is contracting with my company Techpaladin Software to run this part of the project. Network shares represent a significant paper cut, and I’m really excited to be a part of the process to finally get this topic sorted.
I’m not micromanaging the project; frankly, I don’t have the time, even if I wanted to! So my involvement so far has mostly been to put smart people in charge, gather them together into a (virtual) room where they can be productive, and make sure they’re adequately funded! Which is what I’ve done, and and I have every confidence in the team.
Here are some of the ideas under discussion:
kio-fuse-created network share mounts at their current location.kio-fuse automatically create a mount for it on login, similar to “mapping a drive letter” on Windows.kio-fuse mounts network shares.kio-fuse implementation as a fallback only on systems without systemd.Lots of ideas. Preliminary work has already started, and I expect it to be an ongoing area of focus in the coming months.
So hopefully soon this topic will finally be in the rear-view mirror. I think it’s clear that KDE is not yet 100% there on network shares, and we can do better. And we will!
Welcome to another edition of “This month in KDE Linux” — KDE’s in-progress operating system.
This month we completed a major infrastructure project. Previously, our build process was generating Arch packages for KDE software and having mkosi install them; Hadi Chokr ported this to use KDE’s kde-builder tool to compile all KDE software directly. This change brings three benefits:
Another major focus this month was on improving KDE Linux’s automatic QA story. The project already has a basic “does it boot to the desktop?” test for every build, but we can do much better.
To that effect, Bhushan Shah and Thomas Duckworth worked on finishing up the OpenQA-based testing system prototyped by Kangwei Zhu last year. Once fully integrated, this promises to hugely improve our ability to catch bad builds before they’re released, and we can update it over time to catch even more failure conditions.
Harald Sitter also added a test using the existing system to make sure we don’t ship an image with broken file capabilities. We did ship one bad build that includes a regression here, so this new test ensures that it won’t happen again.
After multiple security issues were discovered in the upstream Linux kernel last month, a few of us (Adrian Vovk, Hadi Chokr, and I) did a mini-audit of insecure and unused software included in KDE Linux. This resulted in a variety of positive changes:
I implemented a service to install any new pre-installed Flatpak apps on people’s existing systems. It ignores any apps you’ve previously uninstalled manually.
Speaking of new Flatpak apps, I replaced KWalletManager and its configuration page in System Settings with the new KeepSecret app, packaged using Flatpak.
I also updated Ark’s nightly Flatpak packaging to include 7-zip support and generally synchronize it with the Flathub version.
I migrated the project’s website and documentation to https://linux.kde.org, where everything lives now. I also added a few more pages.
Hadi Chokr set up /opt/local for being a supported location for installing compiled binaries. This is because the usual /usr/local location is read-only on KDE Linux. This is now documented here.
João Pedro Silva Sousa fixed a bug that could make installation fail if there happened to be two KDE Linux live USB disks plugged in at once.
And that wraps up May! There’s still lots to do, so if you’re a fan of the project, please help out:
My last post about good beginner-friendly KDE-focused operating systems sparked some discussions about the concept of “Long-Term Support” (LTS) releases.
But what does this term mean? It’s a bit generic-sounding, making it easy to interpret as meaning almost anything. So let’s go to the source: how the term is defined by the operating systems using it! Here are the non-commercial ones:
Security updates are provided by Debian security team for three years. This generally means that each stable release is supported for its whole life plus an extra year (or so) after a new version of stable is released. In addition, further security support is provided by the LTS and LTS/Extended projects.
LTS stands for long-term support — which means five years of free security and maintenance updates
The latest Long Term Support (LTS) version of the Kubuntu operating system for desktop PCs and laptops, Kubuntu 26.04 [is] supported with security and maintenance updates, until April 2029.
(I didn’t include openSUSE Leap because its marketing material doesn’t use this term, though what it offers is fairly similar in practice)
So these operating systems are fairly consistent about what “Long-Term Support” means to them:
That’s it! So let’s look at what’s NOT promised:
That doesn’t mean an LTS release of Debian, Ubuntu, or Kubuntu will be devoid of these things. It just means they aren’t promised. Probably you’ll get a lot of them anyway, but there’s no guarantee.
I think this is where some of the persistent confusion around the LTS topic comes from.
LTS releases are fairly reliable as long as you use the most popular software from their included software repositories. So in the circumstances when this stops being the case, I think sometimes people can feel betrayed. They think, “I thought this was supposed to be stable! Why didn’t anyone fix this bug yet? Where’s my long-term support?”
But Debian, Ubuntu, and Kubuntu never promised any level of reliability or absence of bugs. They promised that the version-locked software in their repos would receive security fixes for a certain number of years. Ubuntu and Kubuntu also offered a certain amount of non-guaranteed best-effort hardware compatibility improvements and non-security bug fixes.
That’s it!
So it’s important to understand what you’re actually getting with an LTS-style OS. And maybe it’s not for you. There are plenty of other options for people with different desires:
If you’re a software developer or a technology enthusiast, you may want to get software on or closer to its developers’ release schedules. This will give you a stream of new features, UI improvements, and fixes for bugs. In this case, the better option is a rapidly-updating OS like Arch Linux, openSUSE Tumbleweed, Fedora KDE, or one of their children.
The trade-off here is that you may have to live with some things that are currently working getting broken after updating. In other words, the bugs are unstable, unlike in an LTS OS where the bugs are stable.
I personally fall into this group, which is why I use a rapidly-updating OS and not an LTS OS.
I think a lot of people choose an LTS OS to experience fewer bugs, but this is generally not a strength of the LTS product. When an LTS OS freezes on a specific set of software, all the bugs in those versions of the software are frozen, too. Unless the LTS OS provider fixes any of those bugs themselves or backports fixes for them, users will be exposed to them for the lifetime of the release.
With a rapidly-updating OS, when software developers fix bugs in their software, you’ll get those bug-fixes quickly. As long as the software itself is becoming less buggy over time, a rapidly-updating OS shipping software close to its developers’ release schedules will likewise become less buggy over time.
It’s not all puppies and rainbows, though. A fast pace of change means more opportunities for those developers to accidentally introduce new bugs, and also for the introduction of integration issues: bugs caused by software being mis-configured or incompatible with other software. LTS OSs excel at minimizing integration issues between software, because a frozen set of software isn’t a moving target for QA testing.
So in a lot of ways, this choice boils down to whether you’re more bothered by software bugs or by integration issues.
If the manufacturer of your device didn’t provide much or any Linux software support for it, a rapidly-updating OS is likewise a better option here. You’ll quickly get all the components that improve hardware support, not just the parts in the kernel.
If time is money for you, this makes sense. And to get it, you’ll need to pay for a commercially-supported operating system. For example, Canonical offers “Ubuntu Pro” with a level of support that includes the following:
Build with confidence with 24/7/365 phone and ticket support. Get prompt help when something breaks on any of the packages in the Ubuntu Main and Universe repositories, including the most widely used open source applications and toolchains. Our 24/7 plans now include SLAs not only for initial response times, but also for ongoing follow-up updates ensuring continuous visibility and faster remediation throughout the lifecycle of your support case.
Wow! Now that’s support. It costs $300 per year for workstations (servers are over 5x as much).
Red Hat and SUSE offer similar services at similar prices.
And they aren’t cheap! But if time is money, those prices may look pretty reasonable. And you’ll get to talk to a perky and friendly person over the phone when you encounter a covered problem, and someone will to take direct responsibility for getting a fix delivered.
In principle, these technologies allow an LTS-style OS to offer the best of both worlds: a stable base with apps updating more rapidly.
In practice, what you get is a mixing of both worlds. The base OS retains its LTS characteristics, while apps become rapidly-updating, giving you some exposure to breakage coming from new versions alongside more features, UI improvements, and fixes for existing bugs.
We’re spoiled for choice in our ecosystem, which means everyone can find a free software operating system that matches their needs and desires. But you have to know what those needs and desires are, and also successfully map them to the available options! Hopefully this blog post has helped explain what the LTS-style operating systems offer, and who should use them.
I regularly read questions from new users on Reddit and KDE’s discussion forum asking what Linux-based operating system they should start out with, or asking for help after choosing an unsuitable one.
Inspired by a recent example on Reddit, I decided to write this post for them.
Not for you, O advanced reader who is happily using NixOS, Gentoo, or Hannah Montana Linux! If you’re content, I’d encourage you to do something more useful with the next five minutes of your life. These minutes are for for your friend who’s currently using Windows.
A major problem our corner of the world faces is that there’s absolutely terrible information about which Linux-based operating system to choose when you’re ready to make the move:
https://distrowatch.com/ shows approximately five billion options and provides no real guidance for making a decision.
Asking “what Linux distro should I use” to a search engine, an AI, or YouTube returns a veritable graveyard of bad advice, link-spam blog posts, and interactive “help me choose a distro” websites that will steer you wrong 100% of the time.
Famous YouTuber Linus Sebastian has probably made tens of thousands of dollars repeatedly and somewhat hilariously choosing bad options in front of a camera.
With so little to go on, people can be forgiven for making bad choices. So today I’d like to share my personal recommendations — at least for KDE-centric options! KDE maintains https://kde.org/distributions/, which includes four pretty good ones. But I’m going to be bold and recommend only two of them:
Both Fedora KDE and Kubuntu share a lot of positive traits:
There’s just a lot to like here.
But are Fedora KDE and Kubuntu perfect? No. In particular, both are made from mutable packages assembled on your system. This means:
So, not perfect. But, I think, good enough.
Indeed they do! For whose who aren’t familiar, there’s a new crop of operating systems on the horizon, so-called “immutable” OSs — a terrible term since it implies they’re completely locked down and unchanging, which are not the case.
These operating systems offer some form of a read-only core OS, plus various mechanisms for overlaying software on top of it while preventing the core from being damaged over time. This improves safety around system updates in particular.
Practical options here include Aurora, Fedora Kinoite, Bazzite, Kalpa Desktop, and KDE’s own in-progress KDE Linux. Valve’s highly-successful SteamOS is also in this category, though as of early 2026, it’s not yet intended for general-purpose usage on arbitrary hardware the way the others are.
I feel as strongly that this model of operating system represents the future as I do that said future has not yet fully arrived for everyone.
The truth is, while these OSs solve many longstanding problems in traditional package-based operating systems, they also also introduce a plethora of difficult-to-avoid rough edges and paper cuts for general use. Those who work on these OSs need to smooth out those rough edges before their work can go mainstream. I’m personally involved in an effort to do so for KDE Linux, and I’ll be the first to admit it’s not there yet.
If you already have a preferred OS, you’re not in the target audience for this article. 🙂 You’re opinionated and competent enough that you can probably make anything work, and whatever you’ve ended up using likely perfectly suits your own personal tastes.
New users have none of your skills or opinions; they need a general recommendation for something that’s good enough, safe enough, and not too weird. That’s what I’m writing about here.
To be clear, I’m not saying other Linux-based OSs are bad. On the contrary, many are great, and better in a lot of ways than the two I’ve mentioned. Fedora KDE and Kubuntu have other annoyances beyond just “being made of packages” that I wrote about earlier: neither sets up any kind of emergency rollback system by default; their tentative forays into the realm of Snap and Flatpak as additions to their traditional packages complicate things unnecessarily; and I don’t love their goofy wallpapers. These operating systems could be even better for sure.
But whaddaya gonna do, nothing’s perfect. What I’m saying here is that I think these two are good enough to be the best choices for new users in the KDE world.
Ideally you shouldn’t; you should do your own research and make your own decisions. But that can be hard if you’re starting from square one and you don’t know what to look for!
So I’d say the important part is to look for other options out there that share the same traits I wrote in bold text in the “Choose Fedora KDE or Kubuntu” section. Those are what will make a Linux-based OS easier and more comfortable to adopt.
But no matter what you choose, have fun and see it as an adventure! Switching your operating system out for another one is something most people will never do; you’re automatically an interesting person for even making the effort.
If you run into problems, ask humans for help. Don’t ask AI, and don’t go looking for personal workarounds that will only benefit you and might break in the future. Be a part of the community; learn and grow, and help others do the same.
Good luck!
Recently I went on the Linux User Space show to talk about KDE Linux, business, and everyone’s favorite topic: AI. It was a pretty interesting conversation; check it out:
This is part 3 in my series about email management, with the prior one being about using email client apps. This one is about trying to use email filtering to handle email overload.
It’s a flood — no, a deluge! Hundreds of messages a day. Overwhelming. Demoralizing. Soul-crushing. The thought of even looking at your email provokes anxiety.
What to do?
Email filtering to the rescue! Use sieve (KMail even includes an app for it!) to implement a bevy of server-side filtering rules that send emails to different folders. So neat and tidy. So clean. So organized. So much better… not!
You started with the problem of “I get too much email to comfortably handle”. With filtering, you’ve split up the “too much email” into multiple folders, but all those folders put together are still impossible to comfortably handle.
You may have told yourself that this system helps you prioritize, because the most important emails go to your inbox.
But it’s not true; an email’s importance can have much more to do with its content than the characteristics you’re probably using for filtering (sender, mailing list ID, subject line, etc).
For example:
You commented on a bug report, and then someone else replied to your comment with a question. The email notifying you about their reply got filtered into oblivion, so you missed it, and now that person thinks you’re rudely ignoring them, or negligent, or incompetent. That’s damage both to your reputation, and to KDE’s. This is what leads people to whine “KDE doesn’t care!” on social media.
Also, the properties you filter against change over time, which means mail filtering requires maintenance to keep the important emails in your inbox — maintenance that you’ll eventually tire of doing and neglect.
Which means some important emails will still be shunted away to folders you aren’t checking regularly. Which means you’re still missing them. Which means filtering hasn’t solved the problem of missing emails and being perceived as unreliable or rude.
I get it. Filtering is tempting. But it’s just covering up the actual problem. There are only three real solutions to “too much email”:
For a busy professional like you, email is a task list that other people can add items too.
This is terrible, but it’s also a professional obligation, so you need to block out time to handle those tasks somehow. Yet spending tons of time on it will burn you out!
So minimize this to only what’s absolutely necessary to avoid your inbox becoming more full over time. Make the “number of emails in the inbox” trend-line negative. Which means you need to…
Every minute you put into reducing emails will pay you back 100x over the next few years.
And so on. In the “email as task list” model, you have to reduce the number of people, groups, and companies who can assign you email-tasks, or you’ll go mad. Do it, do it now!
A key part of this is using an email client, which I wrote about earlier. Learn your tools! Use keyboard shortcuts. Aggressively delete and archive emails after you handle them. I like automatic color tagging, which I wrote about back in 2024. There are lots of techniques to process emails faster, and I’ll write about some of them later.
But focus on solving the problem, rather than hiding it.
The important part is to see email as a job skill you can commit to getting better at, just like programming, debugging, or source management using git. Don’t accept that you suck at email, give up, and hide the problem under the rug. Get better! Filtering is a tool that holds you back and prevents you from learning stronger email management skills.
Ditch the filtering habit. It’ll be hard at first, but you can push through that and solve the real problems of too much email, un-optimized workflows, and fear of managing email due to lack of the first two.
You can do it! I believe in you!
Welcome to another edition of “This month in KDE Linux”!
Infrastructure remained a major focus this month, with multiple outages and bugs in Arch’s package archive leading to Harald Sitter creating a local mirror for KDE Linux. This substantially increased build delivery reliability.
Harald also worked on improving the speed of delta updates. This is experimental and in-progress, so you have to opt in; See the bottom of https://community.kde.org/KDE_Linux/Delta#Status
Beyond that, a number of features are under development but did not quite complete yet, so expect to hear about them next month.
This month, Hadi introduced a terminal handler to prompt you to add execute permissions to scripts lacking it when you try to run them:
Hadi also moved our console handling to the newer userspace Kmscon software, which we’re using in place of the built-in console from the Linux kernel. Text looks way better now!
Thomas Duckworth implemented screen reader support for the installer.
Jonas Harer and Daniele Me made the default zsh config even better. It really is a joy to use now!
Aidan turned on IPv6 privacy addressing by default, improving privacy a bit when using IPv6 connections.
I made KDE’s ksshaskpass dialog be the thing that prompts you for the password to unlock your encrypted ssh keys, which also allows you to have it save them in the system’s password storage system if you’d like. I also simplified the process of setting up an ssh agent to automatically add your keys, and documented how to flip the final switch to turn it all on.
I also documented how to persistently change kernel parameters, in case you need some extra ones (for example, turning on the experimental Xe driver for your newer Intel GPU).
Finally, I flipped the switch to have KDE Linux use the new Union theming system by default for QML apps. If the results in non-Flatpak QML apps like Discover, System Settings, Info Center, and Emoji Picker look no different… that’s perfect!
That’s all for April, folks! I’ll see everyone for the May report, or ideally, sooner. Because, as you can see, while KDE Linux is being developed by multiple people (good for project health), the number of changes is a bit low (bad for project velocity). There’s plenty to do, so if you’re a fan of the project, please help out:
And if you’re already using KDE Linux, let us know how your experience has been! Is it good? What can we do better?
One of the many benefits of going to in-person sprints is you get to see how other people use their computers, and you can learn some workflow tricks from them. Or, you might notice areas of inefficiency and share tips of your own.
This post will be about the latter, on the subject of email.
Because during the sprint, I observed multiple people using email on their laptops in ways that are slow or ineffective:
If you recognize yourself here, there’s a better way, I promise. 🙂 And I’d like to help you achieve it!
Back in 2024, I wrote about my email workflow and offered some general tips for managing email overload in KDE. I’m going to write more in depth about this topic, today starting with…
Use an email client app.
KDE has one: KMail. If it works well for you, use it! If it doesn’t, use Thunderbird instead, it’s fine. Don’t feel guilty for not using a piece of KDE software. Nobody’s gonna excommunicate you from KDE! I’m officially giving you permission.
Maybe you use an email client on your desktop but haven’t set one up on your travel laptop yet? Well, it’s time!
Because the important part is to consistently use an email client app of some sort. Why?
Most of us have 2 or more email accounts. With webmail, this becomes a pain that scales linearly with the number of accounts.
With an email client app, you can manage multiple accounts’ worth of emails in one UI. When all your accounts are managed from one app, your brain doesn’t need to learn and remember multiple UIs, and and opening new email accounts doesn’t scale the mental burden at all.
An email client app lets you interact with emails using learnable and consistent keyboard shortcuts. Processing emails this way is super fast, so you can get done quickly and go back to something useful. Email sucks; life’s too short to waste time on it.
You can access the email client app easily using the Task Switcher, Overview, or Alt+Tab, rather than letting those webmail tabs get buried among your 75 normal browser tabs and 10 pinned tabs.
Quit the email client app when you want to stop receiving emails.
For webmail, you’re tempted to leave it open in a tab forever, which means to avoid being constantly tortured with email notification, you’ll have to turn them off entirely, so you stop noticing emails when they arrive. This is problematic for the “keep my email open all day” approach where the whole point is being able to action new emails immediately so they don’t pile up.
Using an app that can be turned off also facilitates being a “check email once a day” kind of person, if that’s your jam. Open the app, check your email, action the important ones, delete or archive all of them, then close the app. You can carve out 5-20 minutes for email, be free of email for the rest of the day, and still keep on top of everything!
Imagine trying to manage versions or debug code without git or gdb. It would take ages and the results wouldn’t be as good. Proficiency with these tools makes you feel like a bird soaring above the clouds or a wizard effortlessly wielding powerful magic, not some clod stumbling around in the mud.
Email clients are the same way. Learn powerful tools to bolster your professional skills and feel better about the process of participating in KDE, not just the outcomes.
The Thunderbird email client is the foundation of my email system. In conjunction with other techniques — which I briefly described in the earlier post and will flesh out in more detail over the coming weeks — this is currently my email situation:
Those are all of my emails across 5 accounts. Here are just my KDE emails:
As you can see, this is completely manageable. It takes practically no effort to keep it this way, and there’s no feeling of dread when checking emails in the morning. If you’re drowning in email, you can get here too, I promise.
It starts with using an email client. If you aren’t regularly using one yet, it will take some up-front work, and some re-training, but it’s worth it: you’ll spend less time and mental resources on email and more of it on what actually matters — without taking the easy path of neglecting email and being perceived as a person who’s hard to contact or unreliable.
So get started today with KMail or Thunderbird!
Adventures in Linux and KDE 