[Pan-users] OT: kde4/akonadi/etc (Was: Big XML files...)

[Duncan]

Rui Maciel posted on Wed, 19 Oct 2011 00:53:56 +0100 as excerpted:

> On 10/18/2011 09:00 AM, Duncan wrote:
>> OK, I'm rereading this thread based on the current sqlite solution
>> discussion, and...
>>
>> What do you think of the new, akonadified (and thus sqlite, mysql, or
>> the experimental postgresql backends) kmail?
> 
> Personally, I think it's horrible.  After using kmail since the days of
> Kubuntu 5.04, this akonadi cruft forced me to switch to Thunderbird, and
> never look back.  In fact, the only time I ever looked back was to
> wonder if it would be that hard to fork kmail into a stand-alone email
> client, but it appeared to be too much trouble for such a small reward.

FWIW, thunderbird's not my style.  But claws-mail sure is! =:^)

My reaction was along the lines of "too bad there's not a kde (or qt... 
maybe there is; I've not read of it) mail client that "just does mail 
right", like the gtk-based claws-mail seems to do; I don't care what /
else/ it might do as long as it doesn't depend on the kitchen sink or 
take hundreds of megs of RAM to do it.

But kmail is very much a part of kdepim, with dependencies to kdepimlibs 
and kdepim-common-libs as well as the general kdelibs, and it's kdepim-
common-libs that pulls in akonadi.

It'd be possible to fork it, but not easy, as one would have to 
effectively fork kdepim-common-libs and kdepimlibs from kde 4.3 era to 
avoid the akonadi dependencies that started with kdepim 4.4, pull out all 
the code that wasn't needed for kmail, and probably bundle the rest, 
either static-linking or changing the library and symbol names so they 
didn't conflict with the akonadified kdepim if parts of it were installed 
as well.  It's probably easier to start (nearly?) from scratch, depending 
on qt and possibly kdelibs (based on whether you want a kde-independent 
qt-based app or full kde), and possibly pulling in non-kde mail-handling 
libs, but preferably nothing from kdepim at all.

> Now, after installing Kubuntu 11.10, this akonadi/nepomuk crap is
> becoming so inconveinent that I'm currently considering dumping Kubuntu
> entirely and adopt some other distribution/DE package.   I simply don't
> know why KDE people insist in pushing that stuff, but at least they are
> succeeding in driving people away from their DE, which is a shame.

FWIW, while kde does still make the semantic desktop stuff optional in 
general (tho it's required for certain apps, including pretty much 
anything kdepim, since kdepim-common-libs pulls in akonadi, the reason I 
had to dump akregator too since it's kdepim based), the options must be 
chosen at pre-compile configure time.

That means that binary distributions will have to choose whether to 
activate it or deactivate it by policy, and /most/ binary distributions 
generally activate most option features, unless it's a specific feature 
of their distro that they don't.  (One major exception to this is that 
distros that default to a particular desktop environment will often not 
activate the options for others, since that often pulls them in.  Thus, 
gnome-standard distros will deactivate the optional kde support features 
in many apps, and naturally, kde-defaulting distros would do the reverse, 
in ordered to avoid pulling in both desktops.  Same for xfce, etc, for 
distros/spins/whatever that default to them.)

As a result, among binary-based distros, you'll likely either need to 
choose a distro defaulting to something else (gnome/unity/xfce/whatever) 
and then by policy deactivating the semantic-desktop stuff in kde in 
ordered to reduce dependencies for a non-primary desktop, or find a kde-
focused distro that has as a primary feature that they disable the 
sementic desktop stuff.

Or go source-based.  I'm not sure how arch-linux handles this, but I *DO* 
know (since I'm running it that way) that gentoo specifically exposes the 
semantic-desktop USE flag for kde, letting the individual user/sysadmin 
decide.  But even gentoo's handling isn't perfect.  Without getting too 
technically specific, while it makes sense that if one wanted the 
semantic-desktop features for say, dolphin, that kdelibs would need 
compiled with it as well.  No argument there.

But, the reverse need not be the case; just because one runs a single app 
that requires semantic-desktop (here, after dropping kmail, it was 
akregator, since while it didn't actually use akonadi, it required kdepim-
common-libs, which required akonadi, and akonadi requires semantic-
desktop), while that might indeed require kdelibs be build with semantic-
desktop as well, that should NOT require that dolphin be built with it 
too!  But gentoo/kde used semantic-desktop= dependencies where they 
should have used semantic-desktop? dependencies, forcing the dependencies 
both directions instead of just one, which meant that because akregator 
in a round-about way required akonadi which required semantic-desktop, 
which then legitimately required it for kdelibs as well, that required 
ALL packages with the semantic desktop option be built with it on.

Thus, even with kmail gone, as long as I was still using akregator, that 
forced me to keep semantic-desktop on for all the rest of kde I had 
installed as well.

Which once I realized it, forced my hand as I was tired of semantic-
desktop by then and wanted off, so I had to find a replacement for 
akregator as well even tho had gentoo/kde had the right dependencies, I 
could have probably simply turned it off for all the other apps (dolphin, 
etc) while leaving it on for kdelibs, etc.

As it happened that turned out for the better since I ended up figuring 
out how to run a second claws-mail instance, not for mail, but as my feed-
reader, and I'm happier with it than I was with akregator, now that I've 
actually switched.  But the hassle cost of switching was high enough that 
I would have certainly waited somewhat longer, and might have never 
actually switched, had my hand not been forced.

Meanwhile, however, even tho I had both strigi and nepomuk turned off and 
was no longer running akonadi, the system didn't get a lot of performance 
back until I actually turned off USE=semantic-desktop (plus a few related 
USE flags), uninstalled anything kdepim or akonadi related entirely, and 
rebuilt kdelibs, dolphin, etc, with USE=-semantic-desktop (the - turning 
it off).

But when I actually did so, *WOW* *WHAT* *A* *DIFFERENCE!!**  I swear, it 
was as if I was back on MS again and had just discovered how much of a 
drag the real-time anti-virus scanners were having on the system.  It was 
as if my 4-core system suddenly got two extra cores, or increased in 
clock-speed by half a GHz or so!  It was *SO* totally worth it it's not 
even funny!

I'm now rather convinced that a good half the time (the rest could be 
graphics performance related or the like, I upgraded from an old Radeon 
9200, r2xx series, to a new(er) Radeon hd4650, rv730, about kde 4.3 or 
4.4 era, so I know about that one from personal experience as well) 
people complain about how bloated and slow kde4 is, as opposed to kde3, 
the real problem is the semantic desktop ****, even if they have the bits 
they can turn off (strigi file indexing, nepomuk, akonadi if they're not 
using any already akonadified kdepim apps) actually turned off.

Seriously, pre-compile-configure-time-disabling semantic-desktop and 
related technologies (strigi, nepomuk, akonadi, soprano, redland, raptor, 
virtuoso) and eliminating them from my computer has upped my kde4 
satisfaction levels from perhaps 80% of what they were with kde3, to
95%+.  There's still a few niggles, but I can accept that by definition, 
the kde devs, not being me, will never match my feature decisions 100%.  

Meanwhile, if the fact that I decided if konqueror isn't good enough for 
most kde devs to consider as a serious browser[1] is thrown in as well, 
with my resulting switch to firefox, thus excluding konqueror from the 
evaluation, that personal kde4 satisfaction level rises to 98%+ of the 
comparable level for kde3.

Obviously, turning off semantic-desktop made a BIG difference for me, and 
I can now EASILY envision sticking with "core kde" as my desktop for 
quite some years to come. Before I likely would have, but switching was 
possible.  Now, unless kde pulls another kde4 on us and there's quite 
some indication that they've determined that the kde5 upgrade at least 
will be MUCH less disruptive, there's little chance I'll switch at all.  
That's an impressive improvement no matter how it's sliced! =:^)

I actually find it interesting and rather ironic, that I've come by this 
MUCH higher satisfaction with the core-kde4 desktop environment only as 
I've dumped several formerly kde app choices in favor of alternatives, 
and hard-disabled at pre-compile-configure-time some of what has been 
marketed as some of kde4's biggest and best headline features, but that 
has certainly been the case. <shrug>

----
[1] The recent bugs in konqueror, allowed to persist for many feature-
release versions despite the claim that kde was ready for ordinary use, 
demonstrates quite conclusively that few of them consider konqueror more 
than a toy.  As an example, until 4.6 at least and arguably 4.7 (it was I 
believe there in 4.6 but rather obscure, it's part of the network 
category in kde settings, with 4.7), kde4 had no UI for manually 
reverting trust on security certificates should they be found to be 
compromised.  Recent security certificate and even whole issuer 
compromises have surely proved the case, but even before that, no sane 
person with any knowledge of security certificate mechanisms at all could 
possibly find that a tolerable situation for a browser they depend on for 
Internet shopping and banking, or for webmail as a dissident in someplace 
like Iran.  It therefore follows that no sane person at all concerned 
about konqueror security could have qualified kde versions between 4.2, 
when kde started making the claim, and 4.7, when the issue was fixed, as 
ready for ordinary users, without such a security certificate 
configuration UI in place or at least a caveat that said readiness 
doesn't yet apply to konqueror (or any other component using kde's common 
certificate handling structure).

Since kde did announce kde 4.2 and later versions as ready for ordinary 
users without such a caveat, it therefore follows that the majority of 
kde devs cannot possibly consider konqueror anything more than a toy, and 
don't use it as their browser, at least for anything "serious" like 
supposedly secure net shopping or banking, or for use by those wishing 
their webmail access to be secure, etc.

It's thus self-evident that the majority of them use something else as 
their default browser, and consider konqueror only a toy not worth 
worrying about the security status (or for that matter, bug-free 
functionality in other areas) thereof.

Once I realized that, I realized that I could no longer trust konqueror 
under those circumstances either, and I best find a more satisfactory 
default browser for myself, as well.  It took some configuring as I had a 
lot of klipper actions, etc, hard-coded to konqueror, and I had to setup 
passwords all over again in my new browser, since kwallet is a kde-
specific technology, but I've had firefox setup as my default browser for 
about six months now (it's 4.7.2 now and it was 4.6.2 then, IIRC), and 
most of the formerly hard-coded-to-konqueror configs now use xdg-open, 
thus opening with the configured default browser regardless of what it is.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman