Digikam dependency on akonadi

[Vikram]

Hi I am trying to remove Akonadi and Nepomuk from my Arch linux system.
I tried disabling Akonadi but it sometimes get enabled after a version
upgrade and is a resource hog.

I can't remove Akonadi since my arch package manager says that digikam
depends on kdepimlibs and that in turn depends on Akonadi. Does digikam
depend on either kdepimlibs or Akonadi or is this a Arch packaging issue
? I'd like to keep digikam which I love and use very often but would
like to remove Akonadi.

thanks,
Vikram

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am 24.08.2011 08:03, schrieb Vikram:
> Hi I am trying to remove Akonadi and Nepomuk from my Arch linux system.
> I tried disabling Akonadi but it sometimes get enabled after a version
> upgrade and is a resource hog.

Currently akonadi is a little bit big, that's true. But this will change
in the future. AFAIK sqlite as akonadi storage is on the way (it is
already there but has to be configured by hand).

>
> I can't remove Akonadi since my arch package manager says that digikam
> depends on kdepimlibs and that in turn depends on Akonadi. Does digikam
> depend on either kdepimlibs or Akonadi or is this a Arch packaging issue
> ? I'd like to keep digikam which I love and use very often but would
> like to remove Akonadi.

I don't know why, but most users don't like akonadi and nepomuk. The
strange thing is that if you don't use it you can either switch it of
(nepomuk) or it is not started automatically (akonadi).

Anyway: You can tag photos with data from the address book and this
needs kdepim and akonadi. I think it is a great idea to have a shared
address book for all apps with one simple (or may be not that simple)
interface (same is true for calendar).

For faster search from outside digikam you can enable nepomuk data store
in digikam (all tags are stored in nepomuk as well). This can be
switched in digikam settings.

Martin

>
> thanks,
> Vikram
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Karl Günter Wünsch]

On 08/24/11 08:24, Martin (KDE) wrote:
> I don't know why, but most users don't like akonadi and nepomuk.
Because they are breaking over and over and over again. If I count the
time that I had to spend getting these wretched things to compile (not
working but compile) due to their external dependencies - I'd rather see
them gone for good than spend one more minute going through the next
iteration of them... And if anything goes wrong with the database they
rely on - which is a normal occurrence on all the computers running KDE4
I have to tend to - you're up the creek without a paddle if you don't
happen to be a database expert of sorts. As you explained the next
iteration of this malarchy is already on it's way, this time it's sqlite
- for which IIRC there aren't any proper administrative tools available.
> Anyway: You can tag photos with data from the address book and this
> needs kdepim and akonadi.
Another useless feature for some - I for one am taking about 15,000+
photos in a year and of those not a single one will have people in it
(most of them literally no people at all, I am a nature photographer)
that I know or if I know them I wouldn't add to my address book (sports
personalities at sporting events)! I can even understand why someone
with known people in his photos would like to rip out the dependency -
because every time they give a picture to someone else they'd need to
remove that information anyway to protect the anonymity of the people
depicted (even if they have permission to publish these photos, tagging
these photos when publishing may well be illegal in Germany for example).

> I think it is a great idea to have a shared
> address book for all apps with one simple (or may be not that simple)
> interface (same is true for calendar).
I think it's a path that will drive some people away from digikam for
good. IMHO an address book has no place in an image editing application
- I can even give you cases (such as the above sporting events or
concerts) where your address book must not be used.
>
> For faster search from outside digikam you can enable nepomuk data store
> in digikam (all tags are stored in nepomuk as well). This can be
> switched in digikam settings.
I have just switched from kmail to thunderbird because I want to get rid
of the resource hogs (and points of severe data loss) that akonadi and
nepomuk turned out to be. My machine has 8Gb of RAM, high end 4 core
processor, fast disks to accomodate fast image editing but nepomuk and
akonadi happily tried to take all they could get. So count me in for a
nepomuk and akonadi (and face detection) free digikam which does only
what it says on the tin: picture editing and collection management.
Especially Nepomuk storage is highly unstable and I couldn't tell you
how many times I had to remove the whole database to get it working
again - so all information that happens to be stored only there I
consider non existent in the first place.
regards
Karl Günter
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am 24.08.2011 10:09, schrieb Karl Günter Wünsch:

> On 08/24/11 08:24, Martin (KDE) wrote:
>> I don't know why, but most users don't like akonadi and nepomuk.
> Because they are breaking over and over and over again. If I count the
> time that I had to spend getting these wretched things to compile (not
> working but compile) due to their external dependencies - I'd rather see
> them gone for good than spend one more minute going through the next
> iteration of them... And if anything goes wrong with the database they
> rely on - which is a normal occurrence on all the computers running KDE4
> I have to tend to - you're up the creek without a paddle if you don't
> happen to be a database expert of sorts. As you explained the next
> iteration of this malarchy is already on it's way, this time it's sqlite
> - for which IIRC there aren't any proper administrative tools available.

I like the idea (but I think that akonadi is not in final stage). As
akonadi is a cache only, there should be a button to reset the DB
(whichever it is then) and start from the beginning. May be it is even
wiser to recreate/invalidate the cache every now and then.

>> Anyway: You can tag photos with data from the address book and this
>> needs kdepim and akonadi.
> Another useless feature for some - I for one am taking about 15,000+
> photos in a year and of those not a single one will have people in it
> (most of them literally no people at all, I am a nature photographer)
> that I know or if I know them I wouldn't add to my address book (sports
> personalities at sporting events)! I can even understand why someone
> with known people in his photos would like to rip out the dependency -
> because every time they give a picture to someone else they'd need to
> remove that information anyway to protect the anonymity of the people
> depicted (even if they have permission to publish these photos, tagging
> these photos when publishing may well be illegal in Germany for example).

I don't use the address book in DK. I even don't like it. The list of
addresses clutters my monitor if I touch the entry with the mouse by
accident. I would vote for removing it.

>
>> I think it is a great idea to have a shared
>> address book for all apps with one simple (or may be not that simple)
>> interface (same is true for calendar).
> I think it's a path that will drive some people away from digikam for
> good. IMHO an address book has no place in an image editing application
> - I can even give you cases (such as the above sporting events or
> concerts) where your address book must not be used.
>>
>> For faster search from outside digikam you can enable nepomuk data store
>> in digikam (all tags are stored in nepomuk as well). This can be
>> switched in digikam settings.
> I have just switched from kmail to thunderbird because I want to get rid
> of the resource hogs (and points of severe data loss) that akonadi and
> nepomuk turned out to be. My machine has 8Gb of RAM, high end 4 core
> processor, fast disks to accomodate fast image editing but nepomuk and
> akonadi happily tried to take all they could get. So count me in for a
> nepomuk and akonadi (and face detection) free digikam which does only
> what it says on the tin: picture editing and collection management.
> Especially Nepomuk storage is highly unstable and I couldn't tell you
> how many times I had to remove the whole database to get it working
> again - so all information that happens to be stored only there I
> consider non existent in the first place.

Definitely true. It should be a cache thing only. At least by option. I
currently use kde 4.6 so I have kmail1 (and no data loss so far).

The next problem (for me): I use a NFS base network which gives
different (and additional) problems with akonadi/strigi/nepomuk.

I use Thunderbird and kmail and both have their advantages. But this is
off topic.

> regards
> Karl Günter

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

First of all thank you for taking the time to read my mail and
respond. Also apologies for the multiple mails. I was a long time
Kmail user migrating to Thunderbird and had some config issues.

I appreciate all the fantastic work the KDE devs have done and as an
former software architect I like the concept and architecture of
akonadi and nepomuk. Unfortunately the implementation has been
extremely resource intensive. I have a modest laptop with 2GB RAM and
I would like to keep that for RAW image processing not for nepomuk and
akonadi to use up half of that.

just to clarify the response i get from many experts is that akonadi
isnt supposed to be resource intensive and that doesnt take resources
if you dont start them and there are instructions on how to prevent
the services from starting. there are a couple of issues with this
approach -

1. I need to do this for each user on my machine - myself, wife and
guest account
2. Config files change and get overwritten with upgrades then i have
to find the fix and change in three places.
3. What do users who don't have top of the line hardware do untill the
implementation is fixed ?

Can anyone direct me to instructions on how to compile digikam without
these dependencies ? I'm pretty sure I'm not the only one wanting to
remove these from my laptop so a wiki page with instructions would be
awesome. my humble request for the digikam devs is to not incorporate
akonadi and nepomuk into the core app but leave them on as add ons or
plugins. After all isn't free software all about giving the user
options instead of forcing functionality they down want bogging down
the system ?

Thanks for listening

Vikram

On Wed, Aug 24, 2011 at 1:48 AM, Martin (KDE) <[hidden email]> wrote:

> Am 24.08.2011 10:09, schrieb Karl Günter Wünsch:
>> On 08/24/11 08:24, Martin (KDE) wrote:
>>> I don't know why, but most users don't like akonadi and nepomuk.
>> Because they are breaking over and over and over again. If I count the
>> time that I had to spend getting these wretched things to compile (not
>> working but compile) due to their external dependencies - I'd rather see
>> them gone for good than spend one more minute going through the next
>> iteration of them... And if anything goes wrong with the database they
>> rely on - which is a normal occurrence on all the computers running KDE4
>> I have to tend to - you're up the creek without a paddle if you don't
>> happen to be a database expert of sorts. As you explained the next
>> iteration of this malarchy is already on it's way, this time it's sqlite
>> - for which IIRC there aren't any proper administrative tools available.
>
> I like the idea (but I think that akonadi is not in final stage). As
> akonadi is a cache only, there should be a button to reset the DB
> (whichever it is then) and start from the beginning. May be it is even
> wiser to recreate/invalidate the cache every now and then.
>
>>> Anyway: You can tag photos with data from the address book and this
>>> needs kdepim and akonadi.
>> Another useless feature for some - I for one am taking about 15,000+
>> photos in a year and of those not a single one will have people in it
>> (most of them literally no people at all, I am a nature photographer)
>> that I know or if I know them I wouldn't add to my address book (sports
>> personalities at sporting events)! I can even understand why someone
>> with known people in his photos would like to rip out the dependency -
>> because every time they give a picture to someone else they'd need to
>> remove that information anyway to protect the anonymity of the people
>> depicted (even if they have permission to publish these photos, tagging
>> these photos when publishing may well be illegal in Germany for example).
>
> I don't use the address book in DK. I even don't like it. The list of
> addresses clutters my monitor if I touch the entry with the mouse by
> accident. I would vote for removing it.
>
>>
>>> I think it is a great idea to have a shared
>>> address book for all apps with one simple (or may be not that simple)
>>> interface (same is true for calendar).
>> I think it's a path that will drive some people away from digikam for
>> good. IMHO an address book has no place in an image editing application
>> - I can even give you cases (such as the above sporting events or
>> concerts) where your address book must not be used.
>>>
>>> For faster search from outside digikam you can enable nepomuk data store
>>> in digikam (all tags are stored in nepomuk as well). This can be
>>> switched in digikam settings.
>> I have just switched from kmail to thunderbird because I want to get rid
>> of the resource hogs (and points of severe data loss) that akonadi and
>> nepomuk turned out to be. My machine has 8Gb of RAM, high end 4 core
>> processor, fast disks to accomodate fast image editing but nepomuk and
>> akonadi happily tried to take all they could get. So count me in for a
>> nepomuk and akonadi (and face detection) free digikam which does only
>> what it says on the tin: picture editing and collection management.
>> Especially Nepomuk storage is highly unstable and I couldn't tell you
>> how many times I had to remove the whole database to get it working
>> again - so all information that happens to be stored only there I
>> consider non existent in the first place.
>
> Definitely true. It should be a cache thing only. At least by option. I
> currently use kde 4.6 so I have kmail1 (and no data loss so far).
>
> The next problem (for me): I use a NFS base network which gives
> different (and additional) problems with akonadi/strigi/nepomuk.
>
> I use Thunderbird and kmail and both have their advantages. But this is
> off topic.
>
>> regards
>> Karl Günter
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Vikram]

First of all thank you for taking the time to read my mail and
respond. Also apologies for the multiple mails. I was a long time
Kmail user migrating to Thunderbird and had some config issues.

I appreciate all the fantastic work the KDE devs have done and as an
former software architect I like the concept and architecture of
akonadi and nepomuk. Unfortunately the implementation has been
extremely resource intensive. I have a modest laptop with 2GB RAM and
I would like to keep that for RAW image processing not for nepomuk and
akonadi to use up half of that.

just to clarify the response i get from many experts is that akonadi
isnt supposed to be resource intensive and that doesnt take resources
if you dont start them and there are instructions on how to prevent
the services from starting. there are a couple of issues with this
approach -

1. I need to do this for each user on my machine - myself, wife and
guest account
2. Config files change and get overwritten with upgrades then i have
to find the fix and change in three places.
3. What do users who don't have top of the line hardware do untill the
implementation is fixed ?

Can anyone direct me to instructions on how to compile digikam without
these dependencies ? I'm pretty sure I'm not the only one wanting to
remove these from my laptop so a wiki page with instructions would be
awesome. my humble request for the digikam devs is to not incorporate
akonadi and nepomuk into the core app but leave them on as add ons or
plugins. After all isn't free software all about giving the user
options instead of forcing functionality they down want bogging down
the system ?

Thanks for listening

Vikram

On Wed, Aug 24, 2011 at 1:48 AM, Martin (KDE) <[hidden email]> wrote:

> Am 24.08.2011 10:09, schrieb Karl Günter Wünsch:
>> On 08/24/11 08:24, Martin (KDE) wrote:
>>> I don't know why, but most users don't like akonadi and nepomuk.
>> Because they are breaking over and over and over again. If I count the
>> time that I had to spend getting these wretched things to compile (not
>> working but compile) due to their external dependencies - I'd rather see
>> them gone for good than spend one more minute going through the next
>> iteration of them... And if anything goes wrong with the database they
>> rely on - which is a normal occurrence on all the computers running KDE4
>> I have to tend to - you're up the creek without a paddle if you don't
>> happen to be a database expert of sorts. As you explained the next
>> iteration of this malarchy is already on it's way, this time it's sqlite
>> - for which IIRC there aren't any proper administrative tools available.
>
> I like the idea (but I think that akonadi is not in final stage). As
> akonadi is a cache only, there should be a button to reset the DB
> (whichever it is then) and start from the beginning. May be it is even
> wiser to recreate/invalidate the cache every now and then.
>
>>> Anyway: You can tag photos with data from the address book and this
>>> needs kdepim and akonadi.
>> Another useless feature for some - I for one am taking about 15,000+
>> photos in a year and of those not a single one will have people in it
>> (most of them literally no people at all, I am a nature photographer)
>> that I know or if I know them I wouldn't add to my address book (sports
>> personalities at sporting events)! I can even understand why someone
>> with known people in his photos would like to rip out the dependency -
>> because every time they give a picture to someone else they'd need to
>> remove that information anyway to protect the anonymity of the people
>> depicted (even if they have permission to publish these photos, tagging
>> these photos when publishing may well be illegal in Germany for example).
>
> I don't use the address book in DK. I even don't like it. The list of
> addresses clutters my monitor if I touch the entry with the mouse by
> accident. I would vote for removing it.
>
>>
>>> I think it is a great idea to have a shared
>>> address book for all apps with one simple (or may be not that simple)
>>> interface (same is true for calendar).
>> I think it's a path that will drive some people away from digikam for
>> good. IMHO an address book has no place in an image editing application
>> - I can even give you cases (such as the above sporting events or
>> concerts) where your address book must not be used.
>>>
>>> For faster search from outside digikam you can enable nepomuk data store
>>> in digikam (all tags are stored in nepomuk as well). This can be
>>> switched in digikam settings.
>> I have just switched from kmail to thunderbird because I want to get rid
>> of the resource hogs (and points of severe data loss) that akonadi and
>> nepomuk turned out to be. My machine has 8Gb of RAM, high end 4 core
>> processor, fast disks to accomodate fast image editing but nepomuk and
>> akonadi happily tried to take all they could get. So count me in for a
>> nepomuk and akonadi (and face detection) free digikam which does only
>> what it says on the tin: picture editing and collection management.
>> Especially Nepomuk storage is highly unstable and I couldn't tell you
>> how many times I had to remove the whole database to get it working
>> again - so all information that happens to be stored only there I
>> consider non existent in the first place.
>
> Definitely true. It should be a cache thing only. At least by option. I
> currently use kde 4.6 so I have kmail1 (and no data loss so far).
>
> The next problem (for me): I use a NFS base network which gives
> different (and additional) problems with akonadi/strigi/nepomuk.
>
> I use Thunderbird and kmail and both have their advantages. But this is
> off topic.
>
>> regards
>> Karl Günter
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Vikram]

First of all thank you for taking the time to read my mail and
respond. Also apologies for the multiple mails. I was a long time
Kmail user migrating to Thunderbird and had some config issues.

I appreciate all the fantastic work the KDE devs have done and as an
former software architect I like the concept and architecture of
akonadi and nepomuk. Unfortunately the implementation has been
extremely resource intensive. I have a modest laptop with 2GB RAM and
I would like to keep that for RAW image processing not for nepomuk and
akonadi to use up half of that.

just to clarify the response i get from many experts is that akonadi
isnt supposed to be resource intensive and that doesnt take resources
if you dont start them and there are instructions on how to prevent
the services from starting. there are a couple of issues with this
approach -

1. I need to do this for each user on my machine - myself, wife and
guest account
2. Config files change and get overwritten with upgrades then i have
to find the fix and change in three places.
3. What do users who don't have top of the line hardware do untill the
implementation is fixed ?

Can anyone direct me to instructions on how to compile digikam without
these dependencies ? I'm pretty sure I'm not the only one wanting to
remove these from my laptop so a wiki page with instructions would be
awesome. my humble request for the digikam devs is to not incorporate
akonadi and nepomuk into the core app but leave them on as add ons or
plugins. After all isn't free software all about giving the user
options instead of forcing functionality they down want bogging down
the system ?

Thanks for listening

Vikram

On Wed, Aug 24, 2011 at 1:48 AM, Martin (KDE) <[hidden email]> wrote:

> Am 24.08.2011 10:09, schrieb Karl Günter Wünsch:
>> On 08/24/11 08:24, Martin (KDE) wrote:
>>> I don't know why, but most users don't like akonadi and nepomuk.
>> Because they are breaking over and over and over again. If I count the
>> time that I had to spend getting these wretched things to compile (not
>> working but compile) due to their external dependencies - I'd rather see
>> them gone for good than spend one more minute going through the next
>> iteration of them... And if anything goes wrong with the database they
>> rely on - which is a normal occurrence on all the computers running KDE4
>> I have to tend to - you're up the creek without a paddle if you don't
>> happen to be a database expert of sorts. As you explained the next
>> iteration of this malarchy is already on it's way, this time it's sqlite
>> - for which IIRC there aren't any proper administrative tools available.
>
> I like the idea (but I think that akonadi is not in final stage). As
> akonadi is a cache only, there should be a button to reset the DB
> (whichever it is then) and start from the beginning. May be it is even
> wiser to recreate/invalidate the cache every now and then.
>
>>> Anyway: You can tag photos with data from the address book and this
>>> needs kdepim and akonadi.
>> Another useless feature for some - I for one am taking about 15,000+
>> photos in a year and of those not a single one will have people in it
>> (most of them literally no people at all, I am a nature photographer)
>> that I know or if I know them I wouldn't add to my address book (sports
>> personalities at sporting events)! I can even understand why someone
>> with known people in his photos would like to rip out the dependency -
>> because every time they give a picture to someone else they'd need to
>> remove that information anyway to protect the anonymity of the people
>> depicted (even if they have permission to publish these photos, tagging
>> these photos when publishing may well be illegal in Germany for example).
>
> I don't use the address book in DK. I even don't like it. The list of
> addresses clutters my monitor if I touch the entry with the mouse by
> accident. I would vote for removing it.
>
>>
>>> I think it is a great idea to have a shared
>>> address book for all apps with one simple (or may be not that simple)
>>> interface (same is true for calendar).
>> I think it's a path that will drive some people away from digikam for
>> good. IMHO an address book has no place in an image editing application
>> - I can even give you cases (such as the above sporting events or
>> concerts) where your address book must not be used.
>>>
>>> For faster search from outside digikam you can enable nepomuk data store
>>> in digikam (all tags are stored in nepomuk as well). This can be
>>> switched in digikam settings.
>> I have just switched from kmail to thunderbird because I want to get rid
>> of the resource hogs (and points of severe data loss) that akonadi and
>> nepomuk turned out to be. My machine has 8Gb of RAM, high end 4 core
>> processor, fast disks to accomodate fast image editing but nepomuk and
>> akonadi happily tried to take all they could get. So count me in for a
>> nepomuk and akonadi (and face detection) free digikam which does only
>> what it says on the tin: picture editing and collection management.
>> Especially Nepomuk storage is highly unstable and I couldn't tell you
>> how many times I had to remove the whole database to get it working
>> again - so all information that happens to be stored only there I
>> consider non existent in the first place.
>
> Definitely true. It should be a cache thing only. At least by option. I
> currently use kde 4.6 so I have kmail1 (and no data loss so far).
>
> The next problem (for me): I use a NFS base network which gives
> different (and additional) problems with akonadi/strigi/nepomuk.
>
> I use Thunderbird and kmail and both have their advantages. But this is
> off topic.
>
>> regards
>> Karl Günter
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users