I found something on a french Plan 9 translation site about dd'ing my nvram
from my PC to a file in /sys/src/9/kw then building.
This seems to have gotten me past the point where it crashes because it
can't write to nvram, but it crashes all the same anyway :-)
Marvell>> setenv bootcmd 'dhcp 0x80
Ok, now I can't remember what I just did, but it's working.
On Mon, Aug 30, 2010 at 11:59 PM, David Leimbach wrote:
> I found something on a french Plan 9 translation site about dd'ing my nvram
> from my PC to a file in /sys/src/9/kw then building.
>
> This seems to have gotten me past the poi
> A simple change:
> pid = getpid();
shouldn't you just fix it so _tos->pid is set?
also, the comments in the new nsec.c don't
match the code. the code looks something like this
do{
...
tries = 0;
}while(tries++ == 0); /* retry once */
of cours
On Tue Aug 31 03:27:52 EDT 2010, leim...@gmail.com wrote:
> Ok, now I can't remember what I just did, but it's working.
>
>
>
> On Mon, Aug 30, 2010 at 11:59 PM, David Leimbach wrote:
>
> > I found something on a french Plan 9 translation site about dd'ing my nvram
> > from my PC to a file in
Hi all,
how to lock (protect by password) the cpu console? In default install
afterboot the console is logged by user bootes. Is there a way to avoid this?
tia,
bye
--
Maurizio Boriani
irc: #defo...@freenode.net
PGP key: 0xEBBFF70D
=> A5 96 C1 30 00 78 0C 78 57 5D 3E 05 C2 A4 6D 53 <
On Tue Aug 31 10:21:42 EDT 2010, bau...@gmail.com wrote:
>
> Hi all,
> how to lock (protect by password) the cpu console? In default install
> afterboot the console is logged by user bootes. Is there a way to avoid this?
>
the quick answer is that it's not possible out of the box.
previou
On Tue, Aug 31, 2010 at 3:20 PM, wrote:
>
>how to lock (protect by password) the cpu console? In default
> install
> afterboot the console is logged by user bootes. Is there a way to avoid
> this?
>
>
>
Usually, you'll find people put it in a cupboard or room that you can
physically lock.
On Tue, Aug 31, 2010 at 10:20 AM, wrote:
>
> Hi all,
> how to lock (protect by password) the cpu console? In default install
> afterboot the console is logged by user bootes. Is there a way to avoid this?
>
> tia,
>
> bye
>
> --
> Maurizio Boriani
> irc: #defo...@freenode.net
> PGP key: 0x
> There is also, somewhere, a screen locker program that (I think) Rob
> wrote a few years back; I compiled it and used it successfully last
> year, and you could certainly stick that in your cpustart to
> automatically lock the screen. However, for the life of me I can't
> find the code right now,
On Tue, Aug 31, 2010 at 6:07 AM, erik quanstrom wrote:
> On Tue Aug 31 03:27:52 EDT 2010, leim...@gmail.com wrote:
>
> > Ok, now I can't remember what I just did, but it's working.
> >
> >
> >
> > On Mon, Aug 30, 2010 at 11:59 PM, David Leimbach
> wrote:
> >
> > > I found something on a french Pl
On Tue, Aug 31, 2010 at 5:54 AM, erik quanstrom wrote:
>> A simple change:
>> pid = getpid();
>
> shouldn't you just fix it so _tos->pid is set?
yep. I just have to find the time.
>
> also, the comments in the new nsec.c don't
> match the code. the code looks something like this
>
> do{
In short. Physical access trumps all other locking mechanisms anyway.
CPU servers were not meant to be workstations, and the lack of a screen lock
shows that. But then workstations are easily stolen. 2 were taken from the
building where I work in the last weeks at a law firm office (we share ou
Steve has a conslock in sources. I have a couple of CPUs in open areas
that I lock using it. Put it as the last action in /cfg/machine/cpurc
to lock on startup.
Sent from my iPhone
On Aug 31, 2010, at 8:04 AM, erik quanstrom
wrote:
There is also, somewhere, a screen locker program that
> personal opinion: the difficulty of getting this code right, and its
> complexity, tell me something is wrong with the interface. Look at the
> trouble we're going through to get a 64-bit number out of the kernel.
> Look at how hard it is to get right.
>
> Two ways out:
> 1. "reserved" fds. an f
I've seen a little bit of information about trying to go to LLVM for
Inferno, and getting LLVM on Plan 9 natively (feasibility anyway), and I was
wondering if there's any official projects chasing this in earnest?
Now that I've got an ARM and an x86 plan 9 instance up, I might have some
time, but
> Looking over my notes it appears the only thing I had to do to prevent the
> crash was enable my fossil FS's listening capabilities. Now the guruplug
> gets a kernel and an FS every time.
Yes, if you don't make fossil listening on port 564/tcp, this error appear.
It is a common oversight, when
for cpu servers, I sometimes add cat /dev/kmesg /dev/kprint to cpurc.
as the console does not run rio and you can't hit Del to kill them,
they suffice to lock the keyboard.
there was also the lock program from Rob Pike, IIRC, posted here long
ago, I think.
perhaps not
On Tue, Aug 31, 2010 at 5:25
Is this a trick to get C++ back on Plan9??
On Tue, Aug 31, 2010 at 11:19 AM, David du Colombier <0in...@gmail.com>wrote:
> > Looking over my notes it appears the only thing I had to do to prevent
> the
> > crash was enable my fossil FS's listening capabilities. Now the guruplug
> > gets a kernel and an FS every time.
>
> Yes, if you don't
On Tue, Aug 31, 2010 at 11:33 AM, Nick LaForge wrote:
> Is this a trick to get C++ back on Plan9??
Actually I'm not as interested in C++ as others may be. I'm more interested
in the general capabilities of LLVM. It's a pretty nice target for making
little languages. There's tutorials for doin
here's something quite old which used to work:
http://mirtchovski.com/lanlp9/rlock/index.html
see: /n/sources/contrib/steve/rc/conslock
if you have more than one cpu, change this line:
pwd=$home/lib/conslock.hash
to
pwd=$home/lib/conslock.^$sysname^.hash
> Is this a trick to get C++ back on Plan9??
was it ever?
LLVM is written in C++, so you'd need C++ support on plan 9 first. Probably
the easiest way to do that would be to add support for plan 9 binaries to
clang, and cross-compile llvm for plan 9 with itself.
At least, that's the path I'd take if I was interested in trying.
On Tue, 31 Aug 2010 09:10:4
On Tue, Aug 31, 2010 at 1:59 PM, Ori Bernstein wrote:
> LLVM is written in C++, so you'd need C++ support on plan 9 first. Probably
> the easiest way to do that would be to add support for plan 9 binaries to
> clang, and cross-compile llvm for plan 9 with itself.
>
>
Yep. I was thinking a cross
>There's tutorials for doing so from O'Caml
[http://llvm.org/docs/tutorial/]
That looks really neat. I had watched this*:
[http://vimeo.com/14313378] weeks back, subsequently flipping through
Appel's "Modern Compiler Implementation in ML", but ultimately
deciding the book to be too boring. This
On Tue, 31 Aug 2010 14:03:41 PDT David Leimbach
> On Tue, Aug 31, 2010 at 1:59 PM, Ori Bernstein wrote:
>
> > LLVM is written in C++, so you'd need C++ support on plan 9 first. Probably
> > the easiest way to do that would be to add support for plan 9 binaries to
> > clang, and cross-compile llv
Well I'm interested in Go on Plan 9, but I'm also interested in other
languages too, even one's people haven't written yet.
LLVM seems like pretty decent toolkit for building them up.
Dave
On Tue, Aug 31, 2010 at 2:31 PM, Nick LaForge wrote:
> >There's tutorials for doing so from O'Caml
>
> [h
On Tue, Aug 31, 2010 at 2:52 PM, Bakul Shah
> wrote:
> On Tue, 31 Aug 2010 14:03:41 PDT David Leimbach
> > On Tue, Aug 31, 2010 at 1:59 PM, Ori Bernstein
> wrote:
> >
> > > LLVM is written in C++, so you'd need C++ support on plan 9 first.
> Probably
> > > the easiest way to do that would be to
oops, s/inciting/enticing/ (not quite the same thing... :-p)
> I could see having these all over my house at some point.
I'm having bad luck with my light bulbs lately. There are no
replacements in the shop either and I'm still waiting for my guruscrew
(ingenious light bulb form factor) to arrive.
But when they come they will be everywhere.
On Monday, August 30, 2010, Skip Tavakkolian <9...@9netics.com> wrote:
> do you compile in an nvram (that includes the correct rights?)
>
Yeah, I dd'd the one from my boot disk on the CPU server.
>> On Mon, Aug 30, 2010 at 7:01 PM, erik quanstrom wrote:
>>
>>> > Just got one of these today, and I
go ${loadaddr}
## Starting application at 0x8200 ...
Plan 9
and hang.
It's one of these:
OMAP3503-GP ES3.1, CPU-OPP2 L3-165MHz
Gumstix Overo board + LPDDR/NAND
I2C: ready
DRAM: 256 MB
NAND: 256 MiB
If anyone has used such a beast, let me know.
Linux works fine (aren't we all sick o
now there's also screenlock(8)
http://plan9.bell-labs.com/magic/man2html/8/screenlock
similar to conslock, but authenticates against the auth server
On Tue, Aug 31, 2010 at 5:45 PM, Skip Tavakkolian <9...@9netics.com> wrote:
> see: /n/sources/contrib/steve/rc/conslock
>
> if you have more than o
Don't do this under drawterm, at least not on Windows. It'll gobble
your mouse right up, or at least it did mine.
Of course, there's no reason to run this in drawterm, since your host
OS is certain to have its own screen locker...
John
On Wed, Sep 1, 2010 at 12:21 AM, Federico G. Benavento
wrot
35 matches
Mail list logo
