plasma-desktop (KDE factory) acting up?

[Duncan]

Alex Schuster posted on Wed, 01 Dec 2010 01:50:32 +0100 as excerpted:

> Duncan writes:

OK, this is obviously a long-delayed reply, but I still had this post 
marked to followup on when I got the correctly rounded tuit, so here 
goes.  Obviously I'm deleting a lot of it as now rather dated, but there's 
still some nuggets to reply to...

>> FWIW, to keep control a bit tighter on access to /var/log/messages,
>> when I setup yasp-scripted to tail it, I setup a script that does a
>> tail -100 on it, to be run as root.  Then I configured sudo to allow my
>> user to run that script (passwordless) with no parameters, which should
>> be a /reasonable/ permission lockdown, I think/hope (at least given
>> that I'm specifically allowing the user to view the last 100 lines of
>> /var/log/ messages).  Then the yasp-scripted command can invoke that
>> command thru sudo, piping the output thru tail again to cut it down to
>> the specific number of lines I have space for, thru cut to cut down the
>> columns to the specific number I have space for... and then posting the
>> result in yasp- scripted.
> 
> Why only the last 100 lines? Security? But if the user can read the last
> 100 lines, he can >> them into his log file, and he gets everything. But
> maybe I'm getting this wrong.

While it's for security reasons I limit it, it's not because I'm worried 
about the log being available to be viewed by that user, for the obvious 
reasons you mentioned.  Rather, it has to do with nailing down the precise 
command I allow the user to sudo run as root, only the specific command 
(specified by absolute path so the user can't change it that way) with the 
specific parameters I want, and because tail -f wouldn't work here, so I 
had to choose some arbitrary value and 100 lines seemed more than I'd ever 
be likely to display at once, so that was it.

If you've worked with sudo at all, you probably know that the 
documentation takes some pains to warn about allowing not-fully-specified 
command-lines (including supplied parameters, etc), since a user could 
conceivably use that to abuse the command to some unanticipated end.  It 
was actually that security issue that I had in mind, especially since I 
was allowing this command to be run passwordless, and the 100 lines was 
simply a convenient value arbitrarily chosen to be more than I'd be likely 
to ever actually display in the plasmoid that was the whole purpose for 
this, while still being low enough that it'd be unlikely to create any 
sort of memory or performuse tab-completion at the CLI or the directory 
browse feature in ance issues, etc.

> I have the group set to wheel for the logs I want to be read by trusted
> users.

Well, that's sort of the point as well.  I don't consider my normal user 
login to be entirely trusted, as that's what I run as most of the time, 
including browsing the web, etc, so it'd be the most likely permissions 
used by any inadvertently executed malware, etc.  I have an admin login 
that gets full passwordless sudo rights, and one of the few sudo comands 
allowed to my ordinary user login is a password-ed sudo login to that 
user.  Other than that, my regular user login is pretty restricted, for 
the simple reason that it /is/ my regular user login.

Given the above viewpoint, I did have to consider whether lowering system 
security enough to allow my ordinary user syslog reading rights was wise, 
but decided that the benefits I gained from having the syslog more or less 
constantly visible, so I could see what was happening, outweighed the 
security negatives of exposing the log to be read, in 100-line chunks, as 
that only semi-trusted ordinary user.

FWIW, if you've not seen anything about it yet, reading up on QubesOS is 
something you might be interested in.  The idea is to partition the system 
off into a number of virtual machines with access between them carefully 
controlled.  Unfortunately, my main system is old enough that it doesn't 
have the hardware virtualization helpers that the newer CPUs normally 
have, so while I had actually thought about this sort of approach, it's 
not particularly viable for me at this point.  However, the idea is 
definitely on my list for further investigation once I upgrade to hardware 
virtualization supporting hardware.

Here's a review of the current QubesOS beta, with a diagram demonstrating 
how Joanna Rutkowska, the founder, partitions up her computer into various 
VMs.  (There's a piece of the diagram at the top, but the whole diagram is 
thumbnailed with a link to the full-size version, later.)  That's the sort 
of thing I have in mind, except probably a bit simplified as I don't have 
the work or security worries she does.  (Imagine the reputation a blackhat 
would have after cracking THAT!)

http://www.flaviostechnotalk.com/2011/05/01/is-there-a-blue-pill-for-qubes-
os/

(Watch the link-wrap.)

>> mpd (using qmpdclient when I'm in kde) for music here, as I didn't like
>> where amarok headed with kde4, and wanted the ability to have the music
>> continue uninterrupted regardless of whether I was in X/KDE or not.  I
>> do miss amarok-for-kde3's visualizations, but not enough to want to
>> deal with amarok's extremely heavy dependencies again (especially now
>> that akonadi works well with sqlite and I've thus been able to remove
>> mysql again), plus amarok for kde4 had done away with visualizations
>> when I left it, while adding all sorts of stupid features I didn't
>> really use or want, so it was simply not a good fit for me any more. 
>> Not that it really /ever/ was, given the dependencies in kde3, as well,
>> even if I tolerated them for the visualizations, etc, at that point.
> 
> I sort of like Amarok. It has its bugs, but I see progress, and find it
> very convenient. When Amarok took minutes to start, I tried Clementine,
> which has the look & Feel of Amarok 1.x, but soon I was missing many
> little things. Amarok is geat :)

I appreciate being mysql-free again, after akonadi-server switched to the 
sqlite backend for its default.  That's just one of amarok's way-too-heavy-
for-my-requirements dependencies I don't need installed now.  AFAIK, it 
still uses ruby as well, and I don't have that installed either.

I looked at clementine, but it has some circular dependencies I'd have to 
resolve to merge it.  Portage hints at the USE flags I'd have to change 
temporarily to do it, but it's definitely more of a hassle than it's worth 
to me, so...

I do miss amarok-for-kde3 visualizations, but if I ever get around to 
figuring it out, mpd has some visualizations available (obviously I don't 
know how good since I've yet to configure them), with output from mpd to 
the visualizer over a fifo.  And I **REALLY** like the mpd's daemon idea, 
with multiple front-ends available for CLI and curses outside X, kde/gnome/
qt/gtk and possibly more in X, and even a web-based-front-end available 
for remote control if desired.  Having the daemon start with the system 
services at boot, regardless of whether I bother running a front-end for 
it or not, is neat, and I now have a player available regardless of 
whether I'm in X or not.  Aside from the extremely heavy dependencies, 
that's another thing I disliked about amarok -- it was only available if I 
had X running.  (Of course there are many other ncurses and CLI based 
music players as well, but one reason I like mpd is because of the 
flexibility and native interfaces afforded by all those available front-
ends.)

>> And for file management I divide my tasks into sysadmin type tasks
>> (even as a user, config file editing, moving files in general around,
>> etc), where I use the ncurses based mc in either a text VT or a konsole
>> window, doesn't matter, and user type tasks (almost entirely media file
>> handling), for which I tend to use gwenview.  So while dolphin's on my
>> system and it does popup by default when I click on a dir in a
>> folderview or the like, I don't really tend to use it that much, except
>> very transitorily to access some function not particularly convenient
>> directly from a folderview or quickaccess plasmoid.
> 
> I also don't use dolphin _much_. But it's convenient to browse through
> my MPEG collection, and to sort my music. I can drag files or folders
> into Amarok, which won't work with mc. I can delete quickly with the
> 'Del' key, and have the files still in my Trash [*].
> For images I'm using Gwenview or Dolphin.

I really wish gwenview would handle sound files as well as it does images 
and can handle video, if so configured...  And that it could be configured 
to show all files, not just media files.  If so, I'd likely configure it 
as my default file manager and thus seldom use dolphin at all.

> Then this night I tried Digikam, and investigated this semantic desktop
> stuff. I don't use that much yet, but I think it's the way to go. locate
> is nice, but only when I know the file name. Sorting files is also good
> style, I do this, but this doesn't work too well. Which
> categories /folders should I choose? I easily find a specific cartoon in
> pix/fun /cartoons/<author>. But often multiple categories apply, and
> which one should I choose?

That's what links (either symlinks or hardlinks, depending on your need) 
are for. =:^)

I don't have much use for the semantic desktop, at least as I've seen it 
so far.  I've found it more buggy than useful, and thus, disabled it (tho 
I still have the USE flags on for it).  Saves me a WHOLE lot of headaches 
with the bugs, and... I've simply come to the conclusion that all this 
fancy semantic desktop stuff is for people who don't understand how to 
organize their stuff properly via directory, including usage of symlinks
or multiple-hardlink-files where appropriate.  (I remember when I first 
switched from MS and discovered symlinks.  They remain one of my favorite 
features not found on MS, or at least, not found by the time I switched, 
maybe they've added them since.  Of course, my /real/ favorite feature is 
simply freedomware!  I don't see MS matching Linux on that one any time 
soon!)

FWIW, I don't have a *locate installed on my system for much the same 
reason.  It's far more hassle than it's worth to me, especially since my 
schedule isn't set enough for me to be able to reliably set a time for the 
index updating that won't disturb other stuff I might be trying to do at 
that time, and as you said, it's limited to filenames in any case.

If I need a file, most of the time I can point right to it, with only a 
bit of help from tab completion at the CLI or the browse-directories 
feature of open dialogs, etc.   If I DO need to search for a file, I know 
enough about where I've stored stuff to confine the real-time search 
sufficiently that doing it in real-time instead of hassling with some 
database intensive indexing tool is the vastly better trade-off.

OTOH, there's the horror stories of the folks with thousands of items 
directly in the default download dir of whatever tool they use, hundreds 
of items on their desktop, etc, and who will download something and then 
have to go back and download it again because they can't figure out where 
it downloaded to, because they simply fail to comprehend the value and 
method of organizing things by filesystem directory.  It's for /these/ 
folks that I expect the semantic desktop has the most value.

> [*] Doesn't KDE4's Trash suck?

Actually, it seems to work very well for me, as it obeys my configuring it 
to go away and not bother me! =:^)

Seriously.  Perhaps it's because I started with computers back on DOS and 
MS Windows 3.1, before 
delete-that-doesn't-actually-delete-the-file-and-free-the-space
became popular, but I've simply never had a whole lot of use for keeping 
trash around.

I remember back on MS WormOS 95, when the recycle bin first appeared, I 
hated the full trash icon and would always impulsively empty the trash as 
soon as something appeared there.  I quickly got in the habit of doing 
shift-delete, thus bypassing the trash. (I DID and still do keep the 
confirmation dialog around; that's enough protection for me.  I keep it 
around for send-to-trash too; if I do that by accident, I can cancel and 
delete properly, as I obviously intended.)

So I've taken advantage of KDE's keyboard shortcut customization features 
to have configured both dolphin and konqueror to remap real delete to the 
delete key, and fake delete (delete using shortcut for trash) to none, 
instead of shift-delete and delete, respectively.  As I said, I keep the 
real-delete warning dialog, but that's it, as it's quite sufficient.  And 
I keep the fake delete warning dialog precisely so if I ever do it by 
accident, I can cancel and do a real delete.  I did leave shift-delete 
mapped to delete in gwenview, tho, because I seldom enough actually delete 
there that I'm more likely to hit the delete button by itself by accident, 
and the added shift- , plus the confirmation dialog, protects me from that.

In both konqueror and dolphin I also have the trash set as small as it'll 
let me (0.001%), as well.  I have it set to warn if it gets bigger than 
that, not delete automatically, and don't have the auto-delete-after-N-
days checked either, because most likely, if something's there it's there 
entirely by accident, and I want to know about it.

Of course I don't have any trash plasmoids anywhere on my activities or 
panels either.  I remember hacking the MS WormOS 95 registry to remove the 
desktop icons and set the name to a single space, as well.

So yes, KDE's trash works very well for me, since it so nicely configures 
to get out of the way and not bother me any more! =:^)

> I'm curious how all this will evolve.
> 
> BTW, is there _any_ documentation on how to use this? I know some people
> who don't have a clue what this is for. The plasma handbook has half a
> page about activities, but real life examples would be nice.
> Well, not for me, I think I know what this is about, but I read some
> articles in blogs and am not a new user.

There's some, on kde userbase and the like, as well as blog posts and 
various presentations by the plasma devs, but really, activities have yet 
to come into their own and there's little practical use for them yet.  
Back in November/December when this thread was active, we were on kde 4.5, 
which was really quite limited in terms of real uses for activities, but 
there's just a hint of them in 4.6, with the ability to assign windows to 
specific activities (as well as the more traditional virtual desktops) via 
the windows menu now.  But that's little more than a crippled hint of 
what's coming as well.

Since at least 4.4, the forecast has been that activities wouldn't really 
mature until 4.7 or so.  That's still the case.  I'm certainly curious to 
see how it'll evolve as well, but knowing what they have in mind and what 
the potential is, playing with these crippled hints is a nice exercise in 
frustration.

While we're on the subject, 4.7's likely to be interesting for a number of 
reasons.  I've long stated that 4.2 and earlier were rather raw alphas, 
4.3 was but a beta, 4.4 finally reached reasonable functionality but still 
lacked polish and had enough bugs to make it reasonable for an rc, and 
only with 4.5 (and the later 4.5s at that, due to graphics bugs for many 
early on) did kde4 finally reach proper release quality -- what SHOULD 
have been 4.0.  But 4.5 did come and with it a properly functional 
release, now widely respected for its reasonable quality even if the 
journey had bumps the size of 100 meter cliffs!

It's in that context that we now have 4.6.  In a lot of ways 4.6 has 
almost been like a new development release.  It's the first to dump hal 
and use the replacement u* family.  The kde project is in the middle of 
switching from svn to git and that hasn't gone as smoothly as it might 
have, resulting in some regressions from 4.6.0 in what should have been 
bug-fix-only updates so should have been safe.  There's not a lot of real 
new functionality or features, tho as mentioned above, there's hints of 
future functionality.  So it's sort of a pause; a time to regroup, 
consolidating the current features and setting up kde4 for further 
developments in the future.

By 4.7 (even the feature-freeze for 4.7) one hopes the git transition will 
be pretty much done, and along with it will come a much more accessible 
source setup that's much easier for advanced users to participate in bug 
reporting and bisecting with, among other things.  I know I'm FAR more 
active and effective in my kernel testing than I was pre-git or could be 
today without it, and am looking forward to the same sort of thing for kde. 
(In fact, I've already done my first kde bug bisection down to the 
specific commit, based on the new git repos, while tracing a bug that 
appeared in 4.6.2 while 4.6.1 worked fine, so that's already at least one 
bit of fruit from the upgrade to git!)  In theory, that'll open kde to 
even faster development and more effective bug extermination, just as it 
has for the kernel, as the community participation rises dramatically, 
again, just as it has for the kernel.  But that's a development that'll 
happen over time... I'd guess we'll really begin to see what effects git 
has wrought by 4.9 or so, a year after 4.7, assuming the six-month-minor 
cycle continues.

But 4.7 is likely to bring the new kdepim, with kmail2, and get kdepim out 
of the bug-fix-only cycle it has been in since 4.4.  That's a heavily 
anticipated development tho it has its risks (but it /does/ seem that the 
kdepim guys learned from the kde4 mistakes and if anything, are being 
overly cautious about the upgrade this time =;^).

4.7 has likewise been long predicted to be when activities will finally 
begin to be useful as envisioned, altho there will be further development 
beyond that, obviously.  Again, that's been heavily anticipated.

4.7 was some time ago named the release at which all the printing 
improvements and bug fixing should finally come together.  I don't 
personally have a printer, but I *KNOW* that's heavily anticipated by many 
who use them regularly and are currently rather frustrated at kde's 
printing abilities.

>From what I've read, 4.7 should bring with it a marble with many new 
features.  There has been a mid-series marble release with some of them, 
but being mid-series, many distributions are unlikely to pick it up, and 
as it remained dependent on 4.6, I believe certain features had to wait or 
will be further improved for 4.7, since the kde libraries it depends on 
will then be upgraded as well.

Plus, with what seemed the pause for 4.6, there's likely to be some 
additional nice juicy features to play with too, hopefully without 
regressing /too/ much, and with the later 4.7 bugfix releases actually 
working better in that regard than the 4.6 bugfix releases have seemed to 
do.

[Gentoo specific]

>> Meanwhile, I've been rather unhappy about how the preserved-libs stuff
>> is going.  I'd rather let revdep-rebuild handle it in most cases, as
>> having packages own files they don't create upon rebuild can be
>> problematic, and there's various other issues. [...]

> Hmmm. I thought the big benefit of preserved-rebuild is that when a
> library is upgraded from version A to B, B ist installed, but A is kept,
> so all stuff that links to A still works. That is what I thought to be
> the biggest problem with Gentoo, that an upgrade of an important library
> (like libexpat) breaks much stuff, until this stuff is rebuilt. What if
> I need this stuff before it is recompiled? Now, this no longer happens.
> And doesn't emerge @preserved-rebuild delete A after it is no longer
> needed?

You are correct about the theory.  But in practice, at least as I use 
gentoo and portage, preserved-libs seems to "fix what wasn't broken" as 
they say, naturally breaking some of that which wasn't broken in the 
process.

The problem seems to be that that most people apparently didn't run revdep-
rebuild after every update, as I've long done and has to the best of my 
recollection been gentoo best-practice since before I switched to gentoo 
in 2004.

Compound that with the fact that formerly, far more than necessary was 
being rebuilt by default, because libraries were being linked in as 
dependencies that weren't actually even used (at least not directly), 
which the recent switch to --as-needed in the gentoo-default LDFLAGS fixes 
but which I've been using in my LDFLAGS for years.

Compound /that/ with the mess that *.la files creates, unnecessarily for 
the most part, on a standard dynamically linked system.   Often times 
they'd force a rebuild when an appropriate tweak to the text in the *.la 
file was all that was needed.  But that too is being cured, short term by 
the fixlafiles script and now the portage feature, longer term by the slow 
deletion of all these unnecessary but troublesome *.la files.  (That's 
what the USE=static-libs flag that's gradually being added to stuff is 
partially about.)  And again, altho it's a rather more recent development, 
I've been ahead of the pack, as I took the big step of INSTALL_MASKing 
(actually, PKG_INSTALL_MASKing, since I use FEATURES=buildpkg and didn't 
want them there either) *.la files entirely, with a single exception in /
etc/portage/env/sys-devel/libtool, unsetting the variable for that 
package, since it installs a *.la file that's actually needed, at least 
until configure scripts learn to live without it.

So at the same time, revdep-rebuild both forces far less rebuilds here 
than it does for people without --as-needed in LDFLAGS and with all the 
usual *.la files, **INCLUDING** reducing messes like expat by 3/4 or more 
in most cases, AND I run both it and emerge --depclean consistently after 
every update, thus keeping my system far more cruft and problem free.

The result is that even widely depended updates like expat cause **FAR** 
less breakage and revdep-rebuilds here than they do, or did until recently 
at least, for most users, meaning that the need for
FEATURES=preserved-libs is far lower than it is for most.

At the same time, because I DO run revdep-rebuild so faithfully after 
every update, packages broken by library updates get rebuilt properly, 
instead of staying broken until someone tries to actually use them at a 
critical time like during a presentation from their laptop.

Since the rebuilds are done right away, keeping the old libraries on the 
system only interferes with things, because it breaks revdep-rebuild's 
normal scan for broken library linkages because they aren't broken yet, 
requiring a MANUAL revdep-rebuild scan for that specific library.  That's 
a MAJOR pain in the rear because I often have to run revdep-rebuild 
MULTIPLE times, once per library I've picked out of the messages saying I 
need to do it, in ADDITION to the normal catch-all run, when if the 
libraries weren't kept around in the first place, the catch-all run would 
detect and fix the problem automatically.

In addition, if the upgrade was due to a security issue, guess what, I now 
have security-vulnerable libs still on the system with other packages not 
detected by a revdep-rebuild run because they ARE still on the system 
USING them, even when I've updated the package and by all rights SHOULD 
now be safe!

Now, there's certainly a time and a place for keeping critical libraries 
around.  But that time and place is when they're just that, critical to 
the toolchain, so the rebuild itself isn't broken, or to core system 
applications used to boot to the CLI, so a system is working well enough 
to complete the rebuilds.

Those libraries are few and far between.  The glibc package would contain 
most of them, save for the fact that it's so critical for /everything/ 
that upgrades of it have taken its critical nature into account since 
before the turn of the century, so there's nothing there that needs this 
new feature, either.  There is one package used by newer gcc versions now, 
tho, I forgot its name.   Still, none of the big problem libs like expat 
have been in this category -- booting to CLI and the package toolchain 
work fine with them broken, so revdep-rebuild itself works just fine, and 
that's what matters.  As long as that works, the rest can be rebuilt as 
necessary.

But meanwhile, that was back in November.  Back then, I was getting log 
messages for such deliberately retained libraries DESPITE my FEATURES=-
preserve-libs setting fairly frequently, often for several libraries in a 
single update, thus, as mentioned, requiring several separate manual 
revdep-rebuild runs.

Either the number of such libs with updates suddenly dropped off a cliff, 
or more likely, it was Gentoo developers playing with the new feature and 
learning how to use it properly, and now that they've done so, they've 
realized all these "critical" libs aren't so critical after all, and after 
some complaints and possibly some hassles of their own with it, they've 
returned their processing to normal so portage with
FEATURES=-preserve-libs removes them as it should and revdep-rebuild then 
catches the dependencies and rebuilds them as it should.

Whatever happened, it's working better now than it did, and I've not had 
one of those log notices unnecessarily for quite some time, perhaps since 
the turn of the year even.  But it sure was annoying while it was going on!

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