KDE Quality (problems)

Thu Apr 14 09:19:25 BST 2011

Hi :)

On Thu, Apr 14, 2011 at 8:45 AM, Clemens Eisserer <linuxhippy at gmail.com> wrote:
> Hi,
>
> I use KDE since 1998/1999 with kde-1.1 beeing the first version I
> remember having used.
> I always found it to be simply the best Desktop Environment,
> escpecially during KDE-2.x/3.x times.
> Since KDE-4 I am not that happy anymore.  Early releases were
> horrible, ~4.3/4.4+ is ok, but still not as solid as one would expect.

I've been using KDE since more or less the same time (makes me think
I'm getting old ;)

When KDE 4.0 came out I decided not to switch and stick to KDE 3.x
because KDE 4.0 was meant mainly for developers. Since I'm not a
developer ... I waited til KDE 4.2. At that same time I switched from
openSUSE to ArchLinux. What I found was that KDE 4.2 was WAY more
stable on ArchLinux than on openSUSE (and other distros).

Since then (KDE 4.2), I haven't looked back: ArchLinux + KDE SC 4. I
still keep an eye on other distros (mainly openSUSE & Gentoo) and I
must say that the stability that I find with ArchLinux is way better
that that of other distros. I would suggest you try other distros if
you find that KDE SC 4 on your distro is not that stable.

And, BTW, not only is it more stable, it's "faster". What do I mean by
faster? Easy: in ArchLinux I click and it responds immediately, it's
snappier. With other distros ... you have to wait. BTW: yes, using the
same hardware so I'm not comparing different distros on different
hardware. And no, not virtualising anything, all bare metal ;)

Obviously, this is MHO and YMMV. But if you've been using Linux for
that long ... I assume you're not scared of a bit of CLI and file
editing so I would invite you over to ArchLinux and try it out :)

> The problems I see are:
> 1. Too few developers, too much code
> 2. Too short release cycles & Quality testing
> 3. Features count most mentality.
> 4. Performance
>
> I normally wouldn't bother the list with my ideas, however I have been
> encouraged to do so.

FLOSS is all about Community so I think that giving your opinion is
always good, specially if you do it in an educated way (as you have
done), you don't demand anything and you don't insult anyone. So as
far as I'm concerned: thanks for your opinion :)

> Ad 1.)
> I participated during the kde 4.2/4.3/4.4 beta phase - and came to the
> conclusion it was mostly worthless effort on my side. There are
> simply not enough contributors arround to fix all the open issues.
> I have already a few projects I contribute to, fixing the bugs myself
> is simply no option :/
>
> Furthermore KDE accumulated tons of code over time (I still don't
> see the reason it carries its own Office-Suite, HTML-Rendering
> engine, instant messanger, Media Player, whatever), but only
> few guys are actually working on the code.
> An excellent example is Kopete, which by itself is a great instant
> messanger - however its almost unmaintained. Very urgent problems are
> fixed by people alien to the code, but other than that, the code rots
> and nobody is willing to maintain it, not to mention implement new
> features. Looking back, probably the idea to include their own instant
> messenger into KDE was a bad idea? Who knows, at least it wouldn't be
> KDE's problem if kopete died. The same is true for Ark and a few other
> non-core components.

The # of developers is probably a "marketing" issue. What I mean is
that maybe KDE should try to recruite more developers in some way:
maybe in installfests, maybe in Universities, get more companies to
contribute patches, ...

Another thing that would help is to make more noise about who uses KDE
(or KDE technologies). Companies such as Kitware develop very
interesting (and useful) software, for example.

> Ad 2.)
> Another problem is the release cycle. The cycle is so short, that even
> many bugs reported during alpha stage aren't fixed. At release-time,
> devs are already working on new features, often not backporting their fixes.
> So you end up again with release+1, this time with other bugs.
>
> Its not uncommon for me to see integral parts broken after updating to
> a new major (like the panel in my multimonitor setting when updating
> to 4.6).

I agree with you here but, I would add MHO: maybe 1 release in every 3
should be just for "polishing" KDE SC 4.x. No new features just bug
squashing, optimizing performance, fixing security issues, profiling,
... The other 2 releases would be the "normal everyday work".

Maybe this would help make a "better" KDE (if that's possible ;)

> Ad 3.)
> Features count most. Plasma may still be not completly stable,
> and the TaskManager may do weird things (both from a user perspective
> absolute core-components),
> however wee see social network integration and whatever.

That's why I suggest having 1 (minor) release in every 3 (or maybe
every 4) just for bug squashing, profiling and the sort.

I know there are bug squashing weeks, beta versions, ... But as
Clemens says, it's a short release cycle ... and this is just MHO.

> Ad 4.)
> I remember KDE4 was praised for using less memory and beeing faster than 3.5.
> I knew that would't become reality, 4.6 uses about twice the amount of
> memory 3.5.11 used and starts up way slower.
> Paint performance is mostly bad, but instead of improving the painting
> all simply paint to X11/Xorg and praise the QT-Raster backend which is
> here to solve all problems.
> Guys, XRender has arrived and is implemented by drivers well. If QT /
> your code can't use it - don't blame X11.

In general, all software has grown and gotten fat (I guess that's
called aging and it happens to all of us ;) But hardware has also
gotten "faster" and more powerful. For example, it's easy to have 2 GB
of RAM in a laptop (I've got a netbook with 2 GB of RAM and I bought
it 2 years ago). I'm not trying to defend "bloatware", just stating a
fact.

We all know that buying more hardware is cheaper (and faster) than
profiling and debugging and optimizing code. Sad but true. This takes
me back to my idea of dedicating one release cycle just to those
chores.

We also have to take into account that KDE is not an isolated project.
What I mean is that compilers and non-KDE libraries also affect KDE.
For example, during the KDE 3.x versions there was also a rant in the
KDE community about performance. The KDE developers got to work on it
and it wasn't KDE's "fault". The reason was that gcc wasn't really
optimized for (or couldn't optimize) C++ code. The KDE devs sent some
patches to gcc and the next KDE version was much "faster" and all was
nice and lovely once again :)

Adding new features is not always bad (MHO, again). For example, if
the KDE devs use OpenCL, maybe (and just maybe) we could get better
performance and use our GPUs as co-processors for certain apps
(Kspread, digiKam, ...). Obviously those apps that are highly
parallelized and use SIMD instructions would be the ones that get a
performance boost.

   Rafa
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.