Merge branch 'master' of https://github.com/Microsoft/vscode-docs-pr

Author: Greg Van Liew

api/advanced-topics/remote-extensions.md

@@ -44,11 +44,13 @@ Follow these steps:
 
 ### Debugging your extension in a remote environment
 
+Normally when you build an extension, you edit, launch, and debug it all on your local machine. Debugging your extension in a remote environment follows this same pattern. You will just edit, launch, and debug your extension all on a remote machine, container, or in WSL instead of your local machine.
+
 #### Using a development container
 
 You can edit and debug your extension in a container by following these steps.
 
-1. Add the Node.js dev container definition to your extension folder by pressing `kbstyle(F1)`, selecting the **Remote-Containers: Create Configuration File...** command, and picking **Node.js 8 & TypeScript** (or just Node.js 8 if you are not using TypeScript).
+1. Add the Node.js dev container definition to your extension folder by pressing `kbstyle(F1)`, selecting the **Remote-Containers: Create Configuration File...** command, and picking **Node.js 8 & TypeScript** (or just Node.js 8 if you are not using TypeScript). This will define the container you will use edit, debug, and test the extension.
 
 2. After this command runs, you can modify the contents of the `.devcontainer` folder to include additional build or runtime requirements. See the [in-depth Remote-Containers documentation](/docs/remote/containers#_indepth-setting-up-a-folder-to-run-in-a-container) for details.
 
@@ -71,9 +73,9 @@ You can edit and debug your extension in a container by following these steps.
     }
     ```
 
-4. Run **Remote-Containers: Reopen Folder in Container** and in a moment, VS Code will set up the container and connect. You can now edit your source code as you would in the local case.
+4. Run **Remote-Containers: Reopen Folder in Container** and in a moment, VS Code will set up the container and connect. You will now be able to develop your source code from inside the container just as you would in the local case.
 
-5. Finally, press `kbstyle(F5)` or use the **Debug view** to launch the extension and attach the debugger as you would locally. The window that appears now contains your extension running inside this same container with the debugger attached to it.
+5. Finally, press `kbstyle(F5)` or use the **Debug view** to launch the extension inside this same container and attach the debugger. You will be able to interact with it just as you would in the local case, but from inside the development container you defined in step 1 instead.
 
 #### Using SSH or WSL
 

docs/remote/troubleshooting.md

@@ -237,7 +237,6 @@ icacls "%FILEORFOLDERTOUPDATE%" /c /inheritance:r /grant %USERDOMAIN%\%USERNAME%
 |----|--------------|---|
 | Debian / Ubuntu | Run `sudo apt-get install openssh-server` |  See the [Ubuntu SSH](https://help.ubuntu.com/community/SSH?action=show) documentation for additional setup instructions. |
 | RHEL / Fedora / CentOS | Run `sudo yum install openssh-server && sudo systemctl start sshd.service && sudo systemctl enable sshd.service` | You may need to omit `sudo` when running in a container. |
-| macOS | Go to **System Preferences** > **Sharing**, check **Remote Login**. ||
 
 ## Container tips
 
@@ -400,7 +399,7 @@ You can use Docker and Kubernetes related CLIs and extensions from inside your d
 
 ### Adding a non-root user to your dev container
 
-Many images run as a root user by default. However, some provide non-root users, that you can optionally use instead. If your image or Dockerfile provides a non-root user that you can opt into using (for example, the default is still root), you can specify the user in one of two ways:
+Many images run as a root user by default. However, some provide one or more non-root users, that you can optionally use instead. If your image or Dockerfile provides a non-root user (but still defaults to root), you can opt into using it in one of two ways:
 
 - When referencing an `image` or `Dockerfile`, add the following to your `devcontainer.json`:
 
@@ -414,9 +413,7 @@ Many images run as a root user by default. However, some provide non-root users,
     user: user-name-goes-here
     ```
 
-Note that you do not need to do this if the default behavior of the container is to use the non-root user.
-
-For images that only provide a root user, you can automatically create a non-root user in the `Dockerfile`. For example, this snippet will create a user called `user-name-goes-here` and give it the ability to use `sudo`:
+For images that only provide a root user, you can automatically create a non-root user by using a `Dockerfile`. For example, this snippet will create a user called `user-name-goes-here`, give it the ability to use `sudo`, and set it as the default:
 
 ```Dockerfile
 ARG USERNAME=user-name-goes-here
@@ -496,7 +493,7 @@ This warning is just that, a warning. It is telling you not to parse the output
 This occurs in `Dockerfile`s because the `apt-key` command is not running from a terminal. Unfortunately, this error cannot be eliminated completely, but can be hidden unless the `apt-key` command returns a non-zero exit code (indicating a failure). For example:
 
 ```Dockerfile
-# (OUT=$(apt-key add - 2>&1) || echo $OUT) will only print the output if a non-zero exit code is hit
+# (OUT=$(apt-key add - 2>&1) || echo $OUT) will only print the output with non-zero exit code is hit
 curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | (OUT=$(apt-key add - 2>&1) || echo $OUT)
 ```