27 Apr
2012
27 Apr
'12
7:25 p.m.
On Fri, 27 Apr 2012 11:05:12 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
[disclaimer: I'm not a KDE4
developer and I don't receive any dividend
on the success of either KDE or TDE]
Writing a program in C++ has some overhead, compared to writing it
directly in asm or in C (for example, the brain-dead name mangling in
the GNU v3 ABI, which brings an overhead for the dynamic linker).
Removing your C++ compiler will accomplish little in building a lighter
TDE. The overhead remains. The dependency on a C++ compiler remains.
Considering that, do you see people requesting TDE or KDE being
rewritten in C or x86 asm ?
I think with Akonadi this is the same. Akonadi uses an
industrial-strength DB engine, which is (in the case of MySQL at least)
geared for servers with GBs of RAM. On the performance side, it takes
~150M of RAM on a x86_64 system where KMail handles ~14K mails weighing
~800M and where there is ~1,5G more free RAM; IMHO it is satisfactory.
(and for nepomuk and strigi, they are not really mandatory AFAIK)
I mean if we
started using kwin, we would definitely have
influence upon it because we would be the users. Reporting
bugs requesting features. I am not sure what else you mean
by "influence". KWin4 does everything TWin does.
One of the points of contention with this and other related topics is
how much influence do KDE4 users have? Please notice I did not write
users have no influence. Nor did I write developers don't listen or
respond to users. I only asked rhetorically how much influence.
Consider that nepomuk/akonadi/strigi remain non negotiables, despite
users requesting this from Day One. The argument that these services
can be disabled is not the same as not installing them in the first
place. When other apps depend upon the libraries of those three
packages then disabling the services accomplishes little. The
overhead remains. The dependencies remain.
Many non enterprise users have no need or interest in social
networking, regardless of the potential merits. The entire
nepomuk/akonadi/strigi philosophy never has been optional within
KDE4. Few people have argued that those features be ripped from KDE4.
They argued that they should be optional. Truly optional. People who
run a half dozen KAlarm events and check email twice a day don't need
or want a caching engine running in the background. They don't care
about sharing desktops or activities with other people. They don't
care or need massive meta data indexing.
Sharing desktops and activities _are_
optional in KDE4, since I don't
use it. And the data indexing won't be massive if there isn't much data
to index.
Yet building KDE4 without those three modules is not possible. Much
like using Windows without IE is impossible. Where is the true choice
and influence (other than using a different desktop environment)?
Using KDE without
Qt is impossible. Where is the true choice and
influence ?
If I could use KDE PIM apps without akonadi then likely I would be
using KDE4 part time. Not to mention that I still read reports that
KMail remains broken to one degree or another --- four years later.
IIRC the old
KMail in KDE 4.4 didn't require Akonadi. Since KDE is
backwards compatible between major version numbers you should be able
to use it even on KDE 4.8/4.9.
How much influence would Trinity users have with kwin4 development? I
don't know. I have read too many KDE bug reports that were closed as
Won't Fix.
Those are some of my thoughts about influence.
A significant point about this kwin4 discussion is if kwin4
integration is doable then let the hacking begin. Put up or shut up
(not you Calvin but anybody who wants this integration should put up
or shut up, including those proposing the idea). We Trinity folks
don't go pimping in the KDE4 forums. If we tried that we would be
banned in less than 24 hours. Why do certain individuals think that
pimping KDE4 products here in the Trinity lists is any more
acceptable?
Certain people need to stop acting like a telemarketer. Annoying.
Leave us alone. The proposal has been made. The door to integration
is open. Let the hacking begin.
Let's keep it friendly and to the point.
Indeed. Be friendly. Be open. Stay focused. Block email addresses.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting