Has the KDE Social/Semantic Desktop been worth the hassle to anyone?

[Duncan]

Kevin Krammer posted on Sat, 17 Nov 2012 14:29:22 +0100 as excerpted:

> On Saturday, 2012-11-17, Jerome Yuzyk wrote:
>> With all the hassles added by Akonadi and Nepomuk and Strigi for some
>> higher "social/semantic desktop" purpose, does anyone actually _use_
>> the stuff?
> 
> Of the above three mentioned technologies, only Nepomuk is part of
> "semantic desktop".
> 
> The other two, while being used by Nepomuk as data sources, have their
> own, orthogonal, use cases.

Yes.  You mention strigi's.  I'll mention akonadi.  Like strigi it has 
its use case.  In its case it's to unify the backend for the various 
kdepim apps, eventually saving time and maintenance effort by replacing 
multiple copies of contact information (for example) management code with 
a single copy.

While in theory that should eventually be great, it does mean putting all 
the kdepim eggs in one (much more complicated) basket, making things much 
worse if that basket develops a hole, since now it's the data from all 
those apps at risk.  Also, there's inevitable growing/change pains, and 
getting from here to there isn't an easy process.

The database backend is both the trouble and savior in many ways, as 
databases are notorious for causing "ordinary users" (and not so ordinary 
ones as well) quite the headaches, not always being perfectly reliable 
without "professional" management, etc.  Sure, high-volume commercial 
stuff couldn't do without databases, but just to take mysql as an example 
since that was the first and probably most common akonadi backend, it's 
known for database version upgrades that need extra steps taken to manage 
the data format upgrades, and for such details as time and character-
encoding (unicode/etc) format issues that database pros deal with and 
configure as a matter of course, but that simply aren't appropriate for 
end users to be dealing with.  Yet that's now what end users will HAVE to 
deal with, as kde and mysql upgrade with their distro version, and they 
find their old contact information not making the upgrade in one piece 
with them.

Plus, if there's a bug, binary formats are notoriously difficult to 
repair and are arguably less robust, compared to "plain text" and perhaps 
XML for contact info, etc.

Five years down the line, it might be stable.  Thunderbird and evolution 
both depend on database backends (sqlite I believe, now a choice for 
akonadi as well, tho it wasn't originally, and a lot of folks are still 
using the mysql backend) and they aren't considered /terribly/ unstable.  
But they've had years... the better part of a decade I guess... to 
mature.  What are long-time kmail/kdepim users supposed to do while it's 
stabilizing?  Basically, they're left either dealing with the problem as 
kdepim slowly stabilizes on akonadi, or switching to something more 
reliable in the mean time, from which many will never switch back.

And that's what we see, some people choosing to live with the problems, 
some people switching to other alternatives, from which many will never 
return even after kdepim on akonadi is long since stable.

Was it worth it?  The developers obviously thought it was worth the 
risk.  Users like me are going elsewhere, likely never to return.  Others 
suffer thru it, and there's always new users after the stabilization.

But the answer those of us forced off have will be very different than 
that of the devs, and the new users who didn't have to live thru the 
upgrade.

Oh, well...  (more below)

> Strigi, or more precisely one of its building blocks ("libstreams"), is
> tasked with providing metadata about files, e.g. artist of a digital
> music file, date/time of capture of a digital photo file, etc.
> 
> Such information pieces are nowadays regarded essential by lots of
> users, e.g. expect them to be displayed when hovering over such a file
> or when looking at such a file's properties.
> 
> Since the information is also made available to Nepomuk, applications
> can either use the technologies directly (link with libstreams, extract
> metadata when needed) or by quering Nepomuk.
> 
> The latter approach obviously requiring Nepomuk to run but on the other
> hand making a bigger set of meta data accessible, e.g. user generated
> meta data such as rating, comments or tags, or application generated
> meta data such as file origin (e.g. the web site is was downloaded
> from).
> 
> This type of information is not as expected as the first type, though
> rating is increasingly being used for digital music and comments now are
> often applied to digital photos (description of scenery, people on the
> photo. etc).
> 
> It seems the authors of applications dealing with meta data had
> anticipated a faster growth of such needs, thus making the choice of
> augmented data access more desirable.

It's worth noting that with the whole semantic-desktop including the 
strigi backends turned off, at build-time where it's possible, there are 
some bits of functionality that was in kde3 now missing, because in kde4, 
the semantic-desktop services provide that data.  Metadata such as jpeg 
pixel sizes, comments, etc, is no longer available thru konqueror/
dolphin, etc, because nepomuk and its backends (strigi, tho it's arguably 
a "middle end", etc) are now the standard provider of such info in kde, 
and I've opted out of them.

But if I need that data, there's other ways to get it, other apps, etc.  
And most of the time I can do without.

Choices made, forks in the path chosen.  All that semantic desktop stuff 
is nice and the devs had their reasons, but I'll live without that 
information, or get it from other sources, because the cost in terms of 
resources, speed and stability is simply higher than the benefit I get.


One other question is where from here?  Luckily for those of us opting 
out of semantic-desktop, kde5 aka kde frameworks is supposed to be much 
more modular, so hopefully, the interdependencies become less of an issue 
not more, and I can continue to opt-out on semantic-desktop, etc, at 
build time.  Yes, there will be some apps (kmail, etc) that require it to 
function, and I don't see that changing, tho there's now an opportunity 
for a "lighter" qt/kde mail client, but there's alternatives for those 
apps, and a kde desktop should continue to be possible without semantic-
desktop, at least for those willing to build it themselves (as on gentoo 
for instance).

I believe and hope, anyway.

Meanwhile, as I've stated before, there's arguably an open niche for a kde 
desktop based but "hybrid" binary distro that turns all the semantic-
desktop, akonadi, etc stuff off, using firefox or chromium (because 
konqueror isn't a serious alternative any longer) and maybe thunderbird 
or claws-mail or evolution, in place of the kde alternatives,  It's 
doable on gentoo (as is turning it all on), but I don't know of any 
binary distro filling that niche, yet, and I believe there's an opening 
for one.

-- 
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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.