That one is closed source. It's kind of oddly designed - it ssh:es in to the remote host to download some binary from MS servers, executes it and then communicates with it using SSH TCP forwarding.
"Some binary" = the same version of VS Code (maybe without Electron and some other parts).
Makes sense as you need to - edit files, run tasks and terminals, and run extensions which access the remote filesystem (eg Jump To Definition taking you to header files installed in system folders) - basically everything you need VS Code to do when you run it locally.
The alternative would be running VS Code as a webserver remotely and the local VS Code Electron just acting like a browser window pointing at your server. It probably wouldn't feel as responsive.
Does SFTP let you launch processes? And if so, which ones are you going to launch - are you going to use system grep to implement searching the open folder? There's a lot of different versions of grep out there!
The way the VSCode extension works (doesn't just rely on SFTP to sync files and doesn't require anything to be preinstalled on the remote server) is closest to Transparent Remote Access, Multiple Protocols in Emacs.
Emacs' version is more flexible and a little more quirky. I would guess that like many VSCode features, Emacs was the inspiration here.
They do work with Code-Server (VSCode in Browser) though, which also works on top of the open source parts of VSCode if I'm correct? I wonder how that worked.
Code-Server works surprisingly well anyways, but with VSCode built on Electron I guess it's not that much of a surprise.
Is there an actual reason or just "reasons"? Because those extensions are extremely useful and enabling. I honestly am not sure how to live without them at this point. I use all three of the remote development extensions on a daily basis.
> I honestly am not sure how to live without them at this point.
That's exactly why. I prefer not to have a workflow which depends on proprietary software. What are you going to do if MS breaks your workflow at some point in the future and you've become dependent on it?
Not that everyone has to do that, but it's totally possible to have a FOSS workflow, and I prefer to work that way.
>> I honestly am not sure how to live without them at this point.
> That's exactly why. I prefer not to have a workflow which depends on proprietary software. What are you going to do if MS breaks your workflow at some point in the future and you've become dependent on it?
The comment you quoted is hyperbole. What is the actual worry or problem here? No other tool has the convenience of VS Code right now, so am I supposed to just use something else that has reduced functionality for me because of some nebulous worry? What's the specific worry? Because I don't see an actual one beside some strange commitment to FOSS software.
If Microsoft suddenly deletes VS Code or requires some inordinate amount of payment to keep using it, both unlikely scenarios, then I would just use something else. It's not like my world would suddenly end, my software would stop working, and I would forget how to write software. In such an unlikely case, the inconvenience would be both that VS Code goes away but then also that nothing else has such useful features.
Yeah I think it's always fine to use the most expedient tool for the job. Personally, when I am choosing what to invest my time in, I would rather choose FOSS tools which I know to be independent of corporate interests.
I admit it's a somewhat abstract risk, but what makes me hesitant about proprietary tools is not any one thing, but how you can gradually get embedded in a proprietary workflow. Maybe now it's only remote/ssh, but maybe next you're using some feature that's built on top of that, and a year down the road you're in a position where you would have to refactor your whole project structure and CI setup to use a different set of tools, and maybe convince your team to do the same.
And maybe it's a bit philosophical, but I'm not wild about how MS and others blur the lines between what's open and what's proprietary.
It's all about what you invest in. I've been working with FOSS tools for years, and it takes a while to get your workflows figured out, but I would say I am pretty fast and productive now
You don't know what they're doing and can't know updates are and will stay benign. Anyone signing an NDA that uses it is irresponsible/negligent, unless it is a controlled security exception (or firewalled in some way - but if it can't connect out half the point of the editor is gone).
Are we talking about the same Telemetry that can be turned off? If you work in such an environment, I imagine you can only use approved, audited software - so you don't have an option.
Exactly. And it's not like switching to a third-party product is anymore secure. Imagine justifying to your security and IT teams that instead of using a Microsoft product, you'd rather use a product forked from it that's developed by random people.
I actually think the opposite is security theater. I think the security question is a bit of a wash in general, but I think that in this case, yes, the Microsoft product is likely more secure. How many full time employees are working on VS Code versus VSCodium? FOSS software is not this paragon of security. And the existence of VSCodium is due to telemetry that basically reports nothing, can be inspected, and can be turned off. I don’t see where the security threat is.
This is nonsense, because it patently is security theater. Earlier I was addressing the fact that to look good to a judge or lawyer, you need to do things that are dumb but very strict. That has nothing to do with reality and we shouldn't start pretending it does: The OSS is likely better in every way than what you'll buy (even if it's just because it does the same thing but is much cheaper).
> telemetry that [...] can be inspected
The telemetry cannot be meaningfully inspected, because it may change at any time. You know what it has sent just now, not what it'll send 5 minutes from now.
> telemetry that [...] can be turned off
You cannot know that it was turned off. Historically, MS doesn't respect your choice to turn it off once and will just turn it back on later for whatever reason. Aside from that, you cannot inspect the binary in a meaningful way so you don't know what it will do 5 minutes from now.
This is a terrible take. Why on earth would you trust a closed source, corporate solution more than FOSS sostare? The FOSS solution can be audited and the closed source solution can not. Your opinion is incorrect.
"The Visual Studio Code Remote Development extensions and their related components use an open planning, issue, and feature request process, but are not currently open source. The extensions share source code which is also used in fully managed remote development services like GitHub Codespaces and their related extensions. Given that these services also will support other proprietary products (for example Visual Studio IDE), the extensions are available under a Microsoft pre-release license like other service-based, cross-product extensions such as Visual Studio IntelliCode and Visual Studio Live Share were during their preview periods."
I do a bit of arm development that runs via ssh build servers.
Do actually use VSCodium by default but still need a copy of VSCode to play nicely with all this stuff. It's a weird situation, I'd like to go full codium but it's just not possible in my case hey.
TBH, those extensions are biased enough that it's difficult to integrate them into the company-wide workflow. It works okay-ish for personal uses, but still feels kinda awkward.
