wrong. binary would be the opposite of text.
Now I'm becoming convinced you are trying to infuriate me. That 9P is
actually binary is a _fact_, which you presented to me, thank you, okay?
But, the _idea_, which existed in the posting you had quoted, remained and
remains the same
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,
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
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
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
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
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
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
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
Oops! Hopefully as list moderator you will accept my apologies
for having drawn out a discussion beyond its useful time!!
You have misread my tone--it was suggestive, not assertive. Note that it
was I who raised a question, and then it was I who felt the question was
(more than) adequately
Thanks a lot, Nathaniel Filardo. Your clean and detailed explanation is
very much appreciated. Although, Micah Stetson did post a similar, albeit
far more concise, explanation before.
Despite the impression I seem to have made, I understand--as of a few days
ago, at least--why a Plan 9
Nevertheless, the same machinations that allow for transparency in
Plan 9 disallow certain functions that can be naturally provided by
a NAT implementation, or any of a number of software categories that
involve packet filtering/rewriting/inspection. For example, the one
I referred to in
I wouldn't go so far as to say Plan 9 disallows certain functions that
are implicit in NAT. As someone mentioned in the thread before, it is
certainly possible and rather easy to write something similar to
trampoline(8) to perform load balancing. Add in packet analysis to the
mix and you have
Now, suppose IC goes to listen on TCP:80, by opening /net.alt/tcp/clone.
The same flow of events happen, and to a certain extent, G's network stack
thinks that the exportfs program (running on G) is listening on TCP:80.
exportfs dutifully copies the /net data back to its client.
great post.
Perhaps my choice of wording wasn't exactly correct. Make it does not
function in this capacity unless modified. But there's a missed point: add
in packet analysis and you're doing NAT. The boasted transparency of Plan 9
is a product of bringing most (or really all?) functions, including
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.
What I pointed out to Anant Narayanan was that his proposed _new_
capability which involved _packet analysis_ would _have
On Sun, Nov 16, 2008 at 09:24:19PM +, Eris Discordia wrote:
That isn't happening. All we have is one TCP connection and one small
program exporting file service.
I see. But then, is it the small program exporting file service that
does the multiplexing? I mean, if two machines import a
This explanation isn't immediately comprehensible to me--I guess I'll have
to read the man pages and some other documentation and then come back to
understand this.
Thanks anyway.
--On Sunday, November 16, 2008 4:52 PM -0500 erik quanstrom
[EMAIL PROTECTED] wrote:
the same time. I thought
It was a pleasure and quite educational to read your posting, Micah Stetson.
The Plan 9 kernel doesn't do load balancing like that. (Why should
it?) To do it in Plan 9, you'd write a small program that listened on
a particular address and multiplexed connections to a list of other
addresses.
Every sensible NAT solution must be implemented with that in
mind--not that existing ones have been. Even imagining persistent
connections from an entire Class A network makes one shudder.
Needless to say, the wreak of havoc occurs _long_ before over 16
million hosts need persistent
Are there any NAT solutions which handle millions of hosts? Are
we having a discussion about unicorns?
No. Which is why not that existing ones have been. And wreak of havoc
occurs _long_ before refers to the hypothetical gateway being brought down
with far fewer connections, irrespective of
I believe your are a little late with your remark. The issue
has been resolved.
Oops! Hopefully as list moderator you will accept my apologies
for having drawn out a discussion beyond its useful time!!
Dave Eckhardt
If there were no real routers and the world still used bang paths you
wouldn't be thinking about overlay networks the way you do. Does your
thinking fall under the same category of fallacy?
By the way, I think you have missed the meaning of raison d'etre. There is
a necessity, a problem,
aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22
This is absolutely interesting. Upon reading trampoline(8) it seemed to me
that port forwarding, or rather the more general case of _traffic_
forwarding, is being implemented outside of any NAT. And in this case you
don't have an
Eris, are you telling, that plan9 is not suited to all the problems of
all badly designed and bloated software? Oh goddess, that's horrible.
What is this thing you're searching for? Have you tried it with XML?
NAT's raison d'etre is that IP is broken, NAT doesn't completely solve
this problem, and creates a whole new set of problems that will
plague the world until a new version of IP can be deployed (which
interestingly enough, is made much more complicated by the prevalence
of NAT itself).
In the
On Sun, Nov 16, 2008 at 8:39 PM, Eris Discordia
[EMAIL PROTECTED] wrote:
aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22
And in this case you
don't have an imported /net and the fabled transparency.
Obviously, a linux server is going to have a hard time importing /net
(in a useful
Eris, are you telling, that plan9 is not suited to all the problems of
all badly designed and bloated software? Oh goddess, that's horrible.
What is this thing you're searching for? Have you tried it with XML?
Yes and no. The badly designed and bloated software is in large part a
relic of Bell
[...] NAT's raison d'etre is that IP is broken [...]
That's very far from truth. In this case IP's only fault is lack of
exceptional foresight. Who'd think someday every kids' toy would claim a
network address?
As for NAT, you know very well it has uses entirely unrelated to IP's
Obviously, a linux server is going to have a hard time importing /net
(in a useful way, at least until Glendix gets there).
Of course, which means dependence of network layer operations on an
application layer protocol in a heterogeneous--you aren't plan9ing to take
over the world, are
And what is the IP world? Aren't you part of it? Does your network use a
different transport/network layer protocol than TCP/IP? IL is dead--just in
case you were thinking of it--because to re-invent the wheel was eventually
perceived redundant.
yes. several. il/ip being one of them.
I have no reason to believe Bell Labs' not-so-current
experimentation is any more saintly and free of blemish than the
previous. In time somebody will come up with the Plan 9 Haters Handbook.
Surely, there has been enough traffic here to emphasise that Plan 9
contains some good, fresh ideas
On Sun, Nov 16, 2008 at 9:17 AM, erik quanstrom [EMAIL PROTECTED] wrote:
i think it is a bit easier. the plan 9 kernel is simplier.
but that's beside the point. plan 9 network does more
with less than bsd. /net is more expressive than sockets.
the dial interface is quite elegant. plan 9
the trite not reinventing the wheel is countered with
the equally trite use the right tool for the job. both
avoid the point of carefully evaluating the engineering
problem.
Deprecating IL must have had engineering reasons. Among them, I guess, that
in the course of time and as applications
Finally, one very remarkable remark sighs deeply.
Ron Minnich clarifies what _is_ indeed the advantage of Plan 9. I hope
those who have followed this thread so far at last see what I was driving
at. The edge of Plan 9 was never in kernel space but in user space.
To put it in the abstract
I think Eris is saying that this makes Plan
9's resource requirements grow with the number of hosts behind the
gateway -- not just with the number of connections through it like
Linux.
I don't quite follow. If by resources you mean process related resources
than I would agree. My very first
That isn't happening. All we have is one TCP connection and one small
program exporting file service.
I see. But then, is it the small program exporting file service that does
the multiplexing? I mean, if two machines import a gateway's /net and both
run HTTP servers binding to and
Exactly! An idle TCP connection costs you nothing except the state that
Would you mind reading my response, too, and then informing me of your
opinion?
Not only that, but if you look at the amount of state something like
iptables on Linux needs to keep in order to provide NAT capabilities
Also, neither you nor anyone else have addressed the question of port
forwarding using an imported /net. Now I'm curious: do any of you 9fans have
an internal network behind a gateway that runs Plan 9? In case you do, I'll
be grateful if read about the configuration of your network(s).
May
hello
if the point of port forward is to access a service behind a firewall
you can do something like:
inside% import outside /net /net
inside% start_service
and the servide will listen on the /net of the outside machine.
that's just a simple example.
slds.
gabi
El 15/11/20
Also,
I think if plan9 was the real standard /net, ip, dns and of course nat
would not matter at all.
Imagine i.e. bind '#wan' for putting the world in your namespace. The
device would take care of the communication to the next node and you
would not even have to mind which protocol to use.
Your
On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote:
Exactly! An idle TCP connection costs you nothing except the state
that
Would you mind reading my response, too, and then informing me of
your opinion?
It would be helpful if you can quote exactly the part on which you are
requesting
I'm unclear as to what amount of state iptables needs to keep
After you do something like:
# iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE
the Linux kernel module called nf_conntrack starts allocating
data structures to do its job. I'll leave it up to you to see how much
memory
as usual, plan9 lets you combine simple commands to provide all sorts
of interesting functionality. on my plan9 gateway i often have to do
something like:
aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22
there you have it, port forwarding without the need to reset all your
connections
On Sat, Nov 15, 2008 at 2:29 AM, Eris Discordia
[EMAIL PROTECTED] wrote:
I don't see how port forwarding is possible at all with an
imported /net.
Because your mind is set - as far as you're concerned, NAT is how things work.
With /net, the concept doesn't exist. The http server just imports
On Sat, Nov 15, 2008 at 9:21 AM, Eris Discordia
[EMAIL PROTECTED] wrote:
Also, neither you nor anyone else have addressed the question of port
forwarding using an imported /net.
I love science.
iru
On Nov 15, 2008, at 2:07 PM, Eris Discordia wrote:
What field?
Out of the field := clueless
I believe our conversation stops right here. Should you
ever consider restarting it -- a simple apology for
being an asshole would do the trick.
Thanks,
Roman.
On Nov 15, 2008, at 2:13 PM, Micah Stetson wrote:
I'm unclear as to what amount of state iptables needs to keep
After you do something like:
# iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE
the Linux kernel module called nf_conntrack starts allocating
data structures to do its job.
I believe our conversation stops right here. Should you
ever consider restarting it -- a simple apology for
being an asshole would do the trick.
If you look at the context you'll see this wasn't an insult at all: I wrote
out of the field with respect to [something]. That means you seem to now
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, FIFOs and the
rest of the POSIX paraphernalia?
I'a not the one who has to implement it so my opinion is
nothing more than that,
On Thu, Nov 13, 2008 at 11:52 PM, Roman Shaposhnik [EMAIL PROTECTED] 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, FIFOs and the
rest of the POSIX paraphernalia?
You
The information is very much appreciated here, Erik Quanstrom.
so in plan 9, it's possible to know the device providing the file
(try ls -l /dev), [...]
From this I gather the client-side caching problem sqweek pointed out can
be easily addressed. Caching or no caching can be decided by the
Hiding the details of the underlying resources is one of the
functions/features of the OS, isn't it?
Bjarne Stroustrup likes to call that data abstraction and encapsulation;
in a different context. But the essence of it is the same. Operational
details have to be hidden, functional ones not.
Hiding the details of the underlying resources is one of the
functions/features of the OS, isn't it?
Bjarne Stroustrup likes to call that data abstraction and encapsulation;
in a different context. But the essence of it is the same. Operational
details have to be hidden, functional ones
Welcome, but don't mistake me for someone having the background and
experience with plan 9 to comment with any sort of authority.
I won't ;-)
I'm not sure there's as much difference as you make out to be.
There is a huge difference. Almost as much difference there is between NAT
and
On Fri, Nov 14, 2008 at 12:29 PM, Eris Discordia
[EMAIL PROTECTED] wrote:
What makes /net tick depends on what you export on /net. The kernel
serves your basic /net, yes, but there's nothing to stop you having a
userspace file server on top of that to do whatever filtering you
like.
That
That would break the protocol stack. 9P is an application layer protocol (or
so I understand). It should _never_ see, or worse rewrite, network layer
data units. If by a fileserver on top of that you actually mean a file
server under that then you simply are re-inventing NAT.
Putting a file
On Nov 13, 2008, at 8:55 AM, sqweek wrote:
I understand that if you import a gateway's /net on each computer
in a
rather large internal network you will be consuming a huge amount
of mostly
redundant resources on the gateway. My impression is that each
imported
instance of /net requires a
Hola,
Hiding the details of the underlying resources is one of the functions/features
of the OS, isn't it?
slds.
gabi
-- [EMAIL PROTECTED] wrote:
you of course know that the big difference in unix and other
systems of the day was that files did not have type. this allowed
a tools-based
On Thu, Nov 13, 2008 at 12:17 PM, erik quanstrom [EMAIL PROTECTED] wrote:
Not that type of types. I gave an example (which Charles Forsyth found to
be a bad one) to set the types of types apart. I mean types as in named
pipes (special files) versus regular files. In my experience which is
On Wed, Nov 12, 2008 at 10:23 PM, Eris Discordia
[EMAIL PROTECTED] wrote:
First off, thank you so much, sqweek. When someone on 9fans tries to put
things in terms of basic abstract ideas instead of technical ones I really
appreciate it--I actually learn something.
Welcome, but don't mistake
On Nov 13, 2008, at 8:37 AM, Dan Cross wrote:
On Wed, Nov 12, 2008 at 2:13 PM, [EMAIL PROTECTED] wrote:
stat(5) specifies exclusive-access files, which we do use for
locking.
In what sense is that not `doing locking'? It's not POSIX byte-range
read- or write-locking per fcntl, but it's not
NFS4 still assumes that a file handle can be used to
find a file; neither the persistent nor the volatile
variants are directly comparable to a Qid and both can
complicate implementation. (at least a volatile file handle
allows a file system implementation not based on inodes to be
done more
On Tue, Nov 11, 2008 at 9:51 PM, Roman Shaposhnik [EMAIL PROTECTED] wrote:
On Nov 11, 2008, at 6:11 PM, sqweek wrote:
On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen [EMAIL PROTECTED]
wrote:
I have two measurements of success:
a) what keeps me working on Plan 9 related technologies in
First off, thank you so much, sqweek. When someone on 9fans tries to put
things in terms of basic abstract ideas instead of technical ones I really
appreciate it--I actually learn something. By the way, it is very
interesting how a technical question can be sublimated into a
Gedankenexperiment
On Tue, Nov 11, 2008 at 9:20 PM, Roman Shaposhnik [EMAIL PROTECTED] wrote:
On Nov 11, 2008, at 8:58 PM, ron minnich wrote:
They're utterly different, at every level. Yes, they give you a
similar service, but ...
Whoa! That's a pretty strong claim. Care to substantiate?
The way I see it: if
stat(5) specifies exclusive-access files, which we do use for locking.
In what sense is that not `doing locking'? It's not POSIX byte-range
read- or write-locking per fcntl, but it's not clear to me how often
that's actually useful. In quite a few situations, having a single
process directly
On Wed, Nov 12, 2008 at 11:00 AM, Uriel [EMAIL PROTECTED] wrote:
That's just a taste. They're really very very different.
May Glenda bless the IBM-induced standard wisdom.
So the IBM standard wisdom is that NFS and 9p are really very very
different (actually that was my quote)?
But yes, the
On Wed, Nov 12, 2008 at 1:00 PM, Uriel [EMAIL PROTECTED] wrote:
9P doesn't do locking; .u/.l change the protocol.
yes. (well mostly yes - Geoff points out there are some locking
semantics in 9P, more correctly 9P doesn't do POSIX locking, .L
changes the protocol (.u doesn't make any
It's not POSIX byte-range
read- or write-locking per fcntl, but it's not clear to me how often
that's actually useful.
they aren't. i wrote a paper about it many years ago, when helping to implement
a database system. in short, you can't rely on them for either scale or
properties,
so in any
That explains why IBM's MVS didn't have locking at all. One would
conclude from that fact that locking isn't required to do even serious
business applications.
Brantley
On Nov 12, 2008, at 2:58 PM, Charles Forsyth wrote:
It's not POSIX byte-range
read- or write-locking per fcntl, but
If I understood erik correctly, .L will even add auth into the
protocol... I guess that only leaves us missing sunrpc for 9P to match
NFS4's beauty.
i said nothing about .l. perhaps eric did.
- erik
On Wed, 2008-11-12 at 09:47 -0800, ron minnich wrote:
The way I see it: if you look past stalessness (taken care of
in WebNFS and NFS4) eagerness to do proper caching and
on-the-wire messages there are, actually, quite a few similarities
between the two:
FH is a moral equivalent of a
On Wed, Nov 12, 2008 at 6:47 PM, ron minnich [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 9:20 PM, Roman Shaposhnik [EMAIL PROTECTED] wrote:
On Nov 11, 2008, at 8:58 PM, ron minnich wrote:
They're utterly different, at every level. Yes, they give you a
similar service, but ...
Whoa!
On Wed, Nov 12, 2008 at 8:55 PM, Brantley Coile [EMAIL PROTECTED] wrote:
That explains why IBM's MVS didn't have locking at all. One would conclude
from that fact that locking isn't required to do even serious business
applications.
I don't follow your reasoning.
Saying fcntl locking is not
yuck, i give up. this thread is nearly longer than the kernel. i'm off
to find an island without electricity. i can do without beer.
brucee
You shouldn't need to be starved of electricity in order to get away
from the thread.
---BeginMessage---
yuck, i give up. this thread is nearly longer than the kernel. i'm off
to find an island without electricity. i can do without beer.
brucee
---End Message---
For this we use local Infernos at machines serving resources,
using a dav server to provide the built name space to the native host systems.
Not for devices, but works for most other things.
Devices can be done by adapting their interfaces via wrapper FSs.
Ok, here's a stab at describing my
I must have missed something. what dav server?
hiro
On Tue, Nov 11, 2008 at 9:45 AM, Fco. J. Ballesteros [EMAIL PROTECTED] wrote:
For this we use local Infernos at machines serving resources,
using a dav server to provide the built name space to the native host systems.
Not for devices, but
This approach seems to be flawed on two accounts:
1. it forces the server to resolve symlinks and special
nodes, without an option for the client to do the same.
That prevents cross-tree symlinks and nodes as the
points of rendezvous *on the client*. IOW, the following
will
On Tue, Nov 11, 2008 at 8:30 AM, Uriel [EMAIL PROTECTED] wrote:
(Wasn't the disaster of adding .u to p9p a clear enough indication of
how hopeless that path is?)
no. It just showed that the .u path was wrong. Adding extra ops?
Worked well for me for years, it was easy and simple.
If your
On Tue, Nov 11, 2008 at 10:36 AM, Skip Tavakkolian [EMAIL PROTECTED] wrote:
I just want to have
separate protocol ops for messages versus a single extension op. I
suppose the difference is largely an implementation decision assuming
your protocol operation space is large enough
the thinking
On Wed, Nov 12, 2008 at 2:01 AM, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 10:30 AM, Uriel [EMAIL PROTECTED] wrote:
(Wasn't the disaster of adding .u to p9p a clear enough indication of
how hopeless that path is?)
Yes, .u was a disaster which is why the most
On Tue, Nov 11, 2008 at 10:30 AM, Uriel [EMAIL PROTECTED] wrote:
operations like these (symlink, readlink, lock, etc.) that only have
significance at the extremities should not worry the transit relays.
that was the reason for Text/Rext proposal.
regardless, interpretation of the ops in a
Eric Sir,
That's what I proposed in Madrid when introducing [TR]ext. It cannot
hurt. Forward unknown transactions. The destination will Rerror on
crap - it was buggered anyway (as Roy adn HG would say)..
brucee
(back in volos, i went the wrong way and got stuck on skiathos)
On Tue, Nov 11,
I just want to have
separate protocol ops for messages versus a single extension op. I
suppose the difference is largely an implementation decision assuming
your protocol operation space is large enough
the thinking is that it's the least polluting -- in regard to 9P
messages -- while still
On Tue, Nov 11, 2008 at 9:54 AM, sqweek [EMAIL PROTECTED] wrote:
If corporate acceptance is the new measure of success, maybe we
should be using an XML based protocol extension.
Corporate acceptance was always the measure of success. it's the old
measure. And it works, unless you don't need
On Tue, Nov 11, 2008 at 11:54 AM, sqweek [EMAIL PROTECTED] wrote:
Absolute, complete, utter disaster. Completely hopeless.
If corporate acceptance is the new measure of success, maybe we
should be using an XML based protocol extension.
I have two measurements of success:
a) what keeps
On Tue, Nov 11, 2008 at 1:18 PM, Bruce Ellis [EMAIL PROTECTED] wrote:
Eric Sir,
That's what I proposed in Madrid when introducing [TR]ext. It cannot
hurt. Forward unknown transactions. The destination will Rerror on
crap - it was buggered anyway (as Roy adn HG would say)..
Fair enough, what
It was N+1. I'm still in greece, though I spoke to tiger last night -
I played Buudy Boy with him and he said woof woof - which means come
home. I'll send you the code on my return.
The puppy has spoken (he's less patient than my sheila).
brucee
On Tue, Nov 11, 2008 at 9:55 PM, Eric Van
On Tue, Nov 11, 2008 at 9:37 AM, Skip Tavakkolian [EMAIL PROTECTED] wrote:
operations like these (symlink, readlink, lock, etc.) that only have
significance at the extremities should not worry the transit relays.
that was the reason for Text/Rext proposal.
regardless, interpretation of the
On Tue, Nov 11, 2008 at 4:37 PM, Skip Tavakkolian [EMAIL PROTECTED] wrote:
This approach seems to be flawed on two accounts:
1. it forces the server to resolve symlinks and special
nodes, without an option for the client to do the same.
That prevents cross-tree symlinks and nodes as
On Tue, Nov 11, 2008 at 2:51 PM, erik quanstrom [EMAIL PROTECTED] wrote:
If corporate acceptance is the new measure of success, maybe we
should be using an XML based protocol extension.
Corporate acceptance was always the measure of success. it's the old
measure. And it works, unless you
On Tue, Nov 11, 2008 at 4:28 PM, hiro [EMAIL PROTECTED] wrote:
I must have missed something. what dav server?
We have one for inferno in the octopus. We presented/talked about
it in IWP9 at Volos.
--
- curiosity sKilled the cat
Excuse my interruption, please. I probably understand less than half of
this exchange, certainly none of the in-jokes, and I know Eric Van
Hensbergen might not exactly like compliments from a lowlife but whatever:
you rock Mr. Van Hensbergen!
And some stuff for troll-clubbers to club me with:
On Tue, 2008-11-11 at 09:45 +0100, Fco. J. Ballesteros wrote:
For this we use local Infernos at machines serving resources,
using a dav server to provide the built name space to the native host systems.
Not for devices, but works for most other things.
Devices can be done by adapting their
On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
I have two measurements of success:
a) what keeps me working on Plan 9 related technologies in a paid position
b) what switches people from using NFS, GPFS, or other horribly
complicated solutions to something
On Tue, Nov 11, 2008 at 8:11 PM, sqweek [EMAIL PROTECTED] wrote:
On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen [EMAIL PROTECTED]
wrote:
I have two measurements of success:
a) what keeps me working on Plan 9 related technologies in a paid position
b) what switches people from using
On Nov 11, 2008, at 6:11 PM, sqweek wrote:
On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen
[EMAIL PROTECTED] wrote:
I have two measurements of success:
a) what keeps me working on Plan 9 related technologies in a paid
position
b) what switches people from using NFS, GPFS, or other
1 - 100 of 167 matches
Mail list logo
