In future can KDE still be compiled without semantic desktop forever? (4.5, 4.6 etc...) and please keep possible to use Kmail and Kopete without Akonadi terror. I tried to use Kopete on livecd quickly but Akonadi made it slow.

http://www.tuxmachines.org/node/42728

Do not force Akonadi and Nepomuk to people who do not need it.


Maybe someone creates KDE light someday.
Can someone knows KDE 4.4 distro without Akonadi that is Debian based?

jossilint wrote:In future can KDE still be compiled without semantic desktop forever? (4.5, 4.6 etc...) and please keep possible to use Kmail and Kopete without Akonadi terror. I tried to use Kopete on livecd quickly but Akonadi made it slow.

http://www.tuxmachines.org/node/42728

Do not force Akonadi and Nepomuk to people who do not need it.


Maybe someone creates KDE light someday.
Can someone knows KDE 4.4 distro without Akonadi that is Debian based?

Debian?
Just don't install KDE as is, but rather install every package of KDE on it self.
Non debian based that could be installed without nepomiuk/akonadi: Arch, Slackware, Gentoo...

Try Gentoo Linux. You can install a lightweight version of KDE that does not have Semantic desktop installed by doing "emerge kde-base/kdebase-meta". There are other meta packages that contain subsets of KDE for other stuff you might want like utils and games. It is fairly easy to avoid installing semantic desktop because of this.

You can also specify -semantic-desktop in your use flags to try to avoid it at all costs and the package manager will try to avoid building packages with dependencies on it to the best of its ability.

Even with Gentoo, you can't use KMail without both Nepomuk and Akonadi.

Primoz wrote:

jossilint wrote:Non debian based that could be installed without nepomiuk/akonadi: Arch, Slackware, Gentoo...

i'm guessing that some tinkering would be involved, since nepomuk and akonadi are required, directly or indirectly, for other packages, e.g., kdebase-workspace and kdelibs, at least on arch linux.

Shining Arcanine wrote:Try Gentoo Linux. You can install a lightweight version of KDE that does not have Semantic desktop installed by doing "emerge kde-base/kdebase-meta". There are other meta packages that contain subsets of KDE for other stuff you might want like utils and games. It is fairly easy to avoid installing semantic desktop because of this.

You can also specify -semantic-desktop in your use flags to try to avoid it at all costs and the package manager will try to avoid building packages with dependencies on it to the best of its ability.

That is true. However, there are alternatives to KMail. Mozilla Thunderbird is one. The google approach where everything you do is through a web browser is another.

In future can KDE still be compiled without semantic desktop forever? (4.5, 4.6 etc...) and please keep possible to use Kmail and Kopete without Akonadi

I agree - please heed this request if at all possible.

Many users may value the semantic desktop, but I (like many others) have no use for it - I am not knocking it for what it is, just stating the facts of my situation. My PC has to work hard enough as it is with intensive work like editing graphics and video and running emulators without giving CPU cycles to Nepomuk et. al as well! I fear it will be a major problem for me if it becomes fully integral to KDE.

jossilint wrote:In future can KDE still be compiled without semantic desktop forever? (4.5, 4.6 etc...)

Probably not by default, but if someone would be volunteering to do the separation work and maintain it as a build option, it would quite likely be accepted.

jossilint wrote:and please keep possible to use Kmail and Kopete without Akonadi terror.

It makes no sense to not use Akonadi in KMail since that is basically the main use case for it.
As for Kopete, it might be possible to not build it with address book integration or to create a patch which makes this a build option.

jossilint wrote:I tried to use Kopete on livecd quickly but Akonadi made it slow.

Quite unlikely, Kopete is not using Akonadi yet.

jossilint wrote:http://www.tuxmachines.org/node/42728

This is actually an interesting link. The comment section to this article shows that technologies are not judged by the commenting individuals themselves but that hear-say is rehashed instead.

For example Nepomuk is not about indexing files, which is known to cause I/O and CPU load, it is about cross referencing data.
Sure, indexing is one possible way to add data for cross-referencing, but it is optional, e.g. for people who do not want to search for or in files.
But people who do not need to search for files might still want to search for mails or contacts.

Akonadi is, contrary to what some of commentors believe, not about storing or indexing mails in a database. It is a proxy for accessing data like mails in way that allows users to decide whether to content or parts of content cached for faster access or for access while being offline.
Previous solutions like KMail's index files or KMails disconnected IMAP account type were application specific, requiring other application implement caching on their own, multiplicating the amount of times data has to be fetched and the amount of disk space being used.

Of course there will be corner cases where the only form of PIM data use are a handfully of contacts in a local file or directory.
Such scenarios can be addressed by different configurations in the future while still allowing users with several thousand mails or IMAP accounts to have fast and disconnected access without being bound to one specific user interface.

As people in this thread have pointed out there are alternatives for people who only ever need a single user interface for one type of data and either keep it running all the time or have multiple programs fetching the same data on their own.

Cheers,
_

anda_skoa wrote:

jossilint wrote:I tried to use Kopete on livecd quickly but Akonadi made it slow.

Quite unlikely, Kopete is not using Akonadi yet.

Akonadi made terrifing 130mb file in home directory that was main reason it flooded memory.

Why cannot keep Akonadi separated from KDE, for example if someone wants build a ultralight desktop then she cannot do it without Akonadi, please keep choices open to everyone thanks...

anda_skoa wrote:Probably not by default, but if someone would be volunteering to do the separation work and maintain it as a build option, it would quite likely be accepted.

it seems easier to build a system from the bottom up (adding in desired components) than to prune a system down (removing unwanted components). how modular is kde?

dreamz wrote:

anda_skoa wrote:Probably not by default, but if someone would be volunteering to do the separation work and maintain it as a build option, it would quite likely be accepted.

it seems easier to build a system from the bottom up (adding in desired components) than to prune a system down (removing unwanted components). how modular is kde?

In Arch you could use

Code: Select all

pacman -Rd

To remove unwanted dependencies, but as you know that would result in some cases in crashes...
For Arch there's also KDEmod, which I use and it's quite modular, but you still have to have akonadi/Nepomuk/strigi.
If you just don't want Nepomuk indexing files you can just go to System settings -> Advanced Settings -> Desktop Search and turn off Strigi. And then you won't have nepomuk using that much CPU or RAM.

could they be made optdepends instead?

i've already disabled nepomuk and strigi, but it would be nice if i didn't have to install them since i neither search nor tag.

jossilint wrote:

anda_skoa wrote:

jossilint wrote:I tried to use Kopete on livecd quickly but Akonadi made it slow.

Quite unlikely, Kopete is not using Akonadi yet.

Akonadi made terrifing 130mb file in home directory that was main reason it flooded memory.

This can be tuned: http://techbase.kde.org/Projects/PIM/Ak ... rectory.21

jossilint wrote:Why cannot keep Akonadi separated from KDE, for example if someone wants build a ultralight desktop then she cannot do it without Akonadi, please keep choices open to everyone thanks...

Akonadi is in fact separated. This is one of its design goals, i.e. to be usable for software not built on the KDE development platform.

So one of its users, KDE, decided to deprecate the per-process plugin based PIM resource framework KResources (which was also mostly limited to contacts and calendar) in favor of building its PIM services upon Akonadi.

Obviously applications not using any KDE PIM libs, e.g. not linking against any library from module kdepimlibs do not depend on KDE's Akonadi client library or Akonadi.

Whether or not PIM features such as address book acces/integration are optional in the respective applications depends on whether it is assumed to be a core feature and/or how difficult it is to maintain conditional builds.

The latter might often not be seen as worth the effort since most people will be running the application on a default built stack, i.e. with KDE's PIM libraries.

Cheers,
_

dreamz wrote:

anda_skoa wrote:Probably not by default, but if someone would be volunteering to do the separation work and maintain it as a build option, it would quite likely be accepted.

it seems easier to build a system from the bottom up (adding in desired components) than to prune a system down (removing unwanted components). how modular is kde?

True, generally speaking. I think most usage of Nepomuk is in fact optional, e.g. guarded by build time checks.

On the other hand, build time variants can become a maintenance effort so if nobody volunteers to put in the necessary additional work, they are sometimes dropped or no longer tested.
The more common certain functionality becomes, e.g. tagging being used by more applications, the less it becomes viable to deviate often scarce development resources for keeping separate build options.

But as I wrote before, people willing to do this work would almost certainly not be turned away.

Cheers,
_

anda_skoa wrote:

jossilint wrote:

anda_skoa wrote:
Akonadi made terrifing 130mb file in home directory that was main reason it flooded memory.

This can be tuned: http://techbase.kde.org/Projects/PIM/Ak ... rectory.21

Can you give this order to Kubuntu developers that they make it smaller, you have word power that they listen you, there is time till middle of february feature freeze (18 feb). thanks.