rain(6) is useless. but still it should provide sane defaults
ihmo. ok?
Index: rain.6
===
RCS file: /cvs/OpenBSD/src/games/rain/rain.6,v
retrieving revision 1.14
diff -u -r1.14 rain.6
--- rain.6 31 May 2007 19:19:18 -
On 3/21/11, Matthieu Herrb matthieu.he...@laas.fr 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:
On 03/21/11 08:46, Martynas Venckus wrote:
On 3/21/11, Matthieu Herrb matthieu.he...@laas.fr 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
On 03/21/11 10:18, Alexander Hall wrote:
On 03/21/11 08:46, Martynas Venckus wrote:
On 3/21/11, Matthieu Herrb matthieu.he...@laas.fr 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
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.
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
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 ? ok
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
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
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
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
888888 (cut)
Index: print.c
On Mon, Mar 21, 2011 at 7:04 AM, Benny Lofgren bl-li...@lofgren.biz 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
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
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
* Todd T. Fries t...@fries.net [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
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 gotten one
On 21/03/11 5:59 PM, Henning Brauer wrote:
* Todd T. Friest...@fries.net [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
On 21/03/11 7:08 PM, Stanley Lieber wrote:
On Mon, Mar 21, 2011 at 5:53 PM, Bradb...@comstyle.com 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
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
On Mon, Mar 21, 2011 at 5:53 PM, Brad b...@comstyle.com 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
20 matches
Mail list logo
