Jason, what's the status of this work now? I am very excited about
the possibilities...
On 5 February 2013 08:39, Jason Smith j...@iriscouch.com wrote:
Can we please discuss this when I have running code to talk about?
I mentioned my idea but I have not tried it yet. I agree with Benoit,
Can we please discuss this when I have running code to talk about?
I mentioned my idea but I have not tried it yet. I agree with Benoit,
forking subprocesses feels like a hack. But without working code, it is
hard to judge cost vs. benefit.
On Tue, Feb 5, 2013 at 7:26 AM, Benoit Chesneau
On Feb 5, 2013, at 08:26 , Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Feb 4, 2013 at 6:58 PM, Jan Lehnardt j...@apache.org wrote:
On Feb 4, 2013, at 18:47 , Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt j...@apache.org wrote:
On Feb 4,
On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau bchesn...@gmail.comwrote:
A javascript engine doesn't expose any IO par default. The **framework**
nodejs is, this is all the point. I'm quite interested by the existing
On Mon, 2013-02-04 at 11:18 +0100, Benoit Chesneau wrote:
DOS has nothing with sandboxing or maybe in a large extent here. Sandboxing
in couchjs is about:
1. restrict I/O : no disk or net access from a view
2. make sure that a view function won't leek to another
One attempt to protect
On Feb 4, 2013, at 11:53 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau bchesn...@gmail.comwrote:
A javascript engine doesn't expose any IO par default. The
On Mon, Feb 4, 2013 at 11:59 AM, Klaus Trainer klaus_trai...@posteo.de wrote:
On Mon, 2013-02-04 at 11:18 +0100, Benoit Chesneau wrote:
DOS has nothing with sandboxing or maybe in a large extent here. Sandboxing
in couchjs is about:
1. restrict I/O : no disk or net access from a view
2.
On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt j...@apache.org wrote:
On Feb 4, 2013, at 11:53 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau bchesn...@gmail.comwrote:
A
On Mon, Feb 4, 2013 at 6:58 PM, Jan Lehnardt j...@apache.org wrote:
On Feb 4, 2013, at 18:47 , Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt j...@apache.org wrote:
On Feb 4, 2013, at 11:53 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan
On Thu, 2013-01-31 at 16:17 +0100, Jan Lehnardt wrote:
Can you all help collecting the minimally available Node versions for
systems that we intend to support with master?
Regarding master, any version of Node.js (that includes unreleased ones)
would be fine, as installing it from source is a
I've done some research on sandboxing in JavaScript and Node.js. Below
are some of my findings.
Seven Degrees of Sandboxing:
1. restrict direct read-access to not explicitly white-listed
properties of the global object
2. restrict direct write-access to the global object so that it
cannot
On Thu, 2013-01-31 at 14:46 +, Jason Smith wrote:
The word sandbox is vague. There is no clear definition. (There is a
mundane historical reason for that: the sandbox was whatever the C
program did.)
Good point. For instance, even if you're executing JavaScript within
plain
On Sun, Jan 27, 2013 at 7:49 PM, Dave Cottlehuber d...@jsonified.com wrote:
On 26 January 2013 22:38, Paul Davis paul.joseph.da...@gmail.com wrote:
On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau bchesn...@gmail.com
wrote:
On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith j...@iriscouch.com
On Thu, Jan 31, 2013 at 2:42 AM, Jason Smith j...@iriscouch.com wrote:
On Sun, Jan 27, 2013 at 7:49 PM, Dave Cottlehuber d...@jsonified.com wrote:
On 26 January 2013 22:38, Paul Davis paul.joseph.da...@gmail.com wrote:
On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau bchesn...@gmail.com
On Thu, Jan 31, 2013 at 5:52 AM, Randall Leeds randall.le...@gmail.com wrote:
On Thu, Jan 31, 2013 at 2:42 AM, Jason Smith j...@iriscouch.com wrote:
On Sun, Jan 27, 2013 at 7:49 PM, Dave Cottlehuber d...@jsonified.com wrote:
On 26 January 2013 22:38, Paul Davis paul.joseph.da...@gmail.com
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis paul.joseph.da...@gmail.comwrote:
That whole process sounds like not a lot of fun.
Right. That is kind of my point. CouchDB is a JavaScript thing, and
nowadays people have a very well-adopted and well-understood JavaScript
engine on their
On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis
paul.joseph.da...@gmail.comwrote:
That whole process sounds like not a lot of fun.
Right. That is kind of my point. CouchDB is a JavaScript thing, and
nowadays people have
On Jan 31, 2013, at 14:51 , Randall Leeds randall.le...@gmail.com wrote:
On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis
paul.joseph.da...@gmail.comwrote:
That whole process sounds like not a lot of fun.
Right.
On Jan 31, 2013, at 15:00 , Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 14:51 , Randall Leeds randall.le...@gmail.com wrote:
On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis
paul.joseph.da...@gmail.comwrote:
On Thu, Jan 31, 2013 at 1:51 PM, Randall Leeds randall.le...@gmail.comwrote:
On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis
paul.joseph.da...@gmail.comwrote:
That whole process sounds like not a lot of fun.
On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
That whole process sounds like not a lot of fun.
Right. That is kind of my point. CouchDB is a JavaScript thing, and
nowadays people
Here are some notes following your *enthousiast* mail. There is not
intention to diminish the work or things like it. It is intended to temper
a little this enthousiast and trying to find the right approach on the
problems we are trying to solve.
On Thu, Jan 31, 2013 at 3:46 PM, Jason Smith
On Thu, Jan 31, 2013 at 2:52 PM, Benoit Chesneau bchesn...@gmail.comwrote:
On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis
paul.joseph.da...@gmail.com
wrote:
That whole process sounds like not a lot of fun.
On Jan 31, 2013, at 15:52 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
That whole process sounds like not a lot of fun.
Right.
Part of the difficulty in asserting the correctness of the sandbox is
that important tests like cannot read file, cannot write file,
cannot open socket cannot be written against SpiderMonkey (or,
presumably, V8) as they simply don't provide those features. Node
does, and that's the principal
On Jan 31, 2013, at 16:20 , Robert Newson rnew...@apache.org wrote:
Part of the difficulty in asserting the correctness of the sandbox is
that important tests like cannot read file, cannot write file,
cannot open socket cannot be written against SpiderMonkey (or,
presumably, V8) as they
On Thu, Jan 31, 2013 at 4:16 PM, Jason Smith j...@iriscouch.com wrote:
Yes this is the problem. You are right. This is Jan's answer. CouchDB is
already resilient to a few different runtimes.
- having more concurrency for couchapps and view indexation
Love it, but out of scope in this
Well, I think we can assert sandboxedness against JSAPI and V8
indirectly by verifying that neither provides features like file and
socket I/O. If we also hook couchdb up to something that is capable of
these things, then an engine-specific test suite has to be made to
verify that they've been
Here is where this becomes *really* interesting to me. I have touched on
this before, but let me expand.
Over the past year I thought hard about what is the best way to spend my
time on Apache CouchDB. I repeatedly came to the conclusion that the
single best thing I can do is encourage
On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau bchesn...@gmail.comwrote:
Here are some notes following your *enthousiast* mail. There is not
intention to diminish the work or things like it. It is intended to temper
a little this enthousiast and trying to find the right approach on the
On Thu, Jan 31, 2013 at 4:17 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 15:52 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis
paul.joseph.da...@gmail.com
On Jan 31, 2013, at 16:26 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:16 PM, Jason Smith j...@iriscouch.com wrote:
Yes this is the problem. You are right. This is Jan's answer. CouchDB is
already resilient to a few different runtimes.
- having more
On Thu, Jan 31, 2013 at 3:24 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 16:20 , Robert Newson rnew...@apache.org wrote:
Part of the difficulty in asserting the correctness of the sandbox is
that important tests like cannot read file, cannot write file,
cannot open socket
On Jan 31, 2013, at 16:37 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:17 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 15:52 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith j...@iriscouch.com wrote:
On
Jason,
I don't mean to be deliberately dense, but how could we, even in
principle, write a test that asserts that a map function can't open a
socket when there's no method to do so?
Jan,
I'm completely on-board with engaging the node community for the
reasons you've stated.
B.
On 31 January
On Thu, Jan 31, 2013 at 4:43 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 16:37 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:17 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 15:52 , Benoit Chesneau bchesn...@gmail.com
wrote:
On Jan 31, 2013, at 17:08 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:43 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 16:37 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:17 PM, Jan Lehnardt j...@apache.org wrote:
On
On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau bchesn...@gmail.com
wrote:
Here are some notes following your *enthousiast* mail. There is not
intention to diminish the work or things like it. It is intended to
temper
On Jan 31, 2013, at 17:12 , Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 17:08 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:43 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 16:37 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu,
On Thu, Jan 31, 2013 at 3:47 PM, Robert Newson rnew...@apache.org wrote:
Jason,
I don't mean to be deliberately dense, but how could we, even in
principle, write a test that asserts that a map function can't open a
socket when there's no method to do so?
It's a good point. But, for
On Jan 31, 2013, at 17:14 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau bchesn...@gmail.com
wrote:
Here are some notes following your *enthousiast* mail. There is not
On IOS and Android there isn't any stable release of nodejs today which
can
be problematic. It is easier with v8 now but this is another topic.
But we agree that this is out of scope for now?
This is a policy we should define imo. Do we want to think to a
cross-platform solution today
On Jan 31, 2013, at 17:20 , Benoit Chesneau bchesn...@gmail.com wrote:
On IOS and Android there isn't any stable release of nodejs today which
can
be problematic. It is easier with v8 now but this is another topic.
But we agree that this is out of scope for now?
This is a policy we
On Thu, Jan 31, 2013 at 5:19 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 17:14 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau bchesn...@gmail.com
wrote:
On Jan 31, 2013, at 17:22 , Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 17:20 , Benoit Chesneau bchesn...@gmail.com wrote:
On IOS and Android there isn't any stable release of nodejs today which
can
be problematic. It is easier with v8 now but this is another topic.
But we
On Jan 31, 2013, at 17:23 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 5:19 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 17:14 , Benoit Chesneau bchesn...@gmail.com wrote:
On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith j...@iriscouch.com wrote:
On
On Thu, Jan 31, 2013 at 5:22 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 17:20 , Benoit Chesneau bchesn...@gmail.com wrote:
On IOS and Android there isn't any stable release of nodejs today which
can
be problematic. It is easier with v8 now but this is another topic.
On Thu, Jan 31, 2013 at 3:39 PM, Jan Lehnardt j...@apache.org wrote:
Can someone please specifically describe a sandbox feature? CouchJS
passes the test suite. So what does the sandbox do?
did it many time. See my other mail where I tried to summarise it again.
Can you give me a
On Thu, Jan 31, 2013 at 5:27 PM, Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 3:39 PM, Jan Lehnardt j...@apache.org wrote:
Can someone please specifically describe a sandbox feature? CouchJS
passes the test suite. So what does the sandbox do?
did it many time.
On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau bchesn...@gmail.comwrote:
A javascript engine doesn't expose any IO par default. The **framework**
nodejs is, this is all the point. I'm quite interested by the existing
solutions to sandbox nodejs, do you know some projects that does it?
On Jan 31, 2013, at 17:54 , Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau bchesn...@gmail.comwrote:
A javascript engine doesn't expose any IO par default. The **framework**
nodejs is, this is all the point. I'm quite interested by the existing
On Thu, Jan 31, 2013 at 5:59 PM, Jan Lehnardt j...@apache.org wrote:
On Jan 31, 2013, at 17:54 , Jason Smith j...@iriscouch.com wrote:
On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau bchesn...@gmail.com
wrote:
A javascript engine doesn't expose any IO par default. The **framework**
On Fri, Jan 25, 2013 at 6:01 PM, Jason Smith j...@iriscouch.com wrote:
Hi, David. Yes, you make very good points. I even think you (and Benoit)
may be ultimately correct
I dispute that Node.js is V8. Node is not V8. Node.js is a direct link to
God. When I pray to God in the JavaScript
On 26 January 2013 22:38, Paul Davis paul.joseph.da...@gmail.com wrote:
On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith j...@iriscouch.com wrote:
This is a great thread I'm wholly in favour of pretty much all of it.
As
Russell, thanks for you comments on the ticket.
For the record, I fixed some i/o bugs in couchjs and most of the test suite
is passing on my branch now. I have nearly achieved phase 1.
I think you probably agree, in a situation like this, the only acceptable
approach is the whitelist. I think it
Paul, we are in broad agreement, so therefore you are correct by
definition. :)
JavaScript has seen a huge explosion of tools to parse, process, rewrite,
etc. JavaScript source code. Esprima is the state of the art (at least in
my peer group) and I have had success with Uglify.
The builtin view
On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith j...@iriscouch.com wrote:
Russell, thanks for you comments on the ticket.
For the record, I fixed some i/o bugs in couchjs and most of the test suite
is passing on my branch now. I have nearly achieved phase 1.
I think you probably agree, in a
On Sat, Jan 26, 2013 at 2:11 AM, Jason Smith j...@iriscouch.com wrote:
Russell, thanks for you comments on the ticket.
For the record, I fixed some i/o bugs in couchjs and most of the test suite
is passing on my branch now. I have nearly achieved phase 1.
I think you probably agree, in a
On Sat, Jan 26, 2013 at 2:31 AM, Jason Smith j...@iriscouch.com wrote:
Paul, we are in broad agreement, so therefore you are correct by
definition. :)
+1
JavaScript has seen a huge explosion of tools to parse, process, rewrite,
etc. JavaScript source code. Esprima is the state of the art
On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith j...@iriscouch.com wrote:
Russell, thanks for you comments on the ticket.
For the record, I fixed some i/o bugs in couchjs and most of the test suite
is passing on my
Hi, all.
Encouraged by my successful experiment with a Node.js view server, I am now
working on a branch, nodejs_couchdb, with the following properties:
* Remove couchjs from the project
* Remove dependency on SpiderMonkey, libjs, 1.8.whatever...all that is gone
* Remove dependency on libcurl
*
On Fri, Jan 25, 2013 at 12:06 PM, Jason Smith j...@apache.org wrote:
This is an experiment just to see how things feel. I want to see how it
feels to stop saying CouchDB requires
libjs185/xulrunner/spidermonkey/whatever and start saying CouchDB
requires Node.js.
What do we need Node.js for,
This whole branch is an experiment. That is the main point.
My **tentative** position is that V8 is a waste of time. We should use
Node.js, not V8. In other words, we should not change couchjs to link
against libv8.so instead of libmozjs.so. Instead, we should **remove** the
couchjs binary and
opinion D: we can use full v8 for views because to be honnest we don't
really need node just for views. And for other cases like couch apps but
also couch scripts we can improve the protocol so we can handle it
asynchronously in the language you want. Which may be imply to ship node.
In this
opinion E: add a DSL to create views and improve the protocol for other
cases.
- benoît
On Fri, Jan 25, 2013 at 12:18 PM, Jason Smith j...@iriscouch.com wrote:
This whole branch is an experiment. That is the main point.
My **tentative** position is that V8 is a waste of time. We should use
I preface this with the fact that I'm fairly interested in exploring this.
I think Jason's sentiments are right on in that SpiderMonkey has proven to
be a bit of a burden for us to depend on especially from the point of view
of instructing new users on how to satisfy that dependency.
That said,
I agree with Benoit, *however* those are out-of-scope for my branch. The
experiment is to explore *build* dependencies, nothing else. The Node.js
component is simply 100% compatible with couchjs, providing the same API
for all the code in share/server/*.js.
I am intrigued about hybrid
On 25/01/13 11:18, Jason Smith wrote:
My **tentative** position is that V8 is a waste of time. We should use
Node.js, not V8. In other words, we should not change couchjs to link
against libv8.so instead of libmozjs.so. Instead, we should **remove** the
couchjs binary and build a 100% compatible
Heck, let the man experiment :) It's pretty great that most of the diff is
removal of stuff anyway. Thanks for the heads up and keep us informed.
On Fri, Jan 25, 2013 at 9:35 AM, david martin
david.mar...@lymegreen.co.ukwrote:
On 25/01/13 11:18, Jason Smith wrote:
My **tentative** position
Hi, David. Yes, you make very good points. I even think you (and Benoit)
may be ultimately correct
I dispute that Node.js is V8. Node is not V8. Node.js is a direct link to
God. When I pray to God in the JavaScript language, God moves electrons
around inside my computer. He writes files to my
Both Node.js and V8 are a make away, so the question is what else each
brings to the table.
I'm of the opinion that the big win of Node.js is npm. I would love to see
CouchDB extensible by npm modules. I've done some experiments along those
lines, but the problem comes back to sandboxing. As you
Just to be part of the fun and really add to the mess of options there is
this:
https://github.com/ariya/phantomjs
I think it's somewhere above v8 and below node. Maybe it would be easier to
contain then the node beast for sandboxing and provide developers with some
fun new toys.
Either way we
Wow, thanks for so much feedback, Russell!
Unfortunately, libmozjs185 is also a make away I think.
The V8 vs. Node discussion is premature until we clearly define the
requirements. What exactly is this sandbox? What guarantees or invariants
does it ensure? I have proposed a specific feature list
On Fri, Jan 25, 2013 at 8:51 AM, Jason Smith j...@iriscouch.com wrote:
I agree with Benoit, *however* those are out-of-scope for my branch. The
experiment is to explore *build* dependencies, nothing else. The Node.js
component is simply 100% compatible with couchjs, providing the same API
for
Getting a spec together is a good next step, I'll update COUCHDB-1643 with
some ideas.
One distinction that would be useful, is what functionality is needed in
the view engine for just map/reduce, versus user defined functionality in
filters/validate/update/show/lists. I'm intrigued by the idea
On Fri, Jan 25, 2013 at 3:36 PM, Paul Davis paul.joseph.da...@gmail.comwrote:
On Fri, Jan 25, 2013 at 8:51 AM, Jason Smith j...@iriscouch.com wrote:
I agree with Benoit, *however* those are out-of-scope for my branch. The
experiment is to explore *build* dependencies, nothing else. The
On 25/01/13 18:01, Jason Smith wrote:
1. Install Node.js on your computer, by any means
MAC / Linux typical
sudo apt-get install g++
curl
libssl-dev
apache2-utils
sudo apt-get install git-core
git clone git://github.com/ry/node.git
cd node
./configure (needs M4 may fail for a variety of
77 matches
Mail list logo
