NodeJS under SPARC
2,429 views
Skip to first unread message
Dave
Dec 27, 2011, 4:28:46 PM12/27/11
to nodejs
Good Day!
I was having some difficulty locating NodeJS for SPARC Solaris. Where
can it be D/L'ed?
There seems to be an indication that V8 is not a cross-platform
JavaScript kit, capable of running under SPARC. Would NodeJS work
under a JavaScript engine which supports other platforms more broadly?
A possible performance, feature, or even stability hit might be
acceptable, if we could run NodeJS under a different JavaScript
engine. We are interested in non-blocking H/A applications.
I would be willing to participate in a working group, if others were
interested.
Regards,
Dave
http://netmgt.blogspot.com/
I was having some difficulty locating NodeJS for SPARC Solaris. Where
can it be D/L'ed?
There seems to be an indication that V8 is not a cross-platform
JavaScript kit, capable of running under SPARC. Would NodeJS work
under a JavaScript engine which supports other platforms more broadly?
A possible performance, feature, or even stability hit might be
acceptable, if we could run NodeJS under a different JavaScript
engine. We are interested in non-blocking H/A applications.
I would be willing to participate in a working group, if others were
interested.
Regards,
Dave
http://netmgt.blogspot.com/
Ben Noordhuis
Dec 27, 2011, 8:41:52 PM12/27/11
to nod...@googlegroups.com
On Tue, Dec 27, 2011 at 22:28, Dave <david...@gmail.com> wrote:
> Good Day!
>
> I was having some difficulty locating NodeJS for SPARC Solaris. Where
> can it be D/L'ed?
> Good Day!
>
> I was having some difficulty locating NodeJS for SPARC Solaris. Where
> can it be D/L'ed?
Nowhere. There is no SPARC support.
> There seems to be an indication that V8 is not a cross-platform
> JavaScript kit, capable of running under SPARC. Would NodeJS work
> under a JavaScript engine which supports other platforms more broadly?
V8 indeed doesn't support SPARC. It's deeply integrated into Node so
swapping it for another JS engine is non-trivial and pretty much
amounts to rewriting Node.
If you're serious about this, you want to either port V8 or create a
V8 emulation layer. v8monkey is one such attempt.
Dave
Dec 28, 2011, 9:59:14 AM12/28/11
to nodejs
On Dec 27, 8:41 pm, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
Hi Ben,
It looks like Mozilla forked NodeJS (SpiderNode) with a
a less proprietary JavaScript engine (SpiderMonkey) for
potentially better cross-platform characteristics.
I don't understand the history - it seems crazy to build Node
with cross-platform JavaScript, targeting a proprietary CPU
architecture. Coming from an Open community, I would
appreciate any historical context, if you have insight.
We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
a non-blocking framework compatible with SPARC and Intel.
ARM is a bonus, people have Node running on embedded
systems like re-purposed router appliances (i.e. OpenWRT?)
Is there decent cooperation between the SpiderNode
and NodeJS teams, to provide users the ability to
build Node applications under multiple platforms?
Thank you for the guidance,
Dave
http://netmgt.blogspot.com/
> On Tue, Dec 27, 2011 at 22:28, Dave <davidha...@gmail.com> wrote:
> > Good Day!
>
> > I was having some difficulty locating NodeJS for SPARC Solaris. Where
> > can it be D/L'ed?
>
> Nowhere. There is no SPARC support.
>
> > There seems to be an indication that V8 is not a cross-platform
> > JavaScript kit, capable of running under SPARC. Would NodeJS work
> > under a JavaScript engine which supports other platforms more broadly?
>
> V8 indeed doesn't support SPARC. It's deeply integrated into Node so
> swapping it for another JS engine is non-trivial and pretty much
> amounts to rewriting Node.
>
> If you're serious about this, you want to either port V8 or create a
> V8 emulation layer. v8monkey is one such attempt.
...
> > Good Day!
>
> > I was having some difficulty locating NodeJS for SPARC Solaris. Where
> > can it be D/L'ed?
>
> Nowhere. There is no SPARC support.
>
> > There seems to be an indication that V8 is not a cross-platform
> > JavaScript kit, capable of running under SPARC. Would NodeJS work
> > under a JavaScript engine which supports other platforms more broadly?
>
> V8 indeed doesn't support SPARC. It's deeply integrated into Node so
> swapping it for another JS engine is non-trivial and pretty much
> amounts to rewriting Node.
>
> If you're serious about this, you want to either port V8 or create a
> V8 emulation layer. v8monkey is one such attempt.
Hi Ben,
It looks like Mozilla forked NodeJS (SpiderNode) with a
a less proprietary JavaScript engine (SpiderMonkey) for
potentially better cross-platform characteristics.
I don't understand the history - it seems crazy to build Node
with cross-platform JavaScript, targeting a proprietary CPU
architecture. Coming from an Open community, I would
appreciate any historical context, if you have insight.
We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
a non-blocking framework compatible with SPARC and Intel.
ARM is a bonus, people have Node running on embedded
systems like re-purposed router appliances (i.e. OpenWRT?)
Is there decent cooperation between the SpiderNode
and NodeJS teams, to provide users the ability to
build Node applications under multiple platforms?
Thank you for the guidance,
Dave
http://netmgt.blogspot.com/
Ben Noordhuis
Dec 28, 2011, 11:01:56 AM12/28/11
to nod...@googlegroups.com
On Wed, Dec 28, 2011 at 15:59, Dave <david...@gmail.com> wrote:
> It looks like Mozilla forked NodeJS (SpiderNode) with a
> a less proprietary JavaScript engine (SpiderMonkey) for
> potentially better cross-platform characteristics.
>
> I don't understand the history - it seems crazy to build Node
> with cross-platform JavaScript, targeting a proprietary CPU
> architecture. Coming from an Open community, I would
> appreciate any historical context, if you have insight.
> It looks like Mozilla forked NodeJS (SpiderNode) with a
> a less proprietary JavaScript engine (SpiderMonkey) for
> potentially better cross-platform characteristics.
>
> I don't understand the history - it seems crazy to build Node
> with cross-platform JavaScript, targeting a proprietary CPU
> architecture. Coming from an Open community, I would
> appreciate any historical context, if you have insight.
I admit I don't quite understand the question.
If it's why Node and V8 don't run on SPARC, the answer is "because
it's too niche".
If it's why Node uses V8 and not SpiderMonkey, well, you should ask
Ryan but there are a couple of reasons (V8 being a hell of a lot
faster at the time, having a better API, etc.).
> We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
> a non-blocking framework compatible with SPARC and Intel.
> ARM is a bonus, people have Node running on embedded
> systems like re-purposed router appliances (i.e. OpenWRT?)
>
> Is there decent cooperation between the SpiderNode
> and NodeJS teams, to provide users the ability to
> build Node applications under multiple platforms?
SpiderNode kind of petered out (it was only a hobby project for the
people working on it) so there is not much to cooperate on, I'm
afraid.
Dave
Dec 29, 2011, 2:16:29 PM12/29/11
to nodejs
On Dec 28, 11:01 am, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
so closely to a single JavaScript Engine vendor, when there
are so many other JavaScript Engines out there.
I understand the preference may have been driven by performance,
but the more I read on the history of some community members
wanting more platform choices and Node contributors walking
out of meetings - it makes me wonder.
- I know some Node developers are from Sun, who may
be disinterested [have an axe to grind] with Oracle.
- Some may be Google enthusiasts, who may not
be so interested in seeing non-Google engines used.
- Some may just be Intel bigots, pushing for the death
of Open Systems based upon open CPU architectures
I am really trying to understand why Node is where it is
today and what is keeping Node from being cross-platform.
If the core team and contributors have made up their mind
and non-Intel platforms are forever cut out of the loop, I think
people need to understand that.
> > We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
> > a non-blocking framework compatible with SPARC and Intel.
> > ARM is a bonus, people have Node running on embedded
> > systems like re-purposed router appliances (i.e. OpenWRT?)
>
> > Is there decent cooperation between the SpiderNode
> > and NodeJS teams, to provide users the ability to
> > build Node applications under multiple platforms?
>
> SpiderNode kind of petered out (it was only a hobby project for the
> people working on it) so there is not much to cooperate on, I'm afraid.
Is there less antagonism towards people who want to use Node,
but have multi-vendor open systems production environments?
I am trying to gauge how close the community is to turning up Node on
other platforms, or whether I should just stop bothering to figure out
whether I can contribute or just wait another 6 months until I can.
> On Wed, Dec 28, 2011 at 15:59, Dave <davidha...@gmail.com> wrote:
> > It looks like Mozilla forked NodeJS (SpiderNode) with a
> > a less proprietary JavaScript engine (SpiderMonkey) for
> > potentially better cross-platform characteristics.
>
> > I don't understand the history - it seems crazy to build Node
> > with cross-platform JavaScript, targeting a proprietary CPU
> > architecture. Coming from an Open community, I would
> > appreciate any historical context, if you have insight.
>
> I admit I don't quite understand the question.
I guess I do not understand the design decision to bind Node
> > It looks like Mozilla forked NodeJS (SpiderNode) with a
> > a less proprietary JavaScript engine (SpiderMonkey) for
> > potentially better cross-platform characteristics.
>
> > I don't understand the history - it seems crazy to build Node
> > with cross-platform JavaScript, targeting a proprietary CPU
> > architecture. Coming from an Open community, I would
> > appreciate any historical context, if you have insight.
>
> I admit I don't quite understand the question.
so closely to a single JavaScript Engine vendor, when there
are so many other JavaScript Engines out there.
I understand the preference may have been driven by performance,
but the more I read on the history of some community members
wanting more platform choices and Node contributors walking
out of meetings - it makes me wonder.
- I know some Node developers are from Sun, who may
be disinterested [have an axe to grind] with Oracle.
- Some may be Google enthusiasts, who may not
be so interested in seeing non-Google engines used.
- Some may just be Intel bigots, pushing for the death
of Open Systems based upon open CPU architectures
I am really trying to understand why Node is where it is
today and what is keeping Node from being cross-platform.
If the core team and contributors have made up their mind
and non-Intel platforms are forever cut out of the loop, I think
people need to understand that.
> > We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
> > a non-blocking framework compatible with SPARC and Intel.
> > ARM is a bonus, people have Node running on embedded
> > systems like re-purposed router appliances (i.e. OpenWRT?)
>
> > Is there decent cooperation between the SpiderNode
> > and NodeJS teams, to provide users the ability to
> > build Node applications under multiple platforms?
>
> SpiderNode kind of petered out (it was only a hobby project for the
> people working on it) so there is not much to cooperate on, I'm afraid.
but have multi-vendor open systems production environments?
I am trying to gauge how close the community is to turning up Node on
other platforms, or whether I should just stop bothering to figure out
whether I can contribute or just wait another 6 months until I can.
mscdex
Dec 29, 2011, 2:42:24 PM12/29/11
to nodejs
On Dec 29, 2:16 pm, Dave <davidha...@gmail.com> wrote:
> [...]
personally used node on ARM before.
> [...]
> I am really trying to understand why Node is where it is
> today and what is keeping Node from being cross-platform.
>
> If the core team and contributors have made up their mind
> and non-Intel platforms are forever cut out of the loop, I think
> people need to understand that.
To be fair, V8 is also compatible with ARM and MIPS and I have
> today and what is keeping Node from being cross-platform.
>
> If the core team and contributors have made up their mind
> and non-Intel platforms are forever cut out of the loop, I think
> people need to understand that.
personally used node on ARM before.
Tim Caswell
Dec 29, 2011, 3:16:36 PM12/29/11
to nod...@googlegroups.com
I don't believe anyone is purposely excluding various platforms for
political or business reasons. It's simply a matter of prioritising
limited resources. The V8 team is paid to make an engine for a
desktop browser (we see this focus with the recent hash security
vulnerability and their response). How many desktop systems run on
anything other than intel and arm systems?
political or business reasons. It's simply a matter of prioritising
limited resources. The V8 team is paid to make an engine for a
desktop browser (we see this focus with the recent hash security
vulnerability and their response). How many desktop systems run on
anything other than intel and arm systems?
As far as node using V8, it was the best at the time, and changing is
just too expensive to be worth the cost for most people. I'd write a
spidernode just for the fun of it if I had the time (it can't be much
harder than my luvit project) If I did do a node version based on
spider monkey, I would do it different than the last attempt. I would
re-implement all the libuv bindings from scratch using SM native APIs.
Yes this means that native addons written for V8 won't work in this
new node port, but that's ok.
-Tim Caswell
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
Dean Landolt
Dec 29, 2011, 3:22:40 PM12/29/11
to nod...@googlegroups.com
On Thu, Dec 29, 2011 at 2:16 PM, Dave <david...@gmail.com> wrote:
On Dec 28, 11:01 am, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> On Wed, Dec 28, 2011 at 15:59, Dave <davidha...@gmail.com> wrote:I guess I do not understand the design decision to bind Node
> > It looks like Mozilla forked NodeJS (SpiderNode) with a
> > a less proprietary JavaScript engine (SpiderMonkey) for
> > potentially better cross-platform characteristics.
>
> > I don't understand the history - it seems crazy to build Node
> > with cross-platform JavaScript, targeting a proprietary CPU
> > architecture. Coming from an Open community, I would
> > appreciate any historical context, if you have insight.
>
> I admit I don't quite understand the question.
so closely to a single JavaScript Engine vendor, when there
are so many other JavaScript Engines out there.
I think Ben answered this question pretty clearly: practicality.
I understand the preference may have been driven by performance,
but the more I read on the history of some community members
wanting more platform choices and Node contributors walking
out of meetings - it makes me wonder.
What meetings? I've been around from the community from the beginning and I've never heard of this.
- I know some Node developers are from Sun, who may
be disinterested [have an axe to grind] with Oracle.
- Some may be Google enthusiasts, who may not
be so interested in seeing non-Google engines used.
- Some may just be Intel bigots, pushing for the death
of Open Systems based upon open CPU architectures
I am really trying to understand why Node is where it is
today and what is keeping Node from being cross-platform.
If the core team and contributors have made up their mind
and non-Intel platforms are forever cut out of the loop, I think
people need to understand that.
Is there less antagonism towards people who want to use Node,
> > We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
> > a non-blocking framework compatible with SPARC and Intel.
> > ARM is a bonus, people have Node running on embedded
> > systems like re-purposed router appliances (i.e. OpenWRT?)
>
> > Is there decent cooperation between the SpiderNode
> > and NodeJS teams, to provide users the ability to
> > build Node applications under multiple platforms?
>
> SpiderNode kind of petered out (it was only a hobby project for the
> people working on it) so there is not much to cooperate on, I'm afraid.
but have multi-vendor open systems production environments?
Antagonism? That's a little strong, wouldn't you say? No need to assume bad faith -- I'd defer to the open source software equivalent of Hanlon's Razor: never attribute to malice that which is adequately explained by a lack of resources.
Dave
Jan 2, 2012, 4:37:45 PM1/2/12
to nodejs
On Dec 29, 3:22 pm, Dean Landolt <d...@deanlandolt.com> wrote:
> > I understand the preference may have been driven by performance,
> > but the more I read on the history of some community members
> > wanting more platform choices and Node contributors walking
> > out of meetings - it makes me wonder.
>
> What meetings? I've been around from the community
> from the beginning and I've never heard of this.
I was trying not to implicate anyone, which is why I was generic -
during "Mozilla Person Secret Talk" at "NodeConf 2011".
> > > > We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
> > > > a non-blocking framework compatible with SPARC and Intel.
> > > > ARM is a bonus, people have Node running on embedded
> > > > systems like re-purposed router appliances (i.e. OpenWRT?)
>
> > > > Is there decent cooperation between the SpiderNode
> > > > and NodeJS teams, to provide users the ability to
> > > > build Node applications under multiple platforms?
>
> > > SpiderNode kind of petered out (it was only a hobby project for the
> > > people working on it) so there is not much to cooperate on, I'm afraid.
>
> > Is there less antagonism towards people who want to use Node,
> > but have multi-vendor open systems production environments?
>
> Antagonism? That's a little strong, wouldn't you say?
A poor choice of words on my part.
One (or more) suggested they would walk out if "SpiderNode"
was discussed at the "Mozilla Person Secret Talk" during
"NodeConf 2011" and walked out when it was discussed.
I am uncertain how to properly characterize the observation in
writing.
> > I am trying to gauge how close the community is to turning up Node
> > on other platforms, or whether I should just stop bothering to figure
> > out whether I can contribute or just wait another 6 months until I can.
I believe a contribution may be pending from SpiderNode in May 2011.
Coupled with talk including SpiderNode at "NodeConf 2011", this may
be a contributing factor to why SpiderNode "petered out", after
positive
press in the trade journals for both NodeJS and SpiderNode.
If people resume actively working SpiderNode, will contributions
required
to support other CPU architectures via the alternate JavaScript engine
be
readily received up-stream? (No one wants a fork, just compatibility.)
Would core Node developers prefer another path to supporting other
CPU architectures?
Dave
http://netmgt.blogspot.com/
> On Thu, Dec 29, 2011 at 2:16 PM, Dave <davidha...@gmail.com> wrote:
> > On Dec 28, 11:01 am, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> > > On Wed, Dec 28, 2011 at 15:59, Dave <davidha...@gmail.com> wrote:
> > > > It looks like Mozilla forked NodeJS (SpiderNode) with a
> > > > a less proprietary JavaScript engine (SpiderMonkey) for
> > > > potentially better cross-platform characteristics.
>
> > > > I don't understand the history - it seems crazy to build Node
> > > > with cross-platform JavaScript, targeting a proprietary CPU
> > > > architecture. Coming from an Open community, I would
> > > > appreciate any historical context, if you have insight.
>
> > > I admit I don't quite understand the question.
>
> > I guess I do not understand the design decision to bind Node
> > so closely to a single JavaScript Engine vendor, when there
> > are so many other JavaScript Engines out there.
>
> I think Ben answered this question pretty clearly: practicality.
If that's it, then that's great!!!
> > On Dec 28, 11:01 am, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> > > On Wed, Dec 28, 2011 at 15:59, Dave <davidha...@gmail.com> wrote:
> > > > It looks like Mozilla forked NodeJS (SpiderNode) with a
> > > > a less proprietary JavaScript engine (SpiderMonkey) for
> > > > potentially better cross-platform characteristics.
>
> > > > I don't understand the history - it seems crazy to build Node
> > > > with cross-platform JavaScript, targeting a proprietary CPU
> > > > architecture. Coming from an Open community, I would
> > > > appreciate any historical context, if you have insight.
>
> > > I admit I don't quite understand the question.
>
> > I guess I do not understand the design decision to bind Node
> > so closely to a single JavaScript Engine vendor, when there
> > are so many other JavaScript Engines out there.
>
> I think Ben answered this question pretty clearly: practicality.
> > I understand the preference may have been driven by performance,
> > but the more I read on the history of some community members
> > wanting more platform choices and Node contributors walking
> > out of meetings - it makes me wonder.
>
> What meetings? I've been around from the community
> from the beginning and I've never heard of this.
during "Mozilla Person Secret Talk" at "NodeConf 2011".
> > > > We don't need a lot - NET-SNMP hooks, ICMP, HTTP, and
> > > > a non-blocking framework compatible with SPARC and Intel.
> > > > ARM is a bonus, people have Node running on embedded
> > > > systems like re-purposed router appliances (i.e. OpenWRT?)
>
> > > > Is there decent cooperation between the SpiderNode
> > > > and NodeJS teams, to provide users the ability to
> > > > build Node applications under multiple platforms?
>
> > > SpiderNode kind of petered out (it was only a hobby project for the
> > > people working on it) so there is not much to cooperate on, I'm afraid.
>
> > Is there less antagonism towards people who want to use Node,
> > but have multi-vendor open systems production environments?
>
> Antagonism? That's a little strong, wouldn't you say?
One (or more) suggested they would walk out if "SpiderNode"
was discussed at the "Mozilla Person Secret Talk" during
"NodeConf 2011" and walked out when it was discussed.
I am uncertain how to properly characterize the observation in
writing.
> > I am trying to gauge how close the community is to turning up Node
> > on other platforms, or whether I should just stop bothering to figure
> > out whether I can contribute or just wait another 6 months until I can.
Coupled with talk including SpiderNode at "NodeConf 2011", this may
be a contributing factor to why SpiderNode "petered out", after
positive
press in the trade journals for both NodeJS and SpiderNode.
If people resume actively working SpiderNode, will contributions
required
to support other CPU architectures via the alternate JavaScript engine
be
readily received up-stream? (No one wants a fork, just compatibility.)
Would core Node developers prefer another path to supporting other
CPU architectures?
Dave
http://netmgt.blogspot.com/
Ben Noordhuis
Jan 2, 2012, 6:26:36 PM1/2/12
to nod...@googlegroups.com
On Mon, Jan 2, 2012 at 22:37, Dave <david...@gmail.com> wrote:
> On Dec 29, 3:22 pm, Dean Landolt <d...@deanlandolt.com> wrote:
>> On Thu, Dec 29, 2011 at 2:16 PM, Dave <davidha...@gmail.com> wrote:
>> > I understand the preference may have been driven by performance,
>> > but the more I read on the history of some community members
>> > wanting more platform choices and Node contributors walking
>> > out of meetings - it makes me wonder.
>>
>> What meetings? I've been around from the community
>> from the beginning and I've never heard of this.
>
> I was trying not to implicate anyone, which is why I was generic -
> during "Mozilla Person Secret Talk" at "NodeConf 2011".
> On Dec 29, 3:22 pm, Dean Landolt <d...@deanlandolt.com> wrote:
>> On Thu, Dec 29, 2011 at 2:16 PM, Dave <davidha...@gmail.com> wrote:
>> > I understand the preference may have been driven by performance,
>> > but the more I read on the history of some community members
>> > wanting more platform choices and Node contributors walking
>> > out of meetings - it makes me wonder.
>>
>> What meetings? I've been around from the community
>> from the beginning and I've never heard of this.
>
> I was trying not to implicate anyone, which is why I was generic -
> during "Mozilla Person Secret Talk" at "NodeConf 2011".
That wasn't a meeting, that was Brendan Eich's talk about SpiderNode.
I wouldn't read too much into it, people walk out of talks all the
time (including mine *sigh*).
> I believe a contribution may be pending from SpiderNode in May 2011.
> Coupled with talk including SpiderNode at "NodeConf 2011", this may
> be a contributing factor to why SpiderNode "petered out", after
> positive press in the trade journals for both NodeJS and SpiderNode.
That contribution was a performance improvement for a number of edge
cases, not anything crucial.
Let me reiterate that AFAIK it's simply a lack of time and resources.
Feel free to ask the SpiderNode guys, they hang out in our IRC
channel.
> If people resume actively working SpiderNode, will contributions
> required to support other CPU architectures via the alternate JavaScript engine
> be readily received up-stream? (No one wants a fork, just compatibility.)
No. There is simply not enough developer capacity to maintain two JS engines.
> Would core Node developers prefer another path to supporting other
> CPU architectures?
Yes. Port V8 to SPARC. That's a non-trivial task so ping the V8 guys
before you start. They focus mostly on x86 and ARM and might not be
interested in SPARC support.
Even then, support in Node will be on a 'best effort' basis (unless
you're willing to enter into a support contract with Joyent). Like I
said, there is only so much developer capacity to go around and it
doesn't make sense to spend a lot of time on an architecture that only
a handful of people use.
Case study: MIPS. I test it from time to time but it's a futile
effort. I know of exactly one other guy that runs Node on MIPS. :-/
Ilya Dmitrichenko
May 14, 2012, 4:49:05 PM5/14/12
to nod...@googlegroups.com
Hey,
Being an old thread, but I thought I should mention that Node.js 0.6.14 is known to run on MIPS:
and one might want to run it on something like NetLogin multi-core MIPS64:
Also, if the original poster, David, is still interested in "a non-blocking framework compatible with SPARC and Intel", may he should try Vert.x (http://vertx.io/), which will run very well on Solaris/SPARC within the JVM :)
Cheers,
--
Ilya
Dave
May 15, 2012, 6:27:59 PM5/15/12
to nodejs
Hi Ilya,
Old thread, but very thankful for the reply.
NodeJS Vert-X Business-Need
Yes......Yes.... Intel Solaris
No.......Yes.... SPARC Solaris
Yes..... Yes.... Non-Blocking File API
Yes..... Yes.... Non-Blocking HTTP API
??....... ??..... Non-Blocking ICMP API
??....... ??..... Non-Blocking SNMP API
Are there non-blocking API's for NodeJS or Vert-X for stateless ICMP
and SNMP?
The inclusion of a JVM for Vert-X (vs V8 on NodeJS) is a huge bonus,
since SNMPv3 requires encryption, and the Java framework will
transparently support the dozens of crypto cores native to the SPARC T
processors.
Appreciate of additional guidance,
Dave
http://netmgt.blogspot.com/
On May 14, 3:49 pm, Ilya Dmitrichenko <errordevelo...@gmail.com>
wrote:
> Ilya
Old thread, but very thankful for the reply.
NodeJS Vert-X Business-Need
Yes......Yes.... Intel Solaris
No.......Yes.... SPARC Solaris
Yes..... Yes.... Non-Blocking File API
Yes..... Yes.... Non-Blocking HTTP API
??....... ??..... Non-Blocking ICMP API
??....... ??..... Non-Blocking SNMP API
Are there non-blocking API's for NodeJS or Vert-X for stateless ICMP
and SNMP?
The inclusion of a JVM for Vert-X (vs V8 on NodeJS) is a huge bonus,
since SNMPv3 requires encryption, and the Java framework will
transparently support the dozens of crypto cores native to the SPARC T
processors.
Appreciate of additional guidance,
Dave
http://netmgt.blogspot.com/
On May 14, 3:49 pm, Ilya Dmitrichenko <errordevelo...@gmail.com>
wrote:
mscdex
May 15, 2012, 7:30:15 PM5/15/12
to nodejs
On May 15, 6:27 pm, Dave <davidha...@gmail.com> wrote:
> ??....... ??..... Non-Blocking SNMP API
>
> Are there non-blocking API's for NodeJS or Vert-X for stateless ICMP
> and SNMP?
Since SNMP uses UDP, it most definitely is non-blocking in node. Also
> ??....... ??..... Non-Blocking SNMP API
>
> Are there non-blocking API's for NodeJS or Vert-X for stateless ICMP
> and SNMP?
there are currently a few different snmp modules available in npm.
Recently I have thought about writing a binding to Net-SNMP.
Ilya Dmitrichenko
May 31, 2012, 6:52:23 PM5/31/12
to nod...@googlegroups.com
On Tuesday, 15 May 2012 23:27:59 UTC+1, Dave wrote:
Hi Ilya,
Old thread, but very thankful for the reply.
NodeJS Vert-X Business-Need
Yes......Yes.... Intel Solaris
No.......Yes.... SPARC Solaris
Yes..... Yes.... Non-Blocking File API
Yes..... Yes.... Non-Blocking HTTP API
Yeah, that's awesome :)
??....... ??..... Non-Blocking ICMP API
??....... ??..... Non-Blocking SNMP API
Though, I'd say that might have to implement those yourself in Node ...
I had been actually looking into catching ICMP responses in Node and,
as far as I remember, that when I found this thread :) Hence there is no
ICMP support as of yet as I can tell.
I regards to SNMP - I sort of recollect seeing some SNMP module for Node.
In terms of vert.x, there is currently no UDP support out of the box.
But I'm guessing that it shouldn't to difficult to add, i.e. wrap around Java's
native UDP API. Or, perhaps, you could even wrap on top of some of the
existing libraries for SNMP. I regards to ICMP, I'm sure that's gotta be in JDK :)
Are there non-blocking API's for NodeJS or Vert-X for stateless ICMP
and SNMP?
The inclusion of a JVM for Vert-X (vs V8 on NodeJS) is a huge bonus,
since SNMPv3 requires encryption, and the Java framework will
transparently support the dozens of crypto cores native to the SPARC T
processors.
Yeah, that's work. Actually, in regards to Node's crypt module - you should
be to far off with that either, it's binds to OpenSSL and that supports AES
instruction set (at least on x86), though since version 1.0.1, hence Node
v0.7.8 has the latest OpenSSL :)
Reply all
Reply to author
Forward
0 new messages