Re: Dotfiles
Y'all are really taking all of the fun out of this.
Here's the point - this is an exercise. There is no good reason to do
this. What, you've got a 10 meg disk that is at 95%? Well, if you pay
shipping, I've got a extra 40 meg that I use as a book end that I'll
send you.
Keep the files or delete them, but you've got no good reason for
worrying about them - do you clear your browser's history (cache, etc)
because the store has too many files?
This is fun, and that's it.
On Tue, Jul 2, 2013 at 6:37 PM, Joel Rees <joel.rees@gmail.com> wrote:
> On Wed, Jul 3, 2013 at 6:28 AM, shawn wilson <ag4ve.us@gmail.com> wrote:
>>
>> On Tue, Jul 2, 2013 at 5:14 PM, Lisi Reisz <lisi.reisz@gmail.com> wrote:
>> > On Tuesday 02 July 2013 22:06:17 Yaro Yaro wrote:
>> >> On Jul 2, 2013 3:49 PM, "Hendrik Boom" <hendrik@topoi.pooq.com> wrote:
>> >> > There are lots of .dotfiles cluttering my home directory.
>> >> >
>> >> > No doubt some of them are useful.
>> >> >
>> >> > Many, though, are probably remnants of packages of years past --
>> >> > packages
>> >> > I installed long ago, no longer need, and have removed.
>> >> >
>> >> > Is there any way of identifying which packages are using which
>> >> > dotfiles?
>> >> >
>
> You're thinking too hard. How about
No, see above - he asked how to find which packages are using files.
Not files he's currently using. Even my reply that showed that it
would be better to do this with git missed the point.
>
> ls -lartd .*
>
Yeah, not the answer to the question.
>
>>
>> Use a tool that shows what files are being accessed (like fuser, but
>> you'll probably have better luck with strace or gdb) and use some
>> expect like language (or IPC) to fire up the command (either through
>> strace or gdb or quickly attach gdb to it) and see what files it looks
>> for.
>>
>> Easiest would probably be to: find / type f -perm +111 | while read f;
>> do dotfile-scraper $f; done
>>
>> I think the easiest is 'strace -f -s 1024 -e trace=stat64,read' and
>> run until the volume of output decreases and then just kill the
>> program (probably as a test user so you don't corrupt your own stuff).
>>
>> I don't think this is the answer you were looking and doubt you'll
>> pursue this but, as I said, if you do I'd like to see the script /
>> what you find.
>
>
> I think you're just looking for an excuse to use the low-level stuff. ;-)
>
Well, like I said, this would be a fun project and after all, there's
no good reason so we're all just masturbating here anyway.
>
> The "real" solution kind of points to something we need to do -- sandboxing
> all apps, making them tell the system who they are when they want to drop
> persistent store, maintaining a database of legitimate apps and their
> persistent store.
>
I don't like lots of apps being sandboxed - your shell for instance
has .profile, .bashrc, .bash_history, and others (I use zsh so I
forgot). You could sandbox each user into their own chroot and each
app into their own chroot but then when I go to open my .bashrc with
vim, I need to figure out where the per session root is for my shell
and cross polinating history (ctrl+r in bash i think?) doesn't work.
It's a stretch on what you're proposing, but all in all, I hate the
Apple approach to this (I don't remember who, but I remember reading
about someone needing to jump through hoops and build their own glx or
something for acceleration to work with this model). Cellular phones
being another example of your proposal (and I *hate* working with all
of those systems too - Nokia might've been onto something but they had
gaping security so lets leave them out of this, shall we?).
There is tripwire, ftimes, some internal kernel stuff (don't remember
what it is called in >3.4 iirc) to look at a hash table before running
programs. There are also SELinux hooks for most things you could want
to regulate (which, if developers made SELinux policies for each of
their apps, this might work great but they'd suck at it, so lets not
try to champion that).
If you want to look at this outside of the kernel, strace is what you
use (but it's slow - I think even BSD's version is a bit less than
native as well).
I agree that it would be nice to have finer grained control on what
applications do (especially from a non-uid0 login). I don't think that
your proposal is the right answer.
Reply to: