Edit: The point is that we all have a blind spot around risk assessment and threat evaluation when it comes to certain software topics, such as code editors and terminal software.
A better method might be to fork VSCode’s repo and modify the build scripts and/or code to remove telemetry.
Never trust a source code repository more than you trust the people who commit it and the channel you downloaded it through.
Autoupdates from a source repository that you don’t review before accepting updates are no safer than autoupdates from a binary source.
[1] https://info.microsoft.com/rs/157-GQE-382/images/Microsoft-l... [2] https://open.microsoft.com/2018/06/07/github-acquisition-mic...
Lol Microsoft! why a random $5 number?
And for either of these projects, I wouldn’t use their products without first verifying they are what they say they are. I’d do this by downloading the vscode repo and building directly from source then comparing. But at that point I have two of the same thing (hopefully), so not sure why this is needed in the first place.
It's the principle of the thing; and anything that shaves off a few clock cycles is fine by me.
If for whatever reason you don't like this license, you can build from source. This project seems to do that and remove all of the MS branding and telemetry. There are only a handful of commits on the project so it does not look like it is massive change. The big question is whether that adds enough value and whether this project will make enough effort to keep it's fork up to date.
I agree that for the vast majority of users, using the official binaries should be perfectly fine. MS did a fine job with this product. But nothing wrong with having the choice.
I don't use VS personally, but if I understand correctly their binaries are not free even though users can build their own from a free source code. If this "VSCodium" simplifies the building process, and also removes some anti-features in the process such as telemetry, I think it has value.
"telemetry.enableTelemetry": false
Honestly I'm very happy to give telemetry data. Microsoft is doing so much to improve the experience, they can make it better with some data.I guess that’s why this project is called VSCodium.
With Chromium there is a bit of a problem with protected video codecs, but I think this doesn't apply to VSCodium.
1. Pipe it to an instance of sh or bash, or
2. Download, mark executable, run.
Instead, what they do is they run wget in a subshell and redirect the output of the subshell as input to the source builtin command.
. <( wget -O - https://code.headmelted.com/installers/yum.sh )
Don't really see why though.Speaking of which, the following would have been better:
curl -sSf https://code.headmelted.com/installers/yum.sh | bash
With these parameters, curl should wait for the whole script to be successfully downloaded, and if it isn't it won't write any of it to stdout. Especially important because the authors of the above mentioned script have NOT wrapped the whole script in a function which is then called at the end of the script.If the download fails midway and you are using wget -O - or curl without -f then you execute an incomplete script.
Also, executing the script by using the source builtin is annoying because if you answer "no" to the first question asked by this script then it closes your terminal window :<
I don’t know about you, but I don’t typically feel like shelling out $1000 to buy a machine specifically for an OS I don’t use, just to build a binary to non-paying users of free software.
If Apple would provide easily installable ISOs for VBox/VMWare installations (or something equivalent), I might bother setting up a build for it.
Right now it’s out of the question.
I keep seeing this argument and it honestly just sounds rather lazy when a few seconds of Googling will point you towards build services you can use without having to purchase a Macbook (for instance, TravisCI has an OS X build environment). Or if you're opposed to cloud-hosted build tools for some reason you could ask users/the user requesting a macOS binary would mind working with you to test your build script(s) for compatibility and mention that Mac users will have to build from source in your README. This whole "well I would if Macs weren't so expensive" sounds like "I just don't want to support macOS" because you have options if you actually were interested.
I had to do it a few times in the past and it's surprising how easy it is to run macOS in VirtualBox. Insert ISO, change some configuration, and it boots and installs. Plenty of tutorials and such too.