Every so often (this is today's theme ;) I hear someone say something along the lines of, "I don't need Nepomuk Desktop Search. All my files are properly arranged in a neat folder hierarchy. I am not in need of any help with that, so Nepomuk is a waste of resources and I don't care to have it installed."
I am sure that such people are right about one thing: they have their files highly organized in a great filing system that they use with a great degree efficiency, and as such don't need something to index those files for them.
Nepomuk, however, is not about indexing files, at least not exclusively. It is one things Nepomuk can help you with, but they call it a "social-semantic desktop project" and not a "index your files project" for a reason.
Nepomuk is being used more and more to track, coordinate / orchestrate and index non-"files on my disk" data. Let's take two examples: Akonadi and the Plasma Desktop.
Akonadi is using it to provide search for email, contacts, events, etc. which is one step away from the "file indexing" idea. Instead of building its own search database (and all the overhead that implies), Akonadi is able to lean on Nepomuk for that and, as a bonus, be able to not only index but map the correlations between those sets of data which, as a human being, we'd expect to be there and have at our fingertips.
The Plasma Desktop is going even further with Activities. We now have the ability to store, retrieve and mark as "active" which desktop activity you are working on. There is no file anywhere that maps to this. KWin will be gaining the ability to map windows to these activities, and any other application (KDE or not!) can also choose to map internal data and settings to activities and take appropriate action when the Activity context changes. The mechanism that ties this together? Nepomuk. Since we're using Nepomuk, we get the ability to tie documents and other URL based locations together with Activities as well .. for free.
For me, Nepouk's ability to index my files is a nice feature. It's also one I currently have turned off due to personal preference. Nepomuk's real feature comes in the form of all the indexing and, more importantly, correlation services it provides for all the more ephemeral data and workflow that happens on my computer. Right now Nepomuk is using less than 2MB of unshared memory on my laptop (yes, including the Akonadi bits). That's a fair price in my eyes for that functionality.
Critiquing Nepomuk as a file indexer is therefore selling it short and missing out on the real opportunities it represents. Those opportunities only grow as we exercise one of the attributes that KDE has long been known for: our ability to integrate technologies horizontally across our applications and libraries. The more we use Nepomuk for the things it was truly designed to make possible, the more we'll see the benefits beyond it being a file indexer.
Subscribe to:
Post Comments (Atom)
148 comments:
I don't think people know how to put it in technical terms. I think what people really want is a choice of whether or not to have a "social-semantic desktop" and with nepomuk, shared desktop ontologies and various other semantic desktop packages being required and KDE applications being severely handicapped if not working at all then the social-semantic desktop is being pushed down the throats of those who do not understand it nor want it or feel a need for the 200+ Meg of memory they seem to take up on the system.
No one has really taken much of the time to really put any benefits for Akonadi, Nepomuk or any of these great features, in user terms. Or for that matter given clear examples of there worth on a common desktop users machine.
This is the reason you're seeing the back lash you are, because when I can no longer run KDE 4 on a compressed environment with anything less then 512M when with KDE 3 I had no issues what so ever. The not understood features or clearly defined features are going to be the first thing in my mind that's going to get blamed.
If users (even packagers) understood the benefits of the social-semantic desktop maybe even had an option to run applications without it and compare KDE 4 with it or without it then maybe you wouldn't see such comments and the work would be more appreciated and less of a scape goat for any resource issues.
@JMiahMan +1
I think you missed the big point here Aaron.
The problem most users have with that horrendus CPU and DISK INTENSIVE (for people who do not use/like, I am just interpreting them) is that you simply have to take it down your throat without option, as it is enabled by default, and mostly is a pre-requisite to use KDE as a whole.
Most of those nice, next generation services are great for some people, mut in real-life in a country were great computers are really expensive, here comes my advice: think about using less resources all the time, when making decisions on the software design.
Or learn to hear: I hate neopomuk and Akonadi ;)
I tend to agree with that sentiment. I dont think you can easily convince people like me that they'll ever need nepomuk. But your examples in this article make use of applications i have no particular use of either. I dont search for anything using the KDE provided searchboxes and i dont use widgets on my desktop. I just want a plain old, clean desktop.
Judging from what ive seen around the world wide web, its people like me who "dont need no stinking nepomuk..". People who want to use KDE 4.x.y as a traditional desktop for whatever reason.
The question is whether KDE is willing to provide that.
I think the answer is no its not willing as it shows in latest releases of SC.
Personally I love the idea of a semantic and social desktop and I feel that gnome and KDE are at a stage where the technology is there and the applications are only now starting to take advantage of it.
That being said, I have only switched to KDE recently after being a long time gnome user so my understanding of nepomuk itself is a tad remedial.
Trying to understand exactly what nepomuk tries to achieve is a bit strange too as everything is tied together.
On the gnome side for example you have tracker for indexing and a separate independent framework called zeitgeist which utilizes the filesystem's journal in a new and intriguing way.
I can't help but wonder why we don't use a something like openbfs to reduce the complexity and increase efficiency of the nepomuk goal.
The argument against this before was that you needed to have it work with multiple filesystems but I find myself asking why?
At the end of the day your either looking for a good server filesystem or a good filesystem for the desktop and openbfs is the best one for the desktop.
If you want a server based system then your not going to use openbfs or nepomuk so why accommodate them?
If everyone from nepomuk side and everyone from the gnome side got together to work on openbfs the world would be a much better place :D
@JMiahMan - disabling indexing doesn't solve the performance problems? There were a couple of times I had to do that (although mostly it took care of that itself) but otherwise I haven't seen any performance problems (1.2 GHz Pentium M with 512MB RAM, so nothing special). But sure, maybe we need to communicate the use cases better - but the problem to some extent is that first you need the infrastructure before you can start using it in interesting ways. However, it is arriving - file search, which is only a small aspect, has improved a lot with 4.4 imho.
Going back to Aaron's initial point - well, I do try and organise my files quite well and I mostly succeed. However, I have a lot of separate projects at work and some files are relevant to more than one so I'm finding tagging useful. More importantly, some of my contacts send me emails with really useless subject lines, dealing with several different issues/projects. To have them easily findable I can either make multiple copies in folders for each project or (I hope, in 4.5 with Akonadi and Nepomuk) just tag them. Tagging seems easier.
We saw pushback against things like Phonon too, but now you can preview video and play audio right from Dolphin (I assume that's Phonon?).So now there's no need for a simple, single file audio player - Dolphin can do that.
There still needs to be some performance work to be done on Nepomuk/Akonadi/Kontact/Virtuoso
While I like what it does, it also can used huge amounts of memory. For example, over the last several days, I was creating some DVD's, some with Devede, and a couple with DVD Styler. Nepomuk ended up using up nearly 1GB of RAM by the end of the day. That to me is outrageous and immediately disabled it.
Until Nepomuk/Virtuoso uses the least amount of resources possible and, only then do I think it'll gain widespread acceptance.
@Iuri Fiedoruk
Exactly that is the problem with the users, it is not nepomuk that indexes your drive, it is strigi.
You can disable strigi, keep nepomuk and you don't have a crippled system in any sense.
@JMiahMan, Iuri and MrRtd: Now, evidently either I'm writing extremely poorly or you are reading very clearly. Both are possibilities, of course. I say that because the entire point of the blog post is that Nepomuk isn't simply about file indexing. File indexing is one thing one can use it for, but it's not the only thing.
Your complaints are really related to the file indexing side of Nepomuk.
Of course, you can also turn the whole thing off in System Settings. Which makes all the comments about things being "pushed down the throats of" people pretty galling. If we wanted to push it down your throat we wouldn't make it optional, would we?
I agree with what JMiahMan says. But I also think part of it is that nepomuk is new and buggy. I don't use KDE's PIM suite because it's less user friendly than Google's equivalents. So you can tout that, but until it's got a nicer ui (nepomuk isn't needed to do that) I won't care. I've seen nepomuk used with a new media player called bangarang. Unfortunately the ratings it saved weren't consistent with the ratings seen in dolphin. This was a bug (that we couldn't find so my setup was blamed). Until nepomuk makes itself consistently useful and reliable in places like this (like sharing music/movie track ratings between apps) I couldn't care less about it. Heck you can't even access it from the menu which has a search bar (last time I checked) and I think it was amongst the plugins that would cause krunner to be unresponsive or crash. I know it was on the list of plugins I disabled to get krunner more stable.
basically to me nepomuk is currently buggy and not utilized in enough places to be useful.
@aaron: No I did understood your point. The point is that, just because, developers think neopomuk is nice for them to use in several cases, that do not meant it is good for users in any way :)
Each day it passes, I like less and less KDE4, because developers are always trying to integrate all those backend (and fat) services with their apps, so I can't just run kopete now, because I need (I am talking hypoteticaly) Akonadi, that needs Neopomuk and Strigi... that is a shame!
I understand how cool is to have a daemon keeping synced the contacts from kmail, kontact, kopete, etc... but what if I just want to use my good and old ICQ in kopete without this? Currently, it is no easy peasy to disable all those services and integration.
While I can switch to lxde to have a lightweight UI, it is a bit sad to see the path KDE4 decided to take. :-(
Man, I wished some guys had the will and time to create a simple DE based purely on Qt... :)
@Greg: "I dont think you can easily convince people like me that they'll ever need nepomuk."
Perhaps you don't. Many who think they don't might, however, and only think they don't want or need it because they think, mistakenly, that it's about file indexing, period. (Which it isn't.)
"But your examples in this article make use of applications i have no particular use of either."
Yes, if you don't use Kontact, the Plasma Desktop or other such applications and you don't need a file indexer you won't find much use for Nepomuk. Thankfully you can turn it off in System Settings.
"I dont search for anything using the KDE provided searchboxes and i dont use widgets on my desktop."
Actually, you do use widgets on your desktop, you just realize it. Everything you see in your panel or on your desktop is a widget. Everything.
People have been trying to map things they know to things we're doing and getting it right some of the time and really getting it very, very wrong the rest of the time. Sometimes we think we have no use for something (desktop widgets) when we are using them every day to check the time, launch applications, keep track of windows and desktops in the panel, use icons in the system tray, etc, etc.
"I just want a plain old, clean desktop.
Judging from what ive seen around the world wide web, its people like me who "dont need no stinking nepomuk..". "
What we're asking for is the opportunity to demonstrate the value of these things.
"People who want to use KDE 4.x.y as a traditional desktop for whatever reason.
The question is whether KDE is willing to provide that."
Folderview as desktop (check!), application launch menu like in KDE 3 (check!), ability to turn off Nepomuk, Strigi and others (check!) ... yes, seems like we're not only willing but actually providing these things.
"I think the answer is no its not willing as it shows in latest releases of SC."
What in the latest releases shows that? I'm evidently missing something here.
@MrMcQ2u: "On the gnome side for example you have tracker for indexing and a separate independent framework called zeitgeist which utilizes the filesystem's journal in a new and intriguing way."
It's the same kind of split in KDE: strigi (via libstreamanalyzer) for the indexing, Nepomuk for the semanetics. In fact, that split was first seen in KDE (in F/OSS, anyways; MacOS has (had?) some similar infrastructure that predates both). What's really cool is that the ontologies are shared between all the major F/OSS projects working on this, something that happened only recently. :)
"If everyone from nepomuk side and everyone from the gnome side got together to work on openbfs the world would be a much better place"
The missing link is "getting everyone to use openbfs". A filesystem is not trivial to get right and people are very, very conservative about adoption them. Rightfully so: they hold all your data.
It's probably a more efficient approach, but also a lot closer to improbable in the F/OSS realm. :(
If you need another good example of nepomuk usage: bangarang.
The entire library of this mediaplayer is using akonadi. I found out about it today, but it works great. The devs of this program got their library for free by using nepomuk.
Instead of amarok, which uses it's own database and has quite some performance issues on my systems, the library of bangarang is extremely snappy.
Could you please elaborate on those activities and mapping between them? What are they for and what can they provide? If you could point me to a video which shows some usage scenarios of activity-aware applications, I'd be very thankful.
Cheers
A technical term to describe nepomuk could be "central data manager", or something like that. AIUI, instead of two processes reading their files and sharing data themselves, we have a central process that receives the data, classifies it, and allows other processes to do advanced queries about that data. At the end of the day, I see it an advanced IPC system (in fact IIRC microsoft was expecting to replace COM with winfs)
Probably we should definitely more information about Nepomuk and Strigi, which are two completely separate frameworks.
It must be stressed that Nepomuk *can* work without Strigi, which is what takes CPU and memory when indexing/searching, and that you can limit the memory Nepomuk needs. So you *can* use Nepomuk without a relevant resource consumption, as long as you disable file indexing. Everything comes at its cost, after all.
I enjoyed the post, but I really think this point needs to be stressed more and more, because given the comments we're definitely failing in advertising it.
I wish the semantic desktop was completely optional (at compilation time), I don't even want to build its dependencies just to have them sitting down in my hard drive, wasting space.
This is one of the things I don't like about KDE 4.
Let me explain you something.
Why do you think everyone needs to have rating, tagging and notes attached to every file?
And another argument against is, why do we have to see annoying windows, telling us about Akonadi startup? This is corelated.
Or failed Nepomuk startup. Who cares?
User doesn't have to know anything about Nepomuk, Akonadi. If they have to stay, they have to be silent like a "church mouse".
Otherwise, you have to provide killswitch for this useless technology.
PS I stopped using Kontact with KMail when I was getting annoyed by useless Nepomuk and Akonadi windows. Now I'm quite happy with Opera as e-mail client and Netvibes as homepage combined with comfortable and faster than Akregator RSS reader (it wasn't also well integrated into Kontact and caused a lot of crashes).
Assuming: die Nepomuk! Or hide yourself.
In this kind of discussions I always have to think of the
minimalist backpack .
There is a type of people who want to live a minimalistic live and do not feel comfortable with luxury, simply because it feels as "too much". One could react very emotional to this type of behaviour (you minimalists are against progress!) but fact is that such people exist, they have a reason and we should try to live together. To cope with this difference in the way we use resources (computer resources in this case) it could be more productive to prove to the minimalists how memory efficient KDE4 can be. What would you think Aaron about holding a contest "who can make the most minimalistic KDE4 desktop"? I liked the plasma contest a couple of weeks ago (no time to enter myself but I followed it closely) so this could be the next contest.
Part of the contest would be of course the configuration settings (strigi switched off, desktop effects off etc.), distribution, installed packages and the resources used such as RAM, HDD space, processor speed, video memory etc.
I know you minimalist people out there can't wait to show your minimalist settings. Show it to me!
I think what is missing for Nepomuk is visibility. And I don't mean on the blogs, but in KDE itself. I know I have it running (without Strigi) but I just dont notice any of it! What does it give me that wasn't there before? And I'm not asking you to explain it to me, I think it should be obvious from using KDE.
Of course, I might be using it already without knowing it, but then the features it adds (that weren't there before, an app using it to store its data when before it used its own storage engine doesn't count) are just not obvious enough.
There have been quite a number of articles about how nepomuk is really useful, and I really try to dig it, but no article ever seems to be able to paint me a picture where I go "now THAT is useful, I'll go and try it out immediately"
But I'll happily go on waiting until I "get it" some day, I'm not in a hurry :)
I'm surprised to see so many people claiming Nepomuk gives them no added value. Personally, I find the promise of Nepomuk, KDE 4 and semantic desktop enthrilling. Unfortunately this has been so for the past 2 years.
Development seems to me to be heading in the right direction - semantic desktop sounds the more natural way to deal with entities in the computer. But people are used to the traditional way of interaction with the machine, the switch to a novel way is hard to make. Moreover, Nepomuk services are now being developed, and immediate benefits are not apparent. Until the framework and services become more stable and reliable, and the benefits become more prominent, objection to Nepomuk will stay. The point is, at this point of time Nepomuk may be a nuisance, but it is injustifiablly wrong to judge it now. If Nepomuk development fulfills the dreams presented here and elsewhere, these critics of today might find they have been wrong all along, and by a long shot - they might find out that semantic desktop interaction is the right way of doing things. It feels attitude towards Nepomuk now is as has been to KDE 4 in the beginning. That it is immature and present creates problems, that would subside as it matures and the advantages become more present.
Productively, it seems that there should be a better (i.e. more apparent) UI to disable Strigi and Nepomuk - perhaps as a question dialog at install time or when the computer is under heavy load/RAM usage because of Strigi. That people have to actively seek the system settings option might be a fault in this case.
KDE is not free of problems - in fact I can't use it right now. I was greatly disappointed in finding that Kubuntu 9.10 on an old machine with 512MB of RAM is hardly usable. Battery life on my laptop is not satisfactory, and I can't install KDE on Windows for some reason.
But the promise, and the hard work of all involved keep me assured that one day I'll be able to use my computers to their fullest using KDE (on Linux. And not any other DE). So this is thanks and keep up the good work.
No Arron your point came across well I didn't see a point..
I see KDE developers defending a technology that they've shoved down there users throats without it it being truly ready. Yes I can turn off strigi, I'm very familiar with that. Resources are still taken up however.
So turning off strigi allows me to actually use my machine. Thanks in that case congratulations. Is that is really the type of features, or the type of feedback I am getting back to fix an option (just turn it off) how are you any better then any other commercial project with crappy tech support. Well you're not.
Yes I get your point nepomuk can be used for stuff other then indexing but that doesn't fix or make up for the underlying system not being ready for prime time and like most of the KDE 4 series however it's been pushed on to users and the community.
To what point have the developers become so disconnected from the community that YOU think you know what's best. Ever stop and ask? Do I really need nepomuk, can you truly tell me what I want, well unfortunatly you have because I can't even run Kmail without akonadi, which depends on nepumuk desktop ontolgies and even mysql. Can't I have mail with out running multiple database backends?
If users have failed to undstand what nepomuk, stigi, akonadi and all the other strange names do that's your fault. If it seems too complex it is.
Is this the health care bill? why do all things have to mentioned as "shoved down our throats" ... I do wish that less things were tied into nepomuk and akonadi. I think that the connection is great where it's useful... but most apps should be able to function without support for it even built in.... I think part of what I don't like about it is that it's RDF but a lot of the data I see stored is relational. Seems like an RDBMS could have been a better, faster, more stable solution.
Akonadi is using it to provide search for email, contacts, events, etc. which is one step away from the "file indexing" idea. Instead of building its own search database (and all the overhead that implies), Akonadi is able to lean on Nepomuk for that and, as a bonus, be able to not only index but map the correlations between those sets of data which, as a human being, we'd expect to be there and have at our fingertips."
Can you show me how I can find this data? Because if Nepomuk actually has been finding correlations behind my back, it's not been telling me about it.
@drf: "I really think this point needs to be stressed more and more, because given the comments we're definitely failing in advertising it."
absolutely! :)
@John: "I don't even want to build its dependencies just to have them sitting down in my hard drive, wasting space."
how big is your hard disk?
@Livio: "Why do you think everyone needs to have rating, tagging and notes attached to every file?"
I don't.
"And another argument against is, why do we have to see annoying windows, telling us about Akonadi startup? This is corelated."
It isn't correlated with Nepomuk in the least. I do agree that the Akonadi window is in really poor form and that the KDE PIM project is, to be frank, struggling right now (despite being a corporate project!). They are making progress, however. In the meantime, I'd like that window to be gone as much as you :)
Still, this has nothing to do with Nepomuk.
"If they have to stay, they have to be silent like a "church mouse"."
I agree, and that's something we need to be doing better on.
"Otherwise, you have to provide killswitch for this useless technology."
The technology is not useless (no matter how many times you repeat it), but yes, we do have ways to turn it off.
For me nepomuk is buggy: even when not enabling file indexing(strigi), it consumes 40% of cpu or sometimes 90% lots of times.
If I leave it enabled, the machine starts to get slow from time to time, if I open top guess who appears there. I know it might be my distro or some packaging problem (I use arch with kdemod) but still, every time I had tried to use nepomuk it has deceptionated me. Maybe some day it will good enough but for now it's not worth the resources.
@damian why do you still use kdemod after arch split up the packages for kde (which would have been the #1 reason before, imo). Maybe nepomuk is buggy on arch? seeing as that's what I run... *thinking a kde dev ( like aseigo ) should install arch and test nepomuk w/ stuff like bangarang*
I guess this blog post is in response to my rude/harsh post.
*) The problem I tried to point out is that there is a trend to introduce many shiny new things, while the basic things dont't work. There were grave kdirlister bugs, which existed since 4.0 and lasted till 4.4 which caused many apps to crash. I think more manpower should be spent on the core (especially by the payed developers) before new shiny things are introduced, which will crash anyways because of broken core functionality.
*) The other thing is, I have deliberatly chosen to deactivate nepumuk. Why do I have to get nag screens each startup by akonadi that I have to enable nepumuk.
*) I don't use akonadi (neither for mail nor adressbook nor calendar), I use thunderbird and webstuff. I didn't opt in, that it should be started. Just because it's installed, doesn't mean in has to be started
*) Is it, because it is under development, or why does it start a lot of identical (unneeded) resource deamons and always, at each startup , migrate a default addressbook, which I don't use anyways?
*) Why does udevd cpu usage increase to about 50% all the time when kde runs, while it doesn't happen with gnome (battery live time goes down of course)
*) I mostly like plasma, but why does it with a "standard" setup, one activity, no special background, one taskbar and one folder view need 2+ minutes to startup after login.
*) Something more important for me than any social desktop would be integration of konqueror/rekonq with mozilla weave. I use my netbook at home or while traveling, a mac and a pc (windows and linux) at work, sometimes my girlfriend's notebook, and I can only synchronize my bookmarks with firefoxes. Konqy/webkit browsers are only second class citizens in my world because of that (I'll file a whishlist bug on bko for that)
@frietfriet: Yes, I think you are quite right about minimalism and how some chase it as an end in itself without thought to benefits or consequences.
To me, that's OK. What I'm really concerned with is those folk ruining it for everyone else as they grapple with their minimalism. :)
@Quintesse: "I think what is missing for Nepomuk is visibility."
In terms of user benefit, yes. Though at the same time it also needs to become part of the background noise itself. So while we will see it much more prominent in impact, we should also hopefully see less about it as a technology. Sort of like KParts. :)
"There have been quite a number of articles about how nepomuk is really useful,"
To date these have been oriented more for developers to understand the potential and get busy working on integration points to draw out the benefits (and deliver the visibility you are looking for :)
@Ron: "I was greatly disappointed in finding that Kubuntu 9.10 on an old machine with 512MB of RAM is hardly usable."
I hate to say this ... but if that's the case then there's something very, very wrong with Kubuntu 9.10. :/
(Personally, I don't use it so I can't speak to that, but that should be enough memory to work with.)
Or it could be that it's the desktop effects being turned on in combination with the graphics driver.
Hopefully you'll be able to use it sooner rather than later. :)
@JMiahMan: "I see KDE developers defending a technology that they've shoved down there users throats without it it being truly ready."
I'm not defending anything, I'm describing why we're using it and what we're doing with it. There are some very real misconceptions around that, which I'm trying to help alleviate.
"To what point have the developers become so disconnected from the community that YOU think you know what's best."
It's a bit like the engineer that builds a bridge knowing how to build a bridge better than those who drive on it every day.
"Ever stop and ask?"
All the time, actually. :)
"If users have failed to undstand what nepomuk, stigi, akonadi and all the other strange names do that's your fault."
Honestly, users don't need to know about these things at all. Every time those terms leak through to the user facing communication (e.g. user audience promo, user interface), we have a "bug" of sorts to fix.
This is also where I stop responding to you until you step back, take a breath and come back with a more constructive mode. If you decide to respond in the same kind of way you've decided to approach this so far, I will simply delete those posts without response. We can disagree, we can discuss, but we will do it with respect and in a constructive manner or not at all.
@xenoterracide
I like kdemod's packages more than arch's not because it's modularity but because it has some extra things, backported stuff all that nice things that vainilla kde doesn't have but all distros have.
I think file index and semantic desktop, even if implemented the same way should be shown from 2 different places in system settings and treated like 2 different things. I also have no use for file indexing but I could really use all the nice features in kdepim that will come with nepomuk and akonadi. For example,somethig I'm specting is the new calendar with kontact stuff I guess this wouldn't be possible without nepomuk.
Nepomuk should get more advertisement so distros and packagers make more effort in making it work well, so problem like mine that make people say "this is rubbish is eating my pc let's turn it on and hate it forever" doesn't happen anymore.
@xenoterracide: "but most apps should be able to function without support for it even built in"
indeed, they do.
"I think part of what I don't like about it is that it's RDF but a lot of the data I see stored is relational. Seems like an RDBMS could have been a better, faster, more stable solution. "
a relational DB is being used where useful (e.g. by Akonadi), but for RDF it doesn't make any sense whatsoever and would be an absolute disaster in terms of performance and utility. Some of the leading minds in the field have worked on the EU Nepomuk project, this isn't a backyard amateur hour thing. Technologies like Sparkle and Virtuoso are designed specifically for how RDF gets used and do a really rather remarkable job of what is a pretty hard bunch of comp sci challenges.
@Dion Moult: "Because if Nepomuk actually has been finding correlations behind my back, it's not been telling me about it."
Akonadi has only recently started Nepomuk (KDE SC 4.5 should include those bits), and the correlations are things such as who sent what attachment when or the email conversations you've had with the people involved with a given entry in your calendar. The tools to expose these relationships will (afaiu, anyways) be making their way into apps like Kontact 2 as they become available.
@Damian ah. I swore off kdemod after I ran into the... menu bug that was in... 4.3..1? on it that practically every other distro rolled the patch out for immediately.
@Aseigo perhaps... but in some cases this really feels relational. Bangarang seems relational to me. User contacts seem relational. Ratings are relational. It might be fast... but as I said earlier so far for me it's too buggy to be useful. Bangarang doesn't work correctly in conjunction with nepomuk. I can set ratings for songs in bangarang and they are recorded and I can set ratings in dolphin and they are recorded but they aren't shared. I'm also speculating that it's the reason krunner keeps crashing (not yet tested in 4.4.3)
As a kmail user for years, I have been actively commenting (even in person) on several occasions. I do care as a fan of KDE.
The problem here is not the development nor the idea behind but the management of the thing.
The triplet akonadi-neopomuk-strigi is, in its *current* state terrible for the users. It is normal because it is not even supposed to be on your desktops right now and here is why :
akonadi It has been here for months with absolutely no visible added feature, then it has been made mandatory there is no way you can install kmail/kontact without it. And with this, mysql ! Hard dependency. It just doubles my CPU wake ups on its own on my laptop for... nothing !
neopumuk looks nice in theory, just put there running for the pleasure of running it for months ! It is almost a mythic experience, do I have to run it because I have faith on it ?!
strigi ok, spotlight ? anyone ? I never saw it grabbing noticeable ressources from macbooks. It is just superfast, light, specialized, well integrated just using sqlite as common sense dictates. Strigi is so behind that and so impossible to have on a laptop that it hurts me each time I have to use the stone aged slocate to find my files !
So I keep making the same comment : as a user, don't force me to run mysqld or looping deadcode for the sake of it.
Just release it when it actually does something and in an efficient manner. Make the right management decision : strip it out of kmail 1.x (should have been done like one year ago) and make a terrific kmail 2.0 with the triplet superlight, superfast running on an embedded DB compatible with a desktop.
@xenoterracide: "but in some cases this really feels relational"
some things can be expressed relationally, yes. but some things can't be, at least not easily, because they are more of a direct graph than a set of tuples bound by primary and foreign keys.
"I can set ratings for songs in bangarang and they are recorded and I can set ratings in dolphin and they are recorded but they aren't shared."
i've seen that discussed on the nepomuk list, actually, and is a problem with how bangarang was able to store the tags.
it's being worked on:
http://lists.kde.org/?l=nepomuk&m=126906143614191&w=2
http://lists.kde.org/?l=nepomuk&m=127135859311987&w=2
:)
@aseigo yes but you're missing my point (and or missed my first 2 reply's to this post) right now nepomuk doesn't seem useful or in the cases where it appears it might be... is too buggy to consider. If it's not useable then it's just a resource hog. Sure by 4.6 it might be stable enough to be useful, instead of just some not as optional as we'd like (e.g. probably should have been off by default all this time).
I do not like nepomuk and although I have use for akonadi I do not think the resources it takes are worthy. I use Gentoo Linux here and try to compile the minimum to make system run and save space and memory. My notebook have 2 GB RAM and 100 GB HD, the HD is almost full and 2 GB RAM is not enough to run vmware and other heavy programs together, I have to close something. Using smem I got these USS numbers: akonadi and mysql take 57736 KB of RAM, nepomuk and virtuoso take 80020 KB (virtuoso alone take 33552 KB). USS is the memory that will be release when the program closes (http://lwn.net/Articles/329458). That said all those four programs alone take 137756 KB of RAM and the only program that needs akonadi (and consequently nepomuk) is kmail.
The point I want to say is that from KDE SC 4.3.x to SC 4.4.x I had to spend a extra 137k RAM just to run the same programs I used to run and without any real benefit to me. In the past when people said KDE was bloated I did not agree with them, but now I have to admit that something is wrong when the KDE SC footprint increases in 137k RAM from one release to another without any real benefit.
@Joseph: "I guess this blog post is in response to my rude/harsh post."
Regardless of the (highly questionable, imho) tone of your blog, it wasn't the first I've heard what you wrote about Nepomuk (and it won't be the last, I'm sure :). It was already on my "list of things to write about", your post just nudged it up that list a bit :)
That said, your blog entry, and this comment of yours, did leave me feeling flat. You basically asked for others to fix your issues with little concern to theirs and did so with more than a little misinformation mixed in to the pot (like "Nepomuk == File indexing"). At the same time, you do have some good points such as the state of KDE PIM, esp with its hounding of the user with dialogs and what not. I just wish it was presented in a way that was a bit more intriguing and inspiring rather than written in the tone of your average teenage basement dwelling slashdot troll. No? :)
"There were grave kdirlister bugs, which existed since 4.0 and lasted till 4.4 which caused many apps to crash. I think more manpower should be spent on the core (especially by the payed developers)"
Most of the paid developers do work on these kinds of things. Some that don't, such as Sebastian Trueg, are paid _specifically to work on these shiny things_.
Telling people not to work on X doesn't get them to work on Y.
If we look at core technology, kdelibs is very active these days (much more so than when we were all lamenting it's impending heat death back in 3.4/3.5 days ;), including quite a bit of work on non-shiny things (like mpyne's recent work on the pixmap caching infrastructure).
To add insult to injury here, for some projects such as Okular and Plasma, our biggest weak links for stability and feature availability these days are Qt itself, not KDE at all.
"The other thing is, I have deliberatly chosen to deactivate nepumuk. Why do I have to get nag screens each startup by akonadi that I have to enable nepumuk."
I agree; I can't really defend the results of the KDE PIM team right now. They are struggling to achieve their goals right now and in the process are not always making great choices. I've talked to some of them about that exact dialog, in fact, and they don't yet appreciate the full impact it has.
I think we all expected a bit more by 4.5 and it is worrying, more so that the communication comes in fits and starts and leaves too many people without enough information to go on.
"I didn't opt in, that it should be started. Just because it's installed, doesn't mean in has to be started"
I agree; well, to an extent: there may be things that are starting that use it that you aren't aware of? KAlarm, perhaps? That said, from the list of things in your blog entry, it seems like it's stuff you configured when you used Kontact at some point and then just left to rot, and Akonadi is doing what it's supposed to do: keep granting access to that information.
Does it happen with a new user account?
"Is it, because it is under development, or why does it start a lot of identical (unneeded) resource deamons and always, at each startup , migrate a default addressbook, which I don't use anyways?"
Same song-and-dance about KDE PIM as above, sadly.
But you know .. this blog entry is talking about Nepomuk, not KDE PIM.. :)
"Why does udevd cpu usage increase to about 50% all the time when kde runs, while it doesn't happen with gnome"
Good question; without being able to touch your system or replicate it here how can I know? It's not the usual behaviour, though, or we'd have noticed it quite quickly. ;) Some diagnostics from your side would be great, though.
(con..)
"but why does it with a "standard" setup, one activity, no special background, one taskbar and one folder view need 2+ minutes to startup after login."
Good question; here it's ~20s with a somewhat more complex set up. Without the folderview no the desktop, that drops to ~8 seconds. That's with full debug and things like the weather applet around.
Why don't you try this: kquitapp plasma-desktop, wall clock time the start up of plasma-desktop. then backup .kde/share/config/plasma-desktop-* (two files), remove the folderview, kquitapp plasma-dsektop and time plasma-desktop again. would be interesting to know if that's the issue or if it is something else.
If it is, then we can go from there and try and pin it down. If it isn't, we can move on to the next thing.
I know that i've found the file dialogs to be much slower than they should be recently, and I have begun to wonder what's up with that.
"Something more important for me than any social desktop would be integration of konqueror/rekonq with mozilla weave."
There's the Silk project which is working towards these kinds of webtegration technologies in KDE.
But again, just to stress, trying to swap out "social desktop" for "mozilla weave" isn't likely to get us anything. Not only will those working on "social desktop" be unlikely to work on "mozilla weave", but those who are benefiting from the work on "social desktop" will now feel left out as you do.
@Lamarque: "My notebook have 2 GB RAM and 100 GB HD, the HD is almost full and 2 GB RAM is not enough to run vmware and other heavy programs together, I have to close something"
Your hard drive filling up has very little to do with KDE's install footprint. The one thing that can take up space is file indexes (and why I personally turn off the file indexing), but even then we're talking a few GB at best.
The RAM is another issue; btw, I run with 2GB of RAM as well.
"akonadi and mysql take 57736 KB of RAM"
I must be doing something really different to everyone else, or else Akonadi has gotten a lot better in trunk. It's using 13MB here with a full debug build with multiple calendars in it, KMail running and the calendar in my Plasma panel clock showing events in it. Hmm..
That said, Kontact has never been light on resources. It's using ~98MB right now on my machine. :/
"nepomuk and virtuoso take 80020 KB (virtuoso alone take 33552 KB)"
try turning off the file indexing if that memory consumption is an issue.
"The point I want to say is that from KDE SC 4.3.x to SC 4.4.x I had to spend a extra 137k RAM just to run the same programs I used to run and without any real benefit to me."
I'm not actually so sure the equation is that simple. First, without the file indexing a lot of that will be shed, but with Akonadi itself it's shifting a lot of the footprint from Kontact. The problem right now is that Kontact doesn't fully use Akonadi leaving us in a limbo state at the moment. This is not great, but I'm waiting to see what KMail 2 and friends will have for us.
... interesting to see, btw, that so much of the conversation is about KDE PIM. Demonstrates both how it's a pretty key set of features for many, but also how the current state is not satisfactory. Let's see what can be done ...
"Your hard drive filling up has very little to do with KDE's install footprint."
As I said a little before that paragraph I try to compile everything to the minimum, not only because of KDE. I said that to show that I really care about performance. I also compile only the KDE components I need, and of course I disabled indexing. Anybody notices when strigi starts indexing. It is hard to believe someone can use a computer with 5400 RPM HD when strigi is indexing.
How do you measure the RAM used by your programs?
I do not use Kontact, only kmail and kaddressbook from KDE Pim and nothing more. By the way, kmail here takes 43 MB of RAM, not including the two kio_imap4, which takes about 3 MB each.
"I'm not actually so sure the equation is that simple. First, without the file indexing a lot of that will be shed, but with Akonadi itself it's shifting a lot of the footprint from Kontact. The problem right now is that Kontact doesn't fully use Akonadi leaving us in a limbo state at the moment. This is not great, but I'm waiting to see what KMail 2 and friends will have for us."
I am not using indexing. I want to get rid of nepomuk and akonadi but I can't. Kmail does not work without akonadi, akonadi does not work without mysql and nepomuk, and nepomuk does not work without virtuoso. Akonadi shifting footprint from Kontact is bad for me since I do not use Kontact. I getting the Kotact footprint without gaining anything usefull TO ME back.
My point sill stands, 137 MB of RAM wasted when I upgraded from KDE 4.3.x to KDE SC 4.4.x. I hope KDE SC does not keep this pace or there will be a day when 2 GB of RAM will not be enough to run KDE SC.
My 2 cents on Nepomuk/Akonadi. I was an avid KDE 4 user till such time KDE 4.4 came out. Being a corporate user of the KDE desktop at work, all the time...I wanted a decent stable PIM as it was in 4.3.x (apparently). But in KDE 4.4, all hell broke loose and Akonadi made almost everything slow and finally crash. I wasn't able to sync my Android with Kontact as the akonadi-google connector was badly broken. Akonadi would give tons of cryptic messages everytime the desktop would start.
Add to that, I *had* to use MySQL just to get Kontact running. No, I have no use for Nepomuk or a semantic desktop...but MySQL running on the backend and spawning several memory hungry processes brought my system to a crawl. I tried my best, but gave up and moved to GNOME.
Just a perspective coming from someone who uses KDE and Linux in a corporate environment.
Perhaps some new blood in KDE PIM would help? kickstarter.com is worth a look for funding such an effort if need be. I, personally, would be willing to contribute at least 20 USD to that effort. More likely 50, given how much I use Kontact.
Semantic desktops are not part of my reality. The only thing I know about nepomuk and strigi are that they give me popup windows now and then which I dismiss without reading.
I don't use KMail or KPim, as they just seem to complex.
By the way, what ever happened to KDE's usability group. Do they still contribute to KDE's direction. KDE is getting so complicated to run with so many switches and config options. I am starting to fear visiting System Settings on my computer.
Excuse me while I go back to my cave.
@Asiego: "@John: "I don't even want to build its dependencies just to have them sitting down in my hard drive, wasting space."
"how big is your hard disk?""
That question is funny, because it looks like you are trying hard to justify the semantic desktop on a case to case basis.
There has to be a part of you that knows that forcing users to install redland, rasqal, libiodbc, raptor, virtuoso and mysql for no good reason is not a good idea.
I don't blame you for acting so defensively, after all, there has been a lot of time invested (wasted?) on this.
So why not
making it optional (at build time) and make everybody happy?
@Dion Moult: "Because if Nepomuk actually has been finding correlations behind my back, it's not been telling me about it."
Akonadi has only recently started Nepomuk (KDE SC 4.5 should include those bits), and the correlations are things such as who sent what attachment when or the email conversations you've had with the people involved with a given entry in your calendar. The tools to expose these relationships will (afaiu, anyways) be making their way into apps like Kontact 2 as they become available.
So for example if I download an attachment from an email, like a .zip, extract and copy the files around my computer, Nepomuk will remember where those files originated? Or if I create an appointment "Dinner with John", and I have "John Foo" and "John Bar" in my KAddressBook - Nepomuk will realise they are related? (... and how would that information be useful to me anyway)
Well, I think the factor to guarantee success here is the implementation of how we interact with that data - I really hope that Kontact 2 provides those tools. I hope you would use your influence to ask those developing these tools to constantly post on Planet KDE updating the community on these upcoming interfaces. I think it would give a _lot_ of valuable feedback, and the community will really appreciate it.
... watching and waiting, hoping to see a bit more eyecandy, a bit more insight into the average Joe's workflow, and developers sharing more with the community.
I have no dog in this discussion. I don't use KDE since 1.x (fluxbox only here). I haven't tracked these tools. I'm totally ignorant.
But from just reading through this blog post and the frothing replies, it sure smells like the users are right. It sounds like they're angry about an inefficient and overcomplicated system that they don't understand, and is impacting usability in a real way for them.
Sure, your project is just one part of the puzzle, but you need to accept that you're a component of the problem. Anything that is an 'optional feature' that yet base applications are depending upon has a really bad smell. Your piece should be so painless that no one even notices (a library, or something similarly 'invisible') or it should probably be not required by any base applications for any of their core functionality.
Really, though, if anything is enabled by default that has a really high performance cost that impacts normal usability, that's a bug. Of course, KDE isn't alone, despite plaudits for spotlight, it has the same problems.
I just want to add some +1 for Nepomuk. I'm a semantic desktop believer. Hopefully someday Nepomuk will be able to help me see and use my desktop differently in a better way.
I'm using Acer Timeline, Fedora 10, 2GB RAM. I'm compiling KDE from SVN at the moment, while Amarok playing my face song without stutter. File indexing is suspended automagically. Apparently it's smart. I have composite on. Firefox Minefield running few tabs: seesmic, feedly (both javascript intensive). It's still snappy.
What was the fuss about Nepomuk again?
I think tagging and search dialog can be improved.
Hi Aaron,
It doesn't matter to me if my CPU is busy servicing strigi, I still have nepomuk and strigi enabled :).
As there is advancement in hardware everyday, why should be stick to the older technologies in software. If enabling nepomuk/strigi takes up some space, let them take.
I should simply say, you guys rock. Please keep on developing new technologies.
Eagerly waiting for kmail port on Akonadi :).
from Ron: 'Moreover, Nepomuk services are now being developed, and immediate benefits are not apparent. Until the framework and services become more stable and reliable, and the benefits become more prominent, objection to Nepomuk will stay. The point is, at this point of time Nepomuk may be a nuisance, but it is injustifiablly wrong to judge it now'
- true.
For something that wants to know and hold so much, it needs to become far more reliable than it is now.
I think that for the end user nepomuk and strigi are interdependent, one isn't of real use without the other. Without strigi, nepomuk struggles to show its value.
The desktop search part, which um me is the main selling point, is shaky at best. As of 0.7.1, the indexer still crashes (eventually turning itself off) on attempts to index folders full of mp3s and pics leaving a partially index system with incomplete results. Also I find that krunner is grossly inadequate for searching for the file I want from 30000+ entries. So i open dolphin and try again and suddenly another gig of my memory is gone (currently looking to file this bug, have no internet, this is from opera mini). The search mechanism also isn't versatile enough, not supporting queries like "ple do st mu" for "please don't stop the music" which windows does. I do believe that with time and POSITIVE contributions from all of us, we can get this to work. Hands in people.
P.s I think that dependent programs should have fallbacks in case of nepomuk failure or absence.
Hi Aaron,
I'm not a KDE developer, just a user, but I've been following your blog at PlanetKDE for a while.
I think your post is a good idea to get this discussion going. In fact I'm probably in your target audience, since I usually turn off as much of Nepomuk/Akanodi/Strigi as I can since it just makes the system slow.
You raise good points that the technology is not just for file indexing. However you seem to write from the developer's perspective only - for a user like me, it's hard to see the benefit of the Activities example you mentioned (I use Activities, I just don't see what Nepomuk can contribute here). Maybe you could explain a scenario from a user's point of view where Nepomuk is helpful for people who don't use file indexing or KMail.
There are many technologies where the benefit for the end-user only becomes visible after a while, and I'm sure that in future versions of KDE (like 4.6 maybe?) people will see what Nepomuk is good for. I just don't think the time has come yet, so a simple example from a user's perspective would be good.
Anyway, thanks for the work you do on KDE, I've been using KDE for almost 10 years now, and KDE4 really is a huge step forward. Keep up the good work!
Thanks,
Henning
I think stringi should tell people that it needs to index the whole disk and tell them to wait or postpone.
I love the promise of nepomuk, akonadi, stringi and plasma. But honestly, right now the benefits are really limited for me. I now mistrust new versions of Kubuntu that much that I don't install them on my netbook (I don't like he netbook remix and 10.04 seems to have insame mem usage according to my virtual box testing)
Maybe things will get better once Gnome 3.0 is released and more apps use indexing etc. At the moment I don't searh for stuff on my computers.
Sorry for not reading all comments, I just want to post some thing that has been on my mind a while and I have not found any where to post. Bugzilla bugs don't seem to get addressed.
Akonadi and Nepomuk seem to me to have been pushed on people before they are ready. Very much like PA.
Both suffer from dependency nightmares which makes them very fragile. Both for building from source and for starting them on a distro install. Its really a hit and miss.
The user interface for those components is in one word; horrible. The akonadi UI is mostly limited to a dialog that gives cryptic non-readable information about some dependency not being there. No help on what to do now.
Nepomuk has no user visible user interface except for the file indexing. Which seems to me to be very unfinished. Does it really need to index thumbnails, firefox html cache, git repos, svn repos, etc etc in my homedir?
I think this is one blog where you have a point, but to be honest KDE (community) dropped the ball and even while you have a good point it sounds like weaselling your way out. No loss of love here, though! *hug* :)
FIrst thing to do is IMO to turn off file indexing by default. Second thing to do is to be brutal and just find people to finish these products. If they don't get finished, kick them from the default releases for as long as they are unfinished.
And this includes having proper buildsystem checks so it becomes easy and transparant to build. Ideally removing various dependencies and removing a backend that is not going provide all the functionality. Last making the functionality just work. There is a lot of sillyness in the UIs and basic functionality right now.
ThomasZ
First I couldn't believe most posters here, a good start would be if people showed some respect and at least got Aaron's name right, I'm getting tierd of this Dolchstoß-Legende of how developers ignored the community and dragged us all kicking and screaming into the 21th century. If you feel that you're getting something "showed down your throat" then you should look closer at your choices, like your distro rather than rant about the insensitive developers.
What I, as a regular user, see is users with legitimate PIM problems, and other users running bleeding edge, stuffing their ears while shouting "I'm not listning!" when developers ask them to do some basic diagnosis to identify the actual problems, and this behaviour has been present since 4.0 was released. at least for me it's pretty clear by now: If I want cool features, I have to accept that KDE developers need to release imperfect code in order to 1) Get feedback, and call me crazy but I think they like to get it polite 2) They need to get libraries etc out there so *other* developers can take advantage of them. 3) Upgrading KDE is optional, for me 4.2 and 4.3 were smooth as silk, incidentally 4.3 is what is offered by OpenSuse's stable repos.
About memory usage: if looking at top my system total usage is 1590768k, 19% of that is supposed to be Amarok, Konq and Firefox (mozilla, plix fix ;) ) however this is a bad methodology see, http://ktown.kde.org/~seli/memory/analysis.html - also it's blatantly false as I only have 2 GB RAM as most people here seem to have - and if that much memory were "locked" to KDE, running games like World of Warcraft would be an unpleasent experience.
About akonadi warnings/errors: I wonder how many are due to people upgrading to the "latest-and-greatest" instead of using the stable packages provided by their distro. Anyway, at least that issue can be solved by "shut down Akonadi and check that the mysql process for the current user has also been stopped.
The run this
mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/ " -anda_skoa
"Akonadi needs too much space in my home directory!
An empty, unused Akonadi database needs about 100 Mb of disk space. This is due to the MySQL InnoDB log files which work similar to a journal in a modern file system. These files are constant in size and independent of the actual data stored in Akonadi. The default size is optimized for performance on average desktop hardware where the use of 100 Mb of disk space is no problem. In other cases, such as multi-user systems or embedded devices, this default might not be optimal though.
The default size can be configured, globally or per-user. The global configuration file can be found in $PREFIX/share/config/akonadi/mysql-global.conf, the per-user file is in ~/.config/akonadi/mysql-local.conf and overwrites settings of the global file. In any of these files, you can change the settings innodb_log_file_size and assign it a smaller value than the default (64M).
For this setting to take effect you need to restart Akonadi. With older Akonadi versions (<=1.1.1) you might need to manually remove the InnoDB log files from ~/.local/share/akonadi/db_data for this change to take effect. The log files do not contain data after a clean shutdown and thus can safely be removed while Akonadi is not running.
An alternative approach especially for multi-user systems might be the use of a single, global MySQL server instance." -Techbase
See, it is possible to be both bitter and try constructive, it's not mutually exclusive. I guess what I'm getting at here is that going into a frenzy doesn't help anyone. Google your problem, if it still doesn't work; report that, add specifics, even as a non-coder I understand that "zomg disk and cpu intensive!" isn't going to be very helpful, at least specify which processes and under what circumstances.
Oh and thanks Aaron and all other KDE devs, I really like krunner even if it took a while to figure out that amarok and the "Control Audio Player" runner didn't play nice :P And I'm looking forward to contextually aware activities (or w/e you end up calling akonadi-enabled Activities).
@Thomas I completely seconds that.
I was at the KDE PIM presentation at the last FOSDEM and one of the presenter reported something like :
"We ran the stats on the KDE Pim mailing list and noticed from the postings that the kmail usage dropped below 50%".
So, no I don't feel alone in this.
Well, Nepomuk is not optional (at compile time) because, fortunately, KDE has understood the potential that it has, and it is working hard to realize it (and probably bangarang is the first application using it extensively).
It cannot use a relational DB, even if some things look like relational data, because even these data need to be saved as RDF triples; otherwise, you miss the possibility to use a reasoner on them, which is the foundation of a Semantic {Desktop|Web}.
I use KDE on two Atom-based computers, and I have disabled the Strigi indexer (or limited its action on only the most important directories), but in the end KDE is usable without too much problems; the thing is, I really don't think that KDE 4.x is able to realize a minimal desktop.
One of the most used critics has been the desire of having just the minimum hard disk occupied, the minimum RAM occupied, the minimum CPU occupied; given the fact that I cannot understand the first two items (damn, I have 250+ GB of hard drive and 2 to 4 GB of RAM, why not using them in the first place...), KDE uses resources, and it uses them well most of the times, so if you want 10 MB of RAM occupied then install Fluxbox.
The main problem, in my opinion, is that the Semantic {Desktop|Web} has an enormous potential, but it is something very new for users and sometimes for developers, too, and it cannot be used so much in apps, so it surely needs some more work. But in the end you can always see it (at least) as a centralized place for data, which is really not that bad.
The bangarang, dolphin, nepomuk thing, "xenoterracide" had problem with in this thread works for me, the rating is shared between the applets (with kdemod by the way)
I dont see the most of the problem people write abaout in this thread. To me nepomuk mostly works.
My computer is not especially modern (a mobile core2duo 1.6, with 2GB ram) but kde is fast (and it startup fast, only a couple of sec. slower than gnome). (But I don't use Strigi so I have no idea if its some problem with that)
I think the KDE dev do a amazing work. KDE 4.4 is to me the best DE availably.
Regarding social taggging, ...
How does it work now. Is it possible to tag files on writable removable medias and get the same tags on a second computer. Is there anything planned for easy backing up/importing of the meta data? What if the harddrive fails? Are tags stored location indepenent, some hash of file content? How does it cope with copying the db to another computer, where the username is different and therefor the pathes are different.
In my environment most people have more than one computer, at work most of the things are on samba/nfs shares, especially shared home directories. Often users here are logged in to more than one (remote) desktop with a shared home directory, our workflows needs that, because often tools are bound to certain server systems. How is the metadata of strigi/nepomuk/akonadi/... outdated/preserved if you change computer, with different mount directories and go back to the first one? Search results are only relevant, if they belong to the computer your are working on, but the rest should still be available and not needed to reindex.
From what I gather all the meta stuff is bound to one computer/desktop instance.
I see advantages with indexing things, but I don't like the overhead and some conceptual things.
At work there are things which may never leave the building because of security reasons, but for some people it would be could if the stuff could be indexed, but therefor the index would need to a two level hierarchy, one index centrally stored for data available on shared folders (like a document management system, which is never stored on notebooks, but accessible from within the office building) and if the notebook is moved outside, only indizes for things located on the notebooks should be available. Perhaps something changed, but the last time I did look at that stuff, it was not easy to implement with the current kde frameworks.
I know my blog entry was more rude than it was intended and more rude than it should have been.
It's just the attitude some people seem to have, which annoys me more and more, which seem to be along the lines of everybody has only one computer, a lot of memory, a lot of free hard drive space, so just turn everything on by default without asking, because it is shiny, new and might be usable in 5 releases or so. Everybody will love it, once it's there.
That's just my impression
I agree completely with what gbin writes.
What hurts open source projects like KDE is when you release something as stable that clearly isn't ready for use. I haven't tried KDE 4.4 yet, but from all the comments it's pretty clear that it's not ready yet.
Aaron, I think a large part of the perceived problem is a communication issue and a disconnect between the developer and user community, and unintentionally, your post is a classic example of this, e.g
Nepomuk is being used more and more to track, coordinate / orchestrate and index non-"files on my disk" data. Let's take two examples: Akonadi and the Plasma Desktop.
The trouble here is using Akonadi as an example when the features you are talking about are only available in trunk and the 4.5 branch, still buggy and in heavy development - how are users going to access that? What's the point?
To date users see little to no use out of strigi/neopmuk - they don't currently provide any features they can access or use. The big example you choose to demonstrate the use (Akonadi) is currently only accessible to developers.
In the case of kontact/kmail, usability and stability have actually taken a big hit. I use kontact as my main email client but its taken me months to get it running reliably without that damn akonadi dialog, and even now I still get issues on startup on a regular basis. Reporting bugs seems pointless because all their attention is focused on the KMail 2.0 port, which is probably as it should be.
But I feel very nervous about the eventual kmail 2.0 testing, I have data I can't afford to get mangled, I'll probably switch to thunderbird for the duration and run a shadow account for kmail.
More ... :)
I do look fwd to the semantic desktop when it arrives - I (an moreso, my SO) have real problem organise my files in a tree - I'm not a heriachical person, I look fwd to a working content and tag search.
I have KDE 4.4 on Kubuntu 10.4 - its all working very smoothly. Best release ever - KDE does improve with each release, it just so *much* new tech keeps getting introduced and it all needs a release or two to mature ...
I agree with a earlier poster - one thing that concerns me greatly is the portablity and backup of meta data. I change desktops a lot- always trying new distros, beta testing etc. Tags won't be much use if I have to re-enter them each time.
I love the idea of nepomuk and it definitely fits in with my idea of semantic everywhere however I a bit disappointed with its usage so far. I am willing to wait until more applications begin to use the framework but today its primary function is to store metadata from strigi and herein lies my big gripe that made me abandon it (at least indexing).
I don't know whether it is the fault of strigi or that of nepomuk for failing to save the metadata but i find that the massive amounts of cpu time and disk writes from indexing don't do anything. I look at my nepomuk store and it keeps growing but searching for text from simple textfiles or sourcefiles (in many languages) returns nothing ever. I've tried several distributions but the result is the same.Searching Timelines and filenames and contents of folders and comments work but that is the extent of it. it isn't much of a step up from locate. Comparing indexing to spotlight I find the whole system seriously wanting.
Spotlight doesn't ever hammer my disk or my cpu.
It returns strings from within my mails, any file with text and music etc. Windows search is pretty much the same.
Why can't the same be true for strigi/nepomuk?
I guess that is what people are complaining about.
It would be great to have a more clear understanding of what exactly a "semantic and social desktop" is. I don't participate in Facebook, MySpace, Twitter, etc. so why would I want my desktop to be social? Please, help us understand what these buzzwords are and how they're relating to my computer. I want privacy, not social openness of my whereabouts and activities.
It would also be nice to know how Akonadi, Strigi, and Nepomok interact. Which does what? I thought Strigi was the indexer but I am reading that Nepomuk is? I feel the hype-speak of "semantic and social desktop" keeps getting thrown around but there is never a clarification of what the various technologies are and why.
Still loving KDE tho :) and 4.4.3 in Debian is great.
offtopic... wondering where the release announcement for 4.4.3 is...
Aaron, may I suggest that you post an update giving a practical example of how you use nepomuk? Users want to see "ahh yes, I can relate to that, now I can see how it can help me!"
Aaron, the real memory change could be done if we killed those MySQL servers running with Amarok and Akonadi (~50 MB each), and let those beautiful apps to use the Nepomuk database. If we do that... we have half of the room for hard disk indexing! ;)
The majority of users don't want nepomuk search indexing enabled by default and do not want nepomuk enabled by default. I am very sure of that.
The majority of users have no idea about what nepomuk is or does, nor are they interested in that. That's why they do not want it. Nor do they want to be educated to learn about it. It's so not interesting to Joe user.
Nepomuk is a great idea for a plugin and something fun for the developers to play around with but as yet in kde sc, we (The users) Are yet to see any real demonstration of any game changing uses of nepomuk which we want to use.
Nepomuk is not bad, it's just not essential to a desktop. It is only one single part of a semantic desktop made up of may other semantic software components.
Most users want just a desktop, while kde sc developers mostly seem to want a semantic desktop.
So either the semantic desktop has no future, as we move towards the cloud or you guys have jumped the gun and provided something too early which no serious user will consiously admit to understand or use for many years to come.
Only time will tell and I wouldn't like to speculate which one that is.
@Alejandro Nova "if we killed those MySQL servers running with Amarok and Akonadi (~50 MB each), and let those beautiful apps to use the Nepomuk database."
yes, as far I know there is research being done on that front.
@drz: "The majority of users don't want nepomuk search indexing enabled by default and do not want nepomuk enabled by default. I am very sure of that.
The majority of users have no idea about what nepomuk is or does, nor are they interested in that."
The second sentence really contraddicts the first.
the users should -not- have an idea of what it is, and should -not- care if is enabled or not. at the moment it's noticeable because it has bugs on some systems, every new software has, let's face it (on my system at the moment is taking about 7MB, even with indexing enabled)
It should really not be expected that an user should use or notice a particular framework, it's like feeling offended because the usage of QString, or KIO, is "pushed down the users throat"
now, since it will never come "for free" the options to disable it will stay, but, i'm confident in a short time users will use it without noticing or having even a remote idea it exists or what it is, just as any other framework being used there
Since people are asking for concrete example of what nepomuk might be used for, http://techbase.kde.org/Projects/Nepomuk see chapter 6 and beyond for some, imo, handy suggested features.
@Sir Alex "Well, Nepomuk is not optional (at compile time) because, fortunately, KDE has understood the potential that it has, and it is working hard to realize it"
That sounds like a big pile of marketing BS, the truth is if it was optional probably most people wouldn't install the dependencies because most people couldn't care less for a "semantic desktop".
So essentially we are being obligated to install all this crap because "it has potential", and users don't appreciate that, that explains the number of complains here.
Like I said before: making it optional at build time would make everybody happy.
A lot of very smart people are working on Nepomuk, but right now it still seems like more of a research project than an actual finished product that end users can enjoy. So i can completely understand why people are upset about wasting their resources on something that doesn't do anything for them yet, and is buggy when they do try to use it.
Hopefully this will improve soon, though, because I really do see the future of computing moving in this direction. There's lots of big opportunities this could open up for KDE if it can get it working properly.
It kind of reminds me of the KDE 4.0, or maybe 4.1 releases. Not really ready for a wide audience yet even though it's getting one, but with tons of potential.
Another case of a massively complicated technology witrh tons of dependencie in search of a problem.
If users have to actively know about nepomuk/strigi/akonadi then you could as well cancel those projects now.
I want my desktop to be asocial and without any semantics. Thanks :).
Another thing that concerns me with this direction - we're making the desktop and nearly all the KDE applications dependant on this very complicated and (currently) fragile stack of libraries and servers.
If nepomuk goes south then everything goes down with it.
I think that the main issue with nepomuk is that the most user-visible part (file searching) was not working until 4.4. Of course,this is strigi's fault, and yes,nepomuk doesn't do much there.
And then there is strigi. People said in this thread that spotlight is light. This is absolutely false,simply it is only available on a set of computers powerful enough that it doesn't matter -- however, spotlight indexing a network folder can make your latest mac unusable for a couple hours...
Nepomuk, to be honnest, does't seem to be very useful, right now, but is not a concern. Not very useful because it doesn't even sort files sought by relevance using one of the many heuristics developped by information retrieval researchers. And the value for a user of such a system is automatic harvesting of information (strigi) but also automatic creation and desplay of relations (nepomuk)...
Akonadi, no one would complain about if it were not for the dialog which opens for no valid reason. Except if you are in trunk. In trunk, well,let us just say that on a netbook, it doesn't work: the poor machine is too slow to let it finish the sql queries. And so a bunch of your mails get displayed as comming from "unknown" at an unknown date.
This is because linux has terrible performance under high io. Horrible, and in the 12 years I have been using it,it always has been like that. So if your beautiful design requires a fast disk, your beautiful design is, I'm sorry to say, wrong.
@b0b: "Another case of a massively complicated technology witrh tons of dependencie in search of a problem."
the dependency chain is nominal and the problems are well enunciated.
"I want my desktop to be asocial and without any semantics."
which you can do by turning those features off, or in the case of those that are off by default not turning them on.
"Thanks :). "
you're welcome.
@Blakpaw: "- we're making the desktop and nearly all the KDE applications dependant on this very complicated and (currently) fragile stack of libraries and servers."
i wouldn't call it fragile at all at this point, and other than akonadi nothing is actually dependent on it. plasma desktop will be using it for activity publishing. but "dependent" is absolutely the wrong word for it.
"If nepomuk goes south then everything goes down with it. "
that is a false statement.
@many: c'mon peeople, let's try and move beyond the Chicken Little type responses bases on supposition and assumption. we an do better than that.
@Cyrille: i agree with your assessment on the state of file searching in nepomuk; that said, i really honestly don't think that file searching is going to be most compelling use case. it might not even be in the top 5 by the time we're all said and done.
"In trunk, well,let us just say that on a netbook, it doesn't work: the poor machine is too slow to let it finish the sql queries."
i wonder what the issue there is, since they have it working just fine on the n900 which is rather less powerful than most netbooks out there. maybe it's a dataset size issue? would be interesting to see some digging there to see what the issues are. perhaps table indexes going awry? hmm.
Akonadi, no one would complain about if it were not for the dialog which opens for no valid reason.
Weeelll, also that on many distros it sometimes fails to start on time or fails to load its resources and hence contacts etc are unavailable. There appears to be a lot of finger pointing going on here with the packagers blaming upstream and vica versa. The problem does seem to be that its tricky to package to reliant on servers that are fragile themselves.
@Aaron: Can you actually point to features of Nepomuk that are useful *and* accessible to users in KDE 4.4.2 or 4.4.3?
"I think what is missing for Nepomuk is visibility. And I don't mean on the blogs, but in KDE itself. I know I have it running (without Strigi) but I just dont notice any of it! What does it give me that wasn't there before? And I'm not asking you to explain it to me, I think it should be obvious from using KDE."
This. Exactly this.
Now, I havent's used Linux in a while, but back when I did, I kept on wondering "So, Nepomuk is running on my system. What does it actually give to me in real life?". That question was left unanswered.
Now, had this been released in MacOS (which I mostly use these days), it would have happened differently. They might not have released quite as soon, but when they would have released it, they would have released new versions of apps along with it that take advantage of the feature. That way users get tangible benefits right from the start and they understand immediately how it makes their lives easier.
With Nepomuk, we have the situation where users are left wondering "what the hell is this thing DOING? How is it making my life easier?". What we got was a situation where Nepomuk was released, but there were no apps that used it. And Nepomuk by itself is next to useless.
When someone asks "how is Nepomuk benefitting me", the answer is usually something like "well, it's not doing much right now, but it will do great things in the future! Just you wait!".
Why not hold back the release of Nepomuk untill there were apps that could use it? Then you could do an intitial release of Nepomuk along with bunch of apps that were using it right from the start. That way users would have easier time "getting it".
Maybe that goes against the "release early, and release often"-mantra, but I don't think so. Nepomuk would have been available separately, and curious people could have installed it and play around with it, but the initial release to the public as part of KDE would have occurred only when there were actual apps that used it.
One example when nepomuk is visible is in the media player Bangarang.
I have never did any kde development, and maybe I ave wrong, but I think its funny when non developer complain on tools which have the purpose to do development easier and give new opportunities i the applications.
But usually they still expect the functionality but they expect that the developer implement all the stuff in every application and in every application reinventing the wheel. This so they not get any dependency and can imagine that they have some sort of kiss environment.
(excuse my bad English)
"One example when nepomuk is visible is in the media player Bangarang."
This is the first time I have heard of this app. Is it worth having a system-wide tool running constantly in the background just because one media-player needs it?
"I have never did any kde development, and maybe I ave wrong, but I think its funny when non developer complain on tools which have the purpose to do development easier and give new opportunities i the applications.
But usually they still expect the functionality but they expect that the developer implement all the stuff in every application and in every application reinventing the wheel."
Well, non-developers are (by and large) the people who run the software. And KDE releases a lot of software that is used by end-users. KDE is not only about tools for developers, it's about software for users as well. And there's plenty of apps inside KDE-project that could take advantage of Nepomuk. But they do not.
And of course we could have software that is aimed mostly for developers, with the task of making their developement easier. But the thing with Nepomuk is that users do see it, and they see it consuming CPU-cycles. Yet the actual use for that feature seems quite limited. It's only natural for users to question that are those wasted CPU-cycles worth it.
And you could have developer-aimed tools just fine. MacOS has CoreAudio, CoreData, CoreAnimation etc. that are meant to make developers life easier and add value to their apps. But the thing is that those things are not running in the background, making the system slower.
Releasing Nepomuk this early would have been OK if it did not have drawbacks for the user, if it were just a framework for developers. But right now it only presents drawbacks (slower system) with no benefits. There's only a promise of future benefits.
I'm no developer, but what I would have done is to delay the initial release of Nepomuk until there was support for it in the apps. For example, the requirement for release of Nepomuk would have been that Kontact, Dolphin and Plasma has full, built-in support for it. That way users would immediately realize what benefits Nepomuk brings with it. Releasing it with next to no support in the apps just ensured that people are left scratching their heads when they watch Nepomuk grind away at their HD.
@Aaron: the only thing that I notice from the whole nepomuk/akonadi/strigi mess is that I have to kill-9 kontact about five times during a workday since it simply stops responding at all.
"Janne
Well, non-developers are (by and large) the people who run the software. And KDE releases a lot of software that is used by end-users. KDE is not only about tools for developers, it's about software for users as well."
I don't mean that the KDE SC should target dev-people. I mean that the KDE core give developer tools to do application. This application should integrate with each other. To me that is the core with KDE. Nepomuk make it possible to do that in easier way.
" And there's plenty of apps inside KDE-project that could take advantage of Nepomuk. But they do not."
Yes it is. I suppose the apps that take advantage of nepomuk eventually grows in number.
"I'm no developer, but what I would have done is to delay the initial release of Nepomuk until there was support for it in the apps. For example, the requirement for release of Nepomuk would have been that Kontact, Dolphin and Plasma has full, built-in support for it."
Now with KDE 4.4 I think Nepomuk works with Dolphin, at least. I dont use Kontact and how Plasma use Nepomuk is above my knowledge (I'm not a developer exactly :) )
"That way users would immediately realize what benefits Nepomuk brings with it. Releasing it with next to no support in the apps just ensured that people are left scratching their heads when they watch Nepomuk grind away at their HD."
To me nepomuk don't use especially much of the HD (maybe it do if you use strigi)
@Janne: "Why not hold back the release of Nepomuk untill there were apps that could use it?"
because then nobody would work on it, nobody would be testing it, nobody would be integrating with their app (e.g. bangarang, to keep harping on that) and we'd simply never get it.
Apple has the "benefit" of monolithic development: they develop everything themselves and so need to cooperate with no one. which is what they end up doing.
we cooperate with those we can not see, and so we need to release early and often.
if as a user you'd sit back and go "well, i don't know what the point is of this yet, but there must be a point, let's wait it out" instead of putting undue pressure on developers, these features will evolve and deliver.
haven't we been through this time and agian in kde? but some people refuse to recognize and learn from history.
"This is the first time I have heard of this app. Is it worth having a system-wide tool running constantly in the background just because one media-player needs it?"
to imply that Nepomuk is installed just for Bangarang is rediculous. you can do better than that, Janne.
rather, Bangarang is possible because Nepomuk exists. as does search in Dolphin, the Activities Manager in Plasma Desktop that is taking shape in trunk for 4.5 and more.
"And there's plenty of apps inside KDE-project that could take advantage of Nepomuk. But they do not."
it takes time and effort, which some of us are putting in. but it's not a small task and our resources are small. even with those few resources as a limiter, we are slowly accomplishing what a behemoth Microsoft hasn't been able to do.
be patient, give us time. or even better help out.
"I'm no developer, but what I would have done is to delay the initial release of Nepomuk until there was support for it in the apps."
and following this plan you would never get apps with Nepomuk support.
again, sit back, relax and don't be an arm-chair project manager.
@Mathias: "the only thing that I notice from the whole nepomuk/akonadi/strigi mess is that I have to kill-9 kontact about five times during a workday since it simply stops responding at all. "
that has zero to do with strigi or nepomuk. it is Akonadi, which stumbles when mysql stumbles, which currently happens too often (e.g. at all), usually when trying to do an "automatic upgrade" of the database schema.
get rid of the myself files in your home dir and things will work better again.
not great, but as i've noted a few times here, the KDE PIM team has been struggling of late.
I'd like to mention that your strigi indexer locks up and dies indexing my home directory all the time. I don't know why. I think it sometimes does it because it's indexing files that are being written to. it seems to favorite locking up in ~/logs which is a log directory of konversations irc logs. which is always running.
I tried starting it in 4.4.3 and now it just locks up every time.... what good is this? if it does nothing but locks up.
I must say, Strigi is quite unreliable and resource intensive. I like the idea, but the execution seems to be lacking currently.
As for Akonadi, if the specific problems that the KDE PIM team is having can be identified, it might help to publicize these problems. Maybe people will step up to help.
@aaron: "because then nobody would work on it, nobody would be testing it, nobody would be integrating with their app (e.g. bangarang, to keep harping on that) and we'd simply never get it."
So, basically you guys are repeating the KDE 4.0 fiasco? Or do you still think it was a good idea to release an alpha as 4.0 to users? :)
Do not take me wrong, this is no bashing, I just want to know if KDE developers are still with the ideas the users are their ginea pigs, or moved on and learned that we do not like being used like this ;)
Ok... this actually sounds a lot like bashing... but I can't describe it in other way. You guys are pushing non-ready technology to users just because if, no one is using it, you do not have the will to code it? BLÉ!!! :-P
Aaron:
Okay I'll step back actually reading your responses to others I have kinda gotten a idea and a nice idea of what's going on. I know stuff normally sucks until it gets better. I guess my only wish was some how all of this could be an option at compile time or something we can turn off, at least when it comes to KDEPIM. The admittance from you that KDEPIM is not in the right place where it should be right now has made me feel a lot better.
The reason I get so heated is because I love KDE and even KDE 4 I think in a lot of ways everyone has done a great job, however that only makes things that aren't as sorted stick out like a very sore thumb.
I read a while back that your idea for 4.5 was to make it a well rounded release that's more focused on bugs then features. I hope that's true and following KDE Commits I'm seeing a lot of bugs being fixed. I hope kdepim becomes a focus though, because it's so hard seeing a mail application that I used to use religiously be marred in the name of the semantic desktop.
I still don't understand though why it seems I need multiple database backends. Maybe I'm misunderstanding something, but that's my point. Yes these technologies should be transparent to a normal user, but does that mean they shouldn't know they exist or what they do? If not just for some form of accountability?
I'm really excited about Nepomuk and Strigi (and also Akonadi btw.), I think it will be fantastic once it's all running smoothly. And I really think you all are doing a great job with those things especially considering that there are not that many people working on it and that most of you are doing it in your free time and not as paid work. So thank you all for that!
But I also think that the state of Nepomuk (and other components) at the moment is somewhat not that good. The problems are that for some it's (okay, mostly Strigi, but people don't realize that) just making the computer slower without offering any advantages and most people really understand what it's good for.
So I think at the moment it would be best to just disable Nepomuk and especially Strigi by default. Then maybe make a section on kde.org, very prominent like this: "Help us test these new cool features". In this section write down what it's for and some really cool use cases and a tutorial how to start and use it that way. And maybe a section with common problems and a tutorial on how to help with finding bugs, a link to bugs.kde.org etc.
That way the majority(?) who doesn't use any of this yet and doesn't understand what it's for doesn't get annoyed by the resource usage and the rest of the people get educated about it, understand, what it's really about, get it started and have a place where they can go when they have problems.
This way they understand it's not yet rock stable and feature complete and they know how and where to help.
My suggestion: use xattrs to store metadata such "as this file was downloaded from here " in the file system. I suggested this on freedesktop mailing lists more than 5 years ago, it would not require indexing if there were conventions about keys and semantics.
@Aaron: "myself files"? that would be what/where?
@Iuri: "You guys are pushing non-ready technology to users just because if, no one is using it, you do not have the will to code it?"
nothing like that, Iuri. you always jump to the absolute worst possible assumptions. pessimism is useful, but when it routinely leads you to wrong conclusions you may wish to consider re-tuning how that pessimism is calibrated. :)
anyways.. the issue is not about having or not having the will, it's rather that unless the framework is shipping, no apps will end up using it. if no apps use it, it never gains value nor gets tested.
part of the open source methodology means developing in the open. we could, of course, do like apple and microsoft and work for years and years behind closed doors to get as good as we can only to release only slightly better crap years longer that the current system takes. oh, and millions of $ investment to force people to be motivated to work on something in private.
neither system (closed / open) is without challenge, but open is highly efficient resource-wise and is actually sustainable in the long term.
@Claes: one day, perhaps (and personally i'm in agreement), but we are still YEARS away from having a widely deployed, widely agreed upon standard. it's kind of like IPv6 :)
@Mattias: typo on my part.. "myself" should have been "mysql". sorry :)
@JMiahMan: "The reason I get so heated is because I love KDE and even KDE 4 I think in a lot of ways everyone has done a great job, however that only makes things that aren't as sorted stick out like a very sore thumb."
i know; but let's try to find constructive, positive ways to communicate that so we can discuss issues with clarity. criticisms delivered constructively can lead to immense progress; criticism not delivered that way runs a very high risk of causing people to infight and even give up and walk away.
this happens a lot in f/oss, and the overwhelming cause is non-constructive communication.
constructive critical communication is a learned skill for most of us, but it is learnable and not even that hard :)
"I read a while back that your idea for 4.5 was to make it a well rounded release that's more focused on bugs then features."
that's our goal in the Plasma team, and one i am hoping other teams in KDE will adopt in 2010. we'll see :)
"I hope that's true and following KDE Commits I'm seeing a lot of bugs being fixed."
yep :)
"I hope kdepim becomes a focus though,"
that is up to the PIM team. and the more constructive feedback they get, the more likely that is to happen.
in any case, they have a developer sprint next week and more of the paid developers are being freed up to work on it for 4.5 ... hopefully this gives it some very needed boosts.
"because it's so hard seeing a mail application that I used to use religiously be marred in the name of the semantic desktop."
it's not being marred in the name of the semantic desktop. it's in a poor state due to the PIM team having undertaken a huge engineering project and encountering serious growing pains in doing so. PIM has been "marred" in the name of PIM. absolutely nothing to do with the semantic desktop or social desktop issues.
@JMiahMan: btw, thanks for taking that step back, taking those deep breaths and posting with clarity and constructiveness. it's really appreciated :)
@Aaron
"because then nobody would work on it, nobody would be testing it, nobody would be integrating with their app (e.g. bangarang, to keep harping on that) and we'd simply never get it.
Apple has the "benefit" of monolithic development: they develop everything themselves and so need to cooperate with no one. which is what they end up doing."
I'm not saying that KDE should be like Apple, but it could take some cues from it. Like I said, KDE could have announced Nepomuk, and even made it available as a separate piece of software (for developers and industrious users), but they could have delayed the actual release as part of KDE until there was support for it in the apps.
What I'm saying is that KDE writes software. A lot of software. In a way that is like what Apple does. When Apple releases new version of MAcOS, that OS includes a bunch of apps that take advantage of the features offered by the OS. KDE could do the same thing. When new piece of technology is introduced in KDE, the apps written by KDE would take advantage of it.
What we had was like if Apple had released Spotlight (their desktop-search technology), with no means of users actually using it or benefitting it. They could have explained all the different ways the technology indexes the HD and whatnot, but there would be no way for users to actually use any of that.
I understand the concern regarding chicken and egg problem. Nepomuk would not be released until apps supported it, apps would not support it until it was released. Yes, that could be an issue with third-party apps. But surely that would not be case with KDE-apps? Those have the benefit of knowing that Nepomuk will be released, and it would be released as soon as the apps support it.
"to imply that Nepomuk is installed just for Bangarang is rediculous. you can do better than that, Janne."
Well, that is not my point. My point is that if Bangarang is the only app that really uses Nepomuk, is it worth having Nepomuk running in the background?
""I'm no developer, but what I would have done is to delay the initial release of Nepomuk until there was support for it in the apps."
"and following this plan you would never get apps with Nepomuk support."
I don't think so. Sure, third-party apps might have been slow to adopt Nepomuk (which they have been now as well), but there's no reason why KDE-apps would be as slow. SInce those apps and Nepomuk are both part of KDE, it solves the chicken and the egg-problem. Those apps would not have to concern themselves with "is Nepomuk available to offer this functionality?", and Nepomuk would not have to worry about "will there be apps to take advantage of this functionality?", since the release of the apps would be tied to release of Nepomuk, and vice versa. Both would be under the same umbrella.
"again, sit back, relax and don't be an arm-chair project manager."
I'm not. But I am an user (well, not an active one right now, but still). And I remember seeing settings for Nepomuk, and notifications regarding Nepomuk, and I kept on wondering "what is this thing really DOING?", and I never figured it out. Nepomuk was a total black box to me. When I inquired about it, I got promises for future benefits, but I never got any details how it was benefitting me at that very moment. So is it any wonder if I thought "so, this thing offers me no benefit at the moment. So why exactly is it part of the system?".
So, like I said, I think that it should have been released when it could actually bring tangible benefits to users. And that could have been done by making sure that core KDE-apps take advantage of it. After that, third-party apps would have followed, maybe even with more energy, when their developers really saw what it could do. Maybe third-parties have been slow to adopt Nepomuk, because KDE itself was slow to adopt it?
Anyone here who is complaining about Nepomuk should try it without Strigi enabled. If you can't be bothered to do that, then STFU. PROTIP: if you're griping about notifications or hard disk usage, your complaint is with Strigi, not Nepomuk.
Anyone here who is complaining about Nepomuk should try it without Strigi enabled.
Kind of difficult for people to try it when there is NOTHING TO TRY. I'm guessing you didn't bother to read the thread because one of the main issues for people is the lack of anything they can do with nepomuk apart from file searches.
If you can't be bothered to do that, then STFU.
Bite me.
One thing that would be a visible and really useful feature to implement using neopmuk - add a search to the std KDE file open dialog. Instantly every KDE app has a nepomuk enhanced search available. A semantic full text search would be immensely useful there.
And don't say "Just use Dolphin". Users don't use Dolphin to open files, they use Applications. When my SO is accessing her copious collection of documents, its via OpenOffice, not Dolphin - nor would I want her to use Dolphin, to confusing and the potential to mess up the directories much higher.
@Blackpaw: "Users don't use Dolphin to open files"
this is actually one of the primary uses of Dolphin by many Plasma Desktop users.
@Blackpaw & @Alex: i'm not impressed by your choice to descend into sniping with "STFU" and "bite me". i have a rule on my blog here: "constructive or deleted". if either of you persist, i will blacklist your comments. being involved in the discussion here is a privilege (it's my blog), not a right (go start your own blog if you want to exercise your rights), and the price of admission is to be constructive even when you disagree. cheers :)
@Aaron: "this is actually one of the primary uses of Dolphin by many Plasma Desktop users."
And many don't. We're both going by anecdotal evidence, but most of the users I deal with never use a filemanager (Windows/Explorer or whatever), especially in the enterprise/corporate field where I work - they're application orientated. If they want to open a document they start their word processor and go File|Open. This is why document management system integrate with the file open/save dialogs on windows.
I'd go further and suggest the save dialog have options for tagging documents when saved.
i'm not impressed by your choice to descend into sniping with "STFU" and "bite me"
Fair enough, my apologies. No more in that vein from me.
Since Aaron or anyone else isnt providing any other examples, can anyone care to explain how does bangrang make use of akonadi?
Judging from the screenshots, a benefit i see is file rating.
Is there more to it?
@Blackpaw: "We're both going by anecdotal evidence"
not really :)
"I'd go further and suggest the save dialog have options for tagging documents when saved."
that's useful, yes.
still, the -real- value of nepomuk will be in collecting and correlating implicit information, imho.
@Greg: "Since Aaron or anyone else isnt providing any other examples, can anyone care to explain how does bangrang make use of akonadi?"
it uses Nepomuk, not Akonadi (i know, horrible names; they are not meant to be user-facing names, however :).
and it uses Nepomuk for _all_ of its metadata (track names, albums, artists, rankings, ratings, etc)
@Aaron:not really :)
You have usage data? (Seriously - interested). How was it collected?
@Alex: Anyone here who is complaining about Nepomuk should try it without Strigi enabled.
OK, I'd like to try that. However I'm not using bangrang or KMail, I do use Korganizer from the PIM suite however. So how can I try Nepomuk?
This is a serious question, not a flame - I'm really interested in this. I do believe that Nepomuk/Akanodi/... have great potential, so I'd like to be able to have a glimpse at what it can do for me.
Thanks!
@Henning: If you don't use Nepomuk-enabled applications, you won't see any benefit from it, but it shouldn't cause any trouble, either. Also, experiencing Nepomuk through Akonadi (which Korganizer now uses) is currently not a good way to experience it, since the KDE PIM team is not putting out a particularly good product right now (as Aaron has stated repeatedly).
My point was that people keep complaining about "Nepomuk's" high disk activity and memory usage, when those problems are actually caused by Strigi.
Another point I would like to make: be careful with programs that report memory usage by processes. Their numbers are frequently misleading.
As for the people who get their shorts in a knot over Nepomuk itself taking up space on their disks, the Nepomuk libraries and such take up 14 MB on my notebook. If 14 MB of disk space really means that much to you, then you probably shouldn't be using KDE in the first place.
Let me make one thing clear: I am not saying that there are no problems. I am just saying that Nepomuk itself is worth having, and you shouldn't judge it based on what Strigi and Akonadi do.
One final note: I really think there needs to be more communication from the KDE PIM team. If they are having problems, the team can only gain by sharing them with us.
My problem with the new way KDE does things is that I am having problems with heat on my system and all these extra services running doesn't help that. I just want a simple email client, no calendars, no reminders, just email. I like KMail as it's what I'm used to, but I'm rapidly becoming less enamoured of it due to all the headaches and growing pains, not to mention that, even if you start KMail from the command line, you've still got all the other crap from Kontact running in the background. Try it. Start KMail and then in a console window type "ps aux | grep akonadi" and see what you get. I'll tell you what you'll get -- you'll get a whole bunch of stuff related to calendaring and contact management that you don't want or need in a plain email client!
@John: "My problem with the new way KDE does things"
we've been using centralized services as external daemons since 2.0.
"Start KMail and then in a console window type "ps aux | grep akonadi" and see what you get. I'll tell you what you'll get -- you'll get a whole bunch of stuff related to calendaring and contact management that you don't want or need in a plain email client!"
first, the correlation between line items in the process table and resource consumption is not static. which means a simple "count the processes" doesn't work very well to really understand the impact.
while i agree that there is little need for calendaring information in your case (though i imagine those vcal sources are probably empty and not spinning the cpu either), i can't imagine having an email client without an address book.
prior to akonadi kmail loaded the addressbook 6 times in different places into memory. with akonadi that drops down to 1 copy.
so unless you want an email client with out any address book (recent addresses, commonly used addresses, bookmarked addresses, etc.) then in this particular case it's actually a marked and measurable improvement.
when kmail2 finally emerges "akonadi clean" (and the other kontact apps for those of us who use them) we should really start to see these benefits stacking up more clearly.
I have big problems with nepomuk.
Strigi started by default. Filled my disk. My machine is unusable.
Stopping strigi or changing the list of folders to index does not reduce the size of the nepomuk db, which seems to be designed in "grow only" mode.
No way to explore what is in the nepomuk db.
No way to selectively erase stuff and reclaim space.
No clear separation between the data stored in the nepomuk db by the many applications using it.
Sole possibility is to erase the db altogether, loosing all content.
Very bad design in my humble opinion. Like the window registry, but without the registry editor.
Should not be enabled by default, since it can hit badly.
KDE can be stripped down. Check out Dantti's Print-Manager (instead of Printer Applet), purge Kmail, Kopete, Korganizer, Ktorrent and Quassel.
Replace with Thunderbird, xchat, xarchiver, qbittorrent (yes I know half of them arent KDE/QT apps.. but they are great!). Dont use Air or Oxygen themes (very heavy on CPU)
Disable Nepomuk, Strigi, Akonadi .. and you can get KDE to startup with 300mb of RAM consumption.
I wish somebody would make a stripped down version of KDE - it is not at all difficult to make it run fast and sweet
For Nepomuk in Debian:
# rm /usr/bin/nepomuk*
# rm /usr/lib/kde4/*nepomuk*
# rm /usr/share/kde4/services/*nepomuk*
# rm /usr/share/autostart/nepomukserver.desktop
Also change kwin for openbox, and if you want Kopete without akonadi then System settings>KDE resources>contacts and change for example Folder or file. KDE SC light and fast.
What if I don't need neither file indexing, nor activities? Do you still think I have a reason to have it installed?
Sadly, after all this discussion, everything will remain the same.
We are still forced to install the semantic crap even if only 10% will use it (I don' t think its even 10%).
So far I've been patient with KDE4, because of all the promises, but the reality is that the best desktop environment is now unusable for me. Not only the environment, also some apps like gwenview and amarok which used to be enjoyable to be enjoyable are a mess now.
If at least we had the option to continue using KDE 3.5.10, but no, this has been discussed many times and the answer is always the same, developers don't want to support it, they want to start from scratch and drag users with them.
At the end all that was accomplished was to disappoint and turn away users.
@Alex: Sure, I know that I need to use applications that use Nepomuk. I guess I was asking for a couple of different examples that do use it in a good way.
I know that these are still early days for this technology, so if I have to wait to see the benefits then that's OK, I'm just curious.
In general, I don't really see the problem some people seem to be facing with KDE4 - even if I don't use Nepomuk, the desktop environment is highly usable. KDE SC 4.4 is way better (for me, obviously) than any 3.x release ever was.
Thanks,
Henning
@callegar: "Sole possibility is to erase the db altogether, loosing all content."
that's a pretty good point; you should file a (constructive) report on bugs.kde.org about this so that it gets on to the radar.
"Very bad design in my humble opinion."
a missing data manager doesn't equate to issues with the design.
"Like the window registry, but without the registry editor."
and that it doesn't keep your settings in it, randomly corrupt, etc. bad analogy :)
@Sandeep: "Dont use Air or Oxygen themes (very heavy on CPU)"
Oxygen uses more CPU as it uses a lot of subtle gradients, but the Air desktop theme should be about the same as any other given how the SVG->pixmap cache works. do you have #s for the "heavy on CPU" claim for Air?
@iria: you can also accomplish the same much easier by turning it off in system settings.
@AIM: "What if I don't need neither file indexing, nor activities? Do you still think I have a reason to have it installed?"
I'm sure it's possible to imagine a scenario where a person using a desktop computer would have no use for Nepomuk whatsoever. Just as some people never open a Konsole window. The # of use cases are growing with each release and covering more and more of the user base; eventually we'll probably hit in the high 90%+ range of people who use it, even if they aren't aware of doing so, though.
@John: "We are still forced to install the semantic crap even if only 10% will use it (I don' t think its even 10%)."
Then we disagree on this point, John. I think it's often dangerous to extrapolate from one's own experience what the global state is. :)
"Not only the environment, also some apps like gwenview and amarok which used to be enjoyable to be enjoyable are a mess now."
I will grant you that the new app styles may not be for you. Honestly, many of the people we put in front of the old Gwenview couldn't figure it out and didn't find it a very pleasant UI to use at all. It did have users, though, and some of them absolutely loved it, as apparently you did. I suppose something we're facing is developers being less willing to create hard to use, overly technical UIs just because a small group of people prefers such things. Gwenview in KDE 4 not only has reached a far broader audience but even has more features in it.
It may not be for you, but it has become something for many, many more people than it was in the past.
"If at least we had the option to continue using KDE 3.5.10,"
You do. It's free(dom) software.
"but no, this has been discussed many times and the answer is always the same, developers don't want to support it,"
*We* don't want to support it. *You*, however, can. The problem is that the people who'd like to continue on with KDE 3.5 can't or won't put the time we did. It's a very shaky kind of argument to make that you can force others to do what you want, especially when you have the freedom to make it happen yourself.
"they want to start from scratch and drag users with them."
We didn't start from scratch, and people are free to use it or not.
"At the end all that was accomplished was to disappoint and turn away users. "
Some people, yes. We've also attracted many more users in the meantime (they show up in my blog same as you, not to mention elsewhere on the Net :) and have several large deployments around the world (largest single deployment of KDE 4 I know of so far: 400,000 systems (not users, systems!)).
So while I understand and hear your disappointment and frustration, it really isn't aimed at you personally. The decisions made have been to bring KDE to a wider audience and for the evolving world around us. We're succeeding at doing those things, though some eggs will get broken along the way. Such as not servicing 100% of our pre-existing user base to their satisfaction. So it goes.
At the same time, you have started to do nothing but kvetch in your comments, regurgitating the same tired complaints that have been fielded here before. You've had your say, now let's move on.
@Joh, et al: for an example of what I mean by "a broader audience, etc." please see Henning Schnoor's comment above. We get that kind of positive feedback far more often than the negative sort.
Idea: start a project on kickstarter.com to pay developers to maintain KDE 3.5. If the complainers can't be bothered to contribute work or money to KDE 3.5 desktop maintenance, then we can conclude that they are just whiny malcontents and ignore them.
I guess I'm one of those people that complain. I just don't want to be forced to install anything beyond what I want to run – except for obvious dependencies, of course. I don't like being forced to run a MySQL database on my desktop or anything like that. My desktop is in a way a glorified console to a lot of servers, and any sort of indexing – or however you want to call it – just isn't interesting or useful to me. I wish more effort would go into improving ssh, nfs, samba and AD integration, because network interoperability is much more relevant these days than whatever local files I might have on my desktop. Don't waste time on a handful of local files; improve my network experience and help me to find servers, services and the files I need from that network.
@Alex Wauck: I'd welcome someone else to do so, but I honestly have less time to spare than to spend it on "just to prove it to ya" activities :)
@Wode: "I just don't want to be forced to install anything beyond what I want to run – except for obvious dependencies, of course. I don't like being forced to run a MySQL database on my desktop or anything like that."
You're not forced to, and the MySQL system that is run is pretty lightweight in terms of footprint. There has also been work on a sqlite backend (though sqlite doesn't have amazing performance, though if you don't use the Akonadi features much then it may be a great compromise)
"any sort of indexing – or however you want to call it – just isn't interesting or useful to me."
which, as has been said a number of time, can be turned off with a single checkbox in system settings. :)
"I wish more effort would go into improving ssh, nfs, samba and AD integration"
KDE already has pretty good integration with these things; the SSO side of it is the biggest missing link in the chain, and honestly the biggest challenge there is getting the "desktop" projects working with the "server" projects (e.g. KDE <-> Samba)
"because network interoperability is much more relevant these days than whatever local files I might have on my desktop"
For some people that is quite true. There is, however, still the issue of local caching and representation. IMAP is a great example of that.
"improve my network experience and help me to find servers, services and the files I need from that network. "
we're _also_ working on that. it's not either/or, we don't pick one OR the other, and removing efforts on one doesn't magically have those efforts re-appear on the other.
this is the difference in perspective that someone such as myself has to contend with relative to a single user with a specific use case set (and we all have one! :)
thanks for sharing your perspective ...
A more useful and less time consuming "just to prove it to ya" activity would be to set up a poll on the KDE website with the question:
- Are you actively using the semantic desktop features of KDE4?
1. Yes
2. No
Now that I think of it, why are there no polls on KDE's website? That could help the developers connect more with users.
If you are really interested in knowing how many people are using the semantic desktop thing a poll will tell you.
Quoting Aaron:
----
@Wode: "I just don't want to be forced to install anything beyond what I want to run – except for obvious dependencies, of course. I don't like being forced to run a MySQL database on my desktop or anything like that."
You're not forced to, and the MySQL system that is run is pretty lightweight in terms of footprint. There has also been work on a sqlite backend (though sqlite doesn't have amazing performance, though if you don't use the Akonadi features much then it may be a great compromise)
Well, of course we are not forced to, we can use Gnome, lxdm, or fvwm. What he meant is that if we want to use KDE4 and KDE4 applications, we have to install MySQL and a bunch of other dependencies we don't really need.
"any sort of indexing – or however you want to call it – just isn't interesting or useful to me."
which, as has been said a number of time, can be turned off with a single checkbox in system settings. :)
----
Turning off the checkbox is not the same as: cmake -DBUILD_akonadi=OFF -DBUILD_nepomuk=OFF ...
We still have to install a bunch of things we are not going to use.
To me, Nepomuk is a lot like Avahi (or just zeroconf/"Bonjour™" in general) - it "feels" like something that has a lot of potential somehow, but I can't quite see what the actual potential IS because I, myself, know of little to no way of actively using it for something.
A series of use-case posts might be helpful for this. If I can find something genuinely useful to me that I can do with it, that would make a big difference.
Otherwise, as many other KDE-PIM users have complained, the only visible presence of Nepomuk is the need for a special embedded MySQL process and incoherent "like, dude, something went wrong!" error messages from Akonadi.
(For the record, once I manually limited Strigi to only searching the couple of directories containing reasonably indexable material, the file indexing has been a little useful and not at all intrusive. Since I rarely use it, though, it doesn't really demonstrate Nepomuk usefulness much).
Hey Aaron.
I've been a 7+ year user of KDE and I love it. I've never had any major issues with 4 (2 years ago I was loving 4.0.5) and it's just got better and better... system notifications being one area that I love, the new(er) style is great.
I agree with most of the comments on here, I think the Nepomuk/Akonadi/Strigi+friends combo simply to run Kopete and/or Kmail is a little excessive. People I chat with aren't people I email and vice-versa so I have no need of that cross-application indexing. I don't buy into this Web 2.0 stuff or Social Networking malarky either.
I've always found Kopete to be unreliable (randomly dropping connections on all protocols for no reason). I used to really like KMail but my email is GMail and I have an Android phone so I really don't need an actual email client anymore. The only reason I used KMail recently is to mass-download several tens of attachments, which is easy to do in a couple of clicks on KMail. But now I get warnings about the redland database missing (I think that's it, not at that machine right now) so KMail won't start. So I use a Win 7 laptop with MS Mail client and use that instead (I don't care for Thunderbird either).
Also, a question - I have thousands upon thousands of pictures, music and videos. For all this semantic desktop to work properly, am I supposed to go and tag each individual file? My music is tagged for iPod reasons, but pictures and videos? Over 10,000 of them? Check the contents then tag? That might take until KDE 6 is released :-)
All that being said, I honestly have no complaints about KDE. I love using it, even if there are things which are different and require me to re-learn. It's the best DE out there and I'm proud to be a user of it. I hope you and all the other KDE guys keep plugging away at it and I'm excited to see what's further down the line.
@Aaron
This is off-topic (on a dated discussion, what a combination)
Stumbled upon this: http://thelinuxexperiment.com/guinea-pigs/tyler-b/big-distributions-little-ram/, which shows there is something serious wrong with Kubuntu 9.10. Couldn't get 10.04 to work yet,so don't know about that.
Good news is that updates seemed to improve KDE's RAM usage.
Bad news is that most complaints I've seen now (to which I concur) is about hardware compatibility and the ability to Just Work with KDE SC. While there's a lot of promise in KDE4 technologies, personnally I can't use it since it's not good enough out-of-the-box. This is not only a KDE issue. This is something general to FOSS: the kernel, distributions and hadware manufacturers have their share in the effort to get things (not) working out-of-the-box (My x41 tablet is an example).
More to the topic: Unfortunately, a working Nepomuk is secondary in consideration to a working multi-monitor configuration or better power consumption (out-of-the-box). And while I see the (long-term) benefits of the innovations and understand it Takes Time ( :) ), it still means I don't use KDE (and Linux by proxy) since I need a working configuration right now. I've seen it mentioned by others as well.
I still feel like "Keep up the good work" and "I'll join you (one day)". But I think there's need to focus more on performance KDE-wide, and maybe create tools to help (down/)upstream improve performance as well (similar to the bug reporting system). I think that for end-users - without the patience to hassle around, these 2 topics (HW and power) are essential, and therefore should be more in focus when trying to attract users (from MS Win as well - whether it's for dual-boot or switching OS).
Following that train of thought: a sort of poll presented at KDE forums, of "What topics are most troublesome for you/has made you switch from KDE/etc" would be useful. Maybe the usability team can prepare such a poll with focus on HW/power/.., and each user can press thumb-up/down (as in brainstorm) on 5 (or n) topics only. Example for a topic: "Multi-monitor support with NVidia cards","Wireless taking a lot of power" ...
Another thought: have a database of which distribution working on which configuration (I know this sounds insane at first - plz read on) - let each user (after a week/month of use) enter his configuration and distribution and rate his experience (like 1-3 or 1-5), and maybe add tips and/or complaints. Then have in kde.org the ability to enter a configuration and find the most suitable distribution. It couldn't also help identify problems specific to distros, configurations, or global.
These ideas would also get more users more involved in KDE easily.
Cheers, hope this makes a good read.
BTW, 512 RAM is not enough for openSUSE graphical installation.
@Ron: yes, not everything is within our (KDE's) control on our own, this is completely true. we often have to work with what we have, while trying to work with other projects (such as the ones you list) to help improve what they are doing.
as for the idea for gathering user information, i think that could be quite interesting. unfortunately, i don't think we realistically have the manpower right now to do that. but if someone (such as yourself, even! :) wanted to step up and help contribute to the forward progress of f/oss by working on such a thing, that would be great.
@Ron: I don't know about (K)Ubuntu, but in openSuSE, multi-monitor support got a lot better in the latest release. Earlier, I always had to configure all kinds of things when plugging in different monitors / projectors, now it Just Works (TM) and I don't need to do anything anymore (don't know if the improvement is in X.org or KDE or openSuSE-specific).
I know this is just one example of what you mentioned, but it seems that stuff is happening in the direction you were talking about.
All the best,
Henning
:D Sure. I'll gladly help with what I can - I'm afraid right now it's only ideas and maybe creating the questionaire (Learning how to program is on the list of To-Do's).
Who should I contact about these ideas?
You have usage data? (Seriously - interested). How was it collected?
which made me think: if KDE would have an option to enable "anonymous usage collection", I'd happily enable it! It could give hints to developers where to optimize stuff.
btw, I do use dolphin (I used to think I'd never leave konqueror, but dolphin mostly does its job (though sometimes I'm not convinced about its performance))
@Henning - Thanks! I'll give it a try. It would have to wait a couple of months though :) I used openSUSE in the past, but found it more resource demanding, so it doesn't fit on this particular machine.
@mattie - I'm not sure I understand, but the idea is that users would provide their data themselves - their perspectives; But doing so in a guided way so that this data can be easily mined and analyzed. Think something like Brainstorm in terms of interface, but stricter and with other voting options.
Janne: I remember seeing settings for Nepomuk, and notifications regarding Nepomuk, and I kept on wondering "what is this thing really DOING?", and I never figured it out.
I think it might be useful if, when interfacing with the user, Nepomuk would be called "the kde information store" or something more friendly. Nepomuk is a fine code name for the engine when talking amongst developers, but I really think all these strange names do is serve to confuse end users.
I think that integration between applications in KDE is a great thing, it helps to fight duplication of work, and it's always good.
It seems that akonadi and nepomuk are somehow the main pillars of such integration, and I hope that they will be used in more and more circumstances.
To be honest, I realy like nepomuk and the idea of files, people and metadata connected in a network of relations through nepomuk, and I think that this revolutionary idea will some day create a revolution in our way of using technology.
But at the moment (KDE SC 4.4.5) I have to say that in my experience nepomuk is almost useless. OK, now and then I tag some file just to create some relation between different documents, but still I don't use these tags to search my files.
I keep nepomuk running in the hope that tomorrow it will do something useful to me.
I repeat: the idea it's really great, but we need it to be useful in our real lifes, and it should be easy to use!
So please, do something to make us feel nepomuk easy and useful!
The whole “non-files things” concept is so deeply deeply wrong, it boggles the mind.
Maybe colorful clickable toy interface designers have forgotten about maybe the most basic and greatest concept of Unix OSes: EVERYTHING is a file. Yes, that does encompass everything you just thought of as “not possibly being able to be a file”. Windows, widgets, actions, metadata, everything.
Then suddenly, the point of Nepomuk as a bad clone of file management, but for metadata, vanishes completely.
KDE really has majorly jumped the shark.
To me, who worked about 2 years now, to come up with the perfect shell… the perfect human-computer interface, the following concepts are dead: windows, buttons, task bars, applications (!), desktops, “start” menus, etc, etc, etc.
And all those detail solutions like e-mail, instant messanging, filesystems, databases, etc.
They all dissolve into about one or two general concepts.
If you want to see a well done UI, look at Maya. especially the fact that everything you do is also shown as script commands in the scripting window, and that you can select and make it part of the UI (e.g. by dragging it onto the icon shelf, or assigning a shortcut). Also you can modify everything and everything can be attached to everything. Making it more a well-designed and shockingly easily extensible set of tools in a box than a monolithic application.
But of course even Maya feels incredibly backwards to what I’m about to release.
@gerlos: "the idea it's really great, but we need it to be useful in our real lifes, and it should be easy to use!"
it will end up being mostly transparent to the user. for instance, the activities in 4.5 use nepomuk (and will do so even more so in 4.6), but you'd never guess that from using them. it's plumbing (or at least, should be) like kio, imo.
@navid.zamani: "Maybe colorful clickable toy interface designers"
nice way to start off. such a turn of phrase says a lot about your arrogance and ignorance. there's a great saying: "Keep quiet and they may think you are ignorant; open your mouth and remove all doubt." ;)
"greatest concept of Unix OSes: EVERYTHING is a file."
it is a great concept. but like all concepts, it has its limits. turning it into a religion that everything must then fit only leads one to applying it poorly. hammers and everything looking like nails, right?
so let me give you some examples of things which you can certainly build addresses for but which are completely absurd to think of as files (unless, again, you are simply trying to do so because it's your religious perspective):
* temporal events, such as when you use an application or a document. right now we are working on (for SC 4.6) recording these events and associating them with activities.
* social relationships as represented by sharing and connections between people on the desktop
in both cases, there is nothing there that is anything like a file. yes, the data gets stored somewhere to disk at some point, but the similarity ends there. there is no meaning to sequential reading or random access, there is no meaning to "piping" the contents, etc.
in both cases, it requires a graph. in the first case, a structured one so that the relationships can be mapped and found.
UNIX was designed before many of the things we use computers for today were around. the solutions it brought us are still great for the problems it addressed, but it at times falls down when addressing new kinds of needs.
"the point of Nepomuk as a bad clone of file management, but for metadata, vanishes completely."
i would recommend you read up more on what Nepomuk us. calling it a metadata manager / store is a bit like calling a wristwatch "some gears". yes, there is metadata, and there is management, but that's hardly the extent of the system nor the sum of its parts.
"Making it more a well-designed and shockingly easily extensible set of tools in a box than a monolithic application."
sounds like a great toolbox for programmers and extreme power users who want to fiddle endlessly. turns out that isn't what nearly everyone wants nor needs. nothing against those creating great tools for 0.01% of the population, but that's a very different task from what we're doing.
"But of course even Maya feels incredibly backwards to what I’m about to release."
i look forward to seeing it, though given your pomp i'm not holding my breath. bluster like that rarely precedes anything truly interesting.
Nepomuk and Akonadi are not applications, so to the user they are meaningless. However KDE4 is generating messages about them, so that's confusing at least - usually annoying, too. On top of that there seem to be no applications which actually use them in a way which would get the user interested - you state yourself that you turned off Nepomuk on your own system, so apparently you haven't found a use for it either.
The KDE developers want these services available to applications, and that makes sense. However they cause problems and eat a lot of resources which leads to user complaints. Instead of starting the services by default (and using a setup which consumes lots of memory and CPU) they should default to off. Then when an application is first started which uses these services, that should start a wizard which lets you configure the services.
There the user could decide which of them to run and control the resource requirements. The user would understand what the services are for in this context. Right now he needs to find out what they are for by noticing the high system load and identifying the process which eats up all the resources - that's not a good experience.
Anyway, just a suggestion hope it didn't annoy you.
@Stefan: "However KDE4 is generating messages about them, so that's confusing at least"
yes, you'll the terms pop up in notifications on the desktop. and that's wrong. i've not only talked extensively about de-jargonizing our user interfaces both in presentations, on my blog as well as 1-on-1 with the projects in question, i've also done a lot of patching to those pieces of software to make that happen. so we agree there.
to take another meaning of the word "message": we also communicate about those technologies in our public communications and marketing. we're actively working on refining our split between user-facing and developer-facing messaging there too.
"However they cause problems and eat a lot of resources which leads to user complaints."
we're working on those issues. so we're neither blind to nor in denial.
and some of the complaints are our own fault for no good reason: the akonadi error message window was a bad, bad, bad idea, for instance. it was unnecessary and caused huge amounts of damage to the perception of Akonadi.
" Instead of starting the services by default (and using a setup which consumes lots of memory and CPU) they should default to off."
they are started on demand. so when something needs them, they are started.
that said, it is usually configuration issues that lead to consumption of resources. we need to improve that. not abandon otherwise good technologies.
"Then when an application is first started which uses these services, that should start a wizard which lets you configure the services."
i'm pretty sure 99% of our users don't need to see a random "configure your groupware cache" dialog pop up. that's a power user geek answer, not an elegant end user solution.
"The user would understand what the services are for in this context."
no, they wouldn't. it requires more knowledge of the system than 99% of our users have, likely ever will have and should be required to have.
"that's not a good experience."
agreed; and the answer is fixing the problems not making the user go through even further painful exercises of configuring arcane infrastructure as a result.
"hope it didn't annoy you."
not at all.. thanks for the input, even if we disagree on some points.
Curious. What's the improvement level on the problem of resource consumption in 4.5? Has the issues with this stack been addressed? was it a matter of focus?
also I know in the past you've said the problem is strigi not nepomuk. #1 way to solve this problem... when /it/ is chewing through my 6G of ram it should say 'strigi' not nepomuk. Although preferably nothing eats through my ram.
"#1 way to solve this problem... when /it/ is chewing through my 6G of ram it should say 'strigi' not nepomuk."
well, #1 way to solve the problem is to make it not chew through 6GB of RAM. ;)
#1 way of shifting blame is to replace one bit of jargon for another.
"Although preferably nothing eats through my ram. "
exactly :)
there was a commit the other day that fixed the worst offender: the video metadata analyzer was not obeying the max stream limit size, and so it was quite happily loading _entire movies into memory_ for not particular reason. how big is a DVD again? ;)
you can thank Trueg for that fix.
others have also been going in over the last days, week and months. is it perfect yet? probably not. is it better? yes. are we going to continue work on it? HELL yes.
The fact that Akonadi loads on demand is not precisely much help, because the standard clock plasmoid is asking for it, and that causes it to be active (generally) by default on 4.5, at the time of the latest public (not subversion) release.
This is a mistake, a clock shouldn't ask for a whole database, even if the intention (as other KDE people explained to me, to link dates and events to the little calendar pop-out) is good.
"a clock shouldn't ask for a whole database"
you can turn it off in the configuration dialog; most people find it very useful. on my system, akonadi (inc MySQL) is taking 22 MB of RAM to host 13 different resources. (several calendars, addressbook and a handful of email sources)
i'm also running kontact, so that is shared between my groupware app and the clock.
it kept me on time for a meeting a few days ago as it showed the meeting time in the clock popup (i'd thought it was an hour later in the day, it wasn't!)
it's a fair trade. in fact, it basically takes the cost of running kontact and lets me "amortize" it across several apps, such as plasma-desktop.
if you disagree, and i know some will, turn it off in the clock config. very easy :)
While you speak the truth about memory usage, I have absolutely nothing in Kmail or other PIM apps, until I set everything to empty fields (which fortunately doesn't validate), Akonadi kept running.
Hence for having no data to work with, it's using 22mb. It's too much for "nothing". (not meaning it with sarcasm or any offensive meaning)
I am using RC2 at the moment (RC3 is out and changes it?) but I don't see anything about disabling Akonadi on the Digital Clock Settings dialog. Not even a mention by name. In Calendar there's only "Calendar System" and "Holidays".
You are perhaps talking about trunk? If so I am glad that feature was added in.
By the way, I was just reminded, can I suggest allowing Krunner to be disabled/not started? I use a different launcher myself (Kupfer), and having two running at once is a bit useless. But there's certainly no way to disable it (I checked everywhere, unless there's a non-GUI config setting or a very out-of-the-way option). There's always killing it manually (with no loss of functionality unlike other devs told me) but that's not "pretty". (Well, one would miss the ctrl+esc system monitor, but other than that...)
I'm sure that these will all be very useful services when they are working. Unfortunately, they seem to fail often enough that they can't be entrusted with anything important -- such as an address book -- since the databases are generally corrupted on system shutdown.
Sort of like Firefox: one unexpected shutdown (and since KDE doesn't wait for the services to clean up, all shutdowns are "unexpected") and you have to blow away the database and start clean.
This might be less of a problem if there were some sort of backup mechanism in place, or if there were reasonable user guidance on how to do the cleanup, or if ...
Fortunately, my important data is all in older text-only files, at least for now. It's a bit of a pain that it all has to be imported when I log in, and manually updating the old files is not a lot of fun, but at least I'm not losing anything.
@John: "I don't even want to build its dependencies just to have them sitting down in my hard drive, wasting space."
how big is your hard disk?
The corporate quota on $USER is 768 MiB. Out of that I have to find space for mail, documents I'm working on, and workspace for designs, simulations, etc.
Losing 200 MiB or so is not cheap. Losing it to something that's trying to index several terabytes of NAS is worse. Losing it to something that's still trying to index several terabytes of NAS when the power stops (and thus trashes the database) is worse yet.
Worst of all is logging back in and not having an e-mail client until I dig around in a hidden directory and do an rm -rf on it.
I just upgraded to KDE 4.4.5 and was a little surprised about how very slow my brand new machine (dual core 2.2 GHz 4 GB RAM) appeared to be. I edited a file using vi and the file (1 MB) took a minute to be saved! Looking for reasons I found nepomuk and strigi. (When I started with the new system the machine was busy for hours with building indices.) So, as a Unix user, I did "man nepomuk" and "man strigi" and got no response! I went to the internet and found this useful discussion which taught me how to turn off strigi. This seems to have solved my problem. My machine is back to normal speed. But I am now very curious about the fact that all you discussion participants can spend so much time on the pro:s and con:s of nepomuk and strigi without ever giving a hint on how these "features" can be used. How do you invoke nepomuk? How can you find anything containing some keyword among all your so carefully indexed files? There are certainly no UNIX commands strigi or nepomuk! Just for curiosity it would be interesting to learn how one could benefit from all fantastic features of nepomunk which I certainly cannot even understand (I do not know the meaning of desktop sharing, data management, collaborative environment, an cross-application linking etc.)
Best wishes to you all, vonbarth
Wow. Quite a bunch of comments on that. Stumbled across this article trying to figure out how to make Nepomuk a bit more "lightweight" on my machines, I just feel like adding my €0.02 for whatever it's worth: Recently I moved to KDE 4 - not despite but actually because of things like Nepomuk. Overally, these days I see people forking GNOME 2 and KDE 3.5. I see people re-implementing new desktop environments, new file managers, new MUAs, over and over doing the same thing again but barely pushing things any further. We run 3D accelerated desktops but, in terms of working with computers, we're still on the lowest level possible (moving around files in disk file systems).
The same time, even in 2013s open source desktops, I am completely unable to have an easy, intuitive way of, say, keeping e-mails, web-links, images, source code files and other arbitrary stuff that belong to, say, one project, one session, ..., together without having to store them in one physical folder on some disk. This is fairly unpleasant and feels all stone-age in some ways. From that point of view, I consider Nepomuk and all the infrastructure related to it something that might provide an actual gain to an end user once it's integrated with its environment seamlessly enough to work well without getting in ones way. Maybe it's a matter of choice, but personally, I'd rather spend hardware resources, RAM, CPU cycles and the like on something like Nepomuk which helps me managing information from various sources in a more sane way than having an enhanced UI providing me with translucent windows. ;)
Hi all,
I think I've identified the biggest problem with Nepomuk: exposure.
I'm a new KDE user, and I noticed an icon in the 'Show hidden icons' tab of the main dock: "Desktop Search File Indexing". My question: "Oh cool, what does this do, how do I use it?"
Clicking on that icon allows me to click a button that says "Suspend File Indexing", but what I want is a button to search my desktop. I did see the word 'Nepomuk', and so I googled that, and found articles about how to write programs that use it. Dang, that's not what I want.
After much searching I found this page, which claims there's fabulous features inside, and I read that Dolphin can use it. Fine, so I start up Dolphin, and figured out that I have to enable the 'information' pane. Ok, great. Then I see there's a 'Find' button at the top, and I can search filenames or content in this directory or 'everywhere'.
But how do I search for email? And what about all the other features that developers are gushing about? I can't find it, so I can't say if it's good or bad, I can only say it's frustratingly invisible.
Thus, I say that 'exposure' is what nepomuk needs. Advertise it a little more inside KDE, put up a prominent USER-oriented web page detailing how the common user can use the data nepomuk indexes to be faster/better/smarter than somebody using just Microsoft Windows or MacOSX.
You've (probably) got a wonderful 'product', but if nobody knows where it is or how to 'buy' it, you're failing.
Thanks
Post a Comment