Fired up KDE the other day....
|
| Author | Content |
|---|---|
| Alcibiades May 06, 2010 8:32 AM EDT |
I fired it up the other day. Kontact was crashing in a new and interesting way on this one machine, Debian Squeeze. Start it up, then invoke mail, then invoke korganizer, and it crashes. Start it up, invoke korganizer, it crashes. Start it up, invoke mail then korganizer from the terminal, it crashes. Start up korganizer from the terminal, then mail from Kontact, its fine. What is going on? Dunno, but if you search on korganizer or kontact crashes, there's no lack of hits. OK, I thought, lets update to the latest and greatest KDE and see if that helps. It doesn't. The only thing that helps is getting rid of Kontact and running all the components separately, then its fine. However, in doing this, I got another look at KDE, which is always said to be getting better and better with every release. Its not, its completely unusable. Everything takes endless clicks to start, the panes slide around with no rime or reason. The apps have had to be rewritten for it, and this has led to bugs. My opinion remains the same, when they moved from 3.5 to 4.x, it was just crapping on their users from a great height. Cannot imagine what was going through their minds. |
| dinotrac May 06, 2010 8:57 AM EDT |
Are you sure it was from a great height? Heights tend to affect aim, and they seem to have hit the user base square on. |
| azerthoth May 06, 2010 3:53 PM EDT |
It's interesting as my laptop hasnt been logged out of or rebooted in [uptime= 25 days, 4:50] without a single crash of KDE or any of its apps. Must be a Gentoo thing. I really wish I could duplicate all these crashes and things moving randomly about so I could see what everyone was yapping about. Maybe if tried another distro that expected everyone to accept whatever binary was thrust upon them I would see it. |
| Bob_Robertson May 06, 2010 9:58 PM EDT |
To quote George C. Scott, "Alcibiades always went for the jugular." I had decided to go with xfce, since it can quickly be made clean and simple and still has removable media show up as icons on the desktop (which KDE4 does not). However, the latest xfce has dropped "menu merge" so that the "Debian" menu no longer shows up. The "Debian" menu is everything installed on the machine, while KDE shows KDE specific things, xfce shows xfce specific things, Gnome shows Gnome, etc etc etc. But since any program will run on any DE, the Debian menu allowed access to the "other" applications. Not any more. For some reason, Lxde won't load so I've been channeled into using KDE4, and while it's marginally easier to use than the first time I tried it, it's still repulsive. I do not like it, Sam I Am. {spit!} |
| tuxchick May 06, 2010 10:40 PM EDT |
Bob, that is an inspiring tale of Progress and Innovation. |
| hkwint May 06, 2010 10:57 PM EDT |
To those who have not tried/used Kontact for a while (It's a Kontact problem), let me try to explain what has happened lately.
In my own words: -Some set of developers thought it was (too) hard to maintain and expand KDE using KDE3 frameworks. -Same set thought, the solution was 10+ new frameworks and mentioning the result 'KDE4'. -Some frameworks were ready, some were not, all KDE applications didn't use the new frameworks, but nonetheless KDE 4.0 was released, to make sure enough people would test the new frameworks. -Two of these new frameworks aimed at Personal Information Management ('Outlook'/'Kontact') were / are Akonadi / Nepomuk. These two are famous for causing all troubles. -Akonadi needs a database. Currently, it's using MySQL, because other databases are not suited. http://techbase.kde.org/Projects/PIM/Akonadi#Which_DBMS_does... So desktops users (!) are now running MySQL and InnoDB. However, both MySQL and InnoDB were never intended for non-database savvy 'end' users' such as you, I and probably 98% of the other KDE users out there. MySQL only recently switched to InnoDB however, this might also explain some of the problems, I'm not sure. -There's a well known bug in ~/.local/share/akonadi/mysql.conf (the file recently switched location I believe, first it was somewhere else). That's right, regular desktop users now need to worry about MySQL/InnoDB configuration, just because the people at KDE think you and I need a database in order to keep our addressbook. So, if you fix the file I just mentioned, you might be OK. -However, there's also NEPOMUK. Some semantic desktop project with EU M-$'s in it that they hope to share with Gnome. It's ought to make your desktop smarter and bring 'natural language capabilities' to your desktop. As of 4.3 however, NEPOMUK was'nt required to be part of Akonadi yet, so you could run Akonadi without NEPOMUK, and therefore you could run Akonadi without MySQL. However, since 4.4 NEPOMUK is a required part of Akonadi. Which means, if somebody updates from Kontact 4.3 to 4.4, they might have some new troubles. For me this update caused problems: InnoDB started complaining some log-files had date-stamps in the future (never mind I'm a desktop user, why should I care?). NEPOMUK wouldn't register at DBUS, however, when I moved two files (from the viewpoint of Kontact: Deleting them) all is fine now. Az: Quoting:Must be a Gentoo thing. Probably you're not running Kontact 4.4. Under Gentoo, Kontact is not part of kde-meta. These problems are in Kontact (kdepim-meta), not necessarily in KDE. I suffer from the same kind of problems (and as you might know, I run Gentoo as well). Not only Gentoo users do, it's not without a reason there's a whole page devoted to Akonadi problems on the KDE-website. http://userbase.kde.org/Akonadi_4.4/Troubleshooting If you want to see what everyone is yapping about: -Run and use Kontact 4.3 for a while. Then: #autounmask kdepim-meta-4.4.2 #emerge kdepim-meta-4.4.2 $kontact Just because you use Gentoo doesn't mean Kontact is stable for you, otherwise the KDE people would just advise everybody to use Gentoo and all problems would be gone, don't you think? |
| dinotrac May 06, 2010 11:03 PM EDT |
Hans - Stop making sense. TOS violation. |
| tuxchick May 06, 2010 11:25 PM EDT |
Well they've been saying KDE4 is all baked and ready to rock for quite a number of releases now...maybe not raising expectations would be wiser? I always wanted to be a database admin. But not for my tiny KDE address book. |
| hkwint May 07, 2010 1:19 AM EDT |
First they promised MySQL as a dependency would go away after they made it work with SQLite, now they found out they can't and make Postgresql their second bet, and then at 4.4 they suddenly add NEPOMUK. I'm not sure about this, but when I'm baking bread, changing the ingredients of something that's 'already baked' sounds like a bad idea to me. Dino: I'm really sorry. I was out of internet for some hours (half the country, they had to cut an important line) and then I couldn't sleep, so I had too long to think about that one. Hence the nasty linebreaks caused by copy / pasting from console. |
| azerthoth May 07, 2010 2:23 AM EDT |
I already have it installed as I use sets rather then metas. However since I also run from the KDE overlay I have moved to 4.4.3 already. I'll give it a looksie. |
| jezuch May 07, 2010 2:25 AM EDT |
Currently, my only gripe with KDE4 is that it's ssssssslllllllllllloooooooooooowwwwwwwww. It's really, really, really slow. And I don't think I can blame it on graphics drivers. And every new release gets noticably slower than the previous one. But, on the other hand, with the latest upgrade I got some new useless animations! Like smooth transitions when the window title changes. OK, it looks like I'm transitioning to the "KDE4 haters" camp. Sad. |
| krisum May 07, 2010 3:15 AM EDT |
Quoting: -Akonadi needs a database. Currently, it's using MySQL, because other databases are not suited. Really don't understand their reason for dropping sqlite. How can desktop use lead to massively concurrent access to the db? If their application really does access concurrently, create separate dbs for different components. Even things like Trac have been working decently for us with sqlite backend. |
| Alcibiades May 07, 2010 5:19 AM EDT |
Guys, are you saying that the kontact problems are intrinsic to the individual apps as well? Or do you bypass them when you invoke the apps directly and not through kontact? The only reason we are using kontact is that I have written some scripts which use the command line interface in konsolekalendar to generate event lists in the form that they want them. There does not seem to be any list view in evolution, the last time I looked. But maybe, if the above is right, we just have to get off kmail and korganizer and on to something else? We could get off kmail, obviously, thunderbird would be a very acceptable alternative, or maybe evolution. |
| Sander_Marechal May 07, 2010 5:53 AM EDT |
Quoting:Really don't understand their reason for dropping sqlite. How can desktop use lead to massively concurrent access to the db? Akonadi is used for PIM data. Such data is most often used by applications that run all day long. E-mail, calendar, messenger, etcetera. It's not massive concurrent access. But because these applications run for so long, sooner or later you will get collisions and deadlocks. |
| Alcibiades May 07, 2010 8:22 AM EDT |
Well, I just went over and took the thing (korganizer) out, and replaced it with Sunbird. Only thing to do really. It was now refusing to start, and the error messages had to do with too many crashes from some component, so it was refusing to restart. Hopeless. This is the second KDE 4 app that has broken irretrievably. The other one, I downloaded source for an earlier version and compiled from source and they are running the old version perfectly happily. They are still using kmail and kjots, but if we have any problems with them, they are going too. |
| Bob_Robertson May 07, 2010 9:10 AM EDT |
Al, clearly you are not alone. There is something very wrong with the PIM database back-end. From the Debian-KDE mailing list: >> Can other KDE users please triage these dataloss bugs in Korganizer in KDE >> 4.4: >> >> https://bugs.kde.org/show_bug.cgi?id=172464 >> https://bugs.kde.org/show_bug.cgi?id=226394 >> https://bugs.kde.org/show_bug.cgi?id=228674 >> https://bugs.kde.org/show_bug.cgi?id=236563 >> https://bugs.kde.org/show_bug.cgi?id=236658 >> >> Each one should take less than a minute to triage. >> >> Dataloss is a huge issue and I fear that it is not getting the >> attention that it deserves. Hopefully if some other users confirm the >> issues then the bugs will get priority. Thanks. |
| Bob_Robertson May 07, 2010 9:16 AM EDT |
> that is an inspiring tale of Progress and Innovation. Not all "progress" is forward. |
| dinotrac May 07, 2010 11:21 AM EDT |
Hans - So long as you're sorry, it's ok. But no more of that! |
| Alcibiades May 07, 2010 2:21 PM EDT |
Is the problem perhaps that KDE has moved away from the philosophy of doing one simple thing well? You notice that several apps are now trying to integrate with korganizer. You can see why, there are all kinds of things which if you think about it might be desirable to have generate a todo or a deadline. But if the underlying database gets screwed, the damage is really widespread. Lets hope we can carry on using kmail and kjots by themselves, otherwise its going to be off to thunderbird, and one guesses, gjots. Which last is not a bad package anyway. |
| krisum May 07, 2010 5:11 PM EDT |
Quoting: E-mail, calendar, messenger, etcetera. It's not massive concurrent access. But because these applications run for so long, sooner or later you will get collisions and deadlocks.So create separate dbs for email, calendar etc. If there is still concurrent access expected, take a big (interruptible) lock as appropriate which should not be an issue given that a user will normally not go in a click frenzy. I mean if even a plain text mbox file can work for thunderbird, an sqlite DB should be more that enough for kontact. |
| hkwint May 07, 2010 7:24 PM EDT |
Quoting:Is the problem perhaps that KDE has moved away from the philosophy of doing one simple thing well? Akonadi is just meant to do one thing and do it well: Handling and storing your contacts. In the past, different programs did it all their own way. The idea is to 'separate' the part which handles contacts etc., call it Akonadi, and then all KDE-apps use it for their needs to interface with the contacts-database. Also, I believe Akonadi was designed for 'large enterprises' as well (though I don't know any large enterprises using KDE4?), hence they thought performance could be an issue. |
| azerthoth May 07, 2010 8:12 PM EDT |
now I remember why I never ran into issues with kontact, like any other aggregated app like that, it's ugly and in trying to do many things it utterly fails at doing any of them well. Mind you I have found exactly zero similar apps in any OS or DE that doesnt meet that exact same description. |
| Alcibiades May 07, 2010 9:37 PM EDT |
The latest, they are now telling me their address book is not working. I'll probably have to go in tomorrow and move them to icedove/thunderbird over the weekend. There's really no excuse for this. Kmail and the rest of it worked perfectly for years. The only nice thing about this was how easy it was to migrate the korganizer to Sunbird, just point it at the ics file and it was done. It also turns out to print nicely in lists. Not bad at all. |
| Sander_Marechal May 08, 2010 4:39 AM EDT |
Quoting:So create separate dbs for email, calendar etc. But if you do that, these applications cannot share contact information anymore. The entire idea behind Akonadi is that all apps can share contact information. Sort of like LDAP on steroids. I like the idea. |
| krisum May 08, 2010 12:08 PM EDT |
Quoting: But if you do that, these applications cannot share contact information anymore.Why so? Most of the searches will be key based so, for example, it will be just fine to search the contact db with information from email db. Maybe their design requires elaborate joins, sub-queries etc. spawning these various components, but in my opinion if their design requires an elaborate DBMS just for desktop usage to work satisfactorily then there is something wrong with the design. |
| Sander_Marechal May 08, 2010 2:55 PM EDT |
Your design is too complex. In your design, if an application wants to find out about contact information then it would need to search the e-mail app's database, the messager app's database, the calendaring app's database, etcetera. And all this would need to be coded in the app, so it cannot search databases from apps that it does not know about. Akonadi keeps all contact information in one place. A much better design. The only problem is that they used MySQL as the background database. They could have used SQLite even though it cannot work concurrently. Putting a concurrent front API on a non-concurrent backend is a known and solved problem. Disk device access for one. |
| dinotrac May 08, 2010 3:06 PM EDT |
Sander - Shame on you for suggesting that the brilliant minds of the KDE team could possibly fail to learn from solutions that have been implemented over and over and over and over and over and over and over and over and over again. If they failed to implement something along those lines it must be because old solutions have no place in their zippy new world. |
| krisum May 08, 2010 3:26 PM EDT |
Quoting: Your design is too complex. In your design, if an application wants to find out about contact information then it would need to search the e-mail app's database, the messager app's database, the calendaring app's database, etcetera.Not really, don't know the requirements so all I have said is to separate out information into separate dbs where possible, if concurrency is really a problem. Of course, use patterns can dictate keeping some related information in one db. The simple logic being that if concurrency is the problem then it will usually be due to different applications accessing the db concurrently and it would be expected that those would access their own tables in the db. So there should be quite a lot of scope of separation in there. If lots of cross-talk is expected for certain tables, then it will make sense to put those into the same db. Quoting: Akonadi keeps all contact information in one place."Place" as in db, or "place" as in table, or "place" as in something else? In any case, it still can; I don't understand what's the problem in there. All that I have said of the design is that separation into different dbs can help with concurrency where not much overlap is expected, and related information can still be in one db. I don't think it makes sense to argue more about that since the use patterns are not very clear. Quoting: The only problem is that they used MySQL as the background database.That's the main problem we are discussing, isn't it? As I said, if they *need* something like MySQL to give them acceptable performance for desktop use then something is wrong with their design. Quoting: Putting a concurrent front API on a non-concurrent backend is a known and solved problem.Not if they require transactional semantics from backend. |
| dinotrac May 08, 2010 3:33 PM EDT |
>Not if they require transactional semantics from backend. Isn't that cute? Note the requirement: "transactional semantics from backend", not "transactional semantics". So...I suppose that a front-end can't take care of that. Better call the Rails guys... |
| hkwint May 08, 2010 7:09 PM EDT |
Quoting:don't know the requirements Well, I don't know exactly what a concurrent database means - because I don't know **** about databases (except that MySQL always throws errors on my desktop), but I might help you on that. The Wikipedia piece about Akonadi is probably written by someone from KDE, so I think it sums up the requirements quite well: -Should be extensible, because 'other' desktop projects might use it as well (usable beyond KDE), -concurrent read, write, and query access. Think it has something to do with their requirements it should be suited for the desktop where a single person is using it, or at a company site where 100 people are querying shared information, -unique desktop wide object identification and retrieval - I think that part tells there should be one 'one-fits-all' database were everything is stored. |
| gus3 May 08, 2010 9:31 PM EDT |
Hans: http://en.wikipedia.org/wiki/ACID |
| Sander_Marechal May 09, 2010 6:39 AM EDT |
Reading over the list Hans posted, I guess that something like CoughDB (which is ACID compliant) may have been a better choice for Akonadi. Especially since IMHO contact information isn't easy to map to an RDBMS. |
| tuxchick May 09, 2010 1:20 PM EDT |
I'm no database guru so I could be way off-- isn't LDAP expressly designed for this kind of usage? Not so fast for writes, but very fast for reads, and flexible in ways that RDBMs are not. Because they don't have an inflexible table structure, but can add and remove new fields as you need them. For these reasons big heavy-duty directories and user/asset managers like Fedora Directory Server, which used to be Netscape Directory Server, then iPlanet Directory Server, and then SunONE directory server are LDAP-based. |
| Sander_Marechal May 09, 2010 2:19 PM EDT |
Makes sense, TC. |
| hkwint May 09, 2010 11:29 PM EDT |
In fact, it uses 'extended IMAP'. LDAP can't store mails I assume.
MySQL is probably chosen as they wish to use it for 'groupware' servers too.
If you want 'desktop' and 'groupware server' to use the same framework, you end up with 'groupware server capabilities' on the desktop. http://conference2006.kde.org/conference/talks/9.php |
| Alcibiades May 10, 2010 4:08 AM EDT |
Understand there may be arguments for what they do. But the bottom line is, right now we are on Sunbird and not going back, and if Kmail blows up, we'll be off that in a flash too. Whatever the desirability of various features, being able to use the thing is the most important. Without that, you don't have a product, or users. |
| hkwint May 10, 2010 8:16 PM EDT |
I think my last post touches the core of the problem: If you make something for the desktop and something else for groupware servers, you might end up with duplicated efforts, if you 'unify' desktop and groupware, you end up with 'groupware' capabilities on a desktop, and the result is the 'dependency' on MySQL. |
| krisum May 11, 2010 1:27 AM EDT |
Quoting: if you 'unify' desktop and groupware, you end up with 'groupware' capabilities on a desktop, and the result is the 'dependency' on MySQL.Normally apps should be programmed to use something light like sqlite for light/desktop use and separate DB server like MySQL for heavy/server usage. For instance Trac issue tracking system supports multiple DBs, so SQLite can be used for light usage and Postgres/MySQL for heavy usage -- we have used both as per requirements without issues. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!