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.
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 )
Speaking of which, the following would have been better:
curl -sSf https://code.headmelted.com/installers/yum.sh | bash
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.
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
I guess that’s why this project is called VSCodium.
[visual-studio-code-bin](https://aur.archlinux.org/packages/visual-studio-code-bin/): Original binary from Microsoft
[code](https://aur.archlinux.org/packages/code/): Build from latest release source code
[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).
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.
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.
I don't think this is a big reason Gentoo users use Gentoo. At least not the knowledgeable ones.
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.
Anonymous/aggregated data collection is allowed under the GDPR, though this data collection should still be made clear to the user (and it is on https://code.visualstudio.com/docs/supporting/FAQ#_gdpr-and-...).
You mean those hacked ISOs from TPB for 3 year old OSX releases?
How can I, or anyone else for that matter, be sure they are safe to use and represents runtime behavior of the latest ever-changing (read: breaking) OSX?
It’s not as easy as you make it out to be.
The Hackintosh community has plenty of very knowledgeable individuals who know what they're doing. If someone was trying to pass malware around they would be found out and ostracised very quickly.
You can also find the direct links to Apple's servers if you search. Hint: InstallESD.dmg and swcdn.apple.com .
Why does different rules apply to OSX?
Also: DMG-files can’t be used unless you’ve already purchased that $1000 machine you don’t really want/need. It’s completely unsupported in any meaningful sense outside OSX.
So more roadblocks.
You know how I get a Windows ISO? I download it from Microsoft. Ubuntu? Download it from canonical. Etc etc.
Can we all agree that it is Apple who put up all these roadblocks?
No other OS vendor makes it harder/more expensive to support their platform than Apple does.
And then you can’t really blame developers for not bothering. It’s all on Apple.
This seems to have lead to development of products and features that get a lot of excitement here on HN so maybe it's not all bad.
I have no skin in this particular game, but I'm glad to see the work being done.
Data Collection. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the product documentation.
...and if you've been around and done enough, you would know that "unsupported" doesn't always mean "can't be done". The ones who know it can will hack around, play and investigate, explore the limits, and ultimately become better developers by developing these skills of critical thinking and problem solving. Contrast this with the cookie-cutter developers who won't think beyond what they're told and give up at the slightest difficulty.
I ain't no Apple fan myself but I can sure test something in macOS if I really need to. Give this a read...
https://www.insanelymac.com/forum/topic/329828-making-a-boot...
Sure, but that was the 90s. Now everyone in the world is connected to the same network, and any security flaw can have critical, global consequences.
Basically, having a "wormable" build and deployment pipeline may have been tolerated back then, but it sure isn't now.
> and if you've been around and done enough, you would know that "unsupported" doesn't always mean "can't be done"
Yes, I'm sure it can be done.
> The ones who know it can will hack around, play and investigate, explore the limits, and ultimately become better developers
That's disingenuous. You only have so much time available, and you cannot do everything which is technically possible. You have to prioritize.
My free and underfunded open-source projects are going to invest the efforts I have capacity for into making a better product for the users, not learning all the ins and outs of running a pirated OS on hardware Apple clearly doesn't want it to run on.
Basically: My point was Apple is putting up lots of roadblocks which no other OS-vendor is, and that if they stopped doing that, maybe you'd see more projects bothering to support MacOS as a build-target.
And really... As a user, would you be happy to be told that the software you are asked to install and trust was built on a hacked OSX copy downloaded from the internet which the developer has no way of verifying if is trustworthy or not? I'm going to assume not.
So why are you making the argument that developers should do just that?
"telemetry.enableCrashReporter": false,
"code-runner.enableAppInsights": false,
"update.channel": "none",
"extensions.autoUpdate": false,
"extensions.ignoreRecommendations": true,
"workbench.settings.enableNaturalLanguageSearch": falseOffline mode
Some users do not want any outgoing network requests from VS Code unless they specifically invoke features that require online access. To support this offline mode, we have added new settings to turn off features such as automatic extension update checking, querying settings for A/B experiments, and fetching of online data for auto-completions.
Below is the complete list of settings to control VS Code features that make network requests:
update.channel
update.showReleaseNotes
extensions.autoupdate
extensions.autocheckUpdates
extensions.showRecommendationsOnlyOnDemand
workbench.settings.enableNaturalLanguageSearch
workbench.enableExperiments
telemetry.enableTelemetry
telemetry.enableCrashReporter
git.autofetch
npm.fetchOnlinePackageInfoI'm a very happy vscode user, but this is one antifeature does continue to bother me.
I'd say the opposite. Consider that (a) you typically visit websites briefly and periodically while most vscode users have it open as long as their computer is on, and (b) Electron provides access to lot more device data than the browser sandbox. The reason websites tend to have such far-reaching and devious user-tracking methods is because they're working in such a restricted environment and have to innovate; native desktop apps have far less restrictions.
So, regardless of what they're able to collect, I know what they are collecting, and how personally identifiable it is, and I know that it's pretty tame compared to what I've seen elsewhere.
It could be that MS fixed the issue since, and the connections I see in logs now are from extensions, but I also presume this isn't the case as my firewall rules are IP-based rather than purely app based (since the latter would kill the market browsing functionality).
I'm curious what would happen if a moderate-size country (say, Belgium) were to pass a law saying that telemetry must be opt-in. I bet it would convince everyone to just be universal opt-in for simplicity's sake.
That said, I bet it's still nothing compared to the level of data collection that a typical website does these days.
I block most of it anyway, with a couple of individual exceptions, but other than those examples mentioned above, there's also:
- dc.services.visualstudio.com (40.114.241.141, 52.169.64.244)
- vortex.data.microsoft.com (40.77.226.250, 65.55.44.109, 51.141.13.164, 51.140.40.236)
- bingsettingssearch.trafficmanager.net (13.95.93.152)
I actually have no clue what the last one there is (Bing)—I must have known at some point, but have long forgotten.
Notable exceptions allowed: marketplace.visualstudio.com (13.107.6.175, 191.238.172.191, 13.85.19.92)
OTOH, there was (again, to their credit), a notification when I started the software about how to disable telemetry.
workbench.settings.enableNaturalLanguageSearch
The VSCode team is responsive on GitHub, and are driving development based on the feedback and telemetry they receive. I really am a staunch privacy advocate, but I'm not dogmatic about it - telemetry has it's place.
It can also easily be disabled if you don't want to send it.
Honestly, I don't see the point of this 'fork'.
"Those who cannot remember the past are condemned to repeat it." -- George Santayana
https://bigthink.com/the-proverbial-skeptic/those-who-do-not...