- Non-blocking TCP sockets (using IOCP on Windows)
- Non-blocking named pipes
diff --git a/doc/blog/Uncategorized/profiling-node-js.md b/doc/blog/Uncategorized/profiling-node-js.md
index abb51da26e..6f041af3b9 100644
--- a/doc/blog/Uncategorized/profiling-node-js.md
+++ b/doc/blog/Uncategorized/profiling-node-js.md
@@ -32,7 +32,7 @@ This is a visualization of all of the profiled call stacks. This example is from
That's the summary. There are a few prerequisites:
- - You must gather data on a system that supports DTrace with the Node.js ustack helper. For now, this pretty much means illumos-based systems like SmartOS, including the Joyent Cloud. MacOS users: OS X supports DTrace, but not ustack helpers. The way to get this changed is to contact your Apple developer liason (if you're lucky enough to have one) or file a bug report at bugreport.apple.com. I'd suggest referencing existing bugs 5273057 and 11206497. More bugs filed (even if closed as dups) show more interest and make it more likely Apple will choose to fix this.
+ - You must gather data on a system that supports DTrace with the Node.js ustack helper. For now, this pretty much means illumos-based systems like SmartOS, including the Joyent Cloud. MacOS users: OS X supports DTrace, but not ustack helpers. The way to get this changed is to contact your Apple developer liaison (if you're lucky enough to have one) or file a bug report at bugreport.apple.com. I'd suggest referencing existing bugs 5273057 and 11206497. More bugs filed (even if closed as dups) show more interest and make it more likely Apple will choose to fix this.
- You must be on 32-bit Node.js 0.6.7 or later, built
--with-dtrace. The helper doesn't work with 64-bit Node yet. On illumos (including SmartOS), development releases (the 0.7.x train) include DTrace support by default.
diff --git a/doc/blog/Uncategorized/trademark.md b/doc/blog/Uncategorized/trademark.md
index 1bc177b589..7494915be1 100644
--- a/doc/blog/Uncategorized/trademark.md
+++ b/doc/blog/Uncategorized/trademark.md
@@ -5,13 +5,13 @@ status: publish
category: Uncategorized
slug: trademark
-One of the things Joyent accepted when we took on the Node project was to provide resources to help the community grow. The Node project is amazing because of the expertize, dedication and hard work of the community. However in all communities there is the possibility of people acting inappropriately. We decided to introduce trademarks on the “Node.js” and the “Node logo” in order to ensure that people or organisations who are not investing in the Node community misrepresent, or create confusion about the role of themselves or their products with Node.
+One of the things Joyent accepted when we took on the Node project was to provide resources to help the community grow. The Node project is amazing because of the expertise, dedication and hard work of the community. However in all communities there is the possibility of people acting inappropriately. We decided to introduce trademarks on the “Node.js” and the “Node logo” in order to ensure that people or organisations who are not investing in the Node community misrepresent, or create confusion about the role of themselves or their products with Node.
We are big fans of the people who have contributed to Node and we have worked hard to make sure that existing members of the community will be unaffected by this change. For most people they don’t have to do anything they are free to use the Node.js marks in their free open source projects (see guidelines). For others we’ve already granted them licenses to use Node.js marks in their domain names and their businesses. We value all of these contributions to the Node community and hope that we can continue to protect their good names and hard work.
Where does our trademark policy come from? We started by looking at popular open source foundations like the Apache Software Foundation and Linux. By strongly basing our policy on the one used by the Apache Software Foundation we feel that we’ve created a policy which is liberal enough to allow the open source community to easily make use of the mark in the context of free open source software, but secure enough to protect the community’s work from being misrepresented by other organisations.
-While we realise that any changes involving lawyers can be intimidating to the community we want to make this transition as smoothly as possible and welcome your questions and feedback on the policy and how we are implementing it.
+While we realize that any changes involving lawyers can be intimidating to the community we want to make this transition as smoothly as possible and welcome your questions and feedback on the policy and how we are implementing it.
http://nodejs.org/trademark-policy.pdf
trademark@joyent.com
diff --git a/doc/blog/npm/managing-node-js-dependencies-with-shrinkwrap.md b/doc/blog/npm/managing-node-js-dependencies-with-shrinkwrap.md
index 403eada642..d48afab5a0 100644
--- a/doc/blog/npm/managing-node-js-dependencies-with-shrinkwrap.md
+++ b/doc/blog/npm/managing-node-js-dependencies-with-shrinkwrap.md
@@ -149,7 +149,7 @@ DESCRIPTION
Of course, the details of each use case matter a lot, and the world doesn't have to pick just one solution. If you like checking in node_modules, you should keep doing that. We've chosen the shrinkwrap route because that works better for us.
-It's not exactly news that Joyent is heavy on Node. Node is the heart of our SmartDataCenter (SDC) product, whose public-facing web portal, public API, Cloud Analytics, provisioning, billing, heartbeating, and other services are all implemented in Node. That's why it's so important to us to have robust components (like logging and REST) and tools for understanding production failures post mortem, profile Node apps in production, and now managing Node dependencies. Again, we're interested to hear feedback from others using these tools.
+
It's not exactly news that Joyent is heavy on Node. Node is the heart of our SmartDataCenter (SDC) product, whose public-facing web portal, public API, Cloud Analytics, provisioning, billing, heartbeating, and other services are all implemented in Node. That's why it's so important to us to have robust components (like logging and REST) and tools for understanding production failures postmortem, profile Node apps in production, and now managing Node dependencies. Again, we're interested to hear feedback from others using these tools.
diff --git a/doc/blog/npm/npm-1-0-link.md b/doc/blog/npm/npm-1-0-link.md
index 9e5c3c8e7f..095ecb58b2 100644
--- a/doc/blog/npm/npm-1-0-link.md
+++ b/doc/blog/npm/npm-1-0-link.md
@@ -23,7 +23,7 @@ slug: npm-1-0-link
It was easy enough to point that symlink to a different location. However, since the package.json file could change, that meant that the connection between the version and the folder was not reliable.
-At first, this was just sort of something that we dealt with by saying, “Relink if you change the version.” However, as more and more edge cases arose, eventually the solution was to give link packages this fakey version of “9999.0.0-LINK-hash” so that npm knew it was an imposter. Sometimes the package was treated as if it had the 9999.0.0 version, and other times it was treated as if it had the version specified in the package.json.
+At first, this was just sort of something that we dealt with by saying, “Relink if you change the version.” However, as more and more edge cases arose, eventually the solution was to give link packages this fakey version of “9999.0.0-LINK-hash” so that npm knew it was an impostor. Sometimes the package was treated as if it had the 9999.0.0 version, and other times it was treated as if it had the version specified in the package.json.
A better way
diff --git a/doc/blog/release/node-v0-4-6.md b/doc/blog/release/node-v0-4-6.md
index 964f3a2e93..12d0072836 100644
--- a/doc/blog/release/node-v0-4-6.md
+++ b/doc/blog/release/node-v0-4-6.md
@@ -11,7 +11,7 @@ slug: node-v0-4-6
- Auto completion of built-in debugger suggests prefix match rather than partial match. (koichik)
- circular reference in vm modules. #822 (Jakub Lekstan)
- http response.readable should be false after 'end' #867 (Abe Fettig)
-
- Implemenet os.cpus() and os.uptime() on Solaris (Scott McWhirter)
+
- Implement os.cpus() and os.uptime() on Solaris (Scott McWhirter)
- fs.ReadStream: Allow omission of end option for range reads #801 (Felix Geisendörfer)
- Buffer.write() with UCS-2 should not be write partial char #916 (koichik)
- Pass secureProtocol through on tls.Server creation (Theo Schlossnagle)
diff --git a/doc/blog/release/node-v0-7-0-unstable.md b/doc/blog/release/node-v0-7-0-unstable.md
index 2bf3ad59cf..5b768e70f0 100644
--- a/doc/blog/release/node-v0-7-0-unstable.md
+++ b/doc/blog/release/node-v0-7-0-unstable.md
@@ -12,7 +12,7 @@ slug: node-v0-7-0-unstable
- Upgrade V8 to 3.8.6
- Use GYP build system on unix (Ben Noordhuis)
-
- Experimenetal isolates support (Ben Noordhuis)
+
- Experimental isolates support (Ben Noordhuis)
- Improvements to Cluster API (Andreas Madsen)
- Use isolates for internal debugger (Fedor Indutny)
- Bug fixes
diff --git a/doc/blog/release/v0.8.1.md b/doc/blog/release/v0.8.1.md
index b8c84e20dd..0ce631efed 100644
--- a/doc/blog/release/v0.8.1.md
+++ b/doc/blog/release/v0.8.1.md
@@ -12,7 +12,7 @@ date: 2012.06.29
- Support for parallel use of the cache folder
- Retry on registry timeouts or network failures (Trent Mick)
- Reduce 'engines' failures to a warning
- - Use new zsh completion if aviailable (Jeremy Cantrell)
+ - Use new zsh completion if available (Jeremy Cantrell)
* Fix #3577 Un-break require('sys')