The Discussions and Opinions forum is a place for open discussion regarding everything related to KDE, within the boundaries of KDE Code of Conduct. If you have a question or need a solution for a KDE problem, please post in the apppropriate forum instead.
Reply to topic

stop programming

User avatar zlisiecki
Registered Member
Posts
19
Karma
0
OS

stop programming

Fri Jun 01, 2012 7:53 am
Hi,
KDE was a nice set of programs. Unfortunately the programmers didn't stop programming and now (4.7.2 version) in my opinion some main features seem to be completely spoilt. My current Kontact/Kmail version didn't succede to import mails from the former one, the mail filters seemed to download mails from the mail catalogue itself and number of mails doubled each time kmail was started. There was no other way than move the whole .kde4 and .kde trees to some other position and recreate the whole desktop forgetting the old one. For some time the system worked fine. Unfortunately some importand mails appeared to be stored in virtuoso database somewhere in the old .kde4 . I found no tools to make use nor to extract anything out of this huge akonadi database and I tried to temporarily use the old .kde4. At this stage KDE seamed to manipluate my own settings knowing better what I want like Windows systems does it. There was no return to the proper .kde4, which worked fine !

My conclusion is that probably trying to speed KDE up main user data are stored in cache-like structures, which violate their original consistency. Probably the programmers didn't understand why importand data and settings are traditionally stored in the filesystem (in config files) in UNIX-like systems and so they put everything alltogether in a messy way expecting it'll be faster. No deeper error could be ever done.

If it is not possible anymore to keep my mails in some repository of simple structure which allows access with standard Linux tools like grep the question arises if one shoud give up KDE and search some other desktop program suite.

regards, Zbyszek
User avatar Wizard
Registered Member
Posts
99
Karma
0
OS

Re: stop programming

Fri Jun 01, 2012 8:41 am
I agree with all you said, Zlisiecki. Moreover, KDE devs broke one of the most important UNIX rules: "If it works, don't touch it". I had 0 (zero) problems with former email storage (was Kmail using Maildir?), even with huge, corporate accounts with thousands of emails. After upgrading to KDE 4.7 I ran into constant problems with basic things, yesterday an accound disappeared from Kmail.
I'm also worried because trend of completely abandoning UNIX background is progressing. Everything started with introdution of semantic desktop/nepomuk/strigi/whatever in KDE 4.0. It still (as of KDE 4.7) does not work properly and is mostly used to eat resources and delay boot time. So yes, KDE developers: stop coding! Make existing things work first. Freeze features and fix them :(
User avatar zlisiecki
Registered Member
Posts
19
Karma
0
OS

Re: stop programming

Fri Jun 01, 2012 11:22 am
Thanx Wizard for your reply. This alows me to express some further concerns:

One of Windows - Linux main diffrerences is a well a known comfort Windows is offering. Users even don't need to think much. They get on their screen automaticly what seems best suitable. The problem arises when users really start to think on their own. Unavoidable the computer and the user concure. Linux on the other hand offers some tools with well known interfaces and even internals alowing users to use them the way they want. Let me explain this basic difference in philosophy with the example of Kontact/Kmail:

Kontact/Kmail maintains data consistency basing on some files/catalogues like .local .kde .kde4 . It might be considered as an error if I move them to other places. But what happens when I move these directorys back to the old position and if I does it from the root account. It apprears that after logging in data are still inconsistent ! This proves that Kontact/Kmail/akonadi system tried to manipulate these ressources without my knowledge and without my will ! Still half a problem if the consistency was recreated. My experience as described above shows the opposite.

If some software doesn't work properly one simply decides to use another software package, but if one cannot take one's original data, because their consistency was spoiled during this intermediate usage the situation resambles sabotage. This forces me to the question if some decisive KDE developers are somehow, possibly indirectly gratuated by Microsoft. Let me stress that this is only my open question and not any answere nor objection. I simply see no other good explanation nor the cause for the chosen Kmail technology.
User avatar einar
Administrator
Posts
2272
Karma
5
OS

Re: stop programming

Fri Jun 01, 2012 11:00 pm
Akonadi does not store anything, it's just a cache. Nepomuk does have the mail content (except encrypted mails) to enable full text indexing (and to handle contacts - which is properly working in soon-to-be 4.9), but has no role in displaying things and the like.
Before you point out what seem to be obvious mistakes, you have to keep in mind:

1. Development manpower is always limited, and despite that things are steadily improving (few remember how KMail 2 was in the 4.6 days - I did, and it was nowhere as good as now)
2. Have a look at the Akonadi FAQ as it covers some of the criticisms (warning: it's quite technical).

There are certainly a lot of pain points with PIM at the moment (but also see point 1), but I'd prefer objections to be more technical than gut feelings.


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
cmrntnnr
Registered Member
Posts
22
Karma
0
OS

Re: stop programming

Sat Jun 02, 2012 11:53 am
I too am in agreement with Zlisiecki. Sadly, the topic is a rehash of heated discussions from the past on this forum and others. KMail has many bugs, usability issues, and lack of reliability. It is great that the developers have ambitious goals and work to create great software. KDE 4.8 series is the best yet. However, KMail is an unfinished product that was released as stable to unsuspecting users. On the upside, it does seem to be improving.
User avatar einar
Administrator
Posts
2272
Karma
5
OS

Re: stop programming

Sat Jun 02, 2012 1:42 pm
It was exactly because it was released that it got an official maintainer again, by the way.


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
cmrntnnr
Registered Member
Posts
22
Karma
0
OS

Re: stop programming

Sat Jun 02, 2012 4:34 pm
Further debate on the history of kmail/akonadi/strigi/nepomuk is pointless. The question should be how to prevent another kmail style debacle. It is good that kmail has improved a lot with KDE 4.8 and with luck the good trajectory continues into 4.9.

My point and I believe the point of others is that quality and bug fixing should be considered before software is released into the world as stable. This should be true even for FOSS programs. Users are not guinea pigs; they deserve accurate information to make decisions. Why is releasing an unstable or barely usable product as stable related to having an official maintainer?

Have the maintainers of KDE considered a quality standards board?
User avatar zlisiecki
Registered Member
Posts
19
Karma
0
OS

Re: stop programming

Sun Jun 03, 2012 7:58 am
cmrntnnr wrote:... It is good that kmail has improved a lot with KDE 4.8 and with luck the good trajectory continues into 4.9....

Hi cmrntnnr, I cannot agree. I took a look at more technical description, as Einar suggested:

I noticed KDE uses his own hidden mysql-based database system as a intermediate instance to access all desktop parameters and KDE data alltogether. This means you need a nontrivial and complicated tool to retrieve the simplest data, for example to get the current timezone KDE calls complex structure performing SQL-language parsing, etc. Could anybody answere the simple question - why ?

As one reads the documents one can get the expression KDE-team made a variety of nontrivial decisions about a database usage without rudimentary understanding: a hidden unsupported database system means they try to substitute the mysql company and their engineers , while their initial task was to construct and develope the desktop environment. The reason appeared to be KDE needs a special sort of storage, which not everybody offers. And why does KDE need this storage ? Reading the documents I guess they where looking for concurency control. Possibly they don't know a standard IPC with semaphores, etc. At this stage the situation resembles somebody who hired a truck, because he'v heard a truck has two mirrors allowing to look ahaed and two is always better than one. What he originally needed was to came his hair.

Yet let us ask further question, why KDE needs a concurency control while retrieving the timezone. Nobody changes the timezone with two different applications at the same time and if somebody does it no serious trouble emerges from that.
I guess KDE needs a concurency control because KDE-team decided to retrieve some parameters like the timezone and application data like e-mails with the same tool and the concurency control was actually needed for this application data access. And why does KDE retrieve desktop parameters and application data with the same tool ? Because of some ill idea to have an intermediate cache-like storage for everything. For me it sounds like:

cat every_program* every_data* > very_nice_file

arguing one has all the bits in one nice place now where one can access them with some standard tool (like a good editor).

So what is my conclusion and my advice now:

1. First stop any KDE-development until you have serious Linux programmers, who know standard IPC and have some knowledge about database systems. Not doing so spoils KDE more and more causing serious demage of it as a Linux desktop alternative for Windows. KDE is a community project, which means the information to the community must be given - we don't have enough serious developers, so he don't develope ! Issuing new versions for image purposes alone is counterproductive - you don't need this !

2. If KDE-team starts programming the first step must be to bother about users, who lost their data, like me. I lost my e-mails and I cannot retrieve them in a simple way because one can access them only with akonadi and from akonadi, which causes circulus vitiosus. A simple tool is needed to restore the data to some standard form allowing to import them by other popular programs like thunderbird in place of kmail in my case.

3. Before any KDE developement can take place a KDE team must present a model for a open discussion and all objections must be solved. One must plan the manpower too.

4. Surely get rid of any hidden database system as soon as possible.

Please excuse me, that I state some opinions and draw conclusions without takeing part in former discussions and even without knowing them well. I was just forced to do this by the situation, which appears to me to be dramatical. Belive what i say just if you want and on your own risk.
User avatar zlisiecki
Registered Member
Posts
19
Karma
0
OS

Re: stop programming

Sun Jun 03, 2012 11:33 am
One more remark: I don't have any knowledge about somebody in KDE-team beeing paid to spoil. The true influence might be more subtile. Yet if some corporate professionals have both technical and material means and the known consciousness to asure their primacy why shouldn't they do it ? In my opinion serious Linux developer teams must consider such threats, even if they doesn't take place now. The responsible project planning and open discussion are demanded by be-or-not-to-be situation and not by an idealism.

I have no knowledge nor means to continue this theme further. Excuse me that I expressed it so roughtly.
cmrntnnr
Registered Member
Posts
22
Karma
0
OS

Re: stop programming

Sun Jun 03, 2012 12:25 pm
There is a lot going on beneath the surface of the kde ui that seems unnecessarily complicated. The database example is a nice one. This is FOSS software. Developers are free to use the tools familiar to them and make the design choices they will. Ideally, the designs would be elegant and built on a solid foundation with tried and true tools. That freedom does not mean that KDE stable releases should include whatever software a developer or development team wants in the distribution. At the same time, telling developers that programming and program design must be done a certain way seems to me at least to be against the concept of freedom. I do not want developers to stop programming. They should keep working and properly finish a project; that is not a technical matter. Technical arguments are great but sometimes miss the bigger picture, the software should work before it is given to nondevelopers to use. On that point, kmail was released as a stable part of KDE, and it did not function properly. The large number of cases of lost email and horrendous amounts of time to migrate created negative value. Forum discussions like this one show that users are still sore. In my opinion, the kmail programmers and KDE leadership could have handled this situation better. Quality matters!

I am done with this thread and subject, too.
User avatar zlisiecki
Registered Member
Posts
19
Karma
0
OS

Re: stop programming

Sun Jun 03, 2012 12:56 pm
Thank you.
coogor
Registered Member
Posts
31
Karma
0
OS

Re: stop programming

Fri Jun 22, 2012 8:51 am
Actually, I was about to open a similar thread, as I stepped over this one.
I fully share your disappointment about KMail2, I'm fed up with it as well. Having used KDE since version 1.x, there have been a couple of deep valleys, but none was a nightmare like this.
I'm not a programmer myself (at least not anymore), but look more from a user perspective on it. And the consequence should be: Stabilize especially KMail2 before adding new stuff. Look at bugs.kde.org and follow up on the bugs (as an example: I reported a data loss on the migration from Kmail1 to Kmail2 in february, Severity: major - and nothing happened so far, no further request for information (except about the OS version).
And this is what concerns me: Is there enough focus on quality within the KDE-project?
Odaer
Registered Member
Posts
12
Karma
0

Re: stop programming

Mon Jul 30, 2012 12:02 pm
really, this thread is serious dumb....
User avatar einar
Administrator
Posts
2272
Karma
5
OS

Re: stop programming

Wed Aug 01, 2012 7:24 am
I do not agree with the original poster, however I have to remind that the Code of Conduct and the forum rules must be upheld, even if there are strong feelings of disagreement. In short, use of "dumb" like above (or similar terms with same name-calling feeling) will not be tolerated.


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
User avatar Wizard
Registered Member
Posts
99
Karma
0
OS

Re: stop programming

Sat Nov 10, 2012 11:51 am
Sorry for bringing this thread back to life, but I've found kind of solution for people disappointed with akonadi and I think it's worth mentioning.
Seems Debian has it's quality requirements set too high for akonadi to be included in testing. I may be wrong, I don't follow Debian's development cycle and I don't know real decisions behind it, but as for today, Debian Wheezy includes kontact 4.4.11.1, while KDE version is 4.8.4. Einar mentioned many akonadi 4.8 bugs fixed in 4.9 and Wheezy is heading for release, so seems newer kontact inclusion is quite improbable :)

 
Reply to topic

Bookmarks



Who is online

Registered users: AGB, anli, Baidu [Spider], bilbo, Bing [Bot], bshah, Exabot [Bot], garthecho, Google [Bot], google01103, Hans, jensreuterberg, jsirek, jstaniek, koriun, metzman, MiceAreVeryNice, MSNbot Media, paulus3005, pedrorodriguez, Sentynel, vascobasque, Yahoo [Bot]