[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Journalling
From:       "Yannai A. Gonczarowski" <yannaigo () leyada ! jlm ! k12 ! il>
Date:       1999-02-20 13:58:00
[Download RAW message or body]

Maybe there could be 3 options:
1. Off.
2. On, and remember from KDE session to the next.
3. On, only in memory - never written to the disk, allowing to remember the
last docs used in this session.

I think that whoever is concerened wish people poking around in his files
could still use 3.


Rik Hemsley wrote:
> 
> Paul Campbell wrote:
> 
> > sounds like a nice idea - but please make sure it can be turned OFF
> > (maybe even is off by default) - for privacy reasons I think that
> > anything that keeps a log of what someone's doing and what they've
> > been looking at (remember our commitment to network transparency)
> > is a bad thing .....
> 
> Of course..
> This was a proposition - the proof of concept is done as it's working on my
> box ATM - but I wouldn't have suggested this is the Right Thing just yet.
> 
> I'll have a look at creating a matching KControl thing for it, and either
> disable / remove the icon from KFileDialog depending on the user's settings.
> 
> And yes, I agree it should be off to begin with.
> It is impossible for another user to 'spy' on the journal, unless they are
> suid to the user, as the IPC msg queue and the journal are mode 0600, but I
> still agree. I don't like my boss asking me to look at people's
> .bash_history or mail, and I won't. I think it's immoral (and probably
> illegal). The furthest I've gone is looking at the mail queue to determine
> that yes, a certain pleb was spending their entire day mailing their friend
> rather than working, and I didn't feel right about that either.
> 
> Richard Moore wrote:
> > > Next to this list is the time the document was accessed.
> > Nice - could you make it so can sort by time too?
> 
> Yes.. that was the first thing I did :)
> 
> > Could it be implemented by extending the file dialog instead? This might
> > allow us to avoid the overhead of another process being needed.
> 
> I had thought of that. The way it works at the moment (with IPC) allows me
> to queue up the messages without thinking about it. Working it with some
> code in the file dialog to write directly to the journal is possible, but
> brings in file locking.
> 
> The kjournald process actually uses virtually zero resources. It checks the
> IPC queue every 5 seconds, and does nothing if there's nothing there. It's
> also tiny - it's only about a screenful of code.
> 
> There is a more important problem with it, in that it needs to be kept
> working - start up when KDE starts, quit when KDE quits. I've worked it so
> that it is started from the startkde script and when it starts, it sends out
> a quit signal, which any already-running daemon picks up, and dies. If the
> daemon picks up its own quit signal, it ignores it.
> 
> When KDE quits, kwm can send it a quit signal, though it will die anyway
> thanks to the method described above.
> 
> Enuff rambling. Tomorrow (today), I'll make up some kind of patch for 1.1
> sources, and post it here.
> 
> Cheers,
> Rik

-- 


Regards,
Yannai.

----------------------------------------------------------------------
Yannai A. Gonczarowski        _____..---======~~~~~=======---.._____
 ______________________ __,-='=====____  ================ _____=====`=
(._____________________I__) - _-=_/    `--------=+=-------'
    /      /__...---===='---+---_'                System Administrator
   '------'---.___ -  _ =   _.-'            yannaigo@leyada.jlm.k12.il
                  `--------'         The Hebrew University High School
"Si vis pacem, para bellum"    http://www.leyada.jlm.k12.il/~yannaigo/
----------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]