On Wed, Nov 19, 2008 at 7:36 PM, Francisco J Ballesteros [EMAIL PROTECTED]
wrote:
BTW, I´d love to hear other experiences regarding ns or path reconstruction.
i wrote a reverse path evaluator (ftrans) for inferno - given a path,
it uses fd2path and /prog/xx/ns to attempt to return the
On Fri, Nov 14, 2008 at 12:52 AM, Roman Shaposhnik [EMAIL PROTECTED] wrote:
On Nov 13, 2008, at 8:37 AM, Dan Cross wrote:
[...]
But along the very same line of thought -- wouldn't it also then be
much more reasonable to stick with an alternative aname
approach when adopting 9P for symlinks,
The dos(1) command I wrote (in the style of cpu(1) but attaches to Windows
boxen)
uses a configuration file describing how the windows directories are
mounted (using cifs(1)) on plan9. It also reads /proc/$pid/namespace to
learn of any additional mounts so it can reliable translate plan9 paths
to
On Thu, Nov 20, 2008 at 12:59 PM, Steve Simon [EMAIL PROTECTED] wrote:
The dos(1) command I wrote (in the style of cpu(1) but attaches to Windows
boxen)
uses a configuration file describing how the windows directories are
mounted (using cifs(1)) on plan9. It also reads /proc/$pid/namespace to
On Wed, Nov 19, 2008 at 7:35 PM, Pietro Gagliardi [EMAIL PROTECTED] wrote:
Take a look at this:
http://www.blazebyte.org/gnextop/
It runs a complete Linux system in a web browser, so users of the
PlayStation Portable can finally write software for it without fear of being
bricked by Sony's
We had a prototype that tried to reproduce in a web page
the UI structure as described by o/mero.
Nothing that really could be used in practice.
In the end we abandoned that and used inferno for
the client software (terminal).
It's funny the post about using Sepxs to transfer
FS trees, because
On Thu, Nov 20, 2008 at 8:37 AM, Fco. J. Ballesteros [EMAIL PROTECTED] wrote:
We had a prototype that tried to reproduce in a web page
the UI structure as described by o/mero.
Nothing that really could be used in practice.
In the end we abandoned that and used inferno for
the client software
It was a disaster.
Just an adhoc script to reproduce the structure from the file
tree in omero in the browser.
In any case, I'm not sure where the source might be. I'll take
a look and drop you a line if I find it out.
On Thu, Nov 20, 2008 at 4:16 PM, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
2008/11/19 Nolan Hamilton [EMAIL PROTECTED]
Can people still use Alef?, if so how can I get my hands on it.
People use Limbo.
--
С Уважением
Жилкин Сергей
or, perhaps more accurately, ex-post-facto
page sharing.
http://lwn.net/Articles/306704
freaky.
- erik
I'm completely new to Functional Languages (actually I'm not understanding
whether they are useful in real world, or just to enance ones mind).
But I'm studing Haskell, and I saw that it was ported to Plan 9.
Without starting a flame war, I'd like to know if some of you think it could
be useful
On my opinion, those big languages (haskell, erlang, lisp, etc.)
don't fit to Plan9 or any other os/environment, because they usually
provide their own.
On Thu, Nov 20, 2008 at 9:56 PM, Giacomo Tesio [EMAIL PROTECTED] wrote:
I'm completely new to Functional Languages (actually I'm not
gmail just changed their interface more into the direction of rio acme.
The search function with the rigth button do not function ;-)
gmail just changed their interface more into the direction of rio acme.
--
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)
Rob?
On Thu, Nov 20, 2008 at 10:14 PM, hiro [EMAIL PROTECTED] wrote:
gmail just changed their interface more into the direction of rio acme.
--
Roma
Without starting a flame war, I'd like to know if some of you think it could
be useful on a Plan 9 grid/environment.
I've often though quite a few languages could be shrunken down fit with
Plan9's diretory/files system. Python, for instance, would need much
less code for networking
This is why I've been trying to stay out of it.
So how to think about it? First, it's *not* NAT, because
there's no address translation going on.
I know. I understood this after the discussions of the past few days.
Yet you're still contending the following:
What I pointed out to
Hi 9fans --
I'm just about ready to take the plunge (again) into Plan 9 for file
serving in my home network, partly because fossil seems like a
superior file system for lots of reads, rare writes, and cheap disks
(mp3 jukebox), and partly because I've had a quasi-mystical
fascination with Plan 9
I have a laptop wit a fossil partion which is not backed by
venti. Yesterday I scrambled my display and had to reboot
without shutting things down nicely. That fossil was not
my root, but I believe it was running, with main open.
Today, running 'fossil/fossil -f /dev/sdC0/fossil' gives:
I'm just about ready to take the plunge (again) into Plan 9 for file
Welcome to the pool. The water's great.
started to get the impression that Inferno is perhaps a better way to
go for a newbie like me to the whole rio/acme/fossil Way. Is this
mistaken?
For rio/acme/fossil, you do want to
Inferno (and Limbo) has its own mailing list. Talk on those topics
isn't particularly discouraged here, as there's obviously lots of
overlap in both ideas and community, but it mostly lives on
elsewhere.
They're conceptually very similar, and share much of their
implementation. There are
While debunking these statements has been somewhat efficient thus far,
I think something has not been explicitly addressed --
The boasted transparency of Plan 9 is a product of bringing most
(or really all?) functions, including networking, into a single
framework. That single framework
On Thu, Nov 20, 2008 at 5:56 PM, Giacomo Tesio [EMAIL PROTECTED] wrote:
I'm completely new to Functional Languages (actually I'm not understanding
whether they are useful in real world, or just to enance ones mind).
But I'm studing Haskell, and I saw that it was ported to Plan 9.
Without
On Thu, 2008-11-20 at 17:55 +, Brian L. Stuart wrote:
That's partly because there's a separate Inferno list. And
you're right that they're not the same, but are closely
related. The original Inferno kernel was based on (and
used code from, I think) the Plan 9 kernel that was current
at
The /net FS is directly an application of 9P, and to add further
functionality, such as packet analysis (which seems to be the new hot
topic now), is only to go so far as to change the /net application
this is nitpicking, i apologize
but /net is not a fs. '#I' the ip stack and '#l' the
I've toyed with the idea of a webtop interface to Inferno (that I
suppose could easily have a similar implementation on Plan 9):
http://graverobbers.blogspot.com/2008/04/service-oriented-file-systems.html
I'm sure the Plan B/Octopus guys have some thoughts here as well.
we're
just to be clear, i think webtop or web based approach is a backward
step (or at least a side step). the whole point of plan9 is to
represent everything as a namespace; in rangboom it means representing
distant filesystems in the native form, hence use of windows IFS and
FUSE for Linux and Mac.
but /net is not a fs. '#I' the ip stack and '#l' the ethernet device
are usually bound in union on /net. ip subsumes its subprotocols and
arp. there is nothing preventing one from adding a new networking
protocol nor is there anything preventing one from adding a new type
of networking
On Thu, Nov 20, 2008 at 8:40 PM, David Leimbach [EMAIL PROTECTED] wrote:
On Thu, Nov 20, 2008 at 9:14 AM, hiro [EMAIL PROTECTED] wrote:
gmail just changed their interface more into the direction of rio acme.
In what way?
I've attached a screen-shot. It's only the look, they didn't switch
So now [9p]'s almost the same as Styx, except for
the Inferno authentication.
I think a more precise way of saying it is that in 9p2000 and
the new styx, authentication has been moved outside the
protocol proper. styx==9p now; the names are used by
convention to imply the auth method, if any.
I've often though quite a few languages could be shrunken down fit with
Plan9's diretory/files system. Python, for instance, would need much less
code for networking etc.
So a language that specialsed in I/O primitives would be a good choice. That
doesn't sound like Haskell to me. I/O is
I think a more precise way of saying it is that in 9p2000 and
the new styx, authentication has been moved outside the
protocol proper. styx==9p now; the names are used by
convention to imply the auth method, if any.
You're right. I stand corrected. For some reason I
had thought that the
Yet you're still contending the following:
What I pointed out to Anant Narayanan was that his proposed _new_
capability which involved _packet analysis_ would _have to_ operate on
network layer data units, ergo, NAT again.
Packet analysis == Network layer operations ~= NAT
That's not
yes, it's in nils contrib (noselasd)
On Thu, Nov 20, 2008 at 6:47 PM, John Barham [EMAIL PROTECTED] wrote:
I've often though quite a few languages could be shrunken down fit with
Plan9's diretory/files system. Python, for instance, would need much less
code for networking etc.
So a language
cgifs: mostly done thanks to fgb. i'll put it up soon.
rit: already available thanks to kenji
filterfs: sythesize a filesystem from other fs and rc filters. could use
exportfs as a start. design in mind, no code yet. at one
point ehg mentioned such a thing at Labs.
sessionfs:
i was expecting kenc to complain about the
a 0 test, which can never be true.
int
fetchicmp(Fetchi *f1, Fetchi *f2)
{
uvlong a, b;
a = f1-uid;
b = f2-uid;
a -= b;
if(a 0)
return 1;
if(a 0)
return -1;
That is, the concept of 9P and filesystesms thereof, is an idea of
`networking' in a very general sense
In what very general sense? File servers and 9P seem to me to be mostly
ideas about abstracting a computing platform's functionality, aka
resources--I'm thinking udev or Windows HAL.
The
doppio% 8c -w cm.c
warning: cm.c:14 useless or misleading comparison: UVLONG 0
doppio% qc -w cm.c
warning: cm.c:14 useless or misleading comparison: UVLONG 0
doppio% 5c -w cm.c
warning: cm.c:14 useless or misleading comparison: UVLONG 0---BeginMessage---
i was expecting kenc to complain about
Thanks heaps for your responses. Plan 9 it is then. Expect a lot of
really irritating questions over the next few weeks. :)
On Thu, Nov 20, 2008 at 3:05 PM, Brian L. Stuart [EMAIL PROTECTED] wrote:
I think a more precise way of saying it is that in 9p2000 and
the new styx, authentication has
- provide access to relational database towards a dedicated fs (with XML
rappresentation of query results, but dont know yet about data manipulation
and error handling)
an rdbms interface will be messy; maybe just try to get a ODBC client
library. most of the time what is really
in my contrib there is a more up-to-date lua port
On Thu, Nov 20, 2008 at 8:13 PM, Federico G. Benavento
[EMAIL PROTECTED] wrote:
yes, it's in nils contrib (noselasd)
On Thu, Nov 20, 2008 at 6:47 PM, John Barham [EMAIL PROTECTED] wrote:
I've often though quite a few languages could be
On Thu, Nov 20, 2008 at 2:54 PM, Tod Beardsley [EMAIL PROTECTED]wrote:
Thanks heaps for your responses. Plan 9 it is then. Expect a lot of
really irritating questions over the next few weeks. :)
Often times, googling to find the answer to irritating questions can keep
repetitive traffic
On Thu, Nov 20, 2008 at 11:42 AM, Iruata Souza [EMAIL PROTECTED] wrote:
On Thu, Nov 20, 2008 at 3:23 PM, matt [EMAIL PROTECTED] wrote:
Without starting a flame war, I'd like to know if some of you think it
could
be useful on a Plan 9 grid/environment.
I've often though quite a
hey, 9P is all text [...]
wrong.
Upon reading this:
Each message consists of a sequence of bytes. Two–, four–, and
eight–byte fields hold unsigned integers represented in little–endian
order (least significant byte first). Data items of larger or variable
lengths are represented by a
On Thu Nov 20 19:21:51 EST 2008, [EMAIL PROTECTED] wrote:
this correction: 9P is _not_ all text, but it consists of a well-defined
set of messages. The idea, anyway, is the same.
wrong. binary would be the opposite of text.
That's wrong (or maybe I'm wrong). Whatever network glue /net
it's a good day to be Broken.
i haven't figured this one out yet. i have a snap available.
- erik
acid: stk()
abort()+0x0 /sys/src/libc/9sys/abort.c:6
error(s=0x42413)+0x33 /sys/src/cmd/acme/util.c:55
texttype(t=0x7b300,r=0x2d)+0xb5 /sys/src/cmd/acme/text.c:719
I think that with a bit more work, porting the Ocaml native compiler
to Plan 9 would give you a bigger benefit than GHC (which is unwieldy)
or an interpreter such as Hugs. Having a higher-level language in
which to write native applications will, perhaps, give more people a
viable reason to
On 11/21/08, David Leimbach [EMAIL PROTECTED] wrote:
On Thu, Nov 20, 2008 at 11:42 AM, Iruata Souza [EMAIL PROTECTED] wrote:
On Thu, Nov 20, 2008 at 3:23 PM, matt [EMAIL PROTECTED] wrote:
Without starting a flame war, I'd like to know if some of you think it
could
be useful on a Plan
fyi, here's the rc version of 'save' that uses cgifs:
#!/bin/rc
. /lib/cgifs/sandbox
May I humbly submit that the above is inadequate? I risk sounding
like a serious newbie, but I believe that perhaps 9fans is too broad a
vehicle to do Plan 9 justice. In this case, Skip's posting is
Hello all, firstly let me mention that I'm pretty stoked about using
Plan 9. I've been using it for about a week now, and things are coming
along well.
I'm having a bit of an issue, and it may entirely stem from my lack of
familiarity on the system, so I apologize in advance if this turns out
to
I did have copious amounts of mail in this box, somewhere
in the neighborhood of 3500.
Whenever I allow my IMAP mailbox to grow too large, upas also grinds
to a halt. I haven't yet done justice to Erik Quanstrom's nupas to
see if it makes a difference because it is too big a leap at this
point
Be warned that it is different in the way it represents the folder, so
the end results may be quite dramatic.
? the file system interface is not changed.
- erik
52 matches
Mail list logo
