Sadly the remote ssh and a few other MS extensions don't work with VSCodium
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.
That was my first thought too - the majority of the value I get out of VS is via this.
Though I believe there is another IDE that has similar...forgot which one. So at least not a monopoly
Emacs' version is more flexible and a little more quirky. I would guess that like many VSCode features, Emacs was the inspiration here.
https://www.emacswiki.org/emacs/TrampMode
Tons of IDEs and editors have SFTP sync plugins that can work sort of automatically, but that's pretty different.
Code-Server works surprisingly well anyways, but with VSCode built on Electron I guess it's not that much of a surprise.
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).
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.
"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."
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.
> 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.
Probably someone who has no deadlines.
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.
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.