I encourage you to try scpu.
https://bitbucket.org/mischief/scpu
There are binaries available in 9front pkg repos.
On March 27, 2015 9:48:15 AM PDT, Rudolf Sykora wrote:
>Hello,
>
>trying to connect from 9atom via ssh (v2) to my linux machine I get:
>ssh: dial: handshake failed
&g
Yes. There is no select/copy support.
On March 3, 2015 4:14:56 AM PST, Rudolf Sykora wrote:
>On 3 March 2015 at 12:15, Rudolf Sykora
>wrote:
>
>> is it so that one can't use mouse when running 'vt'?
>
>... meaning for copy-pasting
>R
cinap_lenrek has fixed this in 9front revision dd392df17488. the bug seems
present in 9atom and labs too, though.
does anyone care to take a stab at figuring out why mainmem->curalloc
underflows? here's a c program to reproduce.
#include
#include
/*
8c curalloc.c
8l curalloc.8
p=`{8.out >[2=1] | awk '{ print $2 }' | tr -d : }
echo '*mainmem' | acid -lpool $p
-> curalloc 4294967016
*/
void
domalloc
You would need to implement something like ulimits to fix process exhaustion,
or some kind of rate limit. There are several forms of resource exhaustion in
plan 9. One other that comes to mind is cat /dev/random prevents other clients
from making progress reading /dev/random, such as cpu.
On Ja
it turns out the right thing to do is to just consult cs directly, which can
resolve any of 1.2.3.4, google.com, finn (where ndb has a sys=finn line),
'$ipgw'.
i just updated the code so that i can use a "meta-name" as described in
dial(2), like:
8.out '$cpu'
but i'm not happy with how dnsresolve()/csresolve() functions turned out.
is there a better way?
hi 9fans,
i wrote a little tcp port scanner using libthread's ioprocs. i wasn't able to
test ipv6. enjoy :)
http://9.offblast.org/stuff/netscan.c
who needs select(2) anyway?
Im rewriting parts of the driver after feedback from cinap, namely removing
qlock and nfree, removing the transmit callback and rewriting txproc to use
qbread. ☺
The current source should work though.
thank you for merging some of the patches on the issue tracker, latchesar. :)
latchesar fixed a few bugs i reported earlier this year. you might try mailing
him directly.
ron also has a fork on github.
On Wed Dec 3 20:03:51 EST 2014, skip.tavakkol...@gmail.com wrote:
> nice work! thank you all.
>
> is there an image to start from? any instructions?
>
>
you should look at david's link to the golang-dev thread a few posts ago. he
has a labs image and some notes about the setup. my 9front ima
for more information on the dhcp issue with gce, see
https://code.google.com/p/google-compute-engine/issues/detail?id=77
good news, everyone. ethervirtio seems to work now on google compute engine in
both labs (tested by david) and 9front (tested by me). somebody on irc reported
that it also works for vultr.com. the driver should work fine in any qemu.
only the 386 kernel for labs and 9front were tested, but the
what 'doc' do you refer to? what didn't work properly? nobody can help you if
you don't explain what the problem is.
by 'ci ap' i meant cinap_lenrek.
UEFI support was written for 9front by ci ap. It has been tested on the x230
and in OVMF. I have an working gpt editor but it needs cleanup.
the virtio
> device in GCE seems to differ from qemu's.
>
> if you run into trouble, you can mail me back or contact me on freenode irc,
> where my handle is mischief.
what do you mean by PGROUND here, and BY2PG. do you really mean an explicit
4096 bytes?
- erik
--- End Message ---
if you run into trouble, you can mail me back or contact me on freenode irc,
where my handle is mischief.
19 matches
Mail list logo