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.
