> What do you mean by unique ids? I think it is not enough to have a
> unique id at just one instant. We need a unique id for a qualitatively
> long time (i.e. infinite). It seems to me that numbers in /dev/wsys do
> not get reused, which would be just wanted, but is it really so?
yes they are uni
> the problem is that the fs proc and the keboard thread both fiddle with
> the the hidden array. in the style of rio, the solution would be
> along the lines of sending a message (say) the keyboard thread to hide
> the window. since windows have unique ids, sending a message like
> "hide 72" wou
> situation, maybe this could be added to /sys/src/cmd/rio/rio.c:
>
> : ruda; diff rio.c rio.c_orig
> 683c683
> < if(hidden[i] != nil) unhide(i);
> ---
>> unhide(i);
> : ruda;
>
> This usually helps, but it neither solves much, nor it is 100 % sure
> it saves you. The pro
2008/10/8 andrey mirtchovski <[EMAIL PROTECTED]>:
> while looking around for information on the RC strangeness i triggered
> a bug with rio: if the last window on the "hidden" stack disappears
> _while_ the third mouse button menu is opened, then upon attempting to
> unhide the window without relea
> Electricity is 15p per KwHour round here
>
> 300w
>
> echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc
>
> 410.625 pounds per year
>
> 60w
>
> 82.125 pounds per year
you have a good point, though i assume you mean
; hoc
0.15*0.300 * 24 * 365
394.2
0.15*0.060 * 24
2008/10/11 Russ Cox <[EMAIL PROTECTED]>
> Rather than litter the kernel with special case code,
> why not just set up your terminal to listen to the network?
> Then if you get in that state again you can drawterm in.
>
> Russ
>
> Again, I am normally (with my notebook) _NOT_ connected to _ANY_ net
Rather than litter the kernel with special case code,
why not just set up your terminal to listen to the network?
Then if you get in that state again you can drawterm in.
Russ
in other words, if "most of the time" makes you nervous,
it really is a good idea to have a seperate fileserver,
even if it is running a regular kernel.
As one who is at this moment trying to extricate himself from a corrupted
FS caused by an 'abrupt' restart, I can highly recommend you pay att
2008/10/10 matt <[EMAIL PROTECTED]>
>
> i'm not sure why you can't have a dedicated fileserver.
>> i put mine original fs together for $12.95. this fs is still
>> running, i just wanted to put together a diskless fs.
>>
>>
>
> Electricity is 15p per KwHour round here
>
> 300w
>
> echo 'scale=3;
notice that i've provided you with the gun but only you can pull the
> trigger. i absolve myself of any responsibility :p
>
Unfortunately, I can't do it now either. :(
I should have already been elsewhere for a while.
But if not someone else, I will get back to it on Monday.
Thanks
Ruda
> Was looking right at the same place. :) Only didn't know what to write
> there...
> Ruda
notice that i've provided you with the gun but only you can pull the
trigger. i absolve myself of any responsibility :p
i'm not sure why you can't have a dedicated fileserver.
i put mine original fs together for $12.95. this fs is still
running, i just wanted to put together a diskless fs.
Electricity is 15p per KwHour round here
300w
echo 'scale=3; 0.15 * 0.3 * 25 * 365' | bc
410.625 pounds per year
60
> % diff /tmp/devcons.c devcons.c
> 481,490d480
> < case '☺':
> < {
> < Proc *p; int i;
> < for(i = 0; i < conf.nproc; i++) {
> < p = proctab(i);
> <
i'm sure jmk will kill me for this. is the proc arena contiguous? if
not this could be a double-FAIL :)
% diff /tmp/devcons.c devcons.c
481,490d480
< case '☺':
< {
< Proc *p; int i;
< for(i = 0; i < con
On Fri, Oct 10, 2008 at 9:33 AM, ron minnich <[EMAIL PROTECTED]> wrote:
> Ruda, go ahead and have a go at putting your key sequence into rio.
> You may find it pretty easy to do ...
if rio is broken it may not be able to figure out the key sequence. it
should go in devcons, where the rest of the ^
2008/10/10 ron minnich <[EMAIL PROTECTED]>
> Ruda, go ahead and have a go at putting your key sequence into rio.
> You may find it pretty easy to do ...
>
> ron
>
Well, I will try to do so, just for fun :) And if I find how :) To this end
(being a complete newbie to plan9, actually a physicist),
it would be nicer to fix the bug. covering it up would be oh so
> linux-y.
>
> - erik
>
Are you sure, it is the last bug? :) Otherwise one can again loose some
data...
Ruda
Ruda, go ahead and have a go at putting your key sequence into rio.
You may find it pretty easy to do ...
ron
> So once more and to conclude, wouldn't it be nice to be able to press
> something like ctrl-alt-backspace to, by some means guarantee a way to a
> shell?
it would be nicer to fix the bug. covering it up would be oh so
linux-y.
- erik
two points
> 1. you can run rio in a rio window so you can debug
> rio without fiddling with your root rio.
>
True, but what happened to me was that I did not want to do any debugging. I
wanted to work, i.e. use the computer in the conventional sense -- do sth.
for my school. And you do not usual
> Well, sure. But somehow (don't know exactly how) sth. similar happened to me
> lately -- i.e. I ended with not responding rio. And was just thinking: if I
> could just kill it... and could not, not having an available shell. Could
> not even stop the machine properly (not everybody can have sever
2008/10/10 erik quanstrom <[EMAIL PROTECTED]>
> > How difficult would it be to add something similar to ^t^tr that would
> just
> > killed rio?
>
> how about just fixing the bug?
>
> - erik
Well, sure. But somehow (don't know exactly how) sth. similar happened to me
lately -- i.e. I ended with n
> How difficult would it be to add something similar to ^t^tr that would just
> killed rio?
how about just fixing the bug?
- erik
i think i meant "kill and restart rio" here, not "reboot the node".
How difficult would it be to add something similar to ^t^tr that would just
killed rio?
Ruda
>> (and one more question: if sth. like this happens on a file server -- I have
>> a single machine running all --, is it safe to reboot it with ^t^tr? --
>> usually I use 'fshalt -r'...)
>
> that should be fine most of the time. fossil rarely gets angry if you
> restart it without halting.
"most
> you can log in to the node if it allows that and reboot it. i crashed
> quite a few drawterm sessions to the same node to make sure it's
> repeatable.
i think i meant "kill and restart rio" here, not "reboot the node".
> (btw. can I do sth. else??! -- in linux one can usually kill X with
> alt-ctrl-backspace. Is there anything like that? I hope the underlining
> system is just working)
you can log in to the node if it allows that and reboot it. i crashed
quite a few drawterm sessions to the same node to make sur
2008/10/8 andrey mirtchovski <[EMAIL PROTECTED]>
> while looking around for information on the RC strangeness i triggered
> a bug with rio: if the last window on the "hidden" stack disappears
> _while_ the third mouse button menu is opened, then upon attempting to
> unhide the window without relea
while looking around for information on the RC strangeness i triggered
a bug with rio: if the last window on the "hidden" stack disappears
_while_ the third mouse button menu is opened, then upon attempting to
unhide the window without releasing the mouse button in between will
result in a read add
29 matches
Mail list logo
