base64 encoded Mime section invalid - length (0) was wrong.
Oh my. I'll be going over this in a few days.
On Mon, Feb 08, 2010 at 07:13:36PM +0300, Mike Belopuhov wrote:
> Good day,
>
> the following diff...
>
> - implements bioctl support;
> - fixes hot-un-plugging w/ softeps;
> - improves performance;
> - fixes IPL levels;
> - fixes lots of small thin
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
Para visualizar este correo en el explorador, clic aqum
Este correo ha sido enviado a tech@openbsd.org | Remover suscripcisn
[IMAGE]
Episjeuhe_te tgm die}humsg http://www.e-shop.gr/newsletter/mail-100211.html
cia ma de_te tir pqosvoq]r lar
TGKEVYMIJES PAQACCEKIES 9:00-20:00 STO 211
5000500
Oi til]r isw}oum ap| 06/02/10 l]wqi 20/02/10, ]yr enamtk^seyr tym
apohel\tym jai l|mo cia ta l]kg tou e-shop.gr
Am h]kete ma diacqave_t
2010/2/8 Vadim Zhukov :
> Looks like I was just lucky. :) I do not use malloc.conf. And mktemp(1)
> failed for me only sometimes (I'm using it for generating
> passwords: "mktemp XX"). After a few crashes I realized that it
> hurts me too much... Do not remember what snapshot it was, though
On 8 February 2010 c. 23:50:53 Philip Guenther wrote:
> 2010/2/8 Vadim Zhukov :
> > Thank you for your attention. And sorry, but I think that your
> > version is wrong: in case of only one "X" you'll have "tries" set to
> > 1 instead of NUM_CHARS.
>
>
>
> Time to write some regress tests for mktem
2010/2/8 Vadim Zhukov :
> Thank you for your attention. And sorry, but I think that your version is
> wrong: in case of only one "X" you'll have "tries" set to 1 instead of
> NUM_CHARS.
Time to write some regress tests for mktemp obviously. Do you happen
to have a program reliably demonstrates
On 8 February 2010 c. 21:00:53 Philip Guenther wrote:
> 2010/1/27 Vadim Zhukov :
> > Current implementation of mktemp_internal() access memory before the
> > string given when the whole template given consists of 'X'
> > characters.
>
> Nice catch! I've committed a slightly different fix, but the
2010/1/27 Vadim Zhukov :
> Current implementation of mktemp_internal() access memory before the
> string given when the whole template given consists of 'X' characters.
Nice catch! I've committed a slightly different fix, but the base
idea is the same, thanks!
Philip Guenther
On Mon, Feb 8, 2010 at 11:11 AM, Owain Ainsworth wrote:
> On Mon, Feb 01, 2010 at 11:30:06PM -0500, Ted Unangst wrote:
>> I think this fixes the problem with sleeping and holding pseg_lck.
>
> This won't build on sparc64 (the only caller of valloc_align). If you
> fix that, then I am ok with this
Good day,
the following diff...
- implements bioctl support;
- fixes hot-un-plugging w/ softeps;
- improves performance;
- fixes IPL levels;
- fixes lots of small things;
- does a little bit of cleanup;
- fixes NOWAIT/WAITOK;
- disables useless/unused Driver Persistent Mapping code that prevents
On Mon, Feb 01, 2010 at 11:30:06PM -0500, Ted Unangst wrote:
> I think this fixes the problem with sleeping and holding pseg_lck.
>
> Index: uvm_extern.h
> ===
> RCS file: /home/tedu/cvs/src/sys/uvm/uvm_extern.h,v
> retrieving revisio
* Ted Unangst [2010-02-08 15:04]:
> On Sun, Feb 7, 2010 at 8:02 PM, Philip Guenther wrote:
> > Gah, between that and Henning's observation that those functions may
> > be used by modules, I withdraw the suggestion that they be removed and
>
> That'd be really weird for a module to depend on code
On Mon, Feb 8, 2010 at 9:48 AM, Mark Kettenis
wrote:
>> So how do we move forward?
>
> For one thing, I'd like to see some real benchmarks. Does using a
> larger buffer really speed up cp? You claim moving a "head" between
> reads and writes takes time, but so does moving it between reads. And
> Date: Mon, 8 Feb 2010 08:58:46 -0500
> From: Ted Unangst
>
> On Sun, Feb 7, 2010 at 6:11 PM, Theo de Raadt
> wrote:
> > I think adding big chunks of sysctl code to such specific applications
> > is very un-unix.
> >
> > If choosing a buffer size is going to be a common operation, it should
> >
On Mon, Feb 08, 2010 at 09:06:21AM -0500, Sean Kennedy wrote:
> Moving this to m...@...
>
> Would part of this discussion usefully related to such issues like using 'dd'
> for diskwipes/copies/reformatting and slow data movement speeds?
>
> There are times when I am wiping (for reuse) hard disks
Moving this to m...@...
Would part of this discussion usefully related to such issues like using 'dd'
for diskwipes/copies/reformatting and slow data movement speeds?
There are times when I am wiping (for reuse) hard disks using 'dd' and I set
the BlockSize to > 512 (like 1M or so sometimes)
and
On Sun, Feb 7, 2010 at 8:02 PM, Philip Guenther wrote:
> Gah, between that and Henning's observation that those functions may
> be used by modules, I withdraw the suggestion that they be removed and
That'd be really weird for a module to depend on code in the ssl
module, but whatever.
> instead
On Fri, Feb 05, 2010 at 04:03:33PM -0700, Jeff Ross wrote:
> Could I avoid all of this messing around if I had a server that could run
> amd64? How would a dual processor 1.8 Opteron 244 w/4GB ram compare to this
> 2.4GHZ dual XEON w/4GB ram? Bog knows I don't need another server, but...
amd64
On Sun, Feb 7, 2010 at 6:11 PM, Theo de Raadt
wrote:
> I think adding big chunks of sysctl code to such specific applications
> is very un-unix.
>
> If choosing a buffer size is going to be a common operation, it should
> be an API called to "ask what the buffer size should be". If that is
> the
On Mon, Feb 08, 2010 at 08:10:11AM -0500, Brad Tilley wrote:
> I placed the GUI version there are source.cpp. I don't have the simpler,
> non-GUI version that I posted yesterday, but the use of srand and rand are
> the same in both examples. The GUI version compiles on OpenBSD if you have
> fltk
I placed the GUI version there are source.cpp. I don't have the simpler,
non-GUI version that I posted yesterday, but the use of srand and rand are the
same in both examples. The GUI version compiles on OpenBSD if you have fltk
installed from ports. I only wrote the simpler version to demonstrat
Thought the discussion was over. We repost it later.
On Mon, 08 Feb 2010 09:07 +0100, "Marc Espie" 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 n
Brad Tilley wrote:
That's OK, my skin is thick. Thanks for the feedback.
Ok, back to the real topic. The essence is that for key (or
password generation) you'll want a cryptographically strong
generator.
See
http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
On Mon, Feb 08, 2010 at 01:56:03AM -0200, Christiano F. Haesbaert wrote:
> 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
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
>
26 matches
Mail list logo
