
VSCodium: Binary releases of VSCode without MS branding, telemetry and licensing - hsribei
https://github.com/VSCodium/vscodium
======
floatingatoll
If I needed a one-time “use it and lose it” attack vector, this would be an
excellent way to provide one. Imagine how many thousands of code repositories
I could _successfully_ inject a backdoor into, using only a repackaged
“without the telemetry” version of Microsoft’s code. Y’all are far too
trusting.

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.

~~~
TimTheTinker
Never trust a binary more than you trust the person who built it and the
channel you downloaded it through.

A better method might be to fork VSCode’s repo and modify the build scripts
and/or code to remove telemetry.

~~~
floatingatoll
Gentoo’s biggest failure to me is in persuading people that building from
source is somehow safer than binaries.

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.

~~~
craftyguy
> Gentoo’s biggest failure to me is in persuading people that building from
> source is somehow safer than binaries.

I don't think this is a big reason Gentoo users use Gentoo. At least not the
knowledgeable ones.

~~~
Zancarius
> I don't think this is a big reason Gentoo users use Gentoo.

Exactly. The two most compelling reasons to use Gentoo are/were: 1) It's a
rolling-release distribution and 2) it offers customization by virtue of
building from source. I don't think I've seen the argument that it's more
secure--not seriously anyway. I used it back then because I wasn't a huge fan
of Linux and Gentoo seemed more familiar to me with its ports analog.

Perhaps part of the OP's confusion is the hardened profile (or similar)? I'm
not sure considering their wiki currently advertises it as risk mitigation
[1], but I haven't used Gentoo in probably 6-7 years (at least not
consistently outside a VM) so my memory on this is likely wrong.

[1]
[https://wiki.gentoo.org/wiki/Hardened_Gentoo](https://wiki.gentoo.org/wiki/Hardened_Gentoo)

~~~
floatingatoll
To clarify: Gentoo did no harm. Many Gentoo users cited the risks of prebuilt
binaries in their evangelism of Gentoo. That perceived risk remains an
undercurrent in people’s thinking today, even though we’ve generally since
realized that prebuilt binaries aren’t the risk we were led to believe they
were back then. I blame the Gentoo evangelists of yesterdecade for this
persistent “anti-binary” mindset, not Gentoo itself.

------
PascLeRasc
Thanks for doing this. This will be the canary that tells us whether Microsoft
is really changed like they claim. Since they call themselves "in love with
open source" [1] and letting Github "remain an open platform" [2], I expect
them to not remove this project from Github. If they do remove it, whatever
reason they give about wanting to provide the best possible VSCode experience
is bullshit and Github will no longer be a home for open-source projects.

[1]
[https://info.microsoft.com/rs/157-GQE-382/images/Microsoft-l...](https://info.microsoft.com/rs/157-GQE-382/images/Microsoft-
loves-Linux.pdf) [2] [https://open.microsoft.com/2018/06/07/github-
acquisition-mic...](https://open.microsoft.com/2018/06/07/github-acquisition-
microsoft-commitment-open-source-developers/)

~~~
nojvek
"You can recover from Microsoft and its suppliers only direct damages up to
U.S. $5.00. You cannot recover any other damages, including consequential,
lost profits, special, indirect or incidental damages."

Lol Microsoft! why a random $5 number?

------
diaz
Finally. It obviously is something that flies over the heads of most people
here at least by reading the comments. This is great.

~~~
josteink
I don’t personally see the need, but the fact that someone _can_ do this
should at least once and for all settle how “real” the open-sourceyness of
VSCode is.

~~~
eckza
Some of us want to write code without shipping a bunch of usage data /
telemetry / whatever back up to the Mothership.

It's the principle of the thing; and anything that shaves off a few clock
cycles is fine by me.

~~~
jakear
VS Code already provides mechanisms to disable all background network
activity.

~~~
falcolas
Defaults matter. They matter even more given Microsoft's demonstrated history
of quietly adding new telemetry and metrics which are enabled.

I have no skin in this particular game, but I'm glad to see the work being
done.

------
Waterluvian
I appreciate this effort and am not suggesting it's not necessary. Just
curious: are there any known ill-desired effects of the MS binaries? My
understanding is that it's just branding and telemetry that can be turned off.

~~~
hegz
They can't be distributed in distro package managers which usually require
everything to be foss.

~~~
majewsky
Depends on the distro. For the main Debian repos, it's true. Others like Arch
are more lenient, e.g. Arch packages the Steam client.

~~~
ivanfon
It's worth noting that VS Code is only available in the AUR:

[visual-studio-code-bin]([https://aur.archlinux.org/packages/visual-studio-
code-bin/](https://aur.archlinux.org/packages/visual-studio-code-bin/)):
Original binary from Microsoft

[code]([https://aur.archlinux.org/packages/code/](https://aur.archlinux.org/packages/code/)):
Build from latest release source code

[code-git]([https://aur.archlinux.org/packages/code-
git/](https://aur.archlinux.org/packages/code-git/)): Build from latest Git
commit

The versions that build from source (`code` and `code-git`, AFAIK have
telemetry disabled).

------
Dinux
I don't see the beneficial element to this project. Visual Studio Code is
opensource, free of charge and used by millions at this point, why would
anyone want another license just because of the license alone?

~~~
jillesvangurp
The source license and binary distribution license are different. The source
code is MIT licensed; nothing wrong with that. Great license for this. The
binaries are provided with a different license that also covers components
from third parties that may not be in the vs code repo as well as telemetry
and other data gathered.

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.

~~~
SparkyMcUnicorn
Looking around, this repo is just a few ~10 line shell scripts. Very simple,
and it isn't a fork of vscode. It clones the Microsoft repo directly and
builds it from that.

------
k__
Nice idea.

With Chromium there is a bit of a problem with protected video codecs, but I
think this doesn't apply to VSCodium.

~~~
jasonkostempski
To me, that's a feature.

~~~
k__
Was a bit of a hassle to get popular video platforms running ;/

------
ahoka
Related: [https://code.headmelted.com/](https://code.headmelted.com/)

~~~
codetrotter
Strange way of downloading and executing the installer. Most usually you see
either

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 :<

------
ealhad
Nice! I don't use VSCode, but I know a few people who do and I’ll gladly point
them to this build.

------
temp
Doesn't have the latest build for macOS. :(

~~~
josteink
Disclaimer: general comment. Not affiliated with project, etc.

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.

~~~
filleduchaos
> but I don’t typically feel like shelling out $1000 to buy a machine
> specifically for an OS I don’t use

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.

~~~
aikah
> 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.

Mac development is a bit more complicated than running MacOS on a CI,
especially with GUI apps.

And of course code authors prefer compiling programs themselves on their
infrastructure. If you want to volunteer and provide a Mac Build then get the
source do it and distribute it. But don't accuse people of being somehow lazy
for not supporting mac, that's preposterous.

Apple is responsible for the situation. Don't shift the blame away from them.

~~~
filleduchaos
> Mac development is a bit more complicated than running MacOS on a CI,
> especially with GUI apps.

And this is a cross-platform project that's not exactly Cocoa-heavy (being
based on Electron). The person I responded to did not say anything about
creating GUIs either, so I am not sure what your point is.

> And of course code authors prefer compiling programs themselves on their
> infrastructure.

Which is why Travis, Circle, Appveyor and co have zero users, as we all know.

> If you want to volunteer and provide a Mac Build then get the source do it
> and distribute it

It's almost as if that was one of the things I suggested - working with the
requester to provide a binary

> But don't accuse people of being somehow lazy for not supporting mac, that's
> preposterous.

I said the argument is lazy, not the people. If for some reason (ideological
or whatever) you're not interested in supporting macOS, then say so outright.
Don't pretend as though the only obstacle between you and distributing your
otherwise cross-platform software for macOS is not having a literal Mac in
your hands because there are other easy options, like taking on a contributor
or using a build service.

------
amanzi
This just creates more problems than it solves. If you don't like Microsoft's
approach to VS Code you're better off choosing another editor to use - there
are lots to choose from.

