On Sep 3, 2009, at 10:13 AM, Anthony Sorace wrote:
you can do things like
data constraints and validations in the application code, rather than
in the sql database itself, which always feels like this random
bolt-on to the application logic.
I think it's useful to think of relational databas
> it
> seems so straightforward to just send formatted sql or
> pl/sql to the engine and get normally formatted output.
I did somthing like this for mysql to access our
corperate telephone database.
I took the inferno odbcfs as an example:
http://www.vitanuova.com/inferno/man/10/odbc.htm
On Thu, Sep 3, 2009 at 5:13 PM, Anthony Sorace wrote:
> i've not used matt's sql module itself (i should check it out) so i
> can't comment on his implementation, but... SQL is really ugly. it's
> not hard to construct something that provides the same functionality
> in a much more palatable form
> [...] but... SQL is really ugly. it's
> not hard to construct something that provides the same functionality
> in a much more palatable form. aesthetics aside, if you're dealing
> with a database-heavy app, it can make the code much easier to read.
could you explain what in particular is objecti
i've not used matt's sql module itself (i should check it out) so i
can't comment on his implementation, but... SQL is really ugly. it's
not hard to construct something that provides the same functionality
in a much more palatable form. aesthetics aside, if you're dealing
with a database-heavy app,
> I've done it a few ways. echo commit > /n/db/0/ctl is kind of where one
> ends up
>
> for my limbo postgres module I never got round to the fs part. i just
> wrap the sql bits in their own adt
i would think that rather than use an adt, one would want
to make the language the communication's p
Oh I don't know Shoehorning a DB interface into a FS
interface doesn't feel right but stranger things have
happened.
I've done it a few ways. echo commit > /n/db/0/ctl is kind of where one
ends up
for my limbo postgres module I never got round to the fs part. i just
wrap the sql bits
On Wed, Sep 2, 2009 at 5:50 PM, Bakul Shah
> wrote:
> On Mon, 31 Aug 2009 11:33:13 CDT Eric Van Hensbergen
> wrote:
> > On Mon, Aug 31, 2009 at 11:16 AM, Bakul
> > Shah>
> wrote:
> > >
> > > An intriguing idea that can point toward a synth fs interface
> > > to a dbms or search results But
On Mon, 31 Aug 2009 11:33:13 CDT Eric Van Hensbergen wrote:
> On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shah wrote:
> >
> > An intriguing idea that can point toward a synth fs interface
> > to a dbms or search results But I don't think this would
> > be a lightweight interface.
> >
>
> The fac
> It's (in my opinion) slightly less evil because if(!strlen(name))
> seems like a pretty poor way to determine that you're looking at the
> root zone. It's also more intuitive and easier to document that you're
> looking at the root than saying `to find root, look for a file named
> as an empty st
2009/8/31 erik quanstrom :
>> 2009/8/31 Bakul Shah :
>> > But this is nasty!
>> > % cat ndb/dom/'' # same as ndbquery dom ''
>>
>> No, the nasty part is really that the file should be called `.' and
>> the filesystem reserves dot as the reference to the current directory.
>> You could probably call
> 2009/8/31 Bakul Shah :
> > But this is nasty!
> > % cat ndb/dom/'' # same as ndbquery dom ''
>
> No, the nasty part is really that the file should be called `.' and
> the filesystem reserves dot as the reference to the current directory.
> You could probably call the file `dot' or `root' (cat nd
2009/8/31 Bakul Shah :
> But this is nasty!
> % cat ndb/dom/'' # same as ndbquery dom ''
No, the nasty part is really that the file should be called `.' and
the filesystem reserves dot as the reference to the current directory.
You could probably call the file `dot' or `root' (cat ndb/dom/dot or
c
On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shah wrote:
>
> ndb maps directly to a list of lisp's association lists but
> how would you map this to a synthetic fs? Something like
> / to yield a tuple? For example:
>
My current intuition in these situations is to allow for both
interfaces -- top level
On Mon, Aug 31, 2009 at 10:52 AM, erik quanstrom wrote:
>
> so plunkers like us with a few hundred machines are just "casual users"?
> i'd hate for plan 9 to become harder to use outside a hpc environment.
> it would be good to be flexable enough to support fairly degnerate cases
> like just flat f
On Mon, 31 Aug 2009 09:25:36 CDT Eric Van Hensbergen wrote:
>
> Why not have a synthetic file system interface to ndb that allows it
> to update its own files? I think this is my primary problem.
> Granular modification to static files is a PITA to manage -- we should
> be using synthetic file
> While that sounds interesting and may be useful in its own right, a
> centralized server isn't really desirable -- part of the nice thing of
> zeroconf is moving to a decentralized environment, and ideally doing
> it in a scalable fashion (which isn't trivial on hundreds of thousands
> of cores,
> > i can see in principle how this could be a good idea (no more
> > comments, though). could you elaborate, though. i have found
> > editing /lib/ndb/local works well at the scales i see.
[...]
> machines, even with multiple admins. I have a feeling it starts to
> break down with thousands of
On Mon, Aug 31, 2009 at 9:55 AM, Francisco J Ballesteros wrote:
> Hmmm. we did that for FS processes on Plan B. I mean, keep a
> dynamic version of a registry. It kept the list of volumes available at a
> central place.
>
> I think it can be used as is on Plan 9, without changes.
>
> There was a pr
On Mon, Aug 31, 2009 at 8:21 PM, Devon H. O'Dell wrote:
> 2009/8/31 Vinu Rajashekhar :
>> "You can implement a NAT by mounting a /net from a perimeter machine
>> with a public IP, while connecting to it from an internal network of private
>> IP addresses, using the Plan 9 protocol 9P in the interna
On Mon, Aug 31, 2009 at 9:36 AM, erik quanstrom wrote:
>
> i can see in principle how this could be a good idea (no more
> comments, though). could you elaborate, though. i have found
> editing /lib/ndb/local works well at the scales i see.
>
I think the main issue with just editing /lib/ndb/loc
Hmmm. we did that for FS processes on Plan B. I mean, keep a
dynamic version of a registry. It kept the list of volumes available at a
central place.
I think it can be used as is on Plan 9, without changes.
There was a program (I think it was called adsrv; not sure, it´s on the
Plan B man pages)
2009/8/31 Vinu Rajashekhar :
> "You can implement a NAT by mounting a /net from a perimeter machine
> with a public IP, while connecting to it from an internal network of private
> IP addresses, using the Plan 9 protocol 9P in the internal network."
>
> This is from the wikipedia page on Plan 9 OS.
> >
> > given the database= option, if one could confine rapid changes to
> > smaller files, one could teach ndb to only reread changed files.
> >
>
> Why not have a synthetic file system interface to ndb that allows it
> to update its own files? I think this is my primary problem.
> Granular mod
On Mon, Aug 31, 2009 at 9:04 AM, erik quanstrom wrote:
>
> given the database= option, if one could confine rapid changes to
> smaller files, one could teach ndb to only reread changed files.
>
Why not have a synthetic file system interface to ndb that allows it
to update its own files? I think t
> Of course. My use of DNS was really just in abstract to refer to the
> suite of existing services for name and service resolution under Plan
> 9. However, I think the current interfaces for ndb and cs are very
> limiting and the single file based query mechanisms don't really match
> the hierar
that wiki writeup isn't really right. importing /net isn't NAT in any
sort of technical sense; rather, it's what plan 9 does instead.
there's no "translation" of ports or addresses, it's more
(conceptually) like a straight multiplexing.
On Mon, Aug 31, 2009 at 7:51 AM, erik quanstrom wrote:
> could you explan why you're focused on dns?
> a more natural way to use plan 9 would be to use
> ndb and cs directly. wouldn't it?
>
Of course. My use of DNS was really just in abstract to refer to the
suite of existing services for name a
> "You can implement a NAT by mounting a /net from a perimeter machine
> with a public IP, while connecting to it from an internal network of private
> IP addresses, using the Plan 9 protocol 9P in the internal network."
>
> This is from the wikipedia page on Plan 9 OS.
>
> Is something like ipta
"You can implement a NAT by mounting a /net from a perimeter machine
with a public IP, while connecting to it from an internal network of private
IP addresses, using the Plan 9 protocol 9P in the internal network."
This is from the wikipedia page on Plan 9 OS.
Is something like iptables like in l
> I think there are a few issues beyond will it scale - of course with
> 128k nodes scaling is a baseline prereq for us. On BG we have a
> segmented network to deal with -- but it's likely you'll want some
> form of hierarchy regardless.
>
> I have done much with dynamic service registry us
On Aug 30, 2009, at 10:34 PM, erik quanstrom
wrote:
On Sun Aug 30 14:37:29 EDT 2009, rminn...@gmail.com wrote:
One way to make this kind of interesting is to address how you'd do a
reasonable zeroconf effort given that you need to boot 1m+ machines.
We've booted 4400*250 VMs on a machine at
On Mon, Aug 31, 2009 at 9:47 AM, Federico G.
Benavento wrote:
> Reposting this to 9fans:
>
> hola,
>
> First of all, I'm really glad you are considering Plan 9 for your project,
> thanks.
>
>> Can someone please discuss with me how to proceed, and what are the things
>> I should learn before start
Reposting this to 9fans:
hola,
First of all, I'm really glad you are considering Plan 9 for your project,
thanks.
> Can someone please discuss with me how to proceed, and what are the things
> I should learn before starting on this ?
>
you can start by reading nemo's intro "Introduction to Ope
On Sun Aug 30 14:37:29 EDT 2009, rminn...@gmail.com wrote:
> One way to make this kind of interesting is to address how you'd do a
> reasonable zeroconf effort given that you need to boot 1m+ machines.
> We've booted 4400*250 VMs on a machine at sandia, and, let me tell
> you, it was a pain. It is
One way to make this kind of interesting is to address how you'd do a
reasonable zeroconf effort given that you need to boot 1m+ machines.
We've booted 4400*250 VMs on a machine at sandia, and, let me tell
you, it was a pain. It is amusing to watch the programs traverse
million line /etc/hosts file
I see your point. It does sound like zeroconf would be useful to some
people. I wonder if it could be done with a 9p orientation as eric
suggested.
I don't recall what the security issues are with zeroconf, but, if
it's the microsoft-inspired version I'm thinking of, I would guess
there are many.
> Try this - build the source to charon over a 200ms link over 9p. Then
> try again over sshfs.
why would you do this? why not run the compile closer to
the source. this is the power of plan 9.
> Also, look at a single terminal with a local fossil install. Trace the
> path of an 'ls /'. Count t
> I wasn't thinking about doing this as a GSOC project,
> I wanted to do something for my master's project which
> was a hardcore open-source implementation, that's why I
> was going through the gsoc ideas page.
makes sense to me. i'd incourage you to work a bit with
the community. part of open
On Sun, Aug 30, 2009 at 1:07 PM, erik quanstrom wrote:
>> Simple example: file systems on Plan 9 are slow. Why is that? How do
>> they work? How would you go about finding out how to make them faster?
>
> which ones? there are quite a number to choose from.
> i've found that ken's fs beats the pan
On Sun, Aug 30, 2009 at 10:52 PM, erik quanstrom wrote:
> personally, i think the best contributions come
> from people who have a real personal need or
> better want to solve a problem, solve it and
> contribute the solution back to the community.
>
Yes, I do agree with that.
> i think that's w
personally, i think the best contributions come
from people who have a real personal need or
better want to solve a problem, solve it and
contribute the solution back to the community.
i think that's why unix and plan 9 exist at all.
so i would encourage folks who would like to
contribute to fin
> Simple example: file systems on Plan 9 are slow. Why is that? How do
> they work? How would you go about finding out how to make them faster?
which ones? there are quite a number to choose from.
i've found that ken's fs beats the pants off nfs on similar
hardware with literally one cpu tied beh
On Sun, Aug 30, 2009 at 9:21 AM, ron minnich wrote:
> I think your first, best bet is to try to find out what the Plan 9
> community needs, rather than adding on something that might not be the
> that important. I have not heard anyone express a need for zeroconf in
> Plan 9, but maybe I'm missing
I think your first, best bet is to try to find out what the Plan 9
community needs, rather than adding on something that might not be the
that important. I have not heard anyone express a need for zeroconf in
Plan 9, but maybe I'm missing something.
Simple example: file systems on Plan 9 are slow.
Hi,
I was looking for some open-source implementation work to be done as my
master's project when I chanced upon the Plan 9 GSOC projects page.
My interest is in networking, so I was particularly interested in projects about
adding zeroconf networking and firewall support to Plan 9.
I think I ha
46 matches
Mail list logo
