Re: Dotfiles

Heh. Thanks for filling in the gaps.

(Although, I would point out that every killer app today started as somebody's fun project yesterday, so there's no reason to discourage them. Bits of what we've seen of the road ahead, yeah, let them make up their minds about which way they go.)

On Wed, Jul 3, 2013 at 8:02 AM, shawn wilson <ag4ve.us@gmail.com> wrote:

Y'all are really taking all of the fun out of this.

Or, rather:

Don't forget to keep it fun, guys!

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.

For someone's definition of fun, and that's fine by me.

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.

yeah.

But I still think that

>
> ls -lartd .*

gets Hendrik closer to a clean ~/ quicker than actually trying to solve the problems he posed.

Yeah, not the answer to the question.

Sometimes there are questions hidden in questions.

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

Ah! thank you.

That may convince me that installing the debug symbols on the kernel isn't what I wanted to do. (Debian, anyway, doesn't keep putting abrtd in my face, as opposed to the distro on my netbook that I am trying to talk myself into replacing with Debian.)

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

(Well, if you're going to bring that up, shoot, at least half of what any of us does every day could easily be put under that rubric. But I think we should choose our own metaphors.)

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

There is no right answer. A computer is a fancy pen and a huge fancy notebook to write in. And the pen can do indexing and various other calculations for us. That leaves a lot of room for lots of right answers (lots of them) that are right for one situation, not so right for others.

Hope you didn't mind me filling the gaps in a bit more.

--
Joel Rees