Bol Cesit, Hediyeli Ceyiz Setleri,Bayanlara,Baylara,cocuklara...

2011-03-21 Thread 150 Fabrikadan Evinize
Evinize, Aile fertlerinize, Sevdiklerinize En guzel Urunler 3 Sitede. % 50'ye varan indirim firsatlari, Hediyeli Setler. Mesaji goruntulemekte sorun varsa tiklayiniz. [IMAGE] [IMAGE] [IMAGE] REYONLAR MARKALAR KAMPANYA HAFTANIN FIRSATI ic giyim EV TEKSTiLi CEYiZ SETLERi ... [IMAGE] [IM

Re: qemu-old .. relevent or not?

2011-03-21 Thread Stanley Lieber
On Mon, Mar 21, 2011 at 5:53 PM, Brad wrote: > On 22/03/11 4:54 PM, Stanley Lieber wrote: >>> >>> I've gotten one request to decommission qemu-old. B It surprised me, >>> as I thought there were still issues with qemu/ even with the semi recent >>> thread fix as well as performance differences. >>

Re: [PATCH] Fix for kernel crash with udav(4) device

2011-03-21 Thread Matthias Kilian
On Sun, Mar 20, 2011 at 04:07:33PM -0400, Loganaden Velvindron wrote: > With input from mk, we improved the diff. > > Testing is very much appreciated. [...] I can't comment on the code (it isn't my area, but, worse, i'm still too short of time), but at least a make build over nfs now finished wi

Re: qemu-old .. relevent or not?

2011-03-21 Thread Brad
On 21/03/11 7:08 PM, Stanley Lieber wrote: On Mon, Mar 21, 2011 at 5:53 PM, Brad wrote: On 22/03/11 4:54 PM, Stanley Lieber wrote: I've gotten one request to decommission qemu-old. It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well a

Re: qemu-old .. relevent or not?

2011-03-21 Thread Brad
On 22/03/11 4:54 PM, Stanley Lieber wrote: I've gotten one request to decommission qemu-old. It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or

Re: qemu-old .. relevent or not?

2011-03-21 Thread Brad
On 21/03/11 5:59 PM, Henning Brauer wrote: * Todd T. Fries [2011-03-21 22:01]: Does anybody have objection to retiring qemu-old to the attic or ? yes, I object for the time being. the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a chance to try the recently updated 0.14 ye

Re: qemu-old .. relevent or not?

2011-03-21 Thread Todd T. Fries
I withdraw any thoughts of removing qemu-old anytime soon based on feedback. Henning confirms performance gains for keeping it. And we have a reminder that while kqemu is not recommended, it is only usable on qemu-old. Penned by Todd T. Fries on 20110321 15:58.35, we have: | I've gotte

Re: qemu-old .. relevent or not?

2011-03-21 Thread Henning Brauer
* Todd T. Fries [2011-03-21 22:01]: > Does anybody have objection to retiring qemu-old to the attic or ? yes, I object for the time being. the laptops where i use(d) qemu most are stuck in tokyo, hadn't had a chance to try the recently updated 0.14 yet and due to this situation it'll be a bit, b

Re: qemu-old .. relevent or not?

2011-03-21 Thread Stanley Lieber
> I've gotten one request to decommission qemu-old. It surprised me, > as I thought there were still issues with qemu/ even with the semi recent > thread fix as well as performance differences. > > Does anybody have objection to retiring qemu-old to the attic or ? > > I'd rather not do this prem

qemu-old .. relevent or not?

2011-03-21 Thread Todd T. Fries
I've gotten one request to decommission qemu-old. It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or ? I'd rather not do this prematurely but if

Re: ls(1) displays future timestamps improperly

2011-03-21 Thread Benny Lofgren
On 2011-03-21 20.24, Ted Unangst wrote: > On Mon, Mar 21, 2011 at 7:04 AM, Benny Lofgren wrote: >> Realized I was sloppy with KNF. This diff is hopefully neater looking. > > I like this, but 5 seconds is not enough. I would have chosen at > least an hour, for poorly synced NFS systems, if not a

Re: ls(1) displays future timestamps improperly

2011-03-21 Thread Ted Unangst
On Mon, Mar 21, 2011 at 7:04 AM, Benny Lofgren wrote: > Realized I was sloppy with KNF. This diff is hopefully neater looking. I like this, but 5 seconds is not enough. I would have chosen at least an hour, for poorly synced NFS systems, if not a whole day. Also // comments aren't really in vog

Re: ls(1) displays future timestamps improperly

2011-03-21 Thread Owain Ainsworth
On Mon, Mar 21, 2011 at 12:04:33PM +0100, Benny Lofgren wrote: > Realized I was sloppy with KNF. This diff is hopefully neater looking. > > Regards, > /Benny > > 8<8<8<8<8<8< (cut) > Index: print.c > ===

Re: [PATCH] frame length validation for USB ethernet adapters

2011-03-21 Thread Loganaden Velvindron
Hi, I updated the diff for axe(4) based on what Laurent sent me. He says the patch breaks his axe(4). I also added a comment to explain why it's done, in areas where there's a status bit called RX_STATUS. This is based on an issue I encountered with udav(4), wherein despite having a valid status

Re: upl(4) buffer length validation

2011-03-21 Thread Loganaden Velvindron
Hi, Jasper pointed out that the minimum length should be 1. Plese test ! Index: src/sys/dev/usb/if_upl.c === RCS file: /cvs/src/sys/dev/usb/if_upl.c,v retrieving revision 1.47 diff -u -p -r1.47 if_upl.c --- src/sys/dev/usb/if_upl.c

tcpdump fix for OSPF

2011-03-21 Thread Claudio Jeker
Some crappy systems seem to send out packets with very strange lenght fields. In my particular case the IP length is 64 bytes (overall packet) but the ospf length is 32 bytes and therefor 12 bytes short. The box seems to add some crap as padding (I bet uninitialized memory). Tcpdump does not like

Re: pcap icmptype support

2011-03-21 Thread Claudio Jeker
On Wed, Feb 02, 2011 at 06:49:26PM +0100, Giovanni Bechis wrote: > This diff adds support to icmptype grammar to libpcap. > With this diff we can do: > $ sudo tcpdump -netttv -i nfe0 icmp[icmptype] = 8 > and capture only echo requests. > This diff is needed for an upcoming nmap update. > Comments

Re: ls(1) displays future timestamps improperly

2011-03-21 Thread Benny Lofgren
Realized I was sloppy with KNF. This diff is hopefully neater looking. Regards, /Benny 8<8<8<8<8<8< (cut) Index: print.c === RCS file: /cvs/src/bin/ls/print.c,v retrieving revision 1.27

ls(1) displays future timestamps improperly

2011-03-21 Thread Benny Lofgren
Hi list, If I touch(1) a file to a future date (or, for example, extract a tar archive from a system with an incorrect system clock), ls -l doesn't indicate that unless you use -T as well. That is, ls shows a misleading timestamp for that use case. All unixes I've worked with (including OpenBSD)

Re: make rain(6) use a sane default delay

2011-03-21 Thread Stuart Henderson
On 2011/03/21 07:54, Matthieu Herrb wrote: > rain(6) is useless. far from it, it's a useful network latency and jitter tester with an intuitive visual output :-) > but still it should provide sane defaults ihmo. ok? ok.

Re: make rain(6) use a sane default delay

2011-03-21 Thread Alexander Hall
On 03/21/11 10:18, Alexander Hall wrote: > On 03/21/11 08:46, Martynas Venckus wrote: >> On 3/21/11, Matthieu Herrb wrote: >>> rain(6) is useless. but still it should provide sane defaults >>> ihmo. ok? >> >> Or use sane defaults based on terminal speed; like worms(8) does. > > For this kind of

Re: make rain(6) use a sane default delay

2011-03-21 Thread Alexander Hall
On 03/21/11 08:46, Martynas Venckus wrote: > On 3/21/11, Matthieu Herrb wrote: >> rain(6) is useless. but still it should provide sane defaults >> ihmo. ok? > > Or use sane defaults based on terminal speed; like worms(8) does. For this kind of app (which is indeed quite a waste of space), I fin

Re: make rain(6) use a sane default delay

2011-03-21 Thread Martynas Venckus
On 3/21/11, Matthieu Herrb wrote: > rain(6) is useless. but still it should provide sane defaults > ihmo. ok? Or use sane defaults based on terminal speed; like worms(8) does. Index: rain.6 === RCS file: /cvs/src/games/rain/rain.6,