Not sure when Mr. Adams wrote this, but I think it was mid-90's.
First we thought the PC was a calculator. Then we found out how to turn
numbers into letters with ASCII -- and we thought it was a typewriter.
Then we discovered graphics, and we thought it was a television. With
the World Wi
On 7/3/08, Russ Cox <[EMAIL PROTECTED]> wrote:
>
> > Yeah, i know i can extract it if I try hard enaugh.
> > Others won't even try.
> > I hope this gets fixed.
>
>
> This just isn't high priority for me.
> Once 9vx is ready for prime time and there's
> a real distribution to make, I'll worry about
On Wed, Jul 02, 2008 at 07:12:56PM -0400, erik quanstrom wrote:
> > Native plan9 still booting fine, and here's the configuration for
> > /dev/sdE0/fossil if it's of any relevance:
> > fsys main config /dev/sdE0/fossil
> > fsys main open -V -c 3000
> >
> > Also, so far only /dev/sda was rw for dis
On Thu, Jul 03, 2008 at 12:00:02AM -0400, Russ Cox wrote:
> > Yeah, i know i can extract it if I try hard enaugh.
> > Others won't even try.
> > I hope this gets fixed.
Besides, I guess others will simply try the simple and dummy
workaround, as I did, which is to do it as root/with sudo.
You'll st
> Robert William Fuller wrote:
>> erik quanstrom wrote:
>>
>>
>>
>>> these are tetonic forces. there's nothing directly
>>
>> As a geologist, I can't let this one slip (pun intended.) It's
>> tectonic.
>
> Being of german ancestry, I can't let it slip either.. Maybe Eric meant
> Teutonic? Eit
> I do have to wonder about the whole TV on your mobile craze.
I share your scepticism however employer doesn't, I find
mob-TV meetings are an excellent forum for bullshit bingo.
-Steve
> The "global" plan9 one (sda1) seem to be the same in both cases, as well
> as the other sda* ones (linux), but the subpartitions (not sure they're
> called that way) inside differ.
> I suppose the correct one is the plan9 one, i.e 9fat should start at the
> beginning of the plan9 one (at 63), an
Quote from a comedian (Rhod Gilbert. maybe?):
"Well... No. I've got a TV, OK? I'm not interested in watching TV on my phone
for the same reason that I'm not interested in having a piss in my tumble
dryer".
> Besides, I guess others will simply try the simple and dummy
> workaround, as I did, which is to do it as root/with sudo.
> You'll still get the "extended header keyword" message, which doesn't
> seem that bad, but the unpacking will work, as far as I can tell.
>
> Mathieu.
some hospitality
> The only issue is that I can't justify the time needed to write Plan 9
> drivers when a usable system already exists.
>
> > Still you could use 9vx to run plan9 on top of this system, that way you
> > could maybe
> > migrate the system gradually.
>
> Unless vx32 can run real-time tasks (pretty
>> Besides, I guess others will simply try the simple and dummy
>> workaround, as I did, which is to do it as root/with sudo.
>> You'll still get the "extended header keyword" message, which doesn't
>> seem that bad, but the unpacking will work, as far as I can tell.
>>
>> Mathieu.
>
> some ho
I have a 10.5 MacBook with an external display attached. When I start
9vx, things look normal. I can resize the window on the main display.
If I move it to the second display and resize, the window goes from
"good" to "bad":
http://strand1.com/who/anthony/bug/good.png
http://strand1.com/who/anthon
I think the problem comes from 9vx picking up the main display's
dimensions as the preallocation for "full screen". Drawterm has a fix
for that which loops through all the currently attached displays and
picks up the one with the largest size to decide what the "maximum
dimensions" should be.
here
This seems to be (given my limited understanding) similar to what
acme-sac is doing.
Is there any way we could solve the current state of affairs with
slightly diverging gui/draw codebases for p9p, drawterm, 9vx, acme-sac
and inferno-os? Each seems to have a set of bugs that somewhat
overlaps with
On Thu, Jul 03, 2008 at 07:06:59AM -0400, Russ Cox wrote:
> > The "global" plan9 one (sda1) seem to be the same in both cases, as well
> > as the other sda* ones (linux), but the subpartitions (not sure they're
> > called that way) inside differ.
> > I suppose the correct one is the plan9 one, i.e
> Is there any way we could solve the current state of affairs
if that's the royal "we" you're using then sure, there is a way:
simply download the latest versions of all programs that you're
interested in unifying (p9p, drawterm, 9vx, acme-sac, inferno), merge
the osx drawing code (using the bes
X11 code is still broken in various places, for example in Inferno-os
(and even more so acme-sac, which is missing some of the updates that
made it into inferno-os).
So my comment applies as much to the osx code as to the x11 code, and
to hypothetical win32 code. That is the whole point, that ever
On Thu, Jul 3, 2008 at 8:55 AM, Uriel <[EMAIL PROTECTED]> wrote:
> If there was a single codebase shared
> across projects none of this would be an issue at all.
you are right but it's a hard problem, we're all tight for time, so
the only fix is for somebody to step up and do it.
But your questio
> But your question, 'wouldn't it be better to have one thing to do all
> this different stuff', is certainly answered "probably".
you mean like a fileserver?
- erik
Greetings,
Thanks for finding that snippet, andrey :-) I was about to search the
acme-sac code for it so I could post a patch.
After looking through the 9vx code, it looks like russ is handling
memory allocation for the screen a little differently
than acme-sac (and possibly drawterm).
In acme-sa
On Thu, Jul 03, 2008 at 08:51:22AM -0400, erik quanstrom wrote:
> > The only issue is that I can't justify the time needed to write Plan 9
> > drivers when a usable system already exists.
> >
> > > Still you could use 9vx to run plan9 on top of this system, that way you
> > > could maybe
> > > mi
Sorry, I was a bit hasty with the patch. This one should compile properly:
diff -r ca5b26cbe43a src/9vx/osx/screen.c
--- a/src/9vx/osx/screen.c Tue Jul 01 17:27:41 2008 -0400
+++ b/src/9vx/osx/screen.c Fri Jul 04 01:31:37 2008 +0900
@@ -513,7 +511,9 @@
}else{
Hide
> - BeginFullScreen(&restore, 0, 0, 0, &osx.window, 0, 0);
> + GDHandle device;
> + GetWindowGreatestAreaDevice(&osx.window,
> kWindowTitleBarRgn, &device, NULL);
> + BeginFullScreen(&fullScreenRestore, device, 0, 0,
> &osx.window, 0, 0);
oop
I got annoyed with the idea of lguest being broken, I was stuck on a
long flight, so I redid l.s and fixed it. The new l.s has the
improvements from sources, mainly the 8M pte map instead of the
earlier 4M pte map.
it's also seriously cleaned up to take into account the new lguest
improvements (da
> Is there any way we could solve the current state of affairs with
> slightly diverging gui/draw codebases for p9p, drawterm, 9vx, acme-sac
> and inferno-os? Each seems to have a set of bugs that somewhat
> overlaps with the other projects, and they have to be rediscovered,
> and the fixes moved a
noble goal: look like plan 9 docs
ways to goal:
1. troff
2. tex with the right macros
3. lyx with the right layouts
so I have this paper written in lyx, if anyone has a pointer to (3), let me know
ron
On Thu, Jul 3, 2008 at 12:25 PM, Digby Tarvin <[EMAIL PROTECTED]> wrote:
> You are better off designing somethign that has real-time in mind
> from the start and then retrofitting the Unix/Linux compatability.
As the real-time additions to Plan 9 show, that isn't strictly
necessary -- if the kerne
I think 1.) is the simplest and easiest, but that is just me
uriel
On Thu, Jul 3, 2008 at 7:43 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> noble goal: look like plan 9 docs
>
> ways to goal:
> 1. troff
> 2. tex with the right macros
> 3. lyx with the right layouts
>
> so I have this paper writte
ron,
look at http://9fans.net/archive/2006/11/59. There are more mails in
2006/11 and 2006/10 about TeX and iwp9.
Probably you migth convert the lyx format to TeX (LaTeX) and apply that
header.
slds.
ron minnich escribió:
noble goal: look like plan 9 docs
ways to goal:
1. troff
2. tex wi
Die, thread die!
Note:
I copied the "source request" from an older iwp9 call.
I think the original idea was to be able to electronically
produce the entire proceedings book, with a uniform layout,
page numbers, toc etc.
I am not sure how this worked out, especially if different
people eventually submitted sourc
> Adding those lines verbatim to a file 'config', I then ran:
> vnfs -c 16k config
> and got back:
> handle da...0d
> I don't yet fully understand the implications of that 16 char hex string,
> so I'm not posting it here, but I didn't seem to need it anywhere else.
It was just a debugg
// The bytes you didn't post are the first 8 bytes of
// sha1sum /dev/zero.
Hey! How do you know what's in my /dev/zero?
// Better to just use vacfs -m if you want to view vac,
// and skip NFS entirely.
To the extent that I just (or primarialy) want to see vac
dumps, sure. The idea was having a
> * the kprocdev framework. all i/o into devip, devfs, and devdraw
> is marshalled and handed off to a kproc running in a different
> pthread, so that blocking i/o won't block the cpu0 pthread,
> which is the only one that can run vx32. this means that
> all
On 2008-Jul-2, at 14:10 , Fazlul Shahriar wrote:
I wrote a file server for the SSH File Transfer Protocol (SFTP). You
can find it here:
Well done! It's nice to see some people still prefer writing code
instead of mail ;-)
I'll give it a beating as soon as I have a free moment.
--lyndon
I'm finding that vx32 is a *way* better way to get to lguest guests
than drawterm :-)
It is just so much snappier.
ron
> why can only one thread run vx32?
i think i found part of the answer just now. see the comment above
9vx/main.c:^setsigsegv
>> * the kprocdev framework. all i/o into devip, devfs, and devdraw
>> is marshalled and handed off to a kproc running in a different
>> pthread, so that blocking i/o won't block the cpu0 pthread,
>> which is the only one that can run vx32. this means that
>>
The venti surveys have stopped trickling in. As promised,
here is a summary.
Below is a table summarizing the venti data.
Each line is one server that someone submitted.
I am surprised that there are people out there
with 4+ year old servers. You take very good care
of your disks. I suspect t
Apparently GNU mv is fond of extended attributes, and keeps breaking
9pfuse when I try to move a file between directories. This is the
culprit:
src/cmd/9pfuse/fuse.c:175:case FUSE_SETXATTR:
src/cmd/9pfuse/fuse.c:176:/* struct and two strings */
In fact, SETXATTR comes wi
40 matches
Mail list logo
