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.
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.
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.
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?
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.
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...)
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.
> 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.
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?
Not really. At least: the web happened well before IE was introduced as an answer. In contrast, VS Code was invented much later than git which at the time was an established technology and in some ways a standard.
The other context here is that IE was a competitive browser in its time: 1998-2001. The problem is that it won and then languished. IE had a lot of sway over how developers built things as the market share grew. Then it locked in users in various ways which starved the other competitors.
It took until Phoenix (now Firefox), for there to be something better that grabbed the attention of developers and those sick of being stuck with IE. It became Firefox and Mozilla hatched a pretty effective plan to steal market share. For all of Mozilla's recent failings, we forget (or weren't around to remember) the success of Firefox was pretty impressive as it was a grassroots effort.
I think the downvotes are because Microsoft has been providing some amazing tools completely free of charge. If that helps them sell more Azure... great! Everyone wins, except GitLab and AWS.
Some of us have longer memories of Microsoft's game-plan - embrace and extend. With so man now willing to grant Microsoft open source cred don't forget that it wasn't so long ago that Microsoft was running a Linux patent racket. If we allow The Beast to monopolise open source development tools we have only ourselves to blame.
Not at all. There are no objective criteria to define spyware that do not also apply to Windows or VS Code (and probably the GitHub mobile app, but I have not yet confirmed that).
