1. 18
  1.  

  2. 8

    There are some really specious assertions in here.

    I don’t use any of the extensions the author cites as the “best” parts of Visual Studio Code.

    I also use vscodium instead of the Microsoft release because it’s been blessed by my employer’s security team and is 100% open source.

    Sure, emacs and vim are amazing tools. I’ve used them productively for many years and will continue to do so, but I also use and love VSCodium as my editor of choice when I’m not on a remote server, and I don’t use any of the extensions the author cites.

    I’m not suggesting anyone else use VSCode, I just want to be clear about the fact that the authors “Best parts” are at best highly subjective.

    1. 6

      I really want to use the Remote extension. The fact that it’s proprietary is not a problem, the fact that it is not very portable is. It basically runs a full VS Code headless on the remote end and so only supports the platforms where there are supported binary releases. I can’t run it on FreeBSD, for example, which is what my dev VMs typically run.

      1. 3

        I found the Remote extension to be problematic in a number of ways.

        First, they didn’t market it very well :) It wasn’t at all clear to me when I first tried to use it that what’s really happening is I’m spinning up a headless VSCode on the remote system.

        That’s a log of Javascript and a lot of complexity. That kind of complexity makes security teams crazy, and I don’t blame them.

        It’s an incredibly powerful extension, but its massive scope and complexity makes it not make sense for the security conscious environments I tend to work in.

        1. 4

          Yes, I was quite surprised when I learned how it worked. I expected it to basically need to be able to launch a terminal to run build commands and to read / write files. Running other extensions on the remote side, rather than proxying read/write-file and run-command makes me really nervous.

      2. 3

        As a (mostly) non-user of VSCode, looking in from the outside Remote and LiveShare (along with solid first-class LSP integration) absolutely look like a couple things that I can’t do as well in other editors at the moment. So while there are clearly other use cases and many people may not need them, I do think they are among the few things that actually clearly differentiate VSCode from other options.

        1. 3

          They’re only differentiators IMO if you can actually use them.

          As I mentioned in another response, the Remote extension is great but basically amounts to installing a headless VSCode on your remote host. That’s gonna be a total deal breaker in any environment where security is even remotely a factor.

          1. 4

            In the same way as installing Emacs or a compiler is?

            1. 2

              In the same way as installing Emacs or a compiler is?

              The reason that VS Code’s remote extension runs a headless VS Code is extensions. Any extension that you use may come with arbitrary binaries that it wants to run to provide some of the functionality. In theory, it’s no less secure than running it locally but it can make people nervous if the remote machine is a production machine - generally, crashing the developer’s desktop or running it out of memory is less of a problem than doing the same thing on production hardware.

              The big problem for me with this approach is that it limits the targets to machines with official VS Code binary releases. I think ARM Linux is now supported but if you want to develop on a remote *BSD / Solaris / whatever VM or PowerPC / MIPS / RISC-V / whatever system, it’s a problem.

              1. 1

                Actually potentially much worse.

                emacs and most mainstream compilers have been fairly well vetted by any number of different security teams.

                The problem IMO with the VSCode Remote extension is that it represents an arbitrarily large body of Javascript that can’t easily be audited.

              2. 2

                Fair enough. It still seems like it might be useful for development environments at least, but that is a pretty big concern.

                1. 1

                  basically amounts to installing a headless VSCode on your remote host

                  Well there’s no need for any proprietary extensions to do just that: https://github.com/cdr/code-server

                  1. 1

                    Have you actually tried / deployed this thing? I have, and it doesn’t do what you’re asserting here :)

                    The Remote extension lets you run your VSCode front end Electron-esque GUI on your local workstation but act on files on a remote Linux server.

                    The thing you’re pointing at here presents a web UI where you do everything, and it’s got some rather sincere limitations.

            2. 4

              So, I’ve been using VSCode for the last uh, couple of years probably. I’ve heard of both of those extensions, but I would in no way describe them as the best parts. The large collection of other extensions and the sheer quality of it (I originally thought of it as “like Atom, except it doesn’t crap itself every couple of days”) is much more what keeps me using it.

              The [expletitve] CLA is however much more concerning from my PoV, and would stop me contributing anything to it, but I’m ok with it being slightly proprietary (I’m typing this on a Mac so I’m not exactly on the ideological purity end of things).

              1. 1

                Is it the use of a CLA in general of Microsoft’s CLA in particular that you find concerning?

                1. 2

                  In my opinion, as far as CLA goes, Microsoft’s CLA is fine (I even signed it). But I am categorically against CLA, because it is asymmetric, i.e. not inbound=outbound.

              2. 2

                What open source alternatives are there to LiveShare? I’ve become rather reliant on LiveShare for pair programming during the pandemic, I had never checked whether each extension I was using was open source.

                Teletype for Atom appears to be under an MIT license, and it seemed to work fine for me before I switched to VS Code (after M$ acquired Github and I figured Atom was doomed). https://github.com/atom/teletype

                1. 2

                  I’ve heard lots of good things about tmate but it’s terminal only which may or may not be what you want.

                  At the risk of incurring the wrath of the purists, a question you may wish to ask yourself is - “Why does it matter?”

                  1. 2

                    I’ve heard good things about floobits.com for editor-agnostic shared coding. The plugins are open source, but it’s a company that wants you to pay monthly if you’re a large company.

                  2. 1

                    An intuitive terminal editor like Micro and Tmux could bring you far.