Not really sure what you are implying with the 'Big Brother' comment. The remote development servers are only used for writing/debugging code and not for other daily tasks. Even if they are tracking what tools/functions I am using on the server, what does that matter?
Personally, I have found remote development awesome because it enables engineers to start contributing to a huge product in the very first hour. No need to wait for the repository to clone, the dependencies to install, and the code to build before you can become productive.
I am nobody but I've had this nagging feeling ever since I started working on websites for big corporations about why can't I work on my code on my local machine with no network connectivity? Why do I need to talk to three different databases and two different services on five different servers? Why can't I just fake all those things during my development?
If anything, my not so humble opinion is that remote development further enables bad habits. Of course, remote development is a tool and is not to blame but I recently learned the term "hermetic" build [Google SRE]
>The build process is self-contained and must not rely on services that are external to the build environment.
Personally, I think we should work towards making it possible to run (or at least stub) the whole stack on a single physical machine - be it local or remote. What do you think? I think this is a trivial problem engineering-wise but I am not very good at selling ideas.
[Google SRE] https://landing.google.com/sre/sre-book/chapters/release-eng...
Wiremock but it takes some work. I wish public API providers also provided Mock servers for developers.
Like, is an environment like this encouraging bad habbits?
But anyway..
Special hardware: such as? Very few systems can't be downscaled. Situations where you need this special hardware we are talking horizontal multi server setups anyway.
Special workspaces: be less special, improve tooling, improve build operations. Very few setups actually needs centralised configuration.
Large compilations: I'm not sold that a) there is many people with the justifiable need, and b) any real justifiable need is likely going to want on demand autoscaling of the compilation servers, i.e. development won't be local anyway.
I'm not trying to debunk everything you've said. It's a trade off and I've used central dev databases in the past for legacy systems and it worked well for those in the office.
All I can tell you is that iteration speed, testability of code, manual testing and all around team morale was DRASTICALLY improved by stubbing out that bottleneck in newer systems.
For those that don't, it's much more friction to remember to start it up, etc.
Hence the "big brother" reference.
Frankly, I was/am a little leary of how Facebook might be "improving" the MSVSC Remote Development pack since I use it every day.
Your latter concern is at least a reasonable one, but it should all be open source anyways? Not that any of us have the time to audit everything. I doubt Microsoft is going to allow anything nefarious...
Note that that isn't true in most (all?) European countries. It is illegal to eavesdrop on employees without a strong and particular reason.
you are mixing unrelated things. As an employee of a company it's unlikely you can raise any concern about your privacy when working on the company's main asset.
> Facebook also has a long history of selling the data it collects as a result of tracking even when the people being tracked try as they might to opt out.
provide a reference please
Despite a culture of "move fast and break things," things have never been broken from new more restrictive default privacy settings. Users who signed up in 2005 would still be an open book by default today.
However, you have suggested that there is or should be no privacy when doing development, but I'll remind you that not all devs work in large corporate environments and even when they do, they might reasonably expect to be watched only by their employer. It is frankly not 100% clear that Facebook will never have access to telemetry as a result of "improving" this set of plugins. They certainly did not suggest as much.
In my opinion, there is a dramatic difference between what my employer may or may not do to track me and what a 3rd party social media company may or may not do to track my development practices as a result of using a plugin.
While semantically I may have overstated that Facebook "sells" data, they unquestionably considered doing so between 2012 and 2014 despite promises made to the contrary. They also unquestionably shared data with other large data aggregators. Even if USD did not change hands I think we can be fairly certain that Facebook bartered in user data.
Here is your reference: https://www.cbsnews.com/news/facebook-gave-some-companies-pr...
Reference? Where have you been? Cambridge analytica? It's advertising arms? It's all selling user data either directly or indirectly. Don't be so naive.
I work at Facebook. I would say it's less likely there than elsewhere that I have worked due to how the review cycle is set up. People have this strange idea that Facebook is some kind of top down panopticon.
It absolutely matters. I do not want to give facebook any data, especially about my development work.
The "what does that matter" attitude is the entire reason people do not trust Facebook.
YOU, a random developer working at some other company, or on your open source projects, are not sending data to facebook.
Facebook employees, using facebook's tools, running on facebook's dev-servers, to build facebook, ARE sending dev-tool telemetry to facebook's dev-tool-development team.
"What does it matter?" is referring to the latter.
As a user, shouldn't you be happy if the usage / access to everything by Facebook developers is carefully monitored? That should significantly reduce the risk that some insider improperly accesses any of your data.
Only in the sense that I would be happy that the serial killer that captured me uses sterilised blades. That would considerably reduce the risk of infection.