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.
