Change:
## Quick start - local <del> 1. Install Docker Desktop or Docker on your local machine. (See [docs](https://aka.ms/vscode-remote/containers/getting-started) for additional details.) </del> <ins> 1. Install Docker Desktop or Docker for Linux on your local machine. (See [docs](https://aka.ms/vscode-remote/containers/getting-started) for additional details.) </ins> <del> 2. [Docker Desktop] If you are not using the new WSL2 Docker Desktop engine, increase the resources allocated to Docker Desktop to at least **4 Cores and 4 GB of RAM (8 GB recommended)**. Right-click on the Docker status bar item, go to **Preferences/Settings > Resources > Advanced** to do so. </del> <ins> 2. **Important**: Docker needs at least **4 Cores and 6 GB of RAM (8 GB recommended)** to run full build. If you on macOS, or using the old Hyper-V engine for Windows, update these values for Docker Desktop by right-clicking on the Docker status bar item, going to **Preferences/Settings > Resources > Advanced**. </ins> > **Note:** The [Resource Monitor](https://marketplace.visualstudio.com/items?itemName=mutantdino.resourcemonitor) extension is included in the container so you can keep an eye on CPU/Memory in the status bar.

Discussion:
Testing I don't have a linux dev setup so I figured running smoke tests on linux is a good scenario for our own dev container. However, I failed a few times and eventually gave up enough resources. the readme explains this but not clear enough, e.g you cannot run without tweak the docker settings issues, e.g I have seen this after compiling and bundling for 20minutes <img width="711" alt="Screenshot 2020-06-30 at 11 06 32" src="https://user-"failure to run the smoke test (see below)
did you Open the VS Code repository into Volume?
Yeah breaking this down: looks like was getting used with some of the commands. This can cause folders that were created to be locked to root rather than the current user in the container. That could cause the permission issue. Erich mentioned, using the open reop in container option will dramatically speed things up on macOS and Windows (with the Hyper-V engine) and RAM and CPU need to be increased - I can make the guidance there even stronger. FWIW - I saw 6 mins for and 8 mins for w/4 cores and 8GB of RAM allocated on a 2015 MBP w/16 GB RAM and Sophos AV running. Note that compiling native modules during and max out CPU at certain points and hit ~7.12GB of RAM, so it's undoubtedly getting resource constrained at times. tests did fail - but it looks to me like some sort of bug in the test code. I don't know the test code - but I wonder looking at the logs if the wrong folder is getting created. In the log: And then later... Should test data have been to instead of or vice versa?
Nope. Tho, to my understanding that helps with IO. That's a nice boost but the blocker is that 2GB of RAM aren't enough to compile vscode, the compiler will simply crash at one point. Yeah, I ended up running the build (gulp vscode-linux-x64) with sudo because it failed with permission trouble before. Then I ran the tests as sudo because I was worries about exactly the issues that a normal user cannot access sudo-folders. I don't know the code either but I assume that it works ;-)
Yeah, totally agree there. Making sure the long build times weren't something else.

Can make that much more visible in the READMEs. Strange, yeah I haven't been able to repro that. Debugging a bit it seems like this other path is the handle for the driver. It seems to get past spawning Code and then fails connecting and gives up after 50 tries. Not sure yet why it's failing when does not.
On top of that, I was thinking to add a message to the build script (independent of dev containers) that checks that there is enough RAM to proceed.
Good idea. I also found the problem. Chrome sandboxing doesn't work in containers. So, the test needs to have passed in. After that it works though there's 4 failed tests (unknown if this is something container related). Here's the update. In : EDIT: I also found that you really need 6GB to do the smoke test. Even 4 isn't quite enough, so I can bump up that recommendation.
Even better, it looks like the problem is the default settings. This appears to resolve it in : I think you do have to chown to root and set permissions like you would normally in Linux. I'll play a bit more, but it took a while to figure out since the error was hidden. Now it's just a question of what the best solution is.