5 ms·

I wish the vscode remote dev functionality didn't require a binary server/remote side component. I have a bunch of users who want to use it, but it's not compat

I wish the vscode remote dev functionality didn't require a binary server/remote side component. I have a bunch of users who want to use it, but it's not compatible with the system libraries on our servers and dev environments.

aryamaan 6y ago
Didn't we already solve this problem with containers?
- jabits 6y ago
  You should read the article...nothing to do with containers...
  - IAmLiterallyAB 6y ago
    I believe he was referring to the system libraries being outdated problem
  - mbreese 6y ago
    The article has a lot to do with containers. When you spin up a code space, you get a containerized workspace for the current repository. > Codespaces sets up a cloud-hosted, containerized, and customizable VS Code environment. After set up, you can connect to a codespace through the browser or through VS Code. (But that wasn’t what the parent was referring to...)
sneak 6y ago
There are perpetual reminders all around that Microsoft's only pretending to like f/oss because that's where the developer attention (and thus corporate money) is. There's spyware in all of their open source apps (TypeScript excluded, because they couldn't get away with it there) that you can of course patch out, but you can't get it removed from the project because, free software or not, Microsoft gets to decide what goes in or out. Bet you a dollar the GitHub mobile app that's going to come out pretty soon will also be totally proprietary with no source provided. It's a growing trend in developer tooling: even Docker's desktop versions (not Microsoft's fault, but still) are not even open source (much less free software). It's going to be really sad in a few years when Microsoft starts turning the screws to extract more revenue from this free software ecosystem (GitHub/npm) that they are coming to exert major control over. Soon, the most common "industry standard" tooling for the largest and most popular software development ecosystem (javascript) will rely heavily on proprietary software that spies on you continuously while you use it, just like Windows.
- oefrha 6y ago
  > Bet you a dollar the GitHub mobile app that's going to come out pretty soon will also be totally proprietary with no source provided. Stable version already came out a while ago, been using it on my phone. Also, GitHub the website has never been open source and they never pretended it was or was going to be, so no one was holding breath for source code of the mobile app.
  - saagarjha 6y ago
    I mean, they could have totally released the source and it probably wouldn’t impact their bottom line at all.
    - jon-wood 6y ago
      It would make quite a dent in support contracts for their on-prem offering.
      - snazz 6y ago
        I'm pretty sure it wouldn't. The mobile app isn't something that requires a ton of support anyway. What good would the source code do you in this case?
        jannes 6y ago
        I think jon-wood was talking about the website’s source code, not the mobile app.
- kick 6y ago
  GitHub has always been a proprietary company unconcerned with user freedom. They actually have a whitepaper that predates acquisition on exactly this: https://resources.github.com/whitepapers/introduction-to-innersource/ https://resources.github.com/whitepapers/introduction-to-inn... The company has always been unethical; Microsoft didn't change that.
_jal 6y ago
Reminds me of a job in a past life I was quite happy to leave. It seemed like all I did was clean up low-end websites compromised through Frontpage extensions. That was a year I'll never get back, but I do highly recommend the fun of leaving _vti_bin/ directories laying around with funny-behaving things in them. Every few months I still see evidence in my personal site logs of a script kiddie slowly becoming enraged as they figure out I left them a busy box to play with.
soVeryTired 6y ago
Are you sure it needs a remote component? The remote SSH dev experience is actually pretty good in python.
- thwarted 6y ago
  Quite sure. Here's the documentation. https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview It seems like it runs all the functionality on the remote end, and the vscode instance you're running on the machine in front of you is just the GUI. To install this, you need ssh access, and then it drops some binaries on the remote system and uses ssh to start them up -- so it looks to a layman trying to get this working that "it only needs ssh", but that's just for the install stage. These binaries only work with more recent releases of glibc. You know what's interesting about some of the features listed on that page: - Develop on the same operating system you deploy to or use larger or more specialized hardware. - Sandbox your development environment to avoid impacting your local machine configuration. - Make it easy for new contributors to get started and keep everyone on a consistent environment. - Use tools or runtimes not available on your local OS or manage multiple versions of them. - Access an existing development environment from multiple machines or locations. We have all those already with the way our development environments are setup, but the reason people want to use vscode is for the editor, no one asks about the above things.
  - hamandcheese 6y ago
    So then perhaps you could mount the remote file system with something like SSHFS and use VS Code locally? I don’t understand what VSCode could provide that would be useful while not executing any code on the server side. It sounds like what you’re really asking is that vscode be made compatible with older version of glibc?
    - thwarted 6y ago
      sshfs is god awful slow for heavy local editor use. I don't understand what vscode provides other than an editor when all those capabilities are something that already exists when working directly on a remote machine, either. I am asking that vscode be made compatible with older, established builds of glibc; or that the server component be open source so it's potentially possible to get it to work.
shaklee3 6y ago
Use the remote containers plugin and that problem goes away.

aryamaan 6y ago

Didn't we already solve this problem with containers?

jabits 6y ago
You should read the article...nothing to do with containers...
- IAmLiterallyAB 6y ago
  I believe he was referring to the system libraries being outdated problem
- mbreese 6y ago
  The article has a lot to do with containers. When you spin up a code space, you get a containerized workspace for the current repository. > Codespaces sets up a cloud-hosted, containerized, and customizable VS Code environment. After set up, you can connect to a codespace through the browser or through VS Code. (But that wasn’t what the parent was referring to...)

sneak 6y ago

There are perpetual reminders all around that Microsoft's only pretending to like f/oss because that's where the developer attention (and thus corporate money) is. There's spyware in all of their open source apps (TypeScript excluded, because they couldn't get away with it there) that you can of course patch out, but you can't get it removed from the project because, free software or not, Microsoft gets to decide what goes in or out. Bet you a dollar the GitHub mobile app that's going to come out pretty soon will also be totally proprietary with no source provided. It's a growing trend in developer tooling: even Docker's desktop versions (not Microsoft's fault, but still) are not even open source (much less free software). It's going to be really sad in a few years when Microsoft starts turning the screws to extract more revenue from this free software ecosystem (GitHub/npm) that they are coming to exert major control over. Soon, the most common "industry standard" tooling for the largest and most popular software development ecosystem (javascript) will rely heavily on proprietary software that spies on you continuously while you use it, just like Windows.

oefrha 6y ago
> Bet you a dollar the GitHub mobile app that's going to come out pretty soon will also be totally proprietary with no source provided. Stable version already came out a while ago, been using it on my phone. Also, GitHub the website has never been open source and they never pretended it was or was going to be, so no one was holding breath for source code of the mobile app.
- saagarjha 6y ago
  I mean, they could have totally released the source and it probably wouldn’t impact their bottom line at all.
  - jon-wood 6y ago
    It would make quite a dent in support contracts for their on-prem offering.
    - snazz 6y ago
      I'm pretty sure it wouldn't. The mobile app isn't something that requires a ton of support anyway. What good would the source code do you in this case?
      - jannes 6y ago
        I think jon-wood was talking about the website’s source code, not the mobile app.
kick 6y ago
GitHub has always been a proprietary company unconcerned with user freedom. They actually have a whitepaper that predates acquisition on exactly this: https://resources.github.com/whitepapers/introduction-to-innersource/ https://resources.github.com/whitepapers/introduction-to-inn... The company has always been unethical; Microsoft didn't change that.

_jal 6y ago

Reminds me of a job in a past life I was quite happy to leave. It seemed like all I did was clean up low-end websites compromised through Frontpage extensions. That was a year I'll never get back, but I do highly recommend the fun of leaving _vti_bin/ directories laying around with funny-behaving things in them. Every few months I still see evidence in my personal site logs of a script kiddie slowly becoming enraged as they figure out I left them a busy box to play with.

soVeryTired 6y ago

Are you sure it needs a remote component? The remote SSH dev experience is actually pretty good in python.

thwarted 6y ago
Quite sure. Here's the documentation. https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview It seems like it runs all the functionality on the remote end, and the vscode instance you're running on the machine in front of you is just the GUI. To install this, you need ssh access, and then it drops some binaries on the remote system and uses ssh to start them up -- so it looks to a layman trying to get this working that "it only needs ssh", but that's just for the install stage. These binaries only work with more recent releases of glibc. You know what's interesting about some of the features listed on that page: - Develop on the same operating system you deploy to or use larger or more specialized hardware. - Sandbox your development environment to avoid impacting your local machine configuration. - Make it easy for new contributors to get started and keep everyone on a consistent environment. - Use tools or runtimes not available on your local OS or manage multiple versions of them. - Access an existing development environment from multiple machines or locations. We have all those already with the way our development environments are setup, but the reason people want to use vscode is for the editor, no one asks about the above things.
- hamandcheese 6y ago
  So then perhaps you could mount the remote file system with something like SSHFS and use VS Code locally? I don’t understand what VSCode could provide that would be useful while not executing any code on the server side. It sounds like what you’re really asking is that vscode be made compatible with older version of glibc?
  - thwarted 6y ago
    sshfs is god awful slow for heavy local editor use. I don't understand what vscode provides other than an editor when all those capabilities are something that already exists when working directly on a remote machine, either. I am asking that vscode be made compatible with older, established builds of glibc; or that the server component be open source so it's potentially possible to get it to work.

shaklee3 6y ago

Use the remote containers plugin and that problem goes away.