Occasionally I see online comments saying things like, “more bugfixes week after week; KDE must be a real train wreck!” or “15 years of Wayland and it’s still needing bug fixes; it’ll never be ready!”
It can be a bit funny to see people interpret normal code maintenance as evidence of critical bugginess. But this does make some sense; most objects and systems you’re familiar with around your house and in your life don’t require constant fixing to avoid collapsing, right? They have a bounded problem space; the scope of what they’re expected to do is fixed. Your coffee maker just needs to make coffee! Tomorrow you aren’t going to ask it to make juice, and the electrical outlet it plugs into isn’t going to morph overnight into something physically incompatible with the plug. So the people who built that coffee maker just have to make sure it brews coffee correctly and reliably given the current arrangement of the world around it. Its problem space is bounded.
By contrast, the world around a piece of software is constantly changing in ways that it needs to adapt to; it has an unbounded problem space. For example, one of the libraries that the app delegates some of its work to may change in behavior and cause broken features or crashes in the app. A new CPU architecture, display server, or containerization format may be invented and deployed in an exciting new operating system that people are starting to use, so that the app needs to adapt or else not be able to run on the new OS. A new and previously unusual file format may become popular and users will start expecting the app to work with it. And often user expectations themselves change over time, such that if your app doesn’t evolve in its visuals or interaction paradigm, it will feel clunky and obsolete even if it didn’t feel that way when it was first released.
Because of this, constant maintenance is required to prevent software from becoming obsolete and unusable.
There are methods of development that acknowledge this chaos. You can minimize externally-induced bugginess by intentionally limiting the scope of the software, coding defensively, avoiding programming paradigms that impose lot of mental overhead, and not depending on 3rd-party libraries known to be unstable. But even so, the need for maintenance and bug-fixing is eternal. There’s just no real way out of it.
So the fact that we’re making regular fixes to code that was buggy or has become buggy due to external changes is a good thing, not a bad thing. The alternative isn’t “software so good that it requires no bug fixes” but rather “software that bit-rots and stops working over time due to lack of maintenance.”
Adventures in Linux and KDE 
> most objects and systems you’re familiar with around your house and in your life don’t require constant fixing to avoid collapsing, right?
Maybe not constant maintainence — but people who have owned homes (and anyone who’s dealt with a less-than-awesome landlord) knows that living spaces definitely require maintanence to continue to fuction well and remain clean and safe. Sometimes these needs are very sudden; the water heater broke, the faucet stopped airating the water correctly, and at our house recently the fence started falling down so we’re replacing it.
I’m not a software developer, but I tend to think about bug fixes like that — it’s regular maintanence that keeps everything clean and safe. It’s not necessarily the fault of the builder when things go wrong (although worse built houses degrade faster than well-built ones!), and if you own a home (or use software!) you want things to continue to function well for years to come. An ounce of prevention is worth a pound of cure.
LikeLiked by 2 people
You’re absolutely right about these parallels, and an earlier draft included a few house metaphors sprinkled around here and there.
But software has to contend with rapid changes in the surrounding infrastructure in the way that a house generally doesn’t, and so it doesn’t tend to be designed around as long a service life, which makes it require correspondingly more maintenance.
I suppose an uncomfortable similarity would be climate change altering the environment that a building exists in with respect to outside temperatures, severity of storms and floods, the range of wood-destroying insects, and so on. In such a situation, the building will absolutely need as much unexpected maintenance (or even fundamental re-architecting) as a piece of software whose upstream software libraries are buggy.
LikeLiked by 1 person
As part of “the minority of a minority” since ~Q2 2020, I’ve had an overall positive experience on Wayland (even having started with an Nvidia GPU![1]). I did have a couple of compositor crashes, but with a rate lower than about once every trimester between 2 machines I really can’t complain (but will continue rooting for y’all to figure out graceful compositor restart/recovery without force-closing all apps 😇).
Have been a happy customer since ~2001 (nearly full time since ~2006). Thank you and the entire KDE team for your work, your DE really deserves the Kool moniker!
[1]: Have used on Wayland on a Broadwell era Intel iGPU notebook chip, on an Nvidia GTX 1060 6GB, and on two AMD GPUs (6700XT, and the integrated graphics of a Ryzen 3250U notebook chip). Other than night color not working in the Nvidia GPU (which IIRC has been fixed), and feeling the need of forcing Wayland support on specific non-KDE software (particularly Firefox, Chromium, and Electron) it has been remarkably smooth sailing!
LikeLiked by 2 people
Do Contra, did you mean to say you’ve been a happy “kustomer”?
LikeLiked by 1 person
> “15 years of Wayland and it’s still needing bug fixes; it’ll never be ready!”
> It can be a bit funny to see people interpret normal code maintenance as evidence of critical bugginess.
I bet it’s not because code maintenance is interpreted as “evidence of critical bugginess” but because after 15 years KDE’s Wayland still has easy-to-trigger bugs like “drag’n’drop to crash” being listed as newly fixed. In other words, bugs don’t become more obscure like in other compositors with time, they are always at the same level of easy-to-trigger crashes that make KDE’s Wayland feel totally bugged. Maybe splitting kwin into smaller independent pieces (executables) would help with that e.g. effects separately, basic compositing separately, basic window management separately, etc, etc, etc. kwin, plasmashell and QtQuick applications probably use the GPU way more than any other desktop environment what makes KDE be very sensitive to GPU drivers quality which is likely a big source of this instability that is not present on other compositors. Some option that would fully disable GPU usage by Plasma, KDE Frameworks and KDE Gear might be useful (not only kwin’s compositing!), with auto-detection of driver instability like kwin currently does for compositing.
Yeah, this is likely hard to implement but who said that should be easy given KDE’s rich feature set…
LikeLike
The fact that we rely on GPU drivers being stable when they’re clearly not is a concern of mine as well, and definitely contributes to a certain amount of fundamental instability that’s out of our direct control. it’s my hope that Valve ends up being the one to fix this by putting lots and lots of money into GPU driver stability work across the stack, given its obvious relevance to their business model. And it’s already happening–in public, but not widely advertised. So there’s hope there.
The fact that Wayland’s basic architecture requires more stability from the compositor than has ever been required of it before also concerns me from an architectural level. But we’re still fairly early in the Wayland transition and very few distros are shipping Plasma Wayland by default; the Plasma Wayland userbase is a minority of a minority, and everyone uses their system a bit differently, so there are indeed going to be easy-to-reproduce issues until more people use it.
LikeLiked by 2 people
I’m hardly doubt bugless GPU drivers are possible, even Windows has buggy drivers. IMO, no bugless software is possible what means GPU drivers, given their closeness to hardware, will be a source of the weirdest and most annoying bugs forever.
LikeLike
There are times I find myself with these thoughts as well.
“Was it a mistake to go all in on hardware-accelerated rendering for the desktop itself given the inherent instability of GPU drivers and incentive for GPU manufacturers to not support drivers for old cards because they want you to buy newer hardware instead?”
What we demand of the graphics card is usually not that much, and modern CPUs are monstrous powerhouses that are definitely capable of doing it in a bug-free way; when was the last time you were bitten by a CPU driver bug? It’s rare and well-publicized when it happens. The question is how much more power they would draw while doing it.
Mobile GPUs are also quite terrible and we sometimes have to fall back to simpler effects or CPU rendering for some Plasma Mobile UIs.
LikeLike
One reason a lot of commercial software has moved to a subscription based payment model because applications have reached a state of being “finished” and developers have a hard time convincing users to pay for a new version.
What drives advances in software are advances in hardware. PC hardware changes less and less.
For desktop Linux: After completing the transition from X11 (a protocol from the 80ies!) to Wayland, I think we are headed for a boring and stable future.
LikeLiked by 1 person
Pete,
Totally agree with your comment RE Wayland. Linux (generally) has undergone some very large scale changes over the recent years, including the aforementioned Wayland. I would also mention System D and Pipewire. All three of these have IMO improved Linux and more to the point, all three are finally reaching a decent level of stability, and I can’t see them requiring replacement with ‘the new thing’ for a very long time, if ever, which is not to say they won’t be improved but it’s a smaller scale development than wholesale replacement. There’s also the QT6 transition hurdle which is rapidly being overcome.
As a result, I also envisage calmer seas in the near future. Good times.
LikeLiked by 1 person
> After completing the transition from X11 (a protocol from the 80ies!)
TCP/IP is a suite of protocols from 70s. Please stop this argument that Xorg is “old,” it makes no sense.
LikeLike
Like X, TCP/IP(v4) is very much showing its age with well known and understood limitations, and has multiple improved (if not quite outright better) successor protocols (IPv6, SCTP, QUIC[1]). Unlike X, TCP/IP(v4) adapted better to the changing environment, and TCP/IP(v4) has a much bigger installed base and is a lot harder to transition from (to the point where I feel I will most likely still be using it as my main network protocol when I retire ~30-40 years from now).
[1]: It can be very uncharitably described as a hack riding on UDP, but that’s core to the point (and beauty!) of it.
LikeLike
Well put. OTOH, I’ve met more bugs in Dolphin in recent months, than in the past 10 years combined. Not corner cases, but bugs in a file manager’s core functions that trigger every day, e.g. symlinked dirs not refreshing correctly, moving symlink moves the target instead (still waiting for Frameworks 5.109 to fix it)… The quality of this part of KDE has degraded a lot recently. I’m looking at code changes in the past year trying to understand what happened…
LikeLike
It’s unfortunately just the fairly normal thing that happens when a mature yet old and fragile codebase that hasn’t had enough maintenance gets a lot of changes: stuff breaks. Dolphin just needs a lot more code maintenance to support the level of UI and feature work that it’s been getting recently IMO.
But of course that’s no fun! I also think it needs to be ported to newer technologies like QML. This would provide an opportunity to clean up old code, make the new code more maintainable, and increase the contributor base due to the use of more modern, familiar, and approachable technologies.
If this doesn’t happen, I anticipate that Dolphin will instead eventually be replaced with one of the existing QML file managers that are in various states of skunkworks development, because they’ll be 80% as good (i.e. good enough) but 500% easier to maintain and work on.
LikeLike
Hi, Nate. Thanks for keeping us well informed, as always.
Regarding Spectacle, there was a resource I did appreciate to much, but absent, for this version (24.04.3; to cut and detach a region inside capture).
Where can one demand get functional this applet again?
LikeLike