and it will be an unaswered question. o fortuna, velut luna, statu
variabilis.
infinita variabiles?
On Mon, Nov 15, 2010 at 6:16 AM, Sam Watkins wrote:
> On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote:
>> Please see lsub's Op and my Streaming talk at the most recent IWP9.
>
> Ok, thanks. I did not know that 9p has latency problems even when reading a
> single file. I was talking a
On Mon, Nov 15, 2010 at 3:09 PM, Gorka Guardiola wrote:
> On Mon, Nov 15, 2010 at 6:16 AM, Sam Watkins wrote:
>> On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote:
>>> Please see lsub's Op and my Streaming talk at the most recent IWP9.
>>
>> Ok, thanks. I did not know that 9p has laten
On 15 November 2010 14:15, Gorka Guardiola wrote:
> By namespaces I mean qid's , the notion that a file is the same if the
> name isn't.
mind you, that's problematic in 9p. the qid can be the same even if the
file is different:
% ls -lqd /n/dump/2006/0707/usr/rog
(0003d540 1122 80) d-rwx
Anyone else having trouble getting equis installed via contrib/install?
I tried to do this this morning, as I was interested in giving
cinap_lenrek's dillo rc bundle a spin, and figured I needed X11 for that,
but it might already be there (it's failing).
X11 didn't succeed in installing, and it s
On Sun, Nov 14, 2010 at 7:25 PM, Sam Watkins wrote:
> hi,
>
> I am wondering what you think about the capabilities of 9p compared to
> http/1.1. Perhaps this seems like an odd comparison, but I think 9p and
> http
> are broadly similar in purpose and functionality. While writing a simple
> webs
On Sun, Nov 14, 2010 at 11:29 PM, Gary V. Vaughan wrote:
> You can either try to remember what all of those are, or use something
> like autoconf to probe for known bugs, and gnulib to plug them, or
> you can link against a shim library like GNU libposix which will
> do all of that automatically w
On Sun, Nov 14, 2010 at 6:31 PM, Jeff Sickel wrote:
>
> On Nov 13, 2010, at 5:14 PM, David Leimbach wrote:
>
> > Isn't this what Apple does recommend you do with application bundles?
> Ship
> > the whole directory (.app) with all requisite frameworks and libs?
>
> That's the recommended approach
> Under certain situations, 9p can do some forms of pipelining. The tagged
> requests don't have to be waited on in order, for the next outgoing request
> to be sent, unless there's a dependency of one completing before the other,
> or the evaluation of completion of a previous one on another.
On
On Mon, Nov 15, 2010 at 7:55 AM, Venkatesh Srinivas wrote:
> > Under certain situations, 9p can do some forms of pipelining. The tagged
> > requests don't have to be waited on in order, for the next outgoing
> request
> > to be sent, unless there's a dependency of one completing before the
> oth
the contrib tools are based on replica and in my experience that makes
them slow and fragile. You might want to give the 9pm stuff I did a
try. It works,it's far faster, and they're trivial shell scripts that
are easy to understand. Simple example, installing openssh is about 50
times faster -- min
On Mon, Nov 15, 2010 at 8:01 AM, ron minnich wrote:
> the contrib tools are based on replica and in my experience that makes
> them slow and fragile. You might want to give the 9pm stuff I did a
> try. It works,it's far faster, and they're trivial shell scripts that
> are easy to understand. Simp
On 15 Nov 2010, at 08:02, Enrico Weigelt wrote:
> * Gary V. Vaughan wrote:
>> People like to beat on GNU Libtool, and in some cases that criticism is
>> not undeserved... but in my experience, many critics of the tool come
>> from a perspective of building on a single architecture.
>
> Actually
> I've been thinking there might be a way for me to contribute to contrib here
> with failure cleanup, once I get a good handle on how it all works.
contrib/remove didn't work?
- erik
On Mon, Nov 15, 2010 at 8:04 AM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 8:01 AM, ron minnich wrote:
>
>> the contrib tools are based on replica and in my experience that makes
>> them slow and fragile. You might want to give the 9pm stuff I did a
>> try. It works,it's far faster, an
> the contrib tools are based on replica and in my experience that makes
> them slow and fragile.
My experience is I have never seen contrib be fragile, it just works, and
slow - well some of the huge packages (e.g. x11) do take a while to install,
but I have done that once per file server (i.e. t
> > How do you map it to a local identity?
>
> There's less need to, since most rights checks would be done using the key
> directly, but eve's factotum also probably has a SPKI key, and your identity
> can be stringified into a path of names if necessary.
in that case, what do you do with the us
> *much* rather wait 90 seconds for each build that try to maintain a giant
> tabulation with thousands of entries, which go out of date every time a new
> patch or revision of libc or the compiler or the os or the linker comes along.
there seems to be an affliction in the unix world, that started
On Mon, Nov 15, 2010 at 8:17 AM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 8:12 AM, erik quanstrom wrote:
>
>> > I've been thinking there might be a way for me to contribute to contrib
>> here
>> > with failure cleanup, once I get a good handle on how it all works.
>>
>> contrib/remove
For what it's worth, I installed equis via contrib/install about a
week ago and it worked. Slow, but everything installed and I was able
to use it.
-sl
> having very strange behavior of /tmp after a failed contrib/install.
sounds like magic. what is the behavior?
- erik
On Mon, Nov 15, 2010 at 8:12 AM, erik quanstrom wrote:
> > I've been thinking there might be a way for me to contribute to contrib
> here
> > with failure cleanup, once I get a good handle on how it all works.
>
> contrib/remove didn't work?
>
I did not try it.
Does it work on half-installed stuf
>% ls -lqd /n/dump/2006/0707/usr/rog
>(0003d540 1122 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 7 2005
>/n/dump/2005/0707/usr/rog
>% ls -lqd /n/dump/2006/0707/usr/rog
>(0003d540 1157 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 12 2006
>/n/dump/2006/0707/usr/rog
>they have the same qid but t
Dan makes a good point and I agree entirely with his sentiments. But I do
have a qualm: the Plan 9 designers managed to simplify cross-compilation
to a single underlying (OS) platform, but failed (in a suprisingly ugly
way) to cater for different target object formats, even though there were
effor
On Mon, Nov 15, 2010 at 8:15 AM, Stanley Lieber wrote:
> For what it's worth, I installed equis via contrib/install about a
> week ago and it worked. Slow, but everything installed and I was able
> to use it.
>
Thanks for that feedback. I'm having some issues with it not completing,
and now /tmp
> Thanks for that feedback. I'm having some issues with it not completing,
> and now /tmp says "clone failed" when I try to ls from a cwd of /tmp.
okay, either a process is in the Broken state, or
the file server serving /tmp has exited. you should
be able to get a lot of information with ps and
On Mon, Nov 15, 2010 at 8:24 AM, erik quanstrom wrote:
> > having very strange behavior of /tmp after a failed contrib/install.
>
> sounds like magic. what is the behavior?
>
>
getting "clone failed" when doing "ls" from a cwd of /tmp. I ended up just
firing up another ramfs to move on. It look
2010/11/15 C H Forsyth :
>>% ls -lqd /n/dump/2006/0707/usr/rog
>>(0003d540 1122 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 7 2005
>>/n/dump/2005/0707/usr/rog
>>% ls -lqd /n/dump/2006/0707/usr/rog
>>(0003d540 1157 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 12 2006
>>/n/dump/2006/0707/usr/ro
On Mon, Nov 15, 2010 at 8:27 AM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 8:24 AM, erik quanstrom wrote:
>
>> > having very strange behavior of /tmp after a failed contrib/install.
>>
>> sounds like magic. what is the behavior?
>>
>>
> getting "clone failed" when doing "ls" from a cwd
> > the qid values are actually different
>
> true, but qid.version doesn't help much.
what!? i'd hate to see a file server that didn't
much care which qid.version it had. those directories
you listed are different.
- erik
On Mon, Nov 15, 2010 at 8:20 AM, David Leimbach wrote:
> I just tried contrib/remove, lots of files were rm -f'd, and in the end,
> contrib/install says it's still installed.
Yep, that's not an unusual experience.
ron
On Mon, Nov 15, 2010 at 8:36 AM, David Leimbach wrote:
> Ah now we're failing again:
> error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist
> e
On 15 November 2010 16:48, erik quanstrom wrote:
>> > the qid values are actually different
>>
>> true, but qid.version doesn't help much.
>
> what!? i'd hate to see a file server that didn't
> much care which qid.version it had. those directories
> you listed are different.
if you mount onto o
I've managed to install plan9. Finally. It appears I misunderstood the
error message (messages actually - plural). The problem was that the
hard-drive image I created wasn't big enough. 1GB seems to be enough though.
However my troubles aren't over it seems, since as soon as I log in as
glenda the
> to a single underlying (OS) platform, but failed (in a
> suprisingly ugly
> way) to cater for different target object formats, even
> though there were
> efforts to do so. In my opinion - and this is all I
> hold against Plan
> 9 - by shoehorning various target object formats in the
> linker/loa
On Mon, Nov 15, 2010 at 11:22:52AM -0500, erik quanstrom wrote:
> > > How do you map it to a local identity?
> >
> > There's less need to, since most rights checks would be done using the key
> > directly, but eve's factotum also probably has a SPKI key, and your identity
> > can be stringified in
On Fri, Nov 12, 2010 at 3:41 PM, ron minnich wrote:
> On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen
> wrote:
>
>> Not really, the intent was that servers could implement a subset of
>> the .L features, and return Rerror for any that they don't.
>
> Wonderful! Floren is already fixing pla
> Even then, many vendor compilers and linkers have many
> non-conformances, and outright bugs. Take a look at the
> number of workarounds that make their way into gnulib to
> cover breakage in the POSIX APIs alone.
>
> You can either try to remember what all of those are, or
> use something like
On Mon, Nov 15, 2010 at 8:46 AM, ron minnich wrote:
> On Mon, Nov 15, 2010 at 8:36 AM, David Leimbach wrote:
>
> > Ah now we're failing again:
> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist
> > error:
You're way off about the merits of pipelining.
As far as parallel requests are concerned,
the 9P protocol beats HTTP hands down
(as does basically any other request
response protocol), because it has explicit
unique IDs on the requests and responses.
That allows a server to respond to two
requests
>> I just tried contrib/remove, lots of files were rm -f'd, and in the end,
>> contrib/install says it's still installed.
>
>Yep, that's not an unusual experience.
educated guess at the answer...
contrib/remove prints the commands to remove the package, it does
not actually do the removal, thats
> error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist
> error: copying /386/
On Mon, Nov 15, 2010 at 10:34 AM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 8:46 AM, ron minnich wrote:
>
>> On Mon, Nov 15, 2010 at 8:36 AM, David Leimbach
>> wrote:
>>
>> > Ah now we're failing again:
>> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
>> > erro
On Mon, Nov 15, 2010 at 10:47 AM, Steve Simon wrote:
> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist
> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist
> > error: copying /386/bin/X
That brings up a question of interest to me. How do you effectively
read ahead with the 9p protocol? Even if you issued many read
requests in parallel, the server is allowed to return less data than
was asked for. You'll end up with holes in your buffer that require
at least another roundtrip to
> if you mount onto one, you'll see the mounted files
> on the other.
>
> gorka was talking about identifying files from their qid.
> the version number doesn't help in identifying the file -
> someone could have modified the file 35 times between
> stats.
what definition of "file" are you using?
My personal disappointment with autoconf, is that there was no simple
file which the package author writes (or even autgenerates)
describing what features their package depends on.
There is a file, but its anything but simple and as it (ab)uses m4
and shell script macros that it "knows" exist. It
On 15 November 2010 19:29, erik quanstrom wrote:
>> if you mount onto one, you'll see the mounted files
>> on the other.
>>
>> gorka was talking about identifying files from their qid.
>> the version number doesn't help in identifying the file -
>> someone could have modified the file 35 times bet
> error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist
> error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist
> error: copying /386/
On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote:
> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist
> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist
> > error: copying /386/bin/X11/x
> That brings up a question of interest to me. How do you effectively
> read ahead with the 9p protocol? Even if you issued many read
> requests in parallel, the server is allowed to return less data than
> was asked for. You'll end up with holes in your buffer that require
> at least another ro
> The option is to make servers obey R order for Ts with same tag - just
> as Russ (right?) proposed elsewhere on the list.
no. tags have no order and clients are specificly disallowed
from having multiple messages with the same tag outstanding.
again, see intro(5).
the option is to issue many T
also it shouldn't take that long... if you have the latest contrib
tools what happens
it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from there.
of course that iso.bz2 is 22 MB, but that's not contrib's fault
On Mon, Nov 15, 2010 at 8:33 PM, Federico G. Benavento
wrote:
> the
On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento
wrote:
> also it shouldn't take that long... if you have the latest contrib
> tools what happens
> it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from
> there.
>
> of course that iso.bz2 is 22 MB, but that's not contrib's f
On Mon, Nov 15, 2010 at 3:42 PM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento <
> benave...@gmail.com> wrote:
>
>> also it shouldn't take that long... if you have the latest contrib
>> tools what happens
>> it's this: it first fcp's an iso.bz2 to your /tmp an
the easiest way to reinstall is
% contrib/install -f usr/pkg
On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote:
>>
>> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist
>> > error: copying /386/bin/X11/twm: '/n/dist/3
On Mon, Nov 15, 2010 at 3:45 PM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 3:42 PM, David Leimbach wrote:
>
>>
>>
>> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento <
>> benave...@gmail.com> wrote:
>>
>>> also it shouldn't take that long... if you have the latest contrib
>>> too
nope, the log is the problem, but anyways, ignore those errors, the installation
worked just fine.
I'll try to remove them, so it doesn't confuse anyone
On Mon, Nov 15, 2010 at 8:56 PM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 3:45 PM, David Leimbach wrote:
>>
>>
>> On Mon, Nov 15, 2
On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento
wrote:
> also it shouldn't take that long... if you have the latest contrib
> tools what happens
> it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from there.
>
neat. That's a good step. 9pm won't use replica but at the sa
> > i claim that a fs with this behavior would be broken. intro(5)
> > seems to agree with this claim, unless i'm misreading.
>
> you're right - fossil is broken in this respect, as is exportfs
> {cd /mnt/term/dev; ls -lq | sort} for a quick demo.
so what's fossil's excuse?
- erik
> I always had the impression that the object formats
> used by the various ?l are more for kernels and the
> various formats expected by loaders than for userland
> apps. For userland, I would think the intent is for
> there to be a single consistent object format (at least
> for a given architec
Regarding the "deadlock" report that I occasionally see on my CPU
server console, I won't bore anyone with PC addresses or anything like
that, but I will recommend something I believe to be a possible
trigger: the failure always seems to occur within "exportfs", which in
this case is used exclusive
On Mon Nov 15 23:23:12 EST 2010, lu...@proxima.alt.za wrote:
> Regarding the "deadlock" report that I occasionally see on my CPU
> server console, I won't bore anyone with PC addresses or anything like
> that, but I will recommend something I believe to be a possible
> trigger: the failure always s
On Mon, Nov 15, 2010 at 4:59 PM, ron minnich wrote:
> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento
> wrote:
> > also it shouldn't take that long... if you have the latest contrib
> > tools what happens
> > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from
> there.
> Of course, the ideal situation would be for Go and p9p to converge and
> the whole lot to be back ported to Plan 9.
if you just want go on plan 9, i think object formats
are a non-sequitor.
calling out the guys who wrote plan 9 for not supporting
object formats that plan 9 never used, seems a b
ok, dillo is a linux binary, right? and it looks like is looking for
a unix socket,
but equis has APE sockets!
so for dillo try tcp DISPLAY=127.0.0.1:0
On Tue, Nov 16, 2010 at 1:47 AM, David Leimbach wrote:
>
>
> On Mon, Nov 15, 2010 at 4:59 PM, ron minnich wrote:
>>
>> On Mon, Nov 15, 2010 at
btw, there are no lbuns for firefox and such, but it works, opera does too
On Tue, Nov 16, 2010 at 1:57 AM, Federico G. Benavento
wrote:
> ok, dillo is a linux binary, right? and it looks like is looking for
> a unix socket,
> but equis has APE sockets!
> so for dillo try tcp DISPLAY=127.0.0.1:0
> i assume you've fixed this? (not yet fixed on sources.)
Yes, before I did that the errors occurred much more frequently;
there's definitely something in that, but as Russ points out, the fix
prevents panics and I have yet to see a panic.
I have a suspicion that we're looking at the wrong probl
On Mon, Nov 15, 2010 at 8:57 PM, Federico G. Benavento
wrote:
> ok, dillo is a linux binary, right? and it looks like is looking for
> a unix socket,
> but equis has APE sockets!
> so for dillo try tcp DISPLAY=127.0.0.1:0
I did try that, thinking that could have been the problem. It didn't wor
> if you just want go on plan 9, i think object formats
> are a non-sequitor.
>
But that's not it, really, I want both Go and the ELF capabilities :-)
> calling out the guys who wrote plan 9 for not supporting
> object formats that plan 9 never used, seems a bit rude
> to me.
I am willing to apo
the pc's printed by the lock loop message are kernel code. you
have to load a debug kernel into acid.
--
cinap
--- Begin Message ---
> i assume you've fixed this? (not yet fixed on sources.)
Yes, before I did that the errors occurred much more frequently;
there's definitely something in that, bu
> the pc's printed by the lock loop message are kernel code. you
> have to load a debug kernel into acid.
Thanks, I'll do some digging in the Acid document(s), try to
familiarise myself with the details...
++L
there is a very old version of linuxemu in that lbun... the current
one supports ape unix domain sockets (even server side). it might be
possible to repack the lbun with a current version, but i can't
remember the details.
--
cinap
--- Begin Message ---
On Mon, Nov 15, 2010 at 8:57 PM, Federico
you almost had it with your acid approach :)
if your kernel image is uncompressed and is unstriped, you can
just load it with acid:
acid /386/9pc
if you build it yourself, then there should be such a kernel in /sys/src/9/pc
--
cinap
--- Begin Message ---
> the pc's printed by the lock loop mess
On Tue, Nov 16, 2010 at 06:28:07AM +0100, cinap_len...@gmx.de wrote:
>
> if your kernel image is uncompressed and is unstriped, you can
> just load it with acid:
>
> acid /386/9pc
>
> if you build it yourself, then there should be such a kernel in /sys/src/9/pc
>
OK, will try this evening, I sp
75 matches
Mail list logo
