On Tue, 2009-01-20 at 18:36 -0500, erik quanstrom wrote:
Got it. However, I'm still not fully convinced there's a definite edge
one way or the other. Don't get me wrong: I'm not trying to defend
ZFS (I don't think it needs defending, anyway) but rather I'm trying
to test my mental
On Tue, 2009-01-20 at 20:47 -0500, erik quanstrom wrote:
i apologize for the silly question, but
my p9p-fu is quite weak.
is the reason that plan 9 import is not
part of p9p other than it was not needed?
(of course the ssh-based import is included,
but i believe that is something else
On Mon, 2009-01-12 at 11:06 -0800, Russ Cox wrote:
Super.active is the block number of a VtDirType block:
a block containing a few (I think 3) VtEntry structs.
Turns out there's one extra level of indirection there,
but your response was exactly what I needed to get
me unstuck. Thanks!
cd
Hi!
I'm trying to read up on fossil implementation so
that I can sustain an intelligent conversation with
Andrey ;-)
Now, the paper Fossil, an Archival File Server is
pretty good, but here's one simple question that
I can't find an answer to: there's a pointer to
the root of the filesystem block
On Fri, 2009-01-09 at 15:11 -0500, Dave Eckhardt wrote:
A check could be put in by having venti put some sort of lock
somewhere on the disk. But that would lead to problems if
venti doesn't shut down properly: venti would be gone but the
lock would still be there.
Post an (ignored)
Hi!
1. are the ones starting from underscore totally deprecated?
2. what's the use for sysr1?
Thanks,
Roman.
On Thu, 2009-01-08 at 07:36 -0800, ron minnich wrote:
If you want what a jail does, I still think there are better ways on
ARM, esp. watching this conversation:
- something the equivalent of user mode linux
This one sounds like a waste for a system that is so close
to supporting proper jailing
On Wed, 2009-01-07 at 08:55 -0800, ron minnich wrote:
The underlying assumption of motivation for this discussion is that
jailing (or whatever we want to call it) is somehow a good thing.
Given that every CPU we care about comes with virtualization hardware,
I just can't see the point of jails
On Wed, 2009-01-07 at 01:24 -0500, Dave Eckhardt wrote:
RFNOMNT, like everything in Plan 9, was put in because
someone needed to use it, not as a purely academic
exercise in adding features.
Here is something which either I've misunderstood or is
harder than I'd like.
[...]
What does
On Thu, 2009-01-08 at 19:57 +, Charles Forsyth wrote:
It now seems, that if your process has a read/write access to
a channel capable of speaking 9P not letting it mount that
channel really doesn't accomplish much: whatever messages kernel
would send on your behalf, you can send
On Tue, 2009-01-06 at 09:17 -0500, erik quanstrom wrote:
i think we can skip the sematic arguments and the questions
about rooting. let's go directly to how would you unify
the big-n Namespace in a way that's clearly better?
At this point: I don't know. :-( The discussion was tremendously
On Mon, 2009-01-05 at 11:00 +, roger peppe wrote:
i've sometimes thought that the trick used by #d etc could
be made more transparent by providing a genuine capability
service for fds, in the form of a system call, for instance
getfdcap(int fd, char *buf, int len)
then instead of
On Tue, 2009-01-06 at 18:15 -0500, erik quanstrom wrote:
Although in the alternative universe I can see how implementing #X
as *channels* capable of 9P messages, could enable things like mounting
them on external hosts and letting these hosts manipulate physical
devices attached to yours
On Thu, 2009-01-08 at 18:48 -0500, erik quanstrom wrote:
Although in the alternative universe I can see how implementing #X
as *channels* capable of 9P messages, could enable things like mounting
them on external hosts and letting these hosts manipulate physical
devices attached to
On Tue, 2009-01-06 at 18:44 -0500, erik quanstrom wrote:
a big difference between the decisions is in data integrety.
it's much easier to break a fs that rewrites than it is a
worm-based fs.
True. But there's a grey area here: an FS that *never* rewrites
live blocks, but can reclaim
On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
It would be a shame (but no disaster) if Binutil's nm and other
tools could not at least display native Plan 9 intermediate files. I
need to know or decide how far to take this exercise.
why would that be advantagous on plan 9?
On Tue, 2009-01-06 at 17:54 -0500, erik quanstrom wrote:
On Tue, 2009-01-06 at 15:09 -0500, erik quanstrom wrote:
It would be a shame (but no disaster) if Binutil's nm and other
tools could not at least display native Plan 9 intermediate files. I
need to know or decide how far to take
On Tue, 2009-01-06 at 20:37 +, Charles Forsyth wrote:
This just means that these services need to be mounted at the canonical
there is no point binding #a or #D into the name space.
they can be used only locally and might as well
be accessed directly. they might be considered similar to
On Tue, 2009-01-06 at 11:19 -0500, erik quanstrom wrote:
very interesting post.
indeed. I actually need some time to digest it ;-)
this is an example of the design decision difference between
fossil/venti and zfs: venti commits storage permanently and everything
becomes a snapshot, while
On Sat, 2009-01-03 at 23:01 -0800, Russ Cox wrote:
On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik r...@sun.com wrote:
[complaint about # names]
Please let me know what kind of keywords or emoticons I am supposed
to include in my emails to indicate that they are *not* complaints
On Sun, 2009-01-04 at 00:27 -0500, erik quanstrom wrote:
Usign #X means doing a mount (you are attaching to the root
of the driver's tree).
You're right, of course. But it feels like a very special mount
if one can refer to files served by the drivers directly through:
'#X/bla-bla'.
On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
The let's submit a patch and fix it talk is scary.
Russ, with all due respect, life gets unnecessarily complicated
when on one hand whenever I suggest something for discussion
there's always a member of this list (you included) who asks
me to
On Sun, 2009-01-04 at 08:43 +0200, lu...@proxima.alt.za wrote:
Constructing a namespace without RFNOMNT that does not have #s (say) bound
is not really securing #s (and its other consumers) against that namespace's
actions. Constructing a namespace with RFNOMNT and without #s bound does
On Sun, 2009-01-04 at 20:23 +0200, lu...@proxima.alt.za wrote:
i haven't even seen what i think is a compelling
argument for sendfd yet you're trying to argue
for second-order problems with a particular
application of sendfd.
Sendfd() seems to me a somewhat more carefully controlled
On Sat, 2009-01-03 at 18:57 -0500, Nathaniel W Filardo wrote:
That is, if I cannot refer to an object in my namespace and no
server I can refer to will grant access, then I have achieved isolation of
that object and any process running in my namespace.
That sounds like a reasonable
On Sun, 2009-01-04 at 07:03 +0900, sqweek wrote:
On Tue, Dec 30, 2008 at 8:54 AM, Roman Shaposhnik r...@sun.com wrote:
Personally, though, I'd say that the usefulness of the
dump would be greatly improved
if one had an ability to do ad-hoc archival snapshots AND assigning tags,
not only
[ I took a liberty to merge two of your emails together for the ease of
commenting ]
On Thu, 2009-01-01 at 18:57 -0500, Nathaniel W Filardo wrote:
That is, the claim that a process spawned without access to your home
directory cannot get it is flawed if that process runs as your user.
(Even
On Sat, 2009-01-03 at 10:21 -0800, Skip Tavakkolian wrote:
snarf doesnt work properly in plan9 on vmware fusion 2.0 for mac. from what
i found this seems to be a known issue. is there any fix available?
no; someone needs to write a new version
of the vmware tools that works with the
Guys,
while replying to Nathaniel's post it dawned on
me that something like this:
open(#c/cons, OWRITE|OCEXEC);
completely breaks the paradigm of namespaces.
IOW, if I wanted to construct a namespace with
a specially crafted server offering /dev/cons,
the above would easily break out of
On Sat, 2009-01-03 at 16:46 -0500, erik quanstrom wrote:
while replying to Nathaniel's post it dawned on
me that something like this:
open(#c/cons, OWRITE|OCEXEC);
completely breaks the paradigm of namespaces.
IOW, if I wanted to construct a namespace with
a specially crafted
On Sat, 2009-01-03 at 16:41 -0500, erik quanstrom wrote:
there's also nothing preventing one from implementing a
filtering fs that restricts the directories available in /proc.
True. But there are two problems with a filtering fs:
1. Accessing #p would bypass the fs 100%
2. For things like
On Sat, 2009-01-03 at 17:03 -0500, erik quanstrom wrote:
Did you see the example I provided in the original
email? rfork m is *exactly* RFNOMNT. And it doesn't
seem to work for one simple reason: RFNOMNT doesn't
restrict bind(2).
these are exceptions. from port/chan.c:
case
On Sat, 2009-01-03 at 23:46 +0100, Francisco J Ballesteros wrote:
Isn't it too restrictive, eg, not allowing you to create pipes?
It depends. The point, however, is that NOT allowing to restrict
*all* attaches seem far more restrictive. ;-)
Besides, my main concern is not about restricting at
I'm confused. Is there any part of syspipe() that can NOT
be done from userspace? Why does it have to be a syscall?
Thanks,
Roman.
P.S. I would also argue that sysdup() would seem to be superfluous
if more feature-rich devdup was available.
On Sat, 2009-01-03 at 17:57 -0500, erik quanstrom wrote:
And finally, I'd say having these exceptions is a mistake. Unless,
there's a really good reason, they break the paradigm of RFNOMNT
quite needlessly without even a hint of a benefit.
so, it's likely that RFNOMNT was added and to
On Sat, 2009-01-03 at 15:15 -0800, Russ Cox wrote:
On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom quans...@quanstro.net wrote:
And finally, I'd say having these exceptions is a mistake. Unless,
there's a really good reason, they break the paradigm of RFNOMNT
quite needlessly without even a
On Sat, 2009-01-03 at 23:21 +0100, Francisco J Ballesteros wrote:
Usign #X means doing a mount (you are attaching to the root
of the driver's tree).
You're right, of course. But it feels like a very special mount
if one can refer to files served by the drivers directly through:
'#X/bla-bla'.
On Fri, 2008-12-19 at 20:18 +, Charles Forsyth wrote:
And nobody yet cared to give a concrete explanation of why it might be a bad
idea.
what's the application you've got in mind?
Legacy ones :-( At the moment -- they are homegrown databases. And yes,
as Erik pointed out -- they look
On Fri, 2008-12-12 at 10:16 +0500, Roman Zhukov wrote:
http://9fans.net/archive/2008/11/891
Aha! I now remember seeing that one. But since its been
more than 2 weeks -- I guess the question is, whether
web interface to sources has any chance of recovering.
Thanks,
Roman.
On Thu, 2008-12-04 at 02:39 -0500, Dave Eckhardt wrote:
P.S. I've seen this disbelief in the fact that automoter + NFS
actually can be really convenient mostly come from Linux people.
Perspective depends on experience.
AFS has its warts, but, trust me, if you've used it for a while,
you
Hi, Russ!
Firs of all -- thank a lot for answering all of my question
in a very detailed manner. I really do appreciate it!
Now, if you don't mind, I still have just one question left:
On Mon, 2008-12-01 at 16:55 -0800, Russ Cox wrote:
That's very similar to what I referred to as a synthetic
On Tue, 2008-12-02 at 13:31 -0500, Nathaniel W Filardo wrote:
Namespaces form a large part of the security component of the Plan 9 model,
and (AFAICT) cross-namespace work is underinvestigated
It would be, in fact, a fair answer.
since it starts to look a lot like something that could
On Tue, 2008-12-02 at 14:29 -0500, erik quanstrom wrote:
i would think that either you want encapsulation or you don't.
see-through encapsulation would seem to me to be a contradiction
in terms.
Thanks for the feedback. Lets see if you change your mind after the
explanation given
On Tue, 2008-12-02 at 21:05 +0100, hiro wrote:
I still don't understand what kind of feature you are missing. Could
it be that you just want a naming convention for your mount places?
Writable '#p/id/ns'
Thanks,
Roman.
P.S. Unless somebody tells me that it is a bad idea with the explanation
On Tue, 2008-12-02 at 19:07 -0500, erik quanstrom wrote:
None of these questions are any different in this
context than if there was simply some other process
sharing the name space and doing the same manipulations.
currently one can prevent external changes to a
namespace by creating
On Tue, 2008-12-02 at 16:35 -0500, erik quanstrom wrote:
nope. sorry. i would hate to see such a botch in plan 9.
if you want to distribute load by having multiple fs, then
it should be done so that the client wouldn't know or care
that any distribution is going on.
I think
On Mon, 2008-12-01 at 10:17 -0800, ron minnich wrote:
But this need for an automounter has not really existed for probably
17 years or so ... NFS servers are pretty reliable in many cases. It
is interesting to see the use case for automoiuters change.
Right. I'm actually too young to be able
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
Hi Guys,
I was rereading selected places of Rob's Getting Dot-Dot Right
paper and it suddenly occurred to me that the example he provides
there is something that I have always wanted to have. Here it is:
% cat /proc/125099/ns
.
mount -c /net/il/134/data /mnt/term
cd
On Wed, 2008-11-19 at 20:36 +0100, Francisco J Ballesteros wrote:
The point is that you need a way for the chan to know how to reach the
file server.
That is a larger point here, indeed. However, my question was a simpler
one: is there any reason to show '#s/sutff' at all? Could I ever be
On 11/19/08 17:41, erik quanstrom wrote:
Ok, I can understand why devproc.c does it: it is easy to discover the
name of the actual Chan if you know the node in /srv:
fd = open(#s/stuff, OREAD);
fd2chan(fd, buf, sizeof(buf));
close(fd);
but not the other way around. Buit why ns(1)
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 Tue, 2008-11-11 at 16:15 -0900, Jack Johnson wrote:
Has anyone tried injecting a Plan 9 instance into the new Amazon cloud?
http://aws.amazon.com/ec2/
Amazon prescreen the kernel that you can use there, but!
As was suggested by Richard Miller, if Plan9 can be
a target of kexec -- the sky
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 Mon, 2008-11-10 at 01:55 +0900, sqweek wrote:
On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik [EMAIL PROTECTED]
wrote:
The only question is -- where such a note
is supposed to be sent to?
Can someone, please, educate me on the moral equivalent of process
groups, sessions
On Mon, 2008-11-10 at 15:17 +0900, sqweek wrote:
On Mon, Nov 10, 2008 at 2:50 PM, Enrico Weigelt [EMAIL PROTECTED] wrote:
* Steve Simon [EMAIL PROTECTED] wrote:
How about if you start a page with a list of the 9p
file servers you know of, say on the plan9 wiki, and
then email 9fans
On Mon, 2008-11-10 at 14:49 -0800, ron minnich wrote:
On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik [EMAIL PROTECTED]
wrote:
At least in case of cpu(1) the magic is a bit perverse and quite
unlike the rest of the system. The way notes are managed make
a local end of a cpu(1) jump
On Sun, 2008-11-09 at 11:26 +, Steve Simon wrote:
How about if you start a page with a list of the 9p
file servers you know of, say on the plan9 wiki, and
then email 9fans asking them to add any that you have
missed?
That's the plan!
I can see how such a thing might be a useful resource
On Mon, 2008-11-10 at 23:38 +, C H Forsyth wrote:
And even we we stick with the resources
as regular files approach on the client you're stuck with mostly POSIX
environment + locking (+caching). POSIX means symlink(2) and mknod(2)
no, because (unless i've misunderstood) they are
On Tue, 2008-11-11 at 00:14 +, Charles Forsyth wrote:
But wouldn't you agree that files kept on a remote POSIX file system is
an important and common class of remotes resources for which we don't
quite have a consensus on how to use 9P?
yes, but both your examples are things of purely
erik quanstrom wrote:
How? If there's a stop message already written to /proc/n/ctl. Once
that is done, the process is guaranteed to be in 2 states and those
states only: continue waiting for the I/O, being actually Stopped.
Both of the don't let the scheduler take it to the runqueue.
Guys,
do we have something like this:
http://fuse.sourceforge.net/wiki/index.php/FileSystems
for 9P? At this point I don't even care what OS these
servers run under I just need the most comprehensive
list of every possible kind of a resource that can be
shared/served using 9P.
Thanks,
On Fri, 2008-11-07 at 22:38 +, C H Forsyth wrote:
of course, that's just the protocol, and to show the larger
idea of the representation of things by name spaces
(instead of ioctls and special system calls)
would have to include section 3 (devices).
it's fairly pervasive.
Sure. But
On Fri, 2008-11-07 at 14:31 -0800, ron minnich wrote:
FUSE won. It's easy, it works, and it has cross-platform support
(macos/linux).
It certainly looks that way. It also certainly looks like I have to
study it. Do you guys have any good pointers and/or wisdom in that
department? I'd be happy
On Thu, 2008-11-06 at 06:54 -0500, erik quanstrom wrote:
So how many cores is that for each member of the
Plan 9 community? :-) On a slightly more serious
note, would it be terribly naive to guess that
there would be more cores running Plan 9 in that
machine than there are throughout
On Mon, 2008-11-03 at 18:48 +, Brian L. Stuart wrote:
Frankly, I was trying to see whether an external process reading
on somebody else's /proc/n/note would make any sense. One thing
that I wanted to implement was a note thief process that would
constantly read on a target's
On Mon, 2008-11-03 at 08:03 -0500, erik quanstrom wrote:
what is the point of reading /proc/n/ note for anything but a
stopped/borken process?
or a process already in a note handler?
Could you elaborate, please? Do you mean that if the process
enters its note handler, then the sure fire
On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote:
* Roman Shaposhnik [EMAIL PROTECTED] wrote:
Hi,
Besides the fact that I'm not making binary packages at all,
splitted / small sources make packaging a lot easier.
So let me get this straight: you're trying to solve a problem
[I believe we should go off-line if you're interested in continuing this
discussion, since it has very little to do with plan9port at this point.
I'll reply to the portion that has relevance on the list here, and will
reply to the rest of your email privately]
On Mon, 2008-11-03 at 01:15 +0100,
On Wed, 2008-10-22 at 12:28 -0400, erik quanstrom wrote:
rio does provide most everything one would need for a text-mode
interface. unfortunately, you can't currently tail -f /dev/text. perhaps
such a change would be easier and more general
That's a very good point! It hadn't occurred to me
On Wed, 2008-10-22 at 10:54 -0600, andrey mirtchovski wrote:
This has one or two complications. There is no way to interrupt or kill
the foreground process. Instead, ctrl-c interrupts 9vx itself.
chris,
one of the nice things about the Plan 9 graphics system is that rio is
in no way
On Sat, 2008-10-18 at 10:20 -0700, Russ Cox wrote:
Hence the question -- would you be in favor
of continue adding things as needed. And
if so, what kind of of groundwork would
you expect from the contributors?
Usually it is as simple as adding it to your own tree,
adapting the mkfile,
On Wed, 2008-10-15 at 08:17 -0400, erik quanstrom wrote:
; mntgen a
; bind /env a/env
; bind /bin a/bin
; bind /proc a/proc
; bind a /
; ns
consider it a security feature.
Be it as it may, I still can't quite follow why *manual* pruning
of the entries
Hi Russ!
First of all -- thanks a lot for answering.
On Mon, 2008-10-06 at 09:24 -0700, Russ Cox wrote:
somehow it dawned on me that plan9port lacks
an application to serve a local filesystem
over 9P. Is this on purpose? Am I missing
something fundamental that would allow
for a moral
On Mon, 2008-10-06 at 09:31 -0700, Russ Cox wrote:
it appears that I'm missing something fundamental in how
9pfuse (the one written by Russ) works when it is given
- as an address. The source looks like it should be
simply using stdin for R/W instead of dialing out the
connection first,
On Thu, 2008-07-31 at 15:02 -0700, ron minnich wrote:
OK, am I just out of date or is there a real reason for linker
sets?This question just came up in linuxbios v3 and I am wondering if
I am a stubborn old coot (likely) or if there really is merit to my
dislike of linker sets.
I tend to
On Fri, 2008-08-01 at 06:06 -0400, erik quanstrom wrote:
Now, on the other hand, I guess kernel is different though.
Isn't it supposed to be one huge piece of magic to begin with? ;-)
it's supposed to be neither.
Yeah, but Ron was talking 'bout that kernel from Scandinavia,
right?
Hi
On Wed, 2008-07-30 at 12:51 +0200, [EMAIL PROTECTED] wrote:
hello
Access to sources is anonymous since a couple of years (try 9fs sources),
Thanks!!! mount -n solved my issue 100%.
you only need an account if you're going to write in sources (contrib/). I
think if you want an account
On Wed, 2008-07-30 at 12:51 +0200, [EMAIL PROTECTED] wrote:
hello
Access to sources is anonymous since a couple of years (try 9fs sources)
Although, on a second though, if sources.cs.bell-labs.com doesn't
require authentication it probably should reply with Rerror
to a Tauth message. And it
On Wed, 2008-07-30 at 13:35 +0200, [EMAIL PROTECTED] wrote:
On Tue, Jul 29, 2008 at 12:12:05PM -0700, Bakul Shah wrote:
It is slightly depressing to think that the situation has not really
changed since EWD wrote this in 1975. It will take some young
whippersnapper of a Dijkstra or
On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote:
Convenience is one point (sometimes be a big point), but another
important one is sharing. Without mmap(), an (real) shared library
support most likely will require special kernel support.
What aspect of shared libraries are you aching
On Tue, 2008-07-29 at 12:28 -0400, Venkatesh Srinivas wrote:
As far as interfaces go, mmap() is pretty tragic - the underlying
translation structures can express more interesting things, some of
which are even worth doing.
I can't agree more. The way I look at it is that mmap() seems to
be the
ron minnich wrote:
On Tue, Jul 29, 2008 at 8:19 AM, erik quanstrom [EMAIL PROTECTED] wrote:
you can't make the assumption that a file is local in *ix, either.
in fact, for the last 20 years, every program run on a sunos/solaris
machine has used mmap for the exec.
mmap() is
ron minnich wrote:
more useless crap from memory:
the actual correct usage is
//GO.SYSIN DD *
but of course the * would make things messy.
See this and realize this stuff is still being taught!
http://www.coba.unt.edu/itds/courses/bcis3690/bcis3690.ht
So... for the dense ones (like myself),
Charles Forsyth wrote:
JCL == Java Control Language?
the Job Control Language for System/360
Yeah, I kind of knew that ;-) I was trying to come
up with the best joke I could. If this is not it, I have
no clue what could be funny about JCL ;-)
bundles are implemented by here
On Fri, 2008-07-18 at 15:00 -0400, erik quanstrom wrote:
my inclination would be to give 9vx a proper
ethernet device, but that idea has been discussed
already.
I was about to ask this very question (and say THANK YOU
to Russ for another awesome piece of software), but now
that you've
On Thu, 2008-07-17 at 10:07 +0100, Charles Forsyth wrote:
I could imagine that databases use mmap() havily
it's a little mystery for me why they would do that since it's slower (or
ought to be),
slower compared to what? I'd expect the biggest slowdown for
read()/write() be not the price
On Wed, 2008-07-16 at 22:09 -0400, erik quanstrom wrote:
On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote:
coming as no suprise, the pc port of plan 9
does work just fine with 8 cores.
mpls; cat /dev/sysstat
0 14271 21350133991116
On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote:
coming as no suprise, the pc port of plan 9
does work just fine with 8 cores.
mpls; cat /dev/sysstat
0 14271 21350133991116 0
0 0 99 0
Looking at
On Sun, 2008-06-01 at 15:03 -0700, Tharaneedharan Vilwanathan wrote:
hi,
it has been a long time since we met.
any plans to have our next Plan9 Bay Area Users Group Meeting?
The sooner the better, I hope!
Thanks,
Roman.
101 - 190 of 190 matches
Mail list logo
