Let the user decide if in doubt
Posted on: May 5, 2011
- In: KDE
- 113 Comments
(or: stop services that are not needed by any client)
If it comes to decisions there is always the aim to just do the right thing. In a lot of cases there is the one right thing. In quite a few cases there is no right thing but the consequences are small enough that it does not really matter which decision one takes. And then there are those use-cases where the only right thing to do is to ask the user because any other decision would just be guessing and lead to RAM and CPU wasting.
Yet even in the latter situations some apps are too lazy to ask the user or even claim that not asking the user – not even once – is the best solution – and even more astonishing: for the user’s good. So basically they claim to be smarter than the user or just do not care about the user’s resources or opinion.
Akonadi
In case akonadi is not running when the user starts kmail (and this example is only about that use-case) it asks the user whether it should start the service. That’s good! Tell the user that some needed service is missing and offer the means to start it. Give the user a choice instead of hiding processes. The user might have lost three seconds but he gained knowledge about a service that will consume a considerable amount of RAM and CPU-power. It’s not some small plasma or kded service!
Now if the user quits kmail akonadi will not quit automatically. Why not? Because it does not know whether it is still needed by other apps. As a result it consumes bandwith, RAM and CPU although it is not needed anymore. That’s bad! The fact that akonadi is not stopped when not needed anymore is another aspect where akonadi differs from some small plasma service that is started automatically (hidden) if the user adds the related widget. It is different because the latter also stops the service as automatically and hidden as it started it when the user removes it – thus there is no need to bother the user.
So why not simply ask the user in case of akonadi? Kmail asked the user whether to start the service, so why does it not ask whether it should stop it? If the user would want akonadi to run all the time he would autostart it with the session, would he not? And if kmail can ask the user to start akonadi why can those applications that still need it not do the same? What is wasting more resources and annoying a) to have akonadi in memory just in case there is some other app using it or b) let the user take a decision which takes two seconds? Worst case scenario would be that the application that needs akonadi tells the user to start it, as kmail did in the first place. Remember – if the user would want akonadi to run all the time he could start it as part of the session or click once on some “never quit akonadi” button.
Another approach would be to let kmail ask akonadi whether there are other applications using it. Either applications using it have to register with akonadi or respond to a “who needs me?” query by akonadi. That way the user could get a list of applications using akonadi and decide whether he wants to keep it in memory or not. He knows, the application just guesses or assumes. And it should only be the user that decides when it comes to a “do always”-kind of question. He might as well decide to “always quit akonadi when kmail quits” or “never quit akonadi when kmail quits” or “akonadi should quit as soon as there is no app answering to a ‘who needs me’ query”.
What makes it worse not to ask and just assume that staying in memory is ok is that there is no easy way to stop akonadi. There is no systray icon indicating its status and allowing interaction. There is no start/stop in systemsettings’ PIM module (as there is for e.g. nepomuk). There is no entry in systemsettings’ start/stop module. So even if the user knows about these systemsettings modules he cannot stop akonadi.
IMHO stopping something should be as easy and automatic as starting it. If that’s not the case it is an usability fail. I know that there is akonadictl but that is out of reach for most users and just underlines that stopping is not on the same level of ease as starting. The latter implies that once started the app thinks it is better not to be stopped again.
Lancelot
An even worse example is Lancelot. Adding a plasma widget starts an application without even asking or at least notifying the user. This would be kind of ok, if that application would be stopped as easy and automatically as it was started, as plasmoids can do, yet it is not!
Removing the widget lets lancelot stay in memory just in case there are other apps using it. According to the developer asking the user is out of question because it would involve user-interaction. So in the end you add a widget and remove it and yet have some useless app left wasting megabytes of memory, CPU-time and querying e.g. akonadi. There is no way to stop it via systemsettings. Yet the latter would not help anyway since the user does not even know that some memory/CPU wasting app was started without his knowledge int he first place.
Again wasting resources just in case there might be some app that needs the service is seen as the best way instead of simply asking the user. In times of suspending instead of rebooting and mobile devices this means that lancelot will happily waste your memory and CPU-time for ages although it is not needed at all. Simply because a three second user-interaction is considered bad by the developer. What makes people think that wasting their resources is less annoying to them than interacting with them once in a while?
And of course you are right to claim that nobody forces people to use e.g. Lancelot. Absolutely true! But that is just another reason to not pest those users with your application until they restart their session. They think they stopped everything as explicitly by removing the widget as they allegedly started it explicitly by adding the widget. Did we not all make fun of MS Windows because you had to restart it for all kinds of changes and when removing software?
So IMHO: If an application is not smart enough to know what the right thing to do is and whether it might waste RAM and CPU just for the sake of not interacting with the user – not even once: please ask the only expert regarding what the user wants – the user. Don’t try to be smarter than the user if the alternative is as easy as a single user-interaction. At an absolute minimum provide the user with the graphical means to stop whatever you thought necessary to start automatically but not stop automatically, e.g. via systemsettings as nepomuk does.
UPDATE: Since I seem to not have got that point across very well: I would also like to avoid questioning the user but that needs the service to behave as it was mentioned in some comments by others. As long as it does not do that, I prefer to decide what should be done with services that are not needed by any clients.
UPDATE 2: Since some people could not help themselves but simply claim that my figures on akonadi/kdepim’s memory consumption were wrong and would not even hint towards real memory consumption getting out of bounds, I’d like to point out that using /proc/PID/smaps one can measure the private dirty memory consumption of a process. In KDE’s system monitor you can reight-click a process and pick “detailed memory information” to get that info. So bottom line is, unfortunately my figures were real, are reproduceable on my system and reported to the devs. So for people like Nathan – please don’t get too defensive and aggressive next time – just in case you are wrong. And please do not start claiming that even smaps and private dirty memory consumption is not “real”.
113 Responses to "Let the user decide if in doubt"
May 5, 2011 at 19:34
I agree, i am spending time in #kde channel trying to answer questions, a frequent question is how to completely remove akonadi
Those people are all wrong and actually do not exist – just read the other comments! 😉
Well, no. The point of the other comments is, that if you use kmail, you have to use akonadi.
One cannot use kmail without akonadi (or at least soon).
It makes as much sense as asking to start kwin each time you start the plasma desktop.
Where did I claim that one should use kmail without akonadi?
I claimed that a service without users which occupies a lot of RAM should exit – and that until the service behaves the user should have the same easy means to stop it that he is given to start it, as for nepomuk and others.
May 5, 2011 at 19:38
In the case of lancelot, the application could be stopped when the menu closes, and restarted when it opens again. This would also solve the weird bugs where it malfunctions if you leave while in the applications sub lists.
However, the problem is that the application is noticeably slow to start
May 5, 2011 at 19:38
Why would anyone want to run KMail without Akonadi?
At least in the “next” version everything is stored in Akonadi.
I dont’t think the user should be bother to know how to autostart something.
And what is the problem on a normal computer (at least 2 cores, gigs of memory) with running Akonadi?
First, it’s not about running kmail without akonadi but running akonadi without any client. Who would run a server without any clients, does not make sense, does it?
And regarding resources: akonadi eats hundreds of MB for a single resource if I open a folder with a few thousand emails and kontact takes more than 100 MB as well, so all in all it is a lot.
May 5, 2011 at 22:01
So instead of fixing the technical problem, another problem is added – a UX problem.
Instead of makeing it better, it’s getting worse.
“server without clients”
I think there were some blog posts about it some time ago, some technical problems ore something like that.
“a few thousand emails”
I do not think this is a common use case to have so many emails.
May 5, 2011 at 22:32
I think your common use case is extremely narrow in scope. I know several people, not including myself that have 20k or more emails. BTW those others are not developers and the like; just ordinary users
Having thousands of emails is much more common than you’d expect.. Lots of people use email as if it was IM. OR even if you are on just a few mailing list, it piles up pretty fast.. I currently have over 400k emails with all of my mailboxes and Evolution handles it fine. You have no excuse to do any worse.
“With what memory footprint?”
About 1-2 gigs of ram (but its one of the main applications on my computer, so it’s ok).. I can just close evolution if I want to use less RAM… That’s something a user can understand.
Now, you want to close akonadi when you close KMail.. Maybe that means there is a design problem with KMail… Asking the end user is definitely not the right solution.
(Seems like we reached the max nesting)
I increased the max nesting.
It’s correct that this issue could only come up because data and GUI got separated and thus the user does not get why there is still something doing “mail stuff” when the mail application is closed.
If one would be sarcastic one could state that in kmail1 times a never exiting imap/pop3-kio-slave was regarded a bug although it only used a fraction of akonadi’s memory footprint and now it is regarded a feature that it never quits. 😉
1-2 GB seem a lot to me though for an email client.
May 6, 2011 at 00:02
Who would run a server without any clients, does not make sense, does it?
The calendar widget of the Plasma Clock uses Akonadi to get all appointment and holiday info (that info in turn can come from any Akonadi resource like Google Calendar or Facebook Events and hence does not require KOrganizer).
So Akonadi is needed.
As long as KolabSys is contracted to bring Akonadi to mobile phones, Akonadi’s resource requirements will go down over time.
Yes but no. 🙂 The calendar might need one resource but not all of them. And none are shut-down.
And “over time” does not help today’s users. Just check the archives for all the complaints about nepomuk and even akonadi. Both of which are supposed to not bother the user yet users do ask how to disable or remove them. Certainly not because they never noticed them and enjoyed their functionality.
May 6, 2011 at 03:45
“Just check the archives” I remember myself complaining about Akonadi 8 months ago. I pestered the guys working on Akonadi with my bug reports. And the thing improved. And improved. KDEPIM 4.6 beta 4 was somewhat usable, KDEPIM 4.6 beta 5 was immensely better, and branch now is even better.
I’m waiting for the transition to Virtuoso. That will shave 100 MBs of RAM and give Akonadi more speed. How fast can you improve, Akonadi guys?
How can it shave off 100MB RAM if it does not use that much according to e.g. Nathan? 😉
I’m really looking forward to see it work and behave but until then the user should be able to control it, be it via a question (it’s ok if others don’t like that) or at least via systemsettings.
May 7, 2011 at 16:24
Actually, it isn’t always 100 MB, it depends on your installed memory, because it’s the Mysql server spawn by Akonadi. With a Virtuoso migration, there’s only one server engine serving Akonadi and Nepomuk, so there are massive memory savings. They are trying to do this already; there’s even a package to try a Virtuoso-powered Akonadi in Debian Experimental. Install this:
http://packages.debian.org/experimental/misc/akonadi-backend-odbc
This is experimental, this might break Akonadi, but theoretically it enables you to use Virtuoso and save that memory.
About your proposal, please, give Akonadi more time to behave. My point is: Akonadi had a dismal performance, and now the performance is acceptable thanks to all those bug reports. I’m not a light user of Akonadi, I have a 28,000 mail account, plus loads of experimental Akonadi resources loaded, and KDEPIM 4.6 branch is behaving here. I don’t see akonadiserver, or any Akonadi resource, on top. All Akonadi processes are eating 140 MB of real memory in my 64 bit, 3 year old box. The mysql process eats 88 MB of real memory, and a migration to Virtuoso will kill that. So, can the option box, and let Akonadi behave properly and be loaded always.
May 6, 2011 at 03:09
And I, as the Spanish translation maintainer for Event List plasmoid, vote for Akonadi. Event List is a very useful plasmoid, and it’s nice to have. And the Akonadi system requirements are going down quickly: I filed a bug about akonadi_imap alone using 1 GB of RAM in KDEPIM 4.5. That was fixed, of course.
If you think Akonadi and Strigi are too heavy on resources, I recommend you to try KDEPIM 4.6 branch (post 4.6 beta 5) and libstreams-libstreamanalyzer trunk. Strigi 0.7.3 is close to a release, the libs are already at 0.7.3, and the system hammering is half than what you have with 0.7.2 (the version in all distros I know of). I DO want a Strigi 0.7.3 release, and it’s ready, so, it’s a matter of announcing ;).
libakonadiprotocolinternals1-1.5.2-93.1.x86_64
libakonadi4-debuginfo-4.6.2-218.2.x86_64
akonadi-4.6.40.git.1302464593-1.1.x86_64
akonadi-runtime-1.5.2-93.1.x86_64
libakonadiprotocolinternals-devel-1.5.2-93.1.x86_64
libakonadi4-4.6.2-218.2.x86_64
kmail-debuginfo-4.6.40.git.1302464593-1.1.x86_64
kmail-4.6.40.git.1302464593-1.1.x86_64
libstrigi0-debuginfo-0.7.3.99-60.8.x86_64
strigi-devel-0.7.3.99-60.8.x86_64
libstrigi0-0.7.3.99-60.8.x86_64
strigi-debuginfo-0.7.3.99-60.8.x86_64
strigi-0.7.3.99-60.8.x86_64
It’s not like I am using old packages or not reporting problems for all those projects.
May 5, 2011 at 22:28
Because IMO it is getting to the point that a 2 core box is not enough.
May 6, 2011 at 03:17
Upgrade your Akonadi, your Strigi AND your KMail (last 2 ones from GIT). I’ve reduced all resource usage to acceptable levels with my TurionX2 3-year-old 2 core machine.
May 5, 2011 at 19:48
Concerning lancelot I think it’s a rarely-encountered issue since people dont add/remove a plasmoid as part of their daily routine. I wonder what those “other users” are though, and if they could be reference-counted so that the app can close when no longer needed.
Concerning akonadi, if it is indeed optional at runtime (I thought it had become mandatory ?), I think the proper choice when starting kmail is “1) never use it 2) use it if already started 3) start it if necessary and always use it”. And yes, all optionaly-akonadi-using apps should probably have those options.
But shutting down akonadi automaticaly (or not) is something that should be configured in an akonadi-specific GUI, not in the kmail GUI. Because it affects more than kmail. Yes, we need a GUI to start/stop akonadi.
May 5, 2011 at 20:16
http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html
I _strongly_ disagree. Starting/stopping akonadi is a highly “computer-thingy-internal” stuff. Users absolutely do not care about it.
And why should they? They only want to read the mail, edit events etc. No matter what.
Asking the user simply means mixing the user’s model with the program’s model.
The result is a bad UX – sorry.
My choice would be to only notify the user that aconadi is now started (with the kontact startup).
I think you take the wrong assumptions.
First of all you assume that everybody using KDE wants to use kmail or akonadi. Those that do not use kmail or kdepim might not need akonadi.
Second you assume that users don’t care about their resources. Please check the mailinglist archives for rants about nepomuk and keep in mind that nepomuk does provide easier means to disable it than akonadi!
Third, kmail already asks whether it should start akonadi, so according to you that’s bad usability. No matter how you tun it, it is not consistent to ask whether to start but not to ask whether to stop.
May 5, 2011 at 22:17
First – if users don#t use akonadi, then it soudn’t use any CPU and near to no RAM.
If this is not the case, then fix it! (or dump akonadi)
Second – when akonadi uses too much resources, then it’s a technical issu. This deserves a technical solution.
So fix it or hide it! (or dump akonadi)
Makeing the UX worse does neither fix nor hide the problem.
Third – yes, it’s bad already. User’s should never be forced to get in touch with “akonadi” at all.
I would highly recoomend to read http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
Read all the chapters.
Akonadi is absolutely not in the user model.
And that is why akonadi should take the right decision if it does not want to ask the user and that is: vanish if nobody is using it.
May 5, 2011 at 20:20
I totally and strongly disagree.
Asking the user whether to start or stop some service is absolutely the wrong thing to do and I’ll tell you why: 99.9% of users will have no idea whatsoever what Akonadi is, let alone what it does. Therefore they will be afraid to make the wrong choice when forced to answer a popup question that they don’t know or understand the consequences of. This causes them uncertainty and in the end, it will make them go back to Windows or whatever else they used before, where they did not have to answer “these difficult questions”.
Instead, an application needs to be smart and figure out a sane default as to when to start and stop important services.
May 5, 2011 at 21:06
I couldn’t agree more. If we want to make user-friendly system, we need to make the important decisions for them.
Yes, but not if you decide regarding hundreds of MB RAM.
May 5, 2011 at 22:27
How is that RAM measured? is it resident? shared?
I forgot to ask the obvious. How do you measure the memory consumption so that I can get results measured the same way?
Have you read the comments about nepomuk? did people want to have a choice? Yes! Did they complain although they have the means to disable it? Yes! So what you do is ignoring the lessons one could have learned from nepomuk+strigi.
May 5, 2011 at 22:23
Nepomuk+strigi worked hard to fix their issues. That’s the most important lesson to learn.
Next is that they do have an option to enable / disable. But they _do_not_force_ the user to do that decision.
Givin an option and asking are totally different when it comes to UX.
May 6, 2011 at 00:06
Only people who dislike something bitch on forums.
So the amount of bitching does not indicate anything about what users want unless you conduct proper surveys.
That’s really an easy argument. so nothing mentioned in forums is true? too easy, sorry. And btw. you just contradict yourself since you cannot present a survey either that proves your point, can you?
But they don’t! What’s smart about staying in memory no matter how small the footprint is if there is nobody using the service, e.g. in the case of lancelot? It’s as smart as leaving the engine of your car on or your TV if you are not in the room.
May 5, 2011 at 20:43
I agree with Joe that the user really don’t care about akonadi, he will care about the functionalities it provides, so is quite useless to ask him.
But you did a great job raising this issues and I think that you should report it as bugs that need to be fixed. A plataform that have pretension to be on mobile really should care about wasting resources as you pointed.
Maybe a resonable solution is stop all services that are not being used (everybody that use a service should register on it) and start them only when needed, using something like Dbus.
May 5, 2011 at 20:45
I think your analysis is wrong.
A well written service (even a big one like Akonadi) should not be using any CPU and not causing any wake ups unless actually doing something useful. Also, it should not be using any RAM, but rather after some time of inactivity be swapped out.
Also, stopping and starting services does consume resources, so that should be avoided.
I would argue that asking the user whether or not to start Akonadi (does it really do this?) is a very bad idea. KMail could just start Akonadi when it is first needed.
Never ask the user unless you absolutely must. The user doesn’t know, and the user doesn’t care.
What you should be going after instead is applications/services waking up and doing work when they should be peacefully sleeping in swap.
But the reality is that those services do not act that way but do use a lot of RAM and cause wake-ups. So until they behave they should not be hidden from the user and waste his resources.
If they do behave, then I would agree. On the other hand.
May 6, 2011 at 00:08
If Akonadi actually has bugs that prevent it to sleep properly, fix them and do not introduce the biggest usability f*ckup in history by asking 10000000000 questions.
A some funny guy! Please read the post before showing that you did not get it by exaggerating instead of arguing. Ta!
May 5, 2011 at 20:54
Couldn’t disagree more. For a start, could you define ‘wasting’ CPU and RAM? If some code is leaking memory or has an inefficient loop that does some op that could be done out of loop then you could argue the code is ‘wasting’ these resources… (and your patch to plug the leak and move the op out of loop would be welcomed).
If however a process is doing a job and doing it efficiently then nothing is ‘wasted’. You might have a different view of the cost/benefit proposition of using resources to run the process but that is a different argument, and one that is nuanced by things like what the intended target platform is (modern desktop, legacy desktop, HTPC, tablet, phone, etc etc)
If you can’t get a configuration from a distribution that matches your device profile then that is one issue. If you are using a distribution targeted at one profile on a different (less capable?) one, that is another issue. If you are using an appropriately targeted distribution on it’s intended class of hardware then nagging the user over cryptic things like starting akonadai is just creating a dreadful user experience
Wasting is everything the user does not need. I do not need a lancelot app that has no client using it.
I do not need akonadi without any client using it but still occupying my RAM.
I do need a service as soon as the client needs it. You do not keep your engine on just in case you want to take a ride later on while sitting in the kitchen. You keep the car, but you tun it off until you take a ride.
May 5, 2011 at 22:21
In that same vein, you don’t turn your engine off when you’re coasting up to a stop sign to save fuel just because you don’t need to accelerate for the next 10 seconds; it is a pointless inconvenience that is outweighed by the minor benefit.
In the end, car analogies are useless here as the resource usage discussion is distorted by the lack of similarity between the situations. When something sits in my RAM without being accessed it is mapped off to virtual storage; my car won’t start burning ‘virtual petrol’ were I to leave it on in the driveway without using it.
You still have to address the trade off between usability and the target platform. Modern desktops have lots of resources. I don’t want my machine to be sluggish when I ask it to respond because I was stingy on sparing a few CPU cycles letting strigi do its scanning in the background or for my mail client to be slow to start because I was tight fisted with my RAM and couldn’t spare some to keep a service idling in the background.
If your hardware is so limited you can’t run a full modern desktop, don’t try to run a full modern desktop on it. Pick a lightweight DE, find a distro that supports KDE on minimal hardware or whatever but please don’t try and push a bad UX on rest of the wold because you happen to think every process should ask your permission first before starting.
In fact you do! Modern cars turn off the engine as soon as you are at a traffic light and start again if it turns green, i.e. you step on the pedal.
And again you assume that every KDE user is using kdepim and thus akonadi. That’s simply not the case.
I have two GB RAM and I see akonadi taking a few hundred MB not releasing it after I quit kontact.
And please don’t make yourself look silly by exaggerating. I never said anything about every service but about those that are useless and/or big.
And btw. it was about stopping, not starting…
May 5, 2011 at 23:00
Stopping at a red light is not the same as coasting to a stop sign but to address your straw man, I hated the BMW that I tried that did this; it made bad choices about when to go into fuel saver mode and restarting was slow. Especially notable in stop-start driving to work. Search the web on this topic and most the articles that aren’t marketing are people asking how to turn the ‘feature’ off.
I make no assumptions about people using KDEPim, but developers using things like contacts make assumptions about it being there. I have only 1gig on the work machine I’m typing this on and not one of my 11 akonadai processes is using more than 3 meg.
Please don’t make yourself look silly by suggesting dreadful solutions to imagined problems and perhaps learn to take a little hyperbole with a grain of salt.
btw, starting is what it would need to when required again after it had been stopped.
Again, you have to address what the expectations of a modern desktop experience provides on modern hardware. If you don’t want a modern DE and/or you decided you can’t trade off the required resources then find something that addresses your requirements rather than trying to get a bad UX decision implemented on the rest of us.
A modern desktop is supposed to take smart decisions and not just rely on a lot of resources.
May 6, 2011 at 00:12
They do. Processes go to sleep. The kernel swaps pages onto disc. This is how modern systems work, it’s what kernel developers spend hours working on and what application developers rely on.
Tuning the aggressiveness with which memory is paged, setting nice values etc is what distros do fine tune the experience. There are a lot of moving parts and not all of them are always in sync all the time, but falling back to essentially a non-multiprocessor approach is throwing the baby out with the bath water.
May 5, 2011 at 23:21
“A modern desktop is supposed to take smart decisions and not just rely on a lot of resources.”
Absolutely true.
But whey do you then build a dump dektop, and force the user to take the smart decisions?
No, I notice that smart decisions are not taken by the applications but instead they just rely on more and more resources.
I also notice that this is seen as “best practice” and not fixed, e.g. the lancelot dev claimed that leaving lancelot in memory still causing wake-ups would be the best/smartest solution.
Thus I take the reality approach and do not dream of properly behaving services but rather stick to user intelligence and control.
And it’s not the desktop, it’s a few services which can get quite annoying. Just google for things like beagle, tracker, nepomuk+strigi and other services that are running in the background and supposed to not bother the user. Again, you can wait until they get fixed or simply ask for a possibnility to let the user control them.
May 6, 2011 at 00:16
They don’t rely on more resources and quitting a service that has a long start time because it is not immediately required is not making a smart decision.
There is an expectation for the full desktop that a reasonable amount of resources available. There is also a reliance on OS mechanisms to minimize the footprint of a sleeping service. Sure, there can be issues in the service that stop it from sleeping when it should otherwise and thus prevent the OS from doing its job and getting it out of the way and they need to be fixed when they occur.
But it does not work that way. Reading email, i.e. starting the app and clicking on some email, with kmail1 is faster than with kmail2 although akonadi was already started. so it’s currently simply not true that keeping the service in memory saves start-up time or RAM since kmail does not have to take care of storing etc. And the users need control now and not in some years when there have been resources to get the service out of the way.
I am repeating myself but if services would really not bother the user and users would simply enjoy their functionality, how come that that many users ask on how to disable them. In fact, if they behaved I would not have stumbled across them, would I?
May 5, 2011 at 20:58
I am 100% with Joe on this one.
An idle database uses no processing power. All your arguments about wasted CPU are completely invalid. As for the RAM, I would like to see some kind of evidence that backs your claim up.
There is no option to disable akonadi because KDE PIM *depends* on it. With nepomuk dolphin (and everything else) can just about work without it. It’d be like having a button to say “make my computer work”, “make my computer not work”. Stupid.
So everybody using KDE used kdepim? What if there is nothing using akonadi, why would it be needed? Same for lancelot. This is not about whether akonadi should be running while clients accessing it but about it stopping if there is no one using it.
regarding the RAM. Did you ever open a folder with a few thousand emails and watched the resource’s RAM consumption. It stays there if you quit kontact. And what about mobile devices? How much RAM do they have?
May 6, 2011 at 00:12
Someone who after two years still hasn’t got the memo about the KDE rebranding and still refers to the Workspace as “KDE” shows that he actually has no clue about what he talks about.
That’s your argument against “stop services that are not needed by any clients”? Seems a bit off to me. 🙂
May 5, 2011 at 20:59
Users don’t enjoy to be the sysadmin of their computers, they should instead ejoy the great KDE user experience.
May 5, 2011 at 21:01
I disagree as well. one further reason is that imho by now computers are way more powerful than what most “home users” actually need, so wasting a bit of ram and cpu isn’t really a problem.
Define a bit? A few hundred MB?
May 5, 2011 at 22:43
I have 11 akonadai related processes (contacts, some google plugins and the usual maildir tasks) running and none of them consume more than 3mb, with the average being 2.2mb. Also, they are all asleep most of the time (not running kmail at present).
Sorry for the formatting:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
rabauke 9612 0.1 0.2 56880 5120 ? Sl 18:39 0:00 /usr/bin/akonadi_control
rabauke 9615 15.3 1.3 404880 28644 ? Sl 18:39 0:21 akonadiserver
rabauke 9619 20.7 5.4 294748 112496 ? Sl 18:39 0:28 /usr/sbin/mysqld –defaults-file=/home/rabauke/.local/share/akonadi//mysql.conf –datadir=/home/rabauke/.local/share/akonadi/db_data/ –socket=/home/rabauke/.local/share/akonadi/socket-linux-ly0d/mysql.socket
rabauke 9641 0.4 1.3 388208 26756 ? Sl 18:39 0:00 /usr/bin/akonadi_imap_resource –identifier akonadi_imap_resource_2
rabauke 9642 0.3 1.3 392276 27072 ? Sl 18:39 0:00 /usr/bin/akonadi_imap_resource –identifier akonadi_imap_resource_3
rabauke 9643 0.0 0.9 204652 19476 ? Sl 18:39 0:00 /usr/bin/akonadi_agent_launcher akonadi_maildir_resource akonadi_maildir_resource_1
rabauke 9644 0.1 1.0 284652 21860 ? S 18:39 0:00 /usr/bin/akonadi_maildispatcher_agent –identifier akonadi_maildispatcher_agent
rabauke 9645 16.5 22.8 739728 470212 ? S 18:39 0:22 /usr/bin/akonadi_mixedmaildir_resource –identifier akonadi_mixedmaildir_resource_0
rabauke 9646 0.1 1.0 291368 21056 ? Sl 18:39 0:00 /usr/bin/akonadi_nepomuk_calendar_feeder –identifier akonadi_nepomuk_calendar_feeder
rabauke 9647 0.1 1.0 288648 20924 ? Sl 18:39 0:00 /usr/bin/akonadi_nepomuk_contact_feeder –identifier akonadi_nepomuk_contact_feeder
rabauke 9648 0.8 3.4 525220 70168 ? Sl 18:39 0:01 /usr/bin/akonadi_nepomuk_email_feeder –identifier akonadi_nepomuk_email_feeder
rabauke 9649 0.1 1.0 280356 21988 ? S 18:39 0:00 /usr/bin/akonadi_pop3_resource –identifier akonadi_pop3_resource_5
May 5, 2011 at 23:11
Top is close to useless when trying to judge memory used:
http://www.kdedevelopers.org/node/1445
Nope, it does give a hint and that hint is obvious. And if you do not believe that: I can see swap space increasing, so if there is nothing taking more and more RAM why would that happen at the same time the RAM usage increases. I guess because swap is filled with “not used RAM” and the kernel fools itself! Come on!
May 6, 2011 at 00:22
No, it doesn’t give mush of a hint, read the article I linked.
There is a difference between “top reports back that akonadai is associated with a lot of RAM (most of which is shared)” and “something is using lots of RAM to the extent that my system is swapping”
“I guess because swap is filled with “not used RAM” and the kernel fools itself! Come on!”
don’t put words in my mouth and then try and call me out on them. Try understanding how shared, resident, allocated and virtual memories work in a *nix environment instead
Please follow my logic. If there is nothing filling up RAM swap does not get used. I can leave my system on for days and no swap is used although all kinds of services are running. Now akonadi is turned on and suddenly swap is used. Why if akonadi does not occupy RAM? Can you follow me on that one?
May 6, 2011 at 00:49
replying to this:
“Please follow my logic. If there is nothing filling up RAM swap does not get used. I can leave my system on for days and no swap is used although all kinds of services are running. Now akonadi is turned on and suddenly swap is used. Why if akonadi does not occupy RAM? Can you follow me on that one?”
Not really…. or at least its not an argument by itself that means anything. I have no idea if you had used 99.9% of your available RAM guaranteeing that the next thing started would push you into swap.
I certainly doubt that you had a machine that was sitting there doing nothing for days with all the other services running and hundreds of meg of unused RAM that you did nothing else to but go into akonadai control, start the service and then all of a sudden you were swapping. What was the amount of free RAM before you did this experiment? what was it after?
Yep, that’s what happens. I have about 1 GB of free memory and supposedly a lot more since top shows too much used memory. No swap was used. I then started kmail and akonadi and clicked on some folders with emails in them. Memory usage increased within seconds until swapping started. If akonadi and others would not have filled the empty RAM, why would there be any swapping that leads to 26% of 4 GB swap being used? It would just be silly to use 1 GB swap if there was still plenty of RAM left. I can fill the empty RAM with firefox processes until almost 100% and no swapping starts because everything fits. So if akonadi would fit my 2 GB RAM swapping would not start either.
May 6, 2011 at 13:02
Correlation != causation. The most you can say from your ‘research’ is that opening kmail and browsing mail is correlated with a spike in memory use. Akonadai links to a host of libraries to work and uses a number of other services as well.What evidence have you got that it is akonadai that is causing the spike and not some other lib or service that is triggered by akonadai or the kmail client?
I’m finished with this conversation; it’s your blog so enjoy getting the last word in, but I’d suggest in the future if you want have a conversation like this you do it in the appropriate mailing list first instead of ambushing the developers in a more public forum like a planet aggregated blog. I showing a little courtesy to much to ask? Maybe you should reserve your aggregated blog posts for discussing your contributions and achievements?
May 5, 2011 at 21:06
I agree with Joe and also disagree with this post.
Akonadi provides core functionality for KMail. KMail should always start it if it’s not already running without ever bugging me about it.
Yes, it would be a useful feature for Akonadi to be able to know if there are applications using it and shut itsself down accordingly. It would also be useful to have a checkbox in System Settings like for Nepomuk. But adding extra questions that 99% of users will not understand (Ok, I know what Akonadi is, but how do I know if I have other applications using it??) is the wrong solution.
Akonadi would tell you what applications use it. And if I understood you correctly you agree with me that the user should have a choice to shut-it down if he does not want to use it (as for nepomuk) and that it should quit itself. None of these things happen.
And none of this works for lancelot either which does not even have this central role in KDE.
If Akonadi could tell me if there are applications using it, why can’t it or the application being closed figure out without my help whether it needs to be running or not?
May 5, 2011 at 21:11
I also have to disagree. Users should not need to worry about that sort of thing. Perhaps having a way to override it makes sense, but certainly not having a popup message by default.
And definitely not when starting a program like kmail, which won’t not work without akonadi. It is like asking “You just started your email application. Do you actually want to use the application, or just stare at the pretty interface?”
There is a reason the helper in Microsoft office was considered such a mistake. Users don’t want to bothered with random questions while they are trying to do something.
If there is a problem with applications not knowing when they should start or strop, then those applications should be fixed, the users shouldn’t need to handle it.
Want to bet that if I file a bug about akonadi not quitting if not needed anymore it will be closed as wontfix?
It did already happen for lancelot! And thus I state: If you as a developer are not able to do the right thing, then and only then, ask the user instead of wasting resources.
And you missed the main point of the post which is about _stopping_ services if they are not needed and not about asking whether to start them if they are needed!
May 5, 2011 at 21:20
Did you ever read http://joelonsoftware.com/uibook/chapters/fog0000000059.html ?
I just did and I do not see how this makes it better to have some service around that uses hundreds of MB RAM or even less – but is of no use at all, even more so for lancelot.
As I said in my post: If you cannot make the right choice – which would be to vanish if not needed – ask the user. akonadi does not make that choice thus it should ask.
Assuming that consuming resources for no use at all, i.e. if no clients are around, is taking no decision and thus bad.
May 5, 2011 at 22:48
The user should not make these kind of choices. Almost no user knows or cares.
If Akonadi doesn’t work well it should be fixed. If the design is completely broken and cannot be fixed then throw it away. But you cannot expect a normal user to care.
May 5, 2011 at 21:25
Why not simply give an “option switch” to turn notification on or off.
But being notified of all processes is not the way I would like my system to be setup.
Certainly not! This is not about all the small process the do the right thing and only appear if you need them or are crucial such as dbus. It is about services that are useless because there is nobody using it but still occupying resources. Only those!
May 5, 2011 at 21:46
To be honest that sounds not like a good idea to me.
If I start kmail, I don’t care about the services it needs to get my work done. I don’t want to get asked if I want to start any service. I expect KMail to know on its own what it needs. But you’re right, if a service is no longer needed, it should suspend until needed again.
Lancelot is somehow the same. After I added it somewhere I expect it to be ready for use any time. I don’t want to click the menu icon and have to wait until a certain app has started. Lancelot should have aready been loaded. But again, you’re right, concerning removal. If I remove Lancelot, I want it to get disabled as well.
But if you really want, you can implement an akonadi module for systemsettings to start/stop the service, like for nepomuk. I would use it quite seldom, but maybe it would make sense to have it. Just in case.
Exactly! If they are used they should be ready. If nobody is using them, they should vanish. Easy and straight-forward.
May 5, 2011 at 21:48
“a) to have akonadi in memory just in case there is some other app using it or b) let the user take a decision which takes two seconds”
Neither.
Because the *is* a “right thing to do” here.
It would be:
c) Make Akonadi keep track of which applications start/stop using it – and if the last application stopped using it, quit.
And never bother the user about it, neither when starting nor when quitting.
(Of course a global system settings option should be available, maybe even set to true by default, for always keeping Akonadi pre-loaded (which would naturally override automatic quitting).)
I fully agree with the previous commenter:
Bothering the user with this kind of stuff is just plain wrong, especially if you want your software to (also) target average computer users (which, unless I’m mistaken, is the case with KDE).
May 5, 2011 at 23:07
But thats not the right thing to do. I don’t want a service to stop that will then just have to start up again next time an app comes along that needs it and instead of my app starting quickly and connecting to the already running service I then get to wait for the service to start also (something that may take an order of magnitude longer than simple app that just needs to access my contacts list)
What should (and does) happen is that the unused service should go to sleep and, as memory needs demand it, get mapped off to virtual memory, freeing up RAM until it needs to be mapped back into main storage.
In Kmail1 times people closed their email app and everything else was gone as well. When they wanted to read mail again they started the app again. So why would they now suddenly not do the same thing and expect some service to stay in memory even though it is not used? Kmail1 did not even have a service and people did not complain about that. And it’s not even like email reading got faster because of akonadi (that might change) but starting kmail1 and getting data from it’s non-service is a lot faster than kmail2 with akonadi already running.
So I do not see how one can claim that one saves some start-up time by using akonadi as a permanent service instead of just starting it when needed and shutting it down when not.
May 6, 2011 at 00:34
In kmail1 times kmail contained all the functionality for talking over the various mail related protocols directly and managed the caching and storage associated with those protocols itself. And was also a nearly unmaintainable. Now akonadai handles the protocols and caching and kmail handles being a mail UI and both are much cleaner for it, easier to maintain and better engineered (each does a smaller set of tasks and specialized in doing those tasks). Other apps can now reuse the services that akonadai offers that used to be ‘trapped’ in kmail and are just starting to (the sprint travel org app that was on the planet the other day for example)
No one said it saved start up time compared to k1; I said stopping and starting the service everytime an app needed/was finished with it would be slower than leaving it running, which shold be self evident.
Yes, the latter makes sense but is of no value if the overall time the user spends until he can start working was increased. And that is the only thing the user cares about. so he got a slower “start” until he can read emails. He lost control over yet another service. And he enjoys that? He does not care about it? He does not notice it? As with nepomuk? There might be heroic aims but the user is confronted with those applications today and I do not see what the user gains by not stopping the service today. Even more so since I stated: “if no other app uses it”. So if there are apps using akonadi, fair enough. But we are talking about the use-case where nothing makes use of it or at least large parts of it. What exactly did the modern desktop offer the user in that case? And what did it cost the user?
And you said “[…] and instead of my app starting quickly and connecting to the already running service I then get to wait for the service to start also ” You sum-up the time your app takes to start and the time you have to wait until the service starts. Those two result in the time before you see the data. I pointed out that in case of akonadi the time until you see your data increased although the data was already in memory, i.e. akonadi already running, if you use kmail2. It should also be self-evident that from a user’s point of view that is no improvement and certainly nothing to enjoy. Theory is one thing, actual apps another.
May 6, 2011 at 12:32
you did not say “…in case of akonadi the time until you see your data increased although the data was already in memory, i.e. akonadi already running” you said “So I do not see how one can claim that one saves some start-up time by using akonadi as a permanent service instead of just starting it when needed and shutting it down when not.”
Starting a service and an app at the same time is always going to be slower than starting an app alone.
It really does not make sense to continue before deciding whether users do care about how it works or not.
I’ll just take the suggested approach and claim that the user does not care about why it takes longer, he is just annoyed that it does take longer, no matter whether akonadi was already running or not and not matter whether it is some library used by akonadi or something else.
Of course that contradicts that one should care about whether it’s 100 or 500 MB as a user before claiming that it’s too much and that one should care whether it is really akonadi or some lib it uses.
But somehow I feel that one has to decide whether users should care or not. Whether they should just think task-oriented and base their judgment on that or technical.
If they don’t care about the technical background and just assess the result: in this case I can prove a slower start-up time (bad) and I claim a bigger memory footprint for the use-case of reading emails on my computer.
Since you did not tell me how you measure your claimed 3 MB I cannot get any results from my desktop to prove that the same measurement tools lead to much higher results.
May 5, 2011 at 23:05
So DBus has a nice functionality called auto-activation. When a program asks something of a D-Bus service, D-Bus is capable of starting it automatically and let it reply. Most well-behaved services that are potentially not needed all the time do not start if nothing needs it, and after a while of not being used, exit. As long as Akonadi behaves that way, it should indeed not matter for the user at all, asking the user if an implementation detail should be activated is nuts.
Let me give you an example: my IM client, Empathy, uses a D-Bus service called telepathy-gabble to provide XMPP connectivity so that I can chat with my jabber friends; it is automatically started by D-Bus when services are asked of it. Other clients (like GNOME Shell) can also hook into telepathy-gabble and do stuff with it. When there are no applications using it for a few seconds telepathy-gabble exists. Sounds sane, right?
If Akonadi is chewing a huge amount of resources when it’s used by tiny applications once in a while, then it’s shit and needs to be replaced (the same probably goes for, say, tracker, nepomuk), no point in putting the burden on the user because the technology sucks.
I fullly agree with your point of view.
Even though you also got stuck with this post being about “starting services” although it is about stopping them. 😉
And I would also prefer not to be asked but have a well behaving service. If however there are services that do not behave well, I prefer to be asked instead of having to shut them down manually.
May 6, 2011 at 02:35
On the telepathy example – missioncontrol is started as soon as you connect an account however it remains running as until you log out.
It completely falls into “rabauke’s trap” of as soon as a service isn’t needed any more it should (in his opinion) close.
May 5, 2011 at 23:06
“If an application is not smart enough”
then
a.) the developers are not smart enough
b.) the developers are lazy
c.) the developers didn’t have the time to provide a real solution
Most of the time it’s issue c. And it’s mostly because the UX is not the primary focus. Which is ridiculous for a DE project!
Apple is so succesful because the UX is their primary focus. And they take the efforts to provide a smart solution. Even if they need to cut features.
Agreed! But dealing with it by just adding resources seems to be the easiest way and thus regarded best.
May 5, 2011 at 23:34
Just adding resources is “b”.
Your “ask the user” looks like solution “a”. Although I’m sure it’s “c”, as I know that the PIM hacker’s are one of the finest (but lacking of people and time).
No doubt that developers intend to do their best. But users have to deal with akonadi even before there was time to make it behave. Same for nepomuk+strigi, same for beagle etc. And until then the user should have control which in case of akonadi he does only regarding starting but not when it comes to stoping or freeing the resources.
In KMAil1 times people could quit the email client and be done with it. this is not possible with akonadi + kmail2 anymore.
May 6, 2011 at 00:04
And still – asking the user is the worst UX possible.
Better stick with KMail1 until this issue is done in a more properly way.
Hmmm – on the other hand makeing this absolutely stupid UX increases the preasure on the developers to create a better solution 😛
May 5, 2011 at 23:47
Asking the user for every little thing is a very bad idea. It’s one of the (few) things gnome seems to do right…
I’ve seen my girlfriend figure out kde, and the only thing she seems to have problems with is the random pop-ups of which she doesn’t understand what they’re for. Please don’t add any more of those…
If a service is no longer needed it should be stopped automatically (if there is a use case for it there could be a configuration option to change the default behavior). Moving the responsibility of applications to the user seems to be a very bad idea…
akonadi is not “every little thing” and there would be no need if it stopped after it noticed that nothing is using it. But that’s simply not the case. Same for lancelot. So the choice is unfortunaltely not “have a smart app” or “ask the user” but rather “ask the user” or “have services in memory that are of no use”.
That’s how it is. I also wished for a moon on a stick but that’s not going to happen anytime soon. And until then I prefer to stay in charge of my resources.
May 6, 2011 at 02:49
The current situation is this:
You think akonadi has a wrong approach (leaving the process running), you suggested a single solution that everyone else thinks is a different wrong approach (pestering a user).
You’ve completely ruled out “have a smart app” simply because it’s not in place yet. If I was an akonadi developer this _really_ wouldn’t be a high priority right now. Highlighting problems is ok, stating the first alternative you think of as fact gets arguments.
Automatic shutdown of akonadi services might be a viable solution, (ref counting people using it is pretty do-able) as is selective startup (so Lancelot only starts up calendar resources for example).
You’re not backing down and this makes you just as bad as the people you’re criticising.
As for services, there are (according to Service Manager) 25 things running that I’ve never heard of, and never want to hear about monitoring for me pressing the “eject key” and bluetooth, and freespace notifiers. I don’t even have a CD drive, but I’m damn glad I haven’t had a popup telling me asking if I want to run the drive ejector or not.
(before you tell me you don’t have them, all the kde services run under a single PID called “kded”. You’re probably already running a lot more than you think)
To quote myself: “If an application is not smart enough to know what the right thing to do is […]” I never claimed that what I write is about smart services that the user won’t notice.
How did I rule out a smart service? Just read the bit about Lancelot where I write that it would be ok, if it was smart enough to close if not needed. And how am I not backing down? I want users to be able to stop akonadi as they can stop beagle/nepomuk and so on because for now that is needed exactly because akonadi is special as it is bigger than all the kded services which never get in my way. And to repeat myself. If akonadi would not have come into my way – as the kded services – I would not have noticed it, would I? So how come one can claim that there is no time now to make the service behave but it is also not right to allow the use to easily stop a service that does not yet meet the goal of not getting in the way.
Trust me, I would be the first one to cheer if it worked as it is supposed to – but it does not yet and until then I do not think that giving the user no choice is the best way to go.
And the fact that people keep returning to argue with small services and not getting in the way services which I ruled out in the post seems to indicate that they miss the point of me talking about now and akonadi, i.e. immature, big services and not the ones behaving.
PS: Just to make sure people do not get hung-up on it again. By “no choice” I mean the choice to start and stop e.g. via systemsettings and not only cli and not using kdepim without akonadi.
May 6, 2011 at 15:02
what about a config option somewhere,
that if you wish for Akonadi to remain in memory incase you use kmail or the likes often, then it will.
or if you are not a heavy user that it will release itself after the parent/current applications using it have terminated.
this way no annoying notifications, most users will be happy with defaults as shown above, but for the users that care about their memory usage then they have the option to change this.
could this be a viable compromise?
i don’t see why this would be so hard to implement.
May 6, 2011 at 15:31
One easy improvement would be to autostart Akonadi systemtray integration with the workspace session.
This would allow easy manual starting/stopping.
Since Akonadi is already started on-demand, adding shutdown on-lack-of-demand quite a good idea IMHO.
Most information for that is probably already available in Akonadiserver (established data connections). The only thing missing is a way for only D-Bus using clients to register their need with Akonadiserver or Akonadicontrol.
Probably a bit too late for the Akonadi release which targets KDE’s 4.7 release, but that should make it easier for anyone who wants to try to get it done properly.
Any takers?
Sounds good to me. Even if the akonadi server stays alive it could shut down the resources that have no clients, i.e. the contact resource would stay alive while the kmail-folders-resource etc. is shut-down if there is no mail client accessing it.
I would really like to see that akonadi people take care of marketing their software in a way that it does not suffer the same feedback nepomuk or kde 4.0 got when they were released. As funny as it sounds, but to be able to turn it off, e.g. for those that do not use kdepim or anything else using akonadi, does help. Personally I am looking forward to see a service that improves the PIM experience in a smart way.
May 7, 2011 at 15:55
MIME type based or even folder based decision on shutdown might be doable, but almost certainly magnitudes more work on the server and even additional work on the clients.
Keeping running as-is and fully shutting down on last client vanishing looks a lot more viable to me, at least short and mid term (though one can never rule out someone new showing up for this kind of work).
The marketing might need more work, e.g. there seems to be a misunderstanding on target group (developers, not users).
Additionally almost only PIM developers have made use of it up until now, making the gain for users non-obvious at best, totally undetectable at worst.
Usage by non-PIM apps and better workspace intergation will hopefully solve that within the next two or three release cycles.
May 6, 2011 at 21:45
As far as I understand, akonadi should work like this:
1- You turn on the pc, akonadi might or might not be started as a process, but regardless it should not eat more than the 1 or 2 mb that’s needed for the process.
2- You open kmail, all the data from it is loaded on real ram, occupying real space (depends on mail quantity, a few hundred mb possibly).
3- You close kmail, ram is freed but still kept in the buffer, free for any other app to use, only using those 1 or 2 mb for the process.
So akonadi does not need to “stop” it only needs to free unused ram, but keep it in buffer, so if you have 4 gb of ram, it’s kept there mostly for ever, only showing in “mem” file of free command, but not under “-/+ Buffers…” (I mean that even if it uses 600mb they are not summed up in “free”, as they are only in the buffer). And if you have little memory, this is rapidly used after being freed, so that kmail data is not even in the buffer anymore.
About the little akonadi using plasmoids, if a plasmoids needs the ,maybe, 10/20mb of “this month events” data only that should be put into real ram, if the plasmoids tries to fetch all months data or something like that, the plasmoid is wrong designed and should be fixed to only fetch relevant data.
In conclussion, if akonadi works well enough (freeing ram when it’s not needed, and not using even 0.001% of cpu unless there is some query), then everything should be fine.
After all, akonadi is just a very small layer between an standard database(also some other stuff) and the apps, so it should not bother anyone.
PD: Also make it possible to permanently turn it off for minimal users, who don’t like that 1/2 mb used, or wan’t to disable akonadi features in things like plasmoids, etc.
May 6, 2011 at 22:00
PD2: AFAIK akonadi uses nepomuk for search, so akonadi ram usage might be misleading, as it might be putting stuff into nepomuk.
June 11, 2011 at 11:15
Seems to be part of a general trend towards assuming all KDE end-users are idiots in the KDE developer community. I remember back in KDE3 days when one of the great things about KDE was that the user could configure everything. And I mean EVERYTHING.
Whilst I agree with offering sensible default settings for everything, not pestering users too much, and maybe hiding the more esoteric settings for an application in some ‘advanced’ tab of a settings dialogue somewhere, I resent the fact that the degree of control I have over what my KDE system does is being gradually reduced. If I want to do something stupid with my desktop, I should be able to, even if I do then have to fix it later.
In the scenario above, it is entirely possible that a user is running KDE but not using any apps that use akonadi (e.g. if they do all their PIM using mozilla tools or web-based tools). It may be that a user is on a laptop with limited battery life. It may be that the user has an old system that doesn’t really have the necessary resources to keep akonadi going as a background thing (admittedly maybe they shouldn’t be trying to run KDE4 in this case). Thus the user should have some degree of control over when/if akonadi is run, though it is reasonable for those who don’t fit the ‘default’ user case to have to hunt a little to find the necessary settings.
My KDE week 
May 5, 2011 at 18:48
Excellent idea. I think we could generalize this: we could extend dbus-daemon to support prompting the user before service-activating any service that isn’t running? So the application could just call methods on a service, and if it’s not running, rather than being silently launched, a dialog would be shown asking the user whether to go ahead and start it, or to return an error to the application.
We could extend the D-Bus .service file format to include user-readable descriptions of daemons—or maybe it could be pulled out of the Apt package descriptions.
May 5, 2011 at 22:43
It’s understandable to forget about the first paragraphs if one reads a long text but it hinders understanding nonetheless.