Hi Steve, hi everyone,

Steve Litt - 11.07.24, 04:05:50 CEST:
> Martin Steigerwald said on Wed, 10 Jul 2024 19:46:36 +0200
> >Steve Litt - 10.07.24, 18:42:59 CEST:
> >> dbus. Also, it's got so much stuff interacting with each other that
> >> it's a resource hog, and if your computer is at all flaky, KDE will
> >> make it flake much more often. Imagine you've opened Chromium tabs
> >> for Javacript piggy sites Buick.Com, Ford.Com, Chevy.Com, Jeep.Com
> >> and Dodge.Com. In the best of situations your computer will be slow
> >> and maybe glitchy. Now throw in the KDE resource hog, and watch your
> >> problems multiply.
> >
> >That KDE is a resource hog is a myth.
>
> Here's what I know from personal experience...

Thanks for sharing your experience, Steve. I appreciate it! I will first be
relating to it and then be sharing some of my experience.

> In the early 00's my old, poorly provisioned and glitchy travelling
> mid-tower used KDE and could not make it the whole way through a
> demonstration or presentation. I replaced KDE with IceWM and it became
> a very capable machine.

And thus you concluded its all KDE's fault, instead of actually looking at
the poorly provisioned and glitchy bits of the mid-tower?

> In the early 10's a KDE app, I think Kmail, produced instances of
> dbus-daemon that consumed well over 90% of CPU. I had to create a
> looping daemon that, if dbus-daemon was over 90% twice in 3 seconds,
> killed dbus-daemon.

2010 onwards? Well that is what I mentioned. Should at least have been
KMail from KDE SC 4, i.e. Akonadi based KMail and you confirmed it to be
Akonadi based below.

I mentioned Akonadi in my previous mail. I consider Akonadi to be
unreliable and yes, especially with indexing of lots of mails, a resource
hog. And yes, it did and unfortunately does a lot of useless work. Search
for bug reports I opened about it on https:/bugs.kde.org. It has been
completely ridiculous at times. I often enough freaked out regarding
Akonadi and still do at times. One of the most annoying software solutions
I ever came across and thus, Steve, I completely get your frustration with
it! Entirely! And yes, I have seen DBUS storms with Akonadi as well. So
actually, Steve, absolutely no disagreement here! I wrote that I consider
Akonadi quite broken before.

But Akonadi != KDE. What I object to is your across the board assessment
of KDE. Actually KDE is not even a specific term anymore when it comes to
what software it means. KDE these days refers more to a community than
anything else – one of the most welcoming communities I came across so
far. Plasma desktop is a more specific term and mind you, with Plasma
Mobile it is even running on so called Smartphones with 4 GiB of RAM or
maybe even less. *With* SQLite3 based Akonadi.

But still: Akonadi has severe issues, there is no doubt for me about that.
They even know it. See for example their "Make Indexing Great Again":

https://invent.kde.org/groups/pim/-/milestones/9#tab-issues

I hope they can finally complete this year long on and off ongoing effort. It
would fix a huge lot of issues with Akonadi.

But also their POP3 implementation is kind of broken with lots of delays.
I know it, cause I still use it – hoping for betterment for maybe to long
already:

https://invent.kde.org/pim/pim-technical-roadmap/-/issues/36

So really, Steve, no disagreement here.

But that does not mean that *all* of the KDE products are resource hogs.
*Far from it*! There is for example Konsole which is one of the fastest
terminal emulators available for Linux these days. Sure they trick a bit
regarding output of quickly scrolling text by omitting what the user
cannot follow so quickly anyway, but even aside from that their text
output speed AFAIK is among the fastest you can have. And due to the
modularity it is the same fast speed everywhere a console can be embedded
to.

I am still with KMail cause despite the broken foundation I consider KMail
to be one of the best GUI based mail clients available *anywhere*. To
explain why would be another longer story and the mail is already long
enough. I use Evolution for work and must say I am also impressed by
Evolution. It is rock stable and their foundation is much more reliable
than Akonadi is. Number one priority for Akonadi IMHO for me would be
fixing it. However the few developers mainly, not completely, but mainly I
think work on Akonadi in their free time. So it is their decision what
they work on. And unless I pay for specific development work I have no say
in it.

> Kmail2 was a showcase for the KDE philosophy: "Include everything you
> can, and bind as tightly as you can with the most complex interfaces
> you can." All of a second there was a conspicuous time and CPU
> consuming Akonadi, and some gigantic pig named Nepomuk. And don't
> forget that the 1.6GB soprano-virtuoso.db file.

I even at least partly agree with that one. Still that assessment is in
part due to KMail being rebased on top of Akonadi. The idea behind it is
sound. Have the background things done in the background keeping the front
end application responsive at all times. Cause KMail from KDE 3 was not.
If it had to rebuild one of its index files, it was *completely* blocked.
For minutes! But as you and I experienced and I can say its still an issue
with KDEPIM and Akonadi 5: they did not achieve their goals. Not even
close! KMail can be unresponsive for *minutes* at times, cause of Akonadi
and nothing else than Akonadi. Akonadi for example has the severe
limitation that background activity like indexing mail can and *will* (!)
block foreground activity. But it will also block with POP3 mail retrieval
for some crazy reasons no one knows yet. And this completely abolishes the
goal of all time responsiveness within KMail.

Nepomuk is long gone. There is not even a trace of Nepomuk left within
current Plasma and KDE Gear as far as I am aware. But yeah that Nepomuk
Soprano Virtuoso thing was a mistake considering the extremely bad user
experience. It caused a lot of harm to the reputation of software from the
KDE project. Again the idea behind it was not really bad. But they wanted
too much without really thinking it through to the end and knowing enough
of the stuff – like Virtuoso / Soprano – they started to use. Similar as
with Akonadi. Before deciding to use MySQL and then MariaDB or optional
PostgreSQL as their foundation they should have thought through what that
means for the user. I argue that nowadays either you use SQLite3 or some
other zero maintenance embedded database or do not use a database for a
mail client and PIM solution at all. You cannot require that users become
database administrators. I use PostgreSQL and upgraded the cluster with
the Akonadi databases manually several times. They never managed to shield
users completely from database administration work. With SQLite3 I'd argue
that is possible. Firefox uses a ton of SQLite3 databases. You could run
some maintenance tasks like purging stale data from them. But it is hardly
ever needed. The photo/image collection manager Digikam by default uses
SQLite3 databases. Absolutely no issue there either. My Quassel IRC core
instance has a 1,5 GiB SQLite 3 database on the server. No issue either.
Fortunately it is planned to make SQLite backend the default in the
future. So in a sense Akonadi was kind of over engineered.

But also in general related to your KDE based software experience: Early
2010's is not today. KDE SC 4 is long, long, long gone.

If you tried a KDE based desktop in the early KDE SC 4 days… Yes: It has
been kind of an experimental desktop. Anything before KDE SC 4.2 or so was
a pain to use.

*But these days are long gone*.

> My philosophy is "make everything as simple as possible". KDE's
> philosophy is "weld in everything you possibly can".

No. Again an across the board statement that in its entirety is not an
accurate assessment. With the introduction of KDE Frameworks they
introduced a level of clarity and modularity that I find to be unparalleled
in the world of integrated desktop solutions. The LXQt desktop which is
based to a good degree on KDE Frameworks is a living example of that. I'd
argue an LXQt based integrated desktop without Akonadi and also Baloo
would be similarly lightweight as an icewm based one.

For example about DBUS. They work at making it officially possible to run
Plasma *without* DBUS:

https://kde.org/announcements/frameworks/6/6.4.0/

Their reasoning is interesting:

"per default ON on Linux & BSD systems
off for other stuff: win/mac/android/haiku"

https://invent.kde.org/frameworks/kconfig/-/commit/
9082d57024b4ae216e282ffaa43b2cff200a5414

Yes, you read that right: Haiku. That BeOS successor I never tried so far.
I believe it might be a quite beautiful operating system. And it would be
a lot simpler than Linux these times. Very likely much more Amiga like.

Try that with GNOME… I'd say.

And sure, if you put together your own icewm oder whatever wm based
solution you can likely have a quite a bit simpler and more lightweight
solution than Plasma. But it will also not have many of the usability
features I rely on.

> I suppose it's possible that in the 12 years I haven't used KDE that
> they've somehow made it simple and more modular. But it's really not
> worth the time to find out. If they've simplified, they'd be the only
> software project to do so.

That is indeed entirely your decision on what you spent your time on.

And yes, maybe I should have ditched KMail for its broken foundation. But
I love the application for various reasons that could form part of another
long mail. Still hoping they fix up the foundation one day. Maybe I have
been waiting too long already.

My plea is just for more accurate assessments than across the board
statements. If you decide not to look at the current state of KDE
products… then please consider whether stating "Now throw in the KDE
resource hog" is a fair assessment to make.

I am really a bit tired of these binary all or nothing statements.
Especially when they are not even based on the current situation but on
experiences more than 10 years ago.

Do we really need to throw everything into one bag before even looking
carefully on what we throw where? I think we can do better than that.

I am not arguing that Plasma is right for everyone. That is not up to me
to decide anyway. That is part of the reason you have the choice on Linux.
Go with what works best for you(TM).

> The last time I used KDE it was a horrendous resource hog, and
> I didn't need a top or vmstat command to tell me so: A stop watch was
> sufficient.

Except for what I mentioned like Akonadi and probably to some extent also
Baloo still… I am hardly waiting on anything here – with any of the
current laptops or even tablets I run Plasma on. So as a closing statement
let me state some of my longer term experience with KDE based software:

With KDE 3 on an old Intel Nehalem based Dell Workstation I had uptimes of
several months – of course with hibernation aka suspend to disk cycles
over night. I do not think this workstation has more than 4 GiB of RAM.
Running "who" in June for example revealed that I logged into my KDE 3
desktop in April! That is right: One desktop session for several months!
Absolutely no problem. I am quite sure a current Plasma 5 desktop can
achieve similar uptimes in *one* session.

As written above early KDE SC 4 was kind of broken indeed, but I did see
this with later KDE SC 4 based sessions and especially with Plasma 5
sessions as well. AFAIR they removed Nepomuk / Virtuoso during KDE SC
versions already. Sadly they never either fixed up Akonadi completely or
replaced it with something else. There has been an approach about
rethinking all of this and even there is an implementation with an IMAP
based client called Kube. They completely replaced what is underneath with
something much more simple and very likely much faster than Akonadi. I say
very likely cause I never tested this. But I thought they had a fair point
here and put a lot of effort and thought into getting it right this time.
Sadly there have never been an agreement of the complete PIM developer
team which is actually quite small.

https://invent.kde.org/pim/kube

Sadly their project web page seems out of order: https://kube-project.com/

I'd probably look at whether to base a mail client on notmuch these days.
Other than that I hope with their move to SQLite3 and fixing up indexing
Akonadi will be much much better than it currently is.

About replacing Akonadi. It is difficult. Cause KMail is actually used by
several public authorities within Germany. For example for their top notch
support of crypto stuff like GnuPG and S/MIME which is completely native
within KMail. AFAIK it is unparalleled. No other mail client does crypto
as well as KMail. There have been quite a bit of tax funded development
work on KMail and Co. Unfortunately none of that funded work did fix up the
core issues with Akonadi. Those I mentioned and those I did not mention.
Does it work well enough for their use cases? I do not know. However this
means whatever changes they make, they need to make sure to kind of
automatically migrate user data around.

With the new ThinkPad T14 AMD Gen 5 laptop I am having uptimes of several
days with hibernation cycles in between as well. And when it eventually
breaks it is not the Plasma desktop breaking. But the recent Linux kernels
have a ton of regressions regarding hibernation. Hibernation has been and
is quite likely still completely broken on the Gen 1 laptop. And Linux
support for the newer Gen 5 laptop is not yet fully complete. Talk about
complexity in that area! To have some degree of complexity within a
desktop environment is one thing, but nowadays if you look at the
complexity at the lower level software down to the kernel and firmware… its
crazy. And you have that complexity even with just an icewm on top. It may
be more unlikely to run into bugs of lower level software with icewm as
for example icewm would not utility hardware assisted 3D acceleration for
compositing I assume… but it can still happen.

And I have it on a ThinkPad X1 Gen 1 tables with 8 GiB of RAM with an
Intel ultra low power processor. Absolutely no problem except for lack of
support and in some aspects stability from the side of the Linux kernel. I
plan to put it on a Shiftphone 6mq.

The Trinity desktop people argue that KDE 3 was the best KDE and continue
developing on this one. They do have a point there in a sense cause again
early KDE SC 4 was kind of broken.

However my current assessment is that Plasma 5, if you avoid certain
things like Akonadi and maybe in certain situations indexing file contents
with Baloo, on a well made distribution is 1. rock stable and 2. quite
resource efficient. I had it installed on quite old Fujitsu laptop with 6
GiB RAM. Absolutely no problem. Not even with a Signal app running as a
Flatpak container! And if you need mail: Well then for now use a different
mail client than KMail.

It runs on my music laptop with SQLite3 minimal Akonadi (no data in it).
The laptop has 8 GiB of RAM. It would also do with 2 GiB of RAM. I have
session uptimes of months there as well. Partly cause I rarely update it
and it runs the same kernel for ages. Using a kernel that I know has
working hibernation for that ThinkPad X260. With a Plasma 5 based desktop.
One of the simpler setups that already use Wayland instead of X11.

That Fujitsu laptop was for someone else. And I installed it onto ThinkPad
T14 Gen 1 laptops for two other people. Absolutely no complaint regarding
resource usage or stability so far. It just works. Admittedly one of those
people rarely if ever uses the laptop. He is my dad and usually I am the
one putting the new photos he made onto the laptop for archival purposes.

My assessment is also not completely up to date. I have no systems with
Plasma 6 yet. But once it arrives in Debian and thus Devuan I have not
much of the doubt that it will more or less be a seamless transition.

But I have at least four Plasma 5 installations I use more or less often.
Main laptop, the Gen 5, work laptop, a Gen 2, music laptop a X260 and the
X1 Gen 1 tablet. So I'd argue I can make a fairly accurate and honest
assessment on much more up to date experiences than what you referred to,
Steve.

So I still do not agree with your across the board statement that KDE
would be a resource hog. For all the reasons I outlined so far.

Now I have been writing for hours on this one. Hopefully someone considers
some of what I have been writing here.

Best,
--
Martin