A week of KDE4 usage

[Duncan]

Alex Schuster posted on Thu, 12 May 2011 00:27:50 +0200 as excerpted:

> Rafa Griman wrote:
> 
>> My experiences WERE similar (not any more :) The thing is that the
>> issues I had with KDE SC stability/hiccups/whatever were on a certain
>> distro. When I switched distro ... KDE SC was stable.

>> So the thing is: have you tried another distro? Honestly, change
>> distros and you'll see that KDE SC isn't as bad as you think.
> 
> Nooo way, this won't happen :) Sorry, but I just love Gentoo Linux. I'd
> rather give up KDE4 than using another distro for my personal purposes.

For those who find Gentoo matches them (and I'm certainly one), it often 
fits like a glove and they'd be hard pressed to switch to any other 
distro.  It just doesn't feel right, because it can't be customized to fit 
one's needs so exactly, while at the same time remaining quite automated 
(unlike say Linux from Scratch), so while updates take a lot of clock 
time, they don't take a lot of the /admin's/ time, leaving the admin to do 
other things with that time, like Gentoo can.

I know I run OpenWRT on my router, and while it's an amazing distro on an 
amazing little box, I'd be SO much happier and more efficient if I could 
simply run Gentoo on it.  That's probably why, despite putting OpenWRT on 
it, I don't do a lot with it.

Which is why I'm thinking strongly of ensuring that my next router can 
handle a reasonably mainstream Gentoo, whether that's because I use an x86 
(or even amd64, thus being able to compile once for it and the main system 
in many cases, tho I do have an x86-32 netobook so I could share with it 
instead) based system, probably low-power/fanless, or a well supported ARM 
that is known to work with Gentoo because some dev or outspoken user is 
already doing it.

It's also worth mentioning that Gentoo is by policy a "light-patches" 
distro.  They try to run as close to upstream as possible by policy, only 
patching obviously broken stuff as well as adding patches where necessary 
to make it work properly in Gentoo (honor user CFLAGS where upstream hard-
coded their own, make optional dependencies lock hard-on or hard-off based 
on USE flags rather than "automagically" detecting what's installed and 
supporting it, as that screws up dependency tracking, etc.).

> I also have some experience with [open]SUSE, Fedora and Ubuntu, but I
> did not use KDE4 much there, and did only basic things that would work
> here, too.

>> In the openSUSE Spanish mailing list, there have been all types of
>> regrets towards KDE 4 ... how many have tried KDE on another distro ?
>> ... But people keep on ranting that it's KDE's fault. That's not true.
>> We all know that distros usually add some "features" to "help" you and
>> "make your life easier and nicer".
>> 
>> Honestly, try ArchLinux. It just works. Maybe you have to spend a whole
>> weekend installing it and configuring it. But once it's up and running
>> ... you never ever configure it again: it's a rolling distro
>> 
>> :)
> 
> Yes, I heard good things about ArchLinux, I think it would be my choice
> if there were no Gentoo. And a rolling distro is great. Back in my
> SuSE/Mandrake/Debian/Libranet days, there was not a single upgrade from
> one version to another that did not have big flaws. Some bugs were
> fixed, but others appeared, all in all things went not much better, and
> I had to put time into discovering the new problems and finding
> workarounds for them.

IIRC I read that OpenSuSE is trying a rolling update approach on one 
project now.  If I wasn't hooked on Gentoo already, I might try it.  Or if 
I supported others on their systems as you two do.

Also Linux Mint, but while it has a KDE edition, I think the rolling one 
is Debian Gnome based, tho I might be wrong.

And, back when I ran Mandrake (before it became Mandriva), running Cooker 
was pretty much rolling update, altho they did freeze for a month or so 
before a release.  I believe Debian unstable Fedora rawhide, etc, are 
similar.

> Gentoo sure also has it problems, but if some update refuses to install
> I can continue working. I do not have to take a free weekend like for a
> Mandrake update, hoping that the time would be enough to get a working
> system again, and being prepared to restore the backup just in case the
> update would mess up everything. I do not even have to take the machine
> down for upgrading, my home server once had an uptime of > 400 days,
> running the newest software. Well, except for the kernel, which is why I
> had to reboot eventually.

FWIW, if you've not found and are using a similar tool already, try 
emerging lib_users.  It came up in a comment on the getoo-dev list, and 
someone pretty quickly had an ebuild in-tree for it.  The idea is to run 
it after you do an update.  It goes thru /proc and finds cases of 
applications still mapping otherwise deleted libs.  After the update quit 
kde/X (since that's often a whole slew of such apps running in them think 
of every kde app depending on kdelibs or qt, for instance, and conversely, 
how frequently there are updates to codecs, etc, which appear as libs most 
frequently used by X-based programs), and run lib_users as root to see 
what daemons, etc, need restarted so they'll actually be using the updated 
libs not the old ones.  You can then either restart them one-by-one, or if 
it's enough to be a hassle for that, simply reboot.

In addition to getting the old libs properly cleaned up in existing apps 
so they can't cause any problems, restarting such apps as necessary is a 
good security practice, since it's reasonably likely that at least some of 
those library updates you just did were security related, and restarting 
apps using the vulnerable versions eliminates the window of opportunity 
you're otherwise still exposing, until you reboot or otherwise restart 
these apps.

> I think it's my Radeon HD3200, which is not supported as well as newer
> chipsets. I already thought about replacing my on-board graohics with
> another graphics card.

It's also quite possible it's because it's on-board.  On-board graphics 
are known to be quite finicky and bugridden, sometimes, compared to even 
what should be the same thing, as an add-on card.  Plus the compromises 
they often make with shared system RAM instead of dedicated video-RAM, etc.

Only Intel is said to avoid that (and only to some extent), because on-
board is all they do and native freedomware drivers is all they do, no 
proprietary driver so all their generally quite good efforts at Linux 
support go into the native driver for their on-board graphics.

The exception proving the recent rule, of course, being Intel Poulsbo.  
And apparently that was the right hand not talking to the left about what 
it was doing when it contracted third-party graphics without ensuring 
sufficient permissions to properly open-source things as they normally do.

OTOH, I tend to be an AMD guy for anything desktop/workstation/server (IOW 
not laptop/netbook/mobile), which means Radeon, since nVidia's proprietary 
which I can't/won't run, and Intel's on-board-only, thus unavailable.

But I don't know if that rule-of-thumb is going to hold for the integrated-
on-chip sandybridge/fusion generations or not.  But I'm not in the market 
ATM, so I have time to see how all that works out.

> KDE4 sucks, but I'm hooked. And I love it. <sigh>

As has been famously said about democracy, the only thing worse than a 
kde4 desktop is any of the other alternatives...

>> OK, so you're not going to switch to a new distro, fair enough ... What
>> about your hardware? Are you sure it's stable, well configured, ...
>> I've seen people ranting about how unstable Linux is ... the reason was
>> flaky hardware: cheap RAM, wrong HDD cables (specially during the PATA
>> timeframe), ... Check the hardware.
> 
> That's what people are telling me since my OS/2 days... and the hardware
> was always okay (I think). And I believe my hardware is.

> And hardware errors tend to show up when using Gentoo, like when
> compiling gcc fails, that builds itself twice and compares every bit.

Exactly... for the general computer system hardware, at least.

But graphics is a arguably rather different.  However, that's already 
where you say you believe the problem to be...

> Maybe I'll download a VM of another distro with a current KDE and check
> if my bugs happen there, too. And I should more often things try on my
> own machine, but with a different user. I wonder how much cruft might be
> in my configs that could be the source of some trouble.  On the other
> hand, I hate to restart with a clean config, recreating my setup takes a
> while.

Eh, I'm not going to start clean.  I've customized to much for that to be 
a realistic option.

But I /do/ often test things by renaming the entire $KDE_HOME, so I get a 
clean start (well, there's $XDG_CONFIG_HOME and $XDG_DATA_HOME as well, 
but enough of kde's config is in $KDE_HOME that it makes sense to try it 
as the first bisect step), and then complete a recursive bisect test if 
necessary to find a problem.

Alternatively, if it's repeatable with a single app, I'll strace -eopen 
that app, piping STDERR to a $HOME grep, to see just what it's accessing 
in my $HOME, and go from there.

So if it's a big enough problem to trigger a recursive bisect test, I know 
pretty quickly whether it's in my config and generally have it traced to 
an individual file and often line-of-file by the time I'm done.  And by 
doing that with the big stuff, I'd tend to notice the lack of many of the 
smaller bugs when I'm doing it too, if they were user config related.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
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.