On 2004-06-07 01:30 -0700, David Schultz <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 06, 2004, Stefan Eer wrote:
> > Any reason, that there is a difference in semantics between:
> >
> > seteuid(id) vs. setreuid(-1, id)???
> >
> > The tests performed on the arguments are different
Any reason, that there is a difference in semantics between:
seteuid(id) vs. setreuid(-1, id)???
The tests performed on the arguments are different (assuming a
fixed arg of -1 for ruid) in that seteuid does not support the
case of (euid == cr_uid):
seteuid(euid):
On 2004-01-09 11:38 -0600, Sean Farley <[EMAIL PROTECTED]> wrote:
> I admit to having not tried it, but I wonder how well OpenCM
> (http://www.opencm.org/) would compare. I think it would have a smaller
> footprint than Subversion.
I have prepared a port of OpenCM, but didn't have time to test it
On 2003-11-24 12:20 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> Stefan Eßer <[EMAIL PROTECTED]> writes:
> > Ok. I've also thought some about this, and I think that different media
> > might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs.
On 2003-11-23 10:11 -0800, Wes Peters <[EMAIL PROTECTED]> wrote:
> > Encrypting data and secure removal of data are orthogonal and in case
> > you need one, the other propbably won't be a good choice.
>
> Both are completely adequate to protect the data on the disk from
> disclosure.
Yes, if eff
On 2003-11-23 18:04 +0100, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> 1. Look for BIO_DELETE in the kernel.
Seems that BIO_DELETE isn't really supported anymore
(according to a comment in your GEOM sources ;-)
AFAICT, BIO_DELETE can't easily be made a long running
operation (taking tens of
On 2003-11-23 17:31 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> Stefan Eßer <[EMAIL PROTECTED]> writes:
> > What I'm suggesting is to have the obliteration implemented as an
> > add on to the dirty buffer flush, with the difference that the
> > bu
On 2003-11-23 00:19 -0800, Wes Peters <[EMAIL PROTECTED]> wrote:
> On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote:
> > On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> > > Stefan Eßer <[EMAIL PROTECTED]> writes:
> >
On 2003-11-23 00:16 -0800, Wes Peters <[EMAIL PROTECTED]> wrote:
> On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote:
> > A simple algorithm could just mark each buffer with a special
> > kind of dirty flag and a counter for the pass number (in fact,
> > the existi
On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> Stefan Eßer <[EMAIL PROTECTED]> writes:
> > I may be way off, but I do not think, that a special thread or
> > a cache flush after each block is required: [...]
>
> What happens if you
On 2003-11-21 14:09 -0800, Wes Peters <[EMAIL PROTECTED]> wrote:
> As for performance, you really need to flush the on-device cache on each
> pass to make sure the bit patterns get written to the platter in proper
> order. I don't see any clever way to coalesce the writing of the
> various patt
On 2003-10-12 16:50 +0100, Colin Percival <[EMAIL PROTECTED]> wrote:
> Or rather, lack thereof. I was rather astonished to find that `md5
> /nonexistant` printed an error message but still returned an exit code of
> zero; this is, of course, due to the use of warn() instead of err() in
> resp
There are Linux drivers available for download and it seems,
that the 440x and 520x drivers are very similar. I intended
to make the bge driver support the 440x in my ASUS A7K8X, but
have not had time to actually start that project (beyond the
initial diff of the two official drivers.)
If anybody
13 matches
Mail list logo
