Emaili gvr|nt|lemekte problem yaE D1yorsanD1z l|tfen tD1klayD1nD1z
Bizden bir daha mail almak istemiyorsanD1z tD1klayD1nD1z
www.ikincielnotebook.com web
sitesine gitmek igin tD1klayD1nD1z
www.ikincielnotebook.com web
sitesine gitmek igin tD1klayD1nD1z
www.ikincielnotebook.com web
sitesine gitmek
Hi Vladimir,
Vladimir Kirillov wrote on Fri, Oct 15, 2010 at 02:31:21AM +0300:
> The getmntinfo(3) page says that the mentioned function uses static
> storage which cannot be freed, however this storage is being actually
> malloced and can be freed without consequences.
Err, no.
Reading the code
Hello, t...@!
The getmntinfo(3) page says that the mentioned function uses static
storage which cannot be freed, however this storage is being actually
malloced and can be freed without consequences.
I see no real need in doing such weird things (correct me if i'm
wrong) so here's a diff to actua
> On Thu, Oct 14, 2010 at 11:57 AM, Mike Belopuhov wrote:
> > this dns code has a serious flaw. you use arc4random to allocate request
> > IDs. this is a bad decision, as you actually want a non-repeating
> property.
>
> Why? Each query transmission uses a newly allocated socket with a
> uniqu
On Thu, Oct 14, 2010 at 11:57 AM, Mike Belopuhov wrote:
> this dns code has a serious flaw. you use arc4random to allocate request
> IDs. this is a bad decision, as you actually want a non-repeating
property.
Why? Each query transmission uses a newly allocated socket with a
unique (random) sou
On Thu, Oct 14, 2010 at 4:47 PM, Gilles Chehade wrote:
> Dear tech@,
>
> eric@ has written an (awesome :p) asynchronous resolver that allows us to do
> non-blocking DNS lookups.
>
this dns code has a serious flaw. you use arc4random to allocate request
IDs. this is a bad decision, as you actual
On Thu, Oct 14, 2010 at 04:47:26PM +0200, Gilles Chehade wrote:
> A tarball to test: http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz
>
> This is smtpd-current, queue is unchanged, please test as it is experimental
> code. I will run it for a few days and commit if I see no drawbacks and I do
>
On Thu, Oct 14, 2010 at 11:33:19AM -0400, Randy Lewis wrote:
> Using new 4.7 install with Dell Poweredge 850, Pentium-D, 1G Ram,
> 80GB root drive...works great.
> Added 2nd SATA drive, 2TB size.
> .
> Fdisk -i - OK
> Disklabel, "a" partition (offset 63, normal), maximum size selected, etc.
>
Using new 4.7 install with Dell Poweredge 850, Pentium-D, 1G Ram, 80GB
root drive...works great.
Added 2nd SATA drive, 2TB size.
.
Fdisk -i - OK
Disklabel, "a" partition (offset 63, normal), maximum size selected, etc.
Tried countless approaches to newfs (and newfs_ext2fs) with basically
th
Ted Unangst wrote:
> Why not use the evdns resolver in libevent?
(1) It isn't part of the base system libevent.
(2) It doesn't understand all of our resolv.conf(5) syntax and it
can't talk to a nameserver over IPv6.
--
Christian "naddy" Weisgerber na...@mips.inka.d
On Thu, Oct 14, 2010 at 11:29 AM, Mike Belopuhov wrote:
> On Thu, Oct 14, 2010 at 2:08 AM, Ted Unangst wrote:
>> So it's not a good idea to perform long lasting operations in the kernel.
>> The scheduler doesn't deal well with it and nobody else gets to run.
>>
>> One of those long loops is loadi
On 10/14/10 17:30, Ted Unangst wrote:
On Thu, Oct 14, 2010 at 11:17 AM, Gilles Chehade wrote:
we don't have evdns in our libevent and I'm pretty confident it's not going
to happen any time soon given how many times I heard "no fucking way" by
different hackers :p
In that case, here's
> On Thu, Oct 14, 2010 at 2:08 AM, Ted Unangst wrote:
> > So it's not a good idea to perform long lasting operations in the kernel.
> > The scheduler doesn't deal well with it and nobody else gets to run.
> >
> > One of those long loops is loading a large table into pf. If you're
> > lucky, you'l
OS X routed all dns lookups to a daemon (both unicast and multicast),
they can do local cashing and probably async lookups, maybe thats a
future solution ?
just my two cents.
On Thu, Oct 14, 2010 at 11:17 AM, Gilles Chehade wrote:
> we don't have evdns in our libevent and I'm pretty confident it's not going
> to happen any time soon given how many times I heard "no fucking way" by
> different hackers :p
In that case, here's some more constructive feedback from a quick
On Thu, Oct 14, 2010 at 2:08 AM, Ted Unangst wrote:
> So it's not a good idea to perform long lasting operations in the kernel.
> The scheduler doesn't deal well with it and nobody else gets to run.
>
> One of those long loops is loading a large table into pf. If you're
> lucky, you'll run out of
On Wed, Oct 13, 2010 at 08:08:34PM -0400, Ted Unangst wrote:
> So it's not a good idea to perform long lasting operations in the kernel.
> The scheduler doesn't deal well with it and nobody else gets to run.
>
> One of those long loops is loading a large table into pf. If you're
> lucky, you'l
On 10/14/10 17:06, Ted Unangst wrote:
On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade wrote:
eric@ has written an (awesome :p) asynchronous resolver that allows us to do
non-blocking DNS lookups.
Why not use the evdns resolver in libevent? If you're already using
libevent, wouldn't
On Thu, Oct 14, 2010 at 5:06 PM, Ted Unangst wrote:
> On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade
wrote:
>> eric@ has written an (awesome :p) asynchronous resolver that allows us to
do
>> non-blocking DNS lookups.
>
> Why not use the evdns resolver in libevent? If you're already using
> lib
> On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade wrote:
> > eric@ has written an (awesome :p) asynchronous resolver that allows us to do
> > non-blocking DNS lookups.
>
> Why not use the evdns resolver in libevent? If you're already using
> libevent, wouldn't that be a good fit? DNS resolvers
On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade wrote:
> eric@ has written an (awesome :p) asynchronous resolver that allows us to do
> non-blocking DNS lookups.
Why not use the evdns resolver in libevent? If you're already using
libevent, wouldn't that be a good fit? DNS resolvers are histori
Dear tech@,
eric@ has written an (awesome :p) asynchronous resolver that allows us to do
non-blocking DNS lookups.
As of today, smtpd implements non-blocking lookups through a fork+imsg hack,
creating a socketpair() and a new process for each lookup. It kind of worked
ok but recently a bug report
> On Wed, 13 Oct 2010 20:02:47 -0400 (EDT)
> Ted Unangst wrote:
>
> > Let's say you have a football field in need of a trimming, but the lawn
> > mowers are all broken, but you have an oxen store nearby. Oh, and the big
> > match is in an hour. How many oxen do you need?
> >
> > Normally, yo
Just what i was looking for, but how many shovels will I need for the
shit?
If I get 6400 oxen, maybe they'll have to tread it in.
On Wed, 13 Oct 2010 20:02:47 -0400 (EDT)
Ted Unangst wrote:
> Let's say you have a football field in need of a trimming, but the lawn
> mowers are all broken, bu
Thank you again to the people who tested the first diff. Here's diff two
in the cleanup of the amd64 low-level segment bits. Now that the LDT is
only used by dead compat code, load the ldt register with the null
selector (disabling use of it), stop reloading it on every context switch,
and bl
25 matches
Mail list logo
