2010/2/8 Theo de Raadt :
> For those of you who asked why cp needs to be portable, come on.
> You've got it all wrong. If cp isn't written in a portable fashion,
> then what is the point of doing anything else in a portable fashion.
This is good and reasonable answer. So I think we should stop di
>On Sun, Feb 7, 2010 at 6:11 PM, Theo de Raadt wro=
>te:
>> And in mv, for the cross-device case? =A0I see others that do fast
>> reads, like sum. =A0diff? =A0cmp? =A0grep? =A0How many others? =A0If cp(1=
>)
>> is such a common operation (I bet it isn't), how soon before other
>> programs doing ex
On Sun, Feb 07, 2010 at 04:29:39PM -0800, Philip Guenther wrote:
> On Sat, Feb 6, 2010 at 3:46 PM, Christiano F. Haesbaert
> wrote:
> > Any feedback on this ?
>
> Yep: just committed along with the same thing in dvmrpd. This was
> originally a bug in ospfd, from which both ripd and dvmrpd were
>
On Sun, Feb 7, 2010 at 6:11 PM, Theo de Raadt
wrote:
> And in mv, for the cross-device case? I see others that do fast
> reads, like sum. diff? cmp? grep? How many others? If cp(1)
> is such a common operation (I bet it isn't), how soon before other
> programs doing exactly the same thing wa
On Sat, Feb 6, 2010 at 4:38 AM, Stuart Henderson wrote:
> On 2010/02/05 20:30, Philip Guenther wrote:
>> On Fri, Feb 5, 2010 at 6:14 PM, Ted Unangst wrote:
>> > You are correct, but the patch isn't complete. You should be calling
>> > fclose on the FILE *. Also, the table_write function has sim
On Mon, Feb 8, 2010 at 12:11 AM, Theo de Raadt
wrote:
>>On Sun, Feb 7, 2010 at 2:09 PM, Theo de Raadt
>>wrote:
Why does cp need to be portable? B Who's porting OpenBSD cp to other
>>systems?
>>>
>>> Will the same diff be added to every io generating program in /bin?
>>>
>>> They all generate
On Sat, Feb 6, 2010 at 3:46 PM, Christiano F. Haesbaert
wrote:
> Any feedback on this ?
Yep: just committed along with the same thing in dvmrpd. This was
originally a bug in ospfd, from which both ripd and dvmrpd were
cloned, but it was fixed is the original back in 2006. Maybe we've
got enough
>On Sun, Feb 7, 2010 at 2:09 PM, Theo de Raadt
>wrote:
>>> Why does cp need to be portable? Who's porting OpenBSD cp to other
>systems?
>>
>> Will the same diff be added to every io generating program in /bin?
>>
>> They all generate io, of course.
>
>I was planning on something similar for tar.
On Sun, Feb 7, 2010 at 2:09 PM, Theo de Raadt
wrote:
>> Why does cp need to be portable? Who's porting OpenBSD cp to other
systems?
>
> Will the same diff be added to every io generating program in /bin?
>
> They all generate io, of course.
I was planning on something similar for tar. But that'
Hi
It is supposed to be there, the man page should say "the date, time and window
title".
On Sun, Feb 07, 2010 at 04:53:30PM -0500, Seth Wright wrote:
> On Sun, Feb 7, 2010 at 4:47 PM, Seth Wright wrote:
> > Hello,
> >
> > I noticed with tmux(1) that the default string for the "status-right"
>
On Sun, Feb 7, 2010 at 4:47 PM, Seth Wright wrote:
> Hello,
>
> I noticed with tmux(1) that the default string for the "status-right"
> option produces a right-hand status section that looks like this
> (notice the quotes at the beginning):
>
> "" 11:44 07-Feb-10
>
> I'm thinking that the quoted n
Hello,
I noticed with tmux(1) that the default string for the "status-right"
option produces a right-hand status section that looks like this
(notice the quotes at the beginning):
"" 11:44 07-Feb-10
I'm thinking that the quoted nothingness ("") is not supposed to be
there (at least, the man page
On Sun, Feb 07, 2010 at 12:26:43PM -0800, Philip Guenther wrote:
> (That C++ made me cry. Iterating across a map<> to convert an integer
> in the range 1..56 to a character?!? If only C++ had a datastructure
> which gave O(1) lookup for small indexes, like an array does in C.)
Arrays are legacy
On Sun, 07 Feb 2010 22:03 +0100, "Otto Moerbeek" wrote:
> On Sun, Feb 07, 2010 at 03:43:59PM -0500, Brad Tilley wrote:
>
> > That's OK, my skin is thick. Thanks for the feedback. I had some older fltk
> > code there initially that behaves in a similar fashion (only it has a GUI).
> > It seems s
> (That C++ made me cry. Iterating across a map<> to convert an integer
> in the range 1..56 to a character?!? If only C++ had a datastructure
> which gave O(1) lookup for small indexes, like an array does in C.)
Not to mention that fixed array gets rebuilt upon every function call!
Makes you wi
On Sun, Feb 07, 2010 at 03:43:59PM -0500, Brad Tilley wrote:
> That's OK, my skin is thick. Thanks for the feedback. I had some older fltk
> code there initially that behaves in a similar fashion (only it has a GUI).
> It seems some of you may have seen that for some reason. Caching I guess.
>
On Sun, 07 Feb 2010 21:40 +0100, "Otto Moerbeek" wrote:
> On Sun, Feb 07, 2010 at 03:39:25PM -0500, Brad Tilley wrote:
>
> >
> >
> > On Sun, 07 Feb 2010 21:32 +0100, "Otto Moerbeek" wrote:
> > > On Sun, Feb 07, 2010 at 12:26:43PM -0800, Philip Guenther wrote:
> > >
> > > > On Sunday, February
On Sun, 07 Feb 2010 21:32 +0100, "Otto Moerbeek" wrote:
> On Sun, Feb 07, 2010 at 12:26:43PM -0800, Philip Guenther wrote:
>
> > On Sunday, February 7, 2010, Otto Moerbeek wrote:
> > > That is still wrong for this purpose. Although random(3) is a better
> > > random number generator than rand, i
On Sun, Feb 07, 2010 at 03:39:25PM -0500, Brad Tilley wrote:
>
>
> On Sun, 07 Feb 2010 21:32 +0100, "Otto Moerbeek" wrote:
> > On Sun, Feb 07, 2010 at 12:26:43PM -0800, Philip Guenther wrote:
> >
> > > On Sunday, February 7, 2010, Otto Moerbeek wrote:
> > > > That is still wrong for this purp
On Sun, Feb 07, 2010 at 12:26:43PM -0800, Philip Guenther wrote:
> On Sunday, February 7, 2010, Otto Moerbeek wrote:
> > That is still wrong for this purpose. Although random(3) is a better
> > random number generator than rand, is still a cryptographic weak
> > generator.
> >
> > Better use arc4
On Sunday, February 7, 2010, Otto Moerbeek wrote:
> That is still wrong for this purpose. Although random(3) is a better
> random number generator than rand, is still a cryptographic weak
> generator.
>
> Better use arc4random()
Or rather, since he needs to reduce
the range, use arc4random_unifor
On 7 February 2010 c. 22:57:31 Otto Moerbeek wrote:
> On Sun, Feb 07, 2010 at 08:54:04PM +0100, Otto Moerbeek wrote:
> > On Sun, Feb 07, 2010 at 10:42:40PM +0300, Vadim Zhukov wrote:
> > > On 7 February 2010 c. 21:59:33 Brad Tilley wrote:
> > > > I wrote a small cpp application to generate randomis
The traditional implementation of rand() (including OpenBSD's) cycles very
quickly in the lower bits (try printing a few eg rand() & 0xf). If you do have
to use it for anything, try to use the high bits, although as others have said
you should avoid using it at all particularly for passwords.
On
On Sun, Feb 07, 2010 at 08:54:04PM +0100, Otto Moerbeek wrote:
> On Sun, Feb 07, 2010 at 10:42:40PM +0300, Vadim Zhukov wrote:
>
> > On 7 February 2010 c. 21:59:33 Brad Tilley wrote:
> > > I wrote a small cpp application to generate randomish passwords. It
> > > compiles and runs OK on OpenBSD, h
On Sun, Feb 07, 2010 at 10:42:40PM +0300, Vadim Zhukov wrote:
> On 7 February 2010 c. 21:59:33 Brad Tilley wrote:
> > I wrote a small cpp application to generate randomish passwords. It
> > compiles and runs OK on OpenBSD, however, it does not seem to create
> > random strings (the first and last
On 7 February 2010 c. 21:59:33 Brad Tilley wrote:
> I wrote a small cpp application to generate randomish passwords. It
> compiles and runs OK on OpenBSD, however, it does not seem to create
> random strings (the first and last chars seldom ever change, etc). The
> same code compiles and runs on Li
On Sun, Feb 07, 2010 at 08:24:49PM +0100, Otto Moerbeek wrote:
> On Sun, Feb 07, 2010 at 01:59:33PM -0500, Brad Tilley wrote:
>
> > I wrote a small cpp application to generate randomish passwords. It
> > compiles and runs OK on OpenBSD, however, it does not seem to create random
> > strings (the
On Sun, Feb 07, 2010 at 01:59:33PM -0500, Brad Tilley wrote:
> I wrote a small cpp application to generate randomish passwords. It compiles
> and runs OK on OpenBSD, however, it does not seem to create random strings
> (the first and last chars seldom ever change, etc). The same code compiles
>
On Sun, Feb 07, 2010 at 01:59:33PM -0500, Brad Tilley wrote:
> I wrote a small cpp application to generate randomish passwords. It compiles
> and runs OK on OpenBSD, however, it does not seem to create random strings
> (the first and last chars seldom ever change, etc). The same code compiles
>
> Why does cp need to be portable? Who's porting OpenBSD cp to other systems?
Will the same diff be added to every io generating program in /bin?
They all generate io, of course.
I wrote a small cpp application to generate randomish passwords. It compiles
and runs OK on OpenBSD, however, it does not seem to create random strings (the
first and last chars seldom ever change, etc). The same code compiles and runs
on Linux and Windows and *does* produce randomish strings (n
2010/2/7 Ted Unangst :
>> But using sysctl is insane. That is not portable.
> Why does cp need to be portable? Who's porting OpenBSD cp to other
systems?
Good question.
--
antonvm
32 matches
Mail list logo
