Drawterm used to live in a CVS repository at MIT.
I have moved it to a Mercurial repository at Bitbucket.
http://code.swtch.com/drawterm
The old drawterm CVS repository is still there but will not be updated.
http://swtch.com/drawterm will continue to have tar balls.
Russ
Sorry for posting here, but I can't reach you inferno guys.
I don't know whether it could be gmail's faults, tell me if I can help
in any way.
-- Forwarded message --
From: Mail Delivery Subsystem
Date: Tue, Aug 25, 2009 at 12:18 AM
Subject: Delivery Status Notification (Failure)
> hplaser mydesk 192.168.1.101 192.168.1.101
>- post+600dpi generic generic generic generic tcppost
we use something like this
printer somewhere minooka.coraid.com tcp!printer!9100 81920 post2+1200dpi+duplex
generic generic generic generic tcppost FIFO
i think you may need a FIFO a
On Tue, Aug 25, 2009 at 8:08 PM, erik quanstrom wrote:
>>
>> Any chance this is related to the issues we discussed on #plan9?
>>
No, I'm pretty sure not. This dealt with a relatively rare case, a
filesystem with an optimal read size larger than a constant in the
Venti source. The constant was 64K,
>
> Any chance this is related to the issues we discussed on #plan9?
>
since not everyone who reads the list does irc, why
don't you fill us in on the issues discussed on #plan9?
- erik
On Sun, Aug 23, 2009 at 11:10 AM, Venkatesh Srinivas wrote:
> Hi,
>
> I think I've found a bug in p9p's Venti, if anyone were to take a look
> at this code or tell me if I'm on the right track, it'd be pretty
> neat.
>
> When trying to start Venti on a FreeBSD 8-BETA2 system and a ZFS
> filesystem,
> Perhaps. The harddisk is a FreeAgent Seagate,
> connected via USB. It used to go into sleep mode
> every 15 minutes and I would often have to restart
> cwfs - this is probably cause for a lot of damage.
this sounds like a bug in usb/disk. usb/disk should be
able to handle a sleeping drive witho
> I've already told Akumar offlist, just writing it to the list for
> documentation:
> that auto sleep mode on seagates can be disabled on linux (dunno about
> *BSD) as well with sdparm. I don't remember the args for sure, but
> probably something like
> 'sdparm -c STANDBY /dev/sdX#'
> then
> 'sdpa
