On Tuesday 28 July 2009 21:24:01 Corey wrote:
> On Tuesday 28 July 2009 18:42:05 Russ Cox wrote:
> > It's not a question of time zones. Time zones don't matter.
> > It's just that the clock was wrong before and later is
> > correct--there are many reasons this might happen--
> > and venti shouldn
Uriel wrote:
Likely Google juice, there are still plenty of high-rank links
pointing there lying around the net.
That's how I found it, someone asked about InfernoSpaces and I ended up
here http://ai.ijs.si/mezi/agents/agents.html
Just a question: would it help if I had a SATA-DVD drive on sdE1 ? (And the
target on sdE0, as it is now). Could I then install from the CD without
fiddling? Perhaps, not more than editing plan9.ini?
Thanks, regards,
++pac.
<>
On Tue, Jul 28, 2009 at 2:37 PM, erik quanstrom wrote:
> this change as worked well on my personal system and at coraid
> for the past 6 months. it just works. even on hitherto unknown
> controllers like the orion.
Hmm. A few years ago, I ran into a similar problem and added a
variable that cou
> Hmm. A few years ago, I ran into a similar problem and added a
> variable that could be set in plan9.ini to specify where the nvram
> actually is. It works reasonably well
difficult to maintain in a pretty active environment;
one more reason for boot failure.
- erik
> My standalone terminal is always doing the index, the problem seemed
> to have just suddenly showed up for no reason - the system hasn't crashed,
> I'm not doing anything 'weird', and I always run fshalt before shutting
> down. And this persists across fresh installs.
Not sure what you mean by
> The problem isn't confined to unnecessary warning messages
> being printed.
>
> What about the 'arena arenas00: header is out-of-date' error,
> and the subsequent re-indexing (on every reboot) which occurs
> as a result of the condition?
Despite the mention of "date" in the message,
the logic be
Is an strange problem ... problem with interrupts?
Try to disable some hardware stuff, like the CD-ROM, USB, soundcard, etc.
This problem is only with plan9?
On Wed, Jul 29, 2009 at 4:49 PM, roger peppe wrote:
> well, now i've got another problem...
> i'm gettting strange time behaviour in the v
> This problem is only with plan9?
yup.
although it is plan9-inside-vmware, which could make
a significant difference.
This problem is only with plan9?
yup.
although it is plan9-inside-vmware, which could make
a significant difference.
And you said VMWare 2.x, which is exceedingly old...
Tim Newsham
http://www.thenewsh.com/~newsham/
It might be worth trying to get control back, I think you can do that
for domain squatters that violate trademarks, as is clearly the case
here.
uriel
On Wed, Jul 29, 2009 at 10:58 AM, maht wrote:
> Uriel wrote:
>>
>> Likely Google juice, there are still plenty of high-rank links
>> pointing ther
it's the latest version of VMWare Fusion AFAIK...
2009/7/29 Tim Newsham :
>>> This problem is only with plan9?
>>
>> yup.
>> although it is plan9-inside-vmware, which could make
>> a significant difference.
>
> And you said VMWare 2.x, which is exceedingly old...
>
> Tim Newsham
> http://www.thene
Hello Roger,
I'm currently running latest Plan 9 in vmware fusion Version 2.0
(116369). This system has been behaving perfectly on every installation (save
where i really botched something up trying to learn the system).
What is your host OS? I'm running this on Mac OS X 10.5.8
hope
On Wed, Jul 29, 2009 at 1:30 PM, Uriel wrote:
> It might be worth trying to get control back, I think you can do that
> for domain squatters that violate trademarks, as is clearly the case
> here.
I think that's only if the trademark owner pursues it, and the US may
have other draconian clauses to
This is sort of off-topic, but does anybody have any experience with
Ceph?
http://ceph.newdream.net/
Good or bad war stories (and general thoughts) would be quite welcome.
Thanks,
Roman.
My familiarity with the kernel source code is superficial to say the
least, but it seems to me that this code (from /sys/src/9/pc/trap.c)
contains a race condition:
702 if(sp<(USTKTOP-BY2PG) || sp>(USTKTOP-sizeof(Sargs)-BY2WD))
703 validaddr(sp, sizeof(Sargs)+BY2WD, 0);
7
On Tuesday 28 July 2009 17:42:23 Corey wrote:
> My experience is indicating a different reality,
> or I'm still not interpreting my experience correctly.
>
It was definitely the latter.
On Tuesday 28 July 2009 16:50:15 erik quanstrom wrote:
> you should note that this has absolutely zero to do
17 matches
Mail list logo
