> Last - and most important for me - in industries like my own (healthcare), you work with highly regulated data that has to be stored securely, where having multiple copies of data on multiple laptops can pose an unacceptably large risk.<p>um... please tell me devs don't have access to production data in a healthcare environment (of all places!).<p>I mean, I understand the need for a representative dataset to develop and test against, but this is people's lives they're playing with!<p>And, you know, if you had a decent set of anonymised or fictitious customer data to work with, you wouldn't need to run your IDE in docker, and there would be less surface area for attackers to get to the data.
People who want to work on remote access with restricted setups, checkout Emacs. Tramp mode allows you to edit files over ssh, docker, adb etc without you worrying about anything.<p>And if you haven't tried about Org Mode, it is not exaggeration if I say it is life changing. It can help you organize notes, todos, agendas etc.
I was just playing with Coder's VS Code fork (what this solution uses for VS Code) the other day [1]<p>I want to love it. It makes a very specific use case I use much nicer. I can leave code on a remote server with all the compute power I need to build and run my project, and edit the file I'm working on with VS code's editor without having to sync files around. It does, however, have a few big caveats that killed it for me.<p>It doesn't block any of the browser things that would leave the webpage. Notably, if you hit Ctrl-W to close a file tab because of muscle memory, you'll close the browser tab. Also, if you hit back on accident like I apparently do all the time, you'll go back to the blank tab page. In both of these cases, you'll lose any unsaved state.<p>Also, the extension repo it's pointing at isn't MS's live repo. There are apparently reasons for this, but it means you don't get the latest version of extensions, which was annoying for a specific extension I've gotten used to.<p>I also had issues with VS Code getting confused about state when my connection to the remote box was less than ideal.<p>All in all, I really wanted to like it, but for truly remote cases, I'm back to using Mosh to interact with the remote box, and a simple tool I wrote ages ago to handle rsyncing the local files to the remote box to build and run them there.<p>[1] <a href="https://coder.com/" rel="nofollow">https://coder.com/</a>
Interesting case for cloud based IDEs.<p>I really don't understand the localhost use case though. I'm on MacOS. Why would I spawn a VM (docker for macos) with limited access to my system (container promise) to run an editor already running in a VM?<p>I only end up having a resources and disk space hungry, slow and inconvenient editor?
The title of the article is ever so slightly misleading.<p>It would lead one to believe that VSCode and thus by extension VSCodium could be run in Docker and accessed from a web browser<p>In fact, you can run "Coder" (<a href="https://coder.com/);" rel="nofollow">https://coder.com/);</a> a product, which according to their GitHub had some non-trivial effort put into it to make it run as such.<p>Not least of all, looking through their issue list, is the fact they compile extensions themselves and they are therefore somewhat outdated (according to issue comments from their users).<p>It's nice, but it's not VSCode per-se and sadly means no dice for Codium users.
I'd love to use the VSCode IDE launched from the host and compile C++ code within docker. Is this possible? Currently, I write code in the IDE and compile in the container from the terminal.
Imagine that, cross compile from any host in a contained c++ environment. :)<p>Edit: I use CMAKE_TOOLCHAIN_FILE to describe the target env.
Didn't anyone know it is possible to run a full blown Eclipse in the browser?<p><a href="https://www.eclipse.org/che/" rel="nofollow">https://www.eclipse.org/che/</a>
Whats the 'best' way people are using to have a total portable development environment that I can reach from home or work? Meaning having vs code, node, all the various cloud local emulators/etc that you would normally install for doing that kind of dev work.
This seems very promising. With C9 being moved to AWS soon, I might look into building an internal version of it powered by launching VSCode instances.