Akonadi and Nepomuk are quite annoying services especially when you don't need them at all.
They seem to be forced during installation:
- Akonadi forced by korganizer (not needed to manage simple ics calendars).
- Nepomuk forced by kdebase-runtime-data

When creating new user accounts, you immediately try to stop these services which are making undesirable operations and stressing the hard-disk.

Nepomuk can be removed after installation with a script, but will be re-enabled when updating kdebase-runtime-data (see here ).

Is there an option hidden somewhere to not install Akonadi and Nepomuk during KDE4 installation ?
If not, is it planned to make them optional ?

In Gentoo, you can build KDE without "semantic desktop" support, which leaves no trace of Nepomuk.

As for Akonadi, if you aren't running any programs that use it (you remove any Akonadi compatibility resources in Kontact), Akonadi does not start.

When creating and starting new user accounts, Akonadi is not disabled by default.
If I know before installing KDE that I don't need Akonadi at all, it seems more logic to not install it rather then trying to disable it while making undesirable operations, stressing the hard-disk, looking for I don't kow what, the first time you open a new user account.

I did not find how to not install these things while making a netinstall of either Debian or Kubuntu.

Akonadi starts and configures itself on the first startup because KOrganizer reminder thing starts up in KDE by default, and it uses the Akonadi compatibility resource. Since don't create users that often, it shouldn't really be a problem...

You can't get rid of Akonadi because some things actually need it and will not work without it, so if something needs it, it starts up. And aside from that, it's intended to eventually replace the current backends.

"You can't get rid of Akonadi because some things actually need it and will not work without it"

Yes I can. Fully disabled / 100%. No need at all.

"Akonadi starts and configures itself on the first startup because KOrganizer reminder thing"

No need of Akonadi with ics calendars.

Note that in the future KDE functionality, especially in KDE PIM will be severely reduced if Akonadi is not present and functional. This will become more evident in KDE 4.4 and 4.5.

This will be counteracted however by PIM applications removing their internal protocol implementations and becoming lighter in the process.

Alec wrote:Akonadi starts and configures itself on the first startup because KOrganizer reminder thing starts up in KDE by default, and it uses the Akonadi compatibility resource.

That should not happen!

We explicitly deactivate automated application side compatibility for every release, we only leave in backend side compatibility in case an explicit Akonadi application wants to start it.

What could have happend is that you used a beta or release candidate with the same user profile, that the distributor changed our defaults or that you manually ran out migration tool.

Cheers,
_

L_V wrote:They seem to be forced during installation:
- Akonadi forced by korganizer (not needed to manage simple ics calendars).

I am not sure what the exact reason is to have the application depend on Akonadi since the only thing depending on it is an optional plugin, but it is something you should talk about with your distributor.

Maybe it is easier to add it as a dependency of all KDE PIM applications so it is not necessary to keep track which ones have already been ported to use Akonadi.

For now you can work around this by using one or several of the options described in our FAQ:
http://techbase.kde.org/Projects/PIM/Ak ... konadi_FAQ

Cheers,
_

anda_skoa wrote:

Alec wrote:Akonadi starts and configures itself on the first startup because KOrganizer reminder thing starts up in KDE by default, and it uses the Akonadi compatibility resource.

That should not happen!

We explicitly deactivate automated application side compatibility for every release, we only leave in backend side compatibility in case an explicit Akonadi application wants to start it.

What could have happend is that you used a beta or release candidate with the same user profile, that the distributor changed our defaults or that you manually ran out migration tool.

Cheers,
_

OK, looks like the compatibility resource was only added in the RC.

But, if I create a new user, on the first it shows the "Starting Akonadi server..." dialog, and mysql and akonadi processes start. Is that supposed to happen? (On the next login they do not start anymore.) Is that just something that's done on the first login so that the user does not have to wait for the database to be set up if he decides to use Akonadi?

Alec wrote:But, if I create a new user, on the first it shows the "Starting Akonadi server..." dialog, and mysql and akonadi processes start. Is that supposed to happen? (On the next login they do not start anymore.) Is that just something that's done on the first login so that the user does not have to wait for the database to be set up if he decides to use Akonadi?

That is the backend side compatibility I wrote about above.
What happens is that when any application accesses the user's addressbook or calendar, we perform a check whether this data would also be available to an application using Akonadi.
If not, we add this as a new data source to Akonadi.

In your case something, probably the contact plugin of KRunner, did that and triggered the creation of the Akonadi data sources. On subsequent logins there has been no change to the data setup, so there is no need to create new sources, thus Akonadi is not started.
(Akonadi is always only started on demand)

Cheers,
_

You know, I keep encountering the *same* explanation for Akonadi and Nepomuk. Essentially, it is that these beasts are going to be really helpful, and even essential, Real Soon Now. Meanwhile, they just bog the system down to a truly incredible degree.

I've encountered this sort of a 'stuff it down the users' throats' approach to "new technology" before, if only I could remember where. Oh, yeah, I got it: it was in Windows!

Duh!

I'm sure that this approach somehow made sense to the KDE developers who are planning to put some (all?) their eggs in the Akonadi and Nepomuk baskets. But, whatever sense it makes has eluded my grasp, and that of many other Linux users. Currently, disabling those services is the FIRST task on first KDE start up on the new servers and desktops I'm building. And, check out all the frantic, "how do I kill these P. o. Sh. software packages" traffic on LinuxQuestions that followed the release of Slackware 13 with KDE4.

As far as I can tell, at least within the Slackware community, all that's been accomplished so far is to

• Convince us that some leaders on the KDE team can't tell the difference between a 'really cool idea' and a 'really cool idea that works'. Seriously, guys, that's an important distinction.
• Convince us that Akonadi and Nepomuk are evil entities to be avoided, along with all their offspring.
• Convince us that it might be time to hold our nose and check out Gnome again.

Frankly, I think it's probably in best interest of the KDE team to issue an all points "Oops" and apology, a promise to make sure these P.o.Sh. packages remain OUT of future KDE releases until they are beyond -- way beyond! -- the 'slower than Vista' stage. We also need an official HOWTO 'dig them out of your system'.

No doubt big egos are involved -- certainly the guy who I presume is the key player, one "Dr. Ansgar Bernardi" of semanticdesktop.org is self-impressed. Who else but someone who had his head so far up his own a** that he thinks living in dark warm sh** is heaven could pen a bit of techno-purple prose like "a comprehensive solution for extending the personal desktop into a collaboration environment which supports both the personal information management and the sharing and exchange across social and organizational relations."

To the degree I can parse it out, all he said was, "we have a better way to share info with your co-workers and friends"! How many times have us old geeks heard THAT before? Gee whiz, even the educational whiz-bang PhD my school teacher wife deals with can't sling the jargon sh** that well! And NOBODY babbles meaningless jargon like they do!

But guys, we're trying to do real work out here, and system "services" that currently -- no matter what they *might* do in the future -- turn our desktops into slo-mo muck do NOT belong on our machines.

Sincerely,

GaHillBIlly

GaHillBilly wrote:I've encountered this sort of a 'stuff it down the users' throats' approach to "new technology" before, if only I could remember where.

KDE can be built without these components. Petition the Slackware developers to not include them in the distribution.

In Gentoo, I can build without Nepomuk/Semantic Desktop and Akonadi does not start by default.

"KDE can be built without these components. Petition the Slackware developers to not include them in the distribution."

Not to put too fine a point on it, but the attitude, "we've stuffed sh## into this package, but we won't fuss if you work hard enough to figure out how to scrape it out before it gets all over you!" . . . is not much of a step up from the Microsoft approach.

I ALREADY figured out how to disable it in Slackware. But, the point is, I should NOT have needed to do so.

GaHillBilly

Alec wrote:In Gentoo, I can build without Nepomuk/Semantic Desktop and Akonadi does not start by default.

And I think Nepomuk will also not be started by default even if available, i.e. I think it has to be activated in KDE's system settings.
Could of course be different between distributions.

Cheers,
_

The solution is may be to provide two kinds of KDE:

- a KDE version for distributions (99% of normal and stupid PC users looking for simplicity and efficiency)
- a KDE version for clever developers able to understand cool features for the future.

Everybody would be happy.