Perspectives like these (and others in the thread) remind me that there exists a separate cohort of engineers from people like myself which have absolutely polar opposite views. I respect your opinions, though I couldn't disagree more with them! :)
Well, except the bit about VSCode having "spyware". That's not true, and it weakens your point. It does have telemetry - I suspect that's what you mean, and you should just call it that instead.
I would fall back to the softer "telemetry" ONLY IF they were to provide some sort of genuinely reliable affirmation that it's not spying, which I don't think they could do today absent legal or other generally obvious incentive.
> what it either does now
Spyware is defined (Google) as "a form of malware that hides on your device, monitors your activity, and steals sensitive information like bank details and passwords." Please furnish any example of Microsoft stealing sensitive information like bank details and passwords via VSCode.
> perhaps is reasonably likely to do at some time in the future
An imagined hypothetical does not help your argument.
Well, yes, of course Google would say that. If you ask DuckDuckGo to define spyware, it offers these:
> Software that secretly gathers information about a person or organization.
> programs that surreptitiously monitor and report the actions of a computer user.
Which of course is exactly what VSC does.
Also, if software with telemetry is spyware, there is no mainstream browser clean. Feel free to use forks like Tor Browser or VSCodium if you like, but expanding the scope of spyware unreasonably only gonna cause confusion to average people.
And if it causes confusion -- good. There should be more public confusion on this topic, especially in the realm of "Why does this free program need to know all of this stuff about what I'm doing?"
It's not that answer is "no gathering information ever," it's "providers of a program ought to be compelled to fully and clearly disclose to all what information it is grabbing and what it is doing with it."
And that's emphatically not where we live today.
They've already done it a bunch. Are you naive enough to 100% believe their pinky swears?
https://www.gnu.org/proprietary/malware-microsoft.en.html
gnu.org not reputable? Hey, no worries, it's an ENORMOUS ANNOTATED list. Have fun.
I mean, sure, if you want to avoid log4j from happening, you can write all of your software from the ground up in-house with no third party dependencies (or audit every line of code for every third-party program you do use), but I don't see how that's relevant to a discussion about whether VSCode is compromised to a degree that other editors aren't.
Maybe a little extra caution is warranted.
Totally different, got it.
That means that a user has information about them reported in a way that is:
1. against their will
2. without their knowledge
That is spying. The software that does it is spyware.
Whether or not they intend to use it for anything other than improving the software - if they secretly take data from me without my consent, it's spying.
Whether or not you think it's OK for them to take data, if they do so without my consent, it's spying.
Whether or not you really like VSCode, if they secretly take data without my consent it's spying.
Software that spies is spyware. It's that simple.
Trying to haggle in the margins of one definition of a vague term is not a very strong argument to convince me otherwise.
Also: about the first part of your comment - I stop me from using VSCodium. I'm not interested.
And then turn it off using the built-in setting:
https://code.visualstudio.com/docs/getstarted/telemetry#_dis...
- https://www.roboleary.net/tools/2022/04/20/vscode-telemetry.html
- "It looks like you cannot shut telemetry off 100%. These settings will
opt you of most data sharing scenarios; but not all data sharing
scenarios."
- Apparently even VSCodium can't kill it all
- https://github.com/VSCodium/vscodium/blob/master/DOCS.md#disable-telemetryhttps://code.visualstudio.com/docs/getstarted/telemetry#_vie...
https://code.visualstudio.com/docs/getstarted/telemetry#_gdp...
Firstly, not "just work" means there will be no features to suddenly appear and "help" me. When I start to use a new IDE I never know what inserting "{" does: Will a "}" also appear? Will it start a new line? Will it cause indentation to change? Will it insert a whole snippet? How do I just insert a "{"? An IDE usually comes with lots of "helper" features like this, and questions like these add up. The result is that I never know what happens when I press a key and get agitated when the result isn't what I expect. If I set up everything myself this doesn't happen. (neo)vim is pretty bad in this sense actually. The default formatoptions and filetype indent plugins are pretty annoying, and the "J" normal mode command has behaviors that surprise users and cannot be turned off (you can remap it for sure), but by the time I met VSCode I got familiar enough with them already... I recall VSCode's default was pretty clean. IDEs are absolutely the worst.
Not "just work" also means that I know how to change something if it steps into my way, since I set up everything myself. If I have to edit a file with special formatting rules that I need to follow, I know where to change auto formatting rules. If I have to read some generated code or code from dependency libraries, I know where to turn off warnings from linting. Since rust-analyzer is set up by myself, if one day I find that its version or config is not compatible with this new project I am starting to work on, I know immediately how to change it. If my whole setting up effort is "clicking a button", it becomes harder for me to find where the change needs to be made. Such things are not just "if"s actually, but happen pretty often from my experience, often enough to make me think it's better to set up everything myself than to figure things out each time.
VS Code is a proprietary, spyware-riddled, resource-wasting worked example of why "modern" software sucks. Also for my personal use, everything that's not vim suffers from being not vim; it would cost me effort to switch for no clear benefit, and I'd still need to retrofit the same control scheme into whatever it was because the muscle memory is too strong, at which point I might as well just use actual neo/vim.
> which were built to be used as rich development environments instead of extensible text editors
> spent months tweaking Neovim/Emacs configs
I think part of the difference might be of usecase; if you want an IDE, use an IDE. If you needed to spend that much time bending the tool to what you want, maybe it wasn't a good tool to use. When I open vim, it's because I want a text editor, and it provides a text editor.