Hey folks, Geoff here from Gitpod. Very pleased to see there continues to be strong interest in open (and FOSS) software development tooling. VSCodium uses the OpenVSX registry (which Gitpod folks created) because the VS Market place is proprietary and can only be connected to from official Visual Studio branded products.
If you can't find an extension when using VSCodium then please send a pull-request to this repository https://github.com/open-vsx/publish-extensions with the identifier and that will help grow the ecosystem of open tooling.
Is there a way to tie VSCode extensions to their VSCodium counterparts? I installed codium and started manually installing plugins, but realized that authors, etc don't match up. For example, the Rails plugin in official VSCode shows "周鹏" as the author and 245K downloads, but in codium it's "bung87" with only 3.9K downloads.
I'm just thinking about supply chain attacks. I don't personally review all extension code on the VSCode side, but there's a certain amount of (false) comfort when over 200K folks have downloaded a particular extension.
The discrepancies you mentioned come down to the extension Marketplace used - in VS Code, it is the Microsoft VS Code Marketplace, but in VS Codium it is by default https://open-vsx.org/ (basically a FOSS alternative to the Microsoft one).
The names don’t match up, because on Microsoft’s Marketplace the author handle (display name) is used, but Open VSX returns the username as the author name. The username of the author 周鹏 is bung87 on both the Microsoft Marketplace and OpenVSX. I think this is a good thing to reconsider though and thanks a lot for sharing!
> with only 3.9K downloads
The difference in the download numbers is as simple as the Microsoft Marketplace having their own install counter; Open VSX has less users and therefore less downloads for the extension.
It is true that Open VSX’s approach can be potentially dangerous, since an extension A on the VS Code Marketplace does not have to be the same extension A , it is built on the belief that people will be taking only their namespaces. The verification check mark can help on Open VSX extension pages with this, but it is not available on the VS Code side (yet anyway :)). The Rails extension you mentioned has the checkmark, so it means that it is published by someone who is a part of the project. You can take a look at how it looks like on the extension page: https://open-vsx.org/extension/bung87/rails.
Open VSX (and perhaps VS Code Marketplace) might consider adding support for identity verification through Keyoxide[0]. This would allow interested parties to easily determine whether the user bung87 on Open VSX and the user bung87 on VS Code Marketplace are really the same person and not just someone claiming the same username. There is already support for linking Keyoxide to one's GitHub account and even Hacker News, among other service providers.
Main Keyoxide dev here. That's an interesting suggestion, could be very useful! I don't have much experience with Open VSX or VS Code Marketplace. Do they have APIs for accounts?
I'm not affiliated with either, but from looking at some of the extension pages on Open VSX it appears they use GitHub accounts exclusively for publishers—so that part is already handled by the existing GitHub/Keyoxide integration. For VS Code Marketplace, the publisher pages do include a description section which could be used for the identity proof but there doesn't seem to be a (documented) REST API.
Hi there, I took a look at your site home page and docs, and still can't figure out what it is, or why someone would want to use it. Do you have a link to a 10,000 foot overview / simple use-case explanation, for a short-bus person such as myself?
"Keyoxide allows you to prove "ownership" of accounts on websites, domain names, IM, etc., regardless of your username.
That last part is important: you could, for example, be 'alice' on Lobste.rs, but '@alice24' on Twitter. And if your website is 'thatcoder.tld', how are people supposed to know that all that online property is yours?
Of course, one could opt for full anonymity! In which case, keep these properties as separated as possible.
But if you'd like these properties to be linked and, by doing so, establish an online identity, you'll need a clever solution.
Enter Keyoxide.
When you visit someone's Keyoxide profile and see a green tick next to an account on some website, it was proven beyond doubt that the same person who set up this profile also holds that account."
Thank you. That's easy enough to understand, even for me ;-) The only piece that might use a bit more illumination, is what kind of people are likely to use Keyoxide to check on your proof of ownership once you've set it up, and why they would do so.
"The names don’t match up, because on Microsoft’s Marketplace the author handle (display name) is used, but Open VSX returns the username as the author name."
I know it's insignificant, but that seems like a relatively easy and (marginally?) useful thing to change ;)
It also speaks to a fundamentally broken development process. This sort of thing shouldn't make it through wireframe review because it breaks the core tenet of building a competitor: not fucking with your users' expectations. Something as minor as changing what user handle is displayed was probably hand waved away, if it was even considered, yet here in this thread we have a demonstrable case of a user losing trust and confidence in the project simply as a result of this decision. If you want to convince people to use your software instead of what they're already using, you have to be as close to seamless as possible in all areas that aren't a benefit. In a case like this, the transition from the proprietary marketplace to the FOSS marketplace should be entirely seamless, and every UX change (even if it's an objective improvement, which this is clearly not) from what MS is currently doing represents lost users; the value comes from ethics, not software, so don't fix what isn't broken.
This isn't a huge issue, but it's one of the larger issues why FOSS alternatives are not often as well received as their proprietary counterparts (see: unix). Consumers/users should be the first/only consideration when designing user-facing software, but it's a rare sight to see in FOSS. I wish more FOSS developers cared about the software instead of the code, because the difference manifests in decisions like this.
> Something as minor as changing what user handle is displayed was probably hand waved away, if it was even considered, yet here in this thread we have a demonstrable case of a user losing trust and confidence in the project simply as a result of this decision.
If displaying the same "author" data resulted in users assuming that a given username on the Open VSX site should be trusted just because it happened to match a username on the VS Code Marketplace, it's probably a good thing that Open VSX displays the name differently. These are two different sites, and two different accounts; trust in one should not imply trust in the other. It would be even better if Open VSX could somehow ensure that the displayed author names never match the corresponding projects on VS Code Marketplace, for example by integrating a domain name or other globally-unique component into the author field.
Hmmmm. What about swapping `display_name` + `account_is_verified` for `display_name` + `display_name_is_verified` or alternatively `display_name` / `verified_display_name`? The idea being to tie the verification mark to the display name, not just the account.
Such a scheme could then enforce policy in the verification process that imposes restrictions on what the display name would be allowed to be.
I installed it via homebrew on an M1 and got “VSCodium” can’t be opened because Apple cannot check it for malicious software. From what I can tell from https://github.com/VSCodium/vscodium/issues/228 I have to self sign. This seems like a security hole to me.
The first time you launch vscodium, don't do so via "Open" or double-click; instead, right-click and choose open. This will give you the option to bypass macOS's GateKeeper just once, after which you can launch the app normally.
You should be able to override that warning in system settings. They make it inconvenient on purpose, and it's per-app, but you only have to do it once per app
For sure legal. Technically, it's extremely simple to change the Marketplace in VS Codium, but it is against the ToS of Microsoft's Marketplace to change it to theirs (see https://github.com/microsoft/vscode/issues/31168#issuecommen... for more details). As the linked comment also states, this is a big part of the reason why Open VSX was created and is widely used by VS Code forks.
Why would this be an issue? The code itself can't agree to the ToS, so only people using it could possibly do so, and depending on how the connection is set up, they might be able to skip agreeing to the ToS since that's just a client-side construction in MS VS (I hope).
So then the user can make the change, and then it's the user's ToS violation.
If the publisher makes this change in public then it's their ToS violation with receipts. I don't think you're really arguing that the VSCodium folks should make this change in violation of the ToS, sign it, and package it up...
They have built this whole alternative ecosystem so they can be in compliance.
does this allow only open source extensions, or proprietary ones as well? If it's the latter, is there a way to filter for only foss extensions? I don't use vscode/vscodium mostly because I didn't want to get suckered into having an open source trojan horse bring a bunch of proprietary crap into my system
It is a bit puzzling to me that this would be an issue, since extensions generally do not call any VS Code binaries, they should ideally access everything through the VS Code Extension API (https://code.visualstudio.com/api) and never call any VS Code-related binaries, since VS Code can run on a portable mode as well. If issues like this arise, it is most likely a fault of the extension itself, so reporting should be done on a repository or an issue tracker of that extension. I have never seen an extension call the `code` binary, so I would guess it could realistically only be helpful for some kind of a workaround for an API limitation.
If you have any of these extensions that break on VS Codium, could you please share them with me? I would love to dig for more and help towards fixing said extensions there.
Yes, through the Samsung debugger. See https://isdotnetopen.com for more information about remaining problems in the .net ecosystem. dotnet claims to be open but it really isn’t yet unfortunately…
The C# extension from the open-vsx repository is from Samsung. I've never used it but it looks like it uses omnisharp just like the MS version. I would say yes, it is usable.
If anyone is interested in an experience report, I've been using it for about three years and it's exactly the same experience as VSCode (even works with Live Share, for example).
This means you might find that extensions you use in VSCode aren't in Codium. This is usually remedied by just downloading the extension manually yourself or by asking the extension developers to cross-publish.
I used vscodium for a while up until this change was made. The maintainers changes the extension registry to the new one while it had something like 40 total extensions available without any sort of meaningful notification to users, and in a minor version release no less.
Pretty shitty move, IMO. I have trouble trusting maintainers that are willing to push such drastic changes without letting people know.
By April 2020, it had roughly 200 extensions because there was no push for marketing it just yet. By the time VSCodium implemented it in June 2022, the push to move extensions over was in the works, and hundreds more were added.
Also have been using VSCodium for years and the transition had no effect on my daily work, despite needing plugins on new machines for the relatively niche language of Elixir.
I'm sure it works fine now, and I don't doubt that it was fine in your case, but it was a huge inconvenience for me and the maintainers were pretty unhelpful about it when people complained. It literally took 9 months for a feature to be added that allowed changing the marketplace a user wanted without it being overwritten by updates.
The correct way to do this would have been to start with a way to persistently change the marketplace URL being used and having the change be opt-in, then having a major version release when the default value was changed, including obvious instructions about how to change the desired marketplace.
Instead, people were told to do the work themselves of porting over the extensions they wanted. That's a great way to get people who don't have the time or interest in that to just abandon the project altogether.
Even if it is fine now, I just don't want a tool I use for my daily work to be one that could break from an auto-update because the maintainers decided to make some massive change without consideration for the users.
That's all fair. My gripe is when people hold much higher standards for FOSS/benevolent projects, when they're usually run by a small team of developers working on their own dime.
Please be more considerate. Sure a very unfortunate decision was made but there's a bunch of people working to offer you and I a true open source alternative to the VSCode ecosystem and I find it excessive and offensive to call that a "pretty shitty move".
Microsoft made VSCode. Microsoft paid for 99% of its development. Thanks to Microsoft, VSCode has the level of development activity and the sheer volume of changes it has. If Microsoft didn't make VSCode, it would end up just like any other crappy Javascript code editor (like Atom).
It's nice that Microsoft made the code open source. I can respect that. If you want me to respect someone just taking Microsoft's code, repackaging it and cutting off the original extension ecosystem... yea, you'll have a hard time convincing me to do that.
> I find it excessive and offensive
Well I find it excessive and offensive to (from the moral point of view) steal Microsoft's code and make it your own without really adding much (if anything) on your own.
That's why I said "morally". The fact that I can take the SQLite code (for example), change a few lines so it's now TotallyNotSQLiteDB, compile it and sell it as my own, without me ever contributing anything back, is not really morally right. The fact that the licence allows such use is a different thing. And you're free to do immoral, but otherwise perfectly legal things. The thing here is that if you're going to do immoral things, people could have have a problem with respecting you or your project. I don't respect people who rebrand open source projects. If you fork a project and add significant work, then that's great and in the spirit of open source (e.g. Electron taking Chromium and Node and making something new and great, Mariadb forking Mysql and going their way with it etc. etc.), but rebrands suck.
the response itself was shitty - there is a non-shitty way to make the decision that was made. People effectively said "hey this is breaking some workflows and I don't have the bandwidth personally to do the work to correct this, can we revert this and figure out a better way?" and the maintainers basically said "bummer dude, maybe you should make time to port extensions."
If my use of curse words is your problem with my comment, fine. But I don't think it's unfair of me to call out a bad decision and a bad handling of the response to that decision when we're talking about a tool that people will do their daily work in.
Upon reviewing the issue surrounding this change on their repository, I can see that an option to persistently change this setting was merged in about 9 months after the change was made. So yes, it is an option now, but at the time the change was made there were only temporary workarounds that would be overwritten whenever an update hit.
> […] but i still miss the remote development using SSH
Me too. Editing text is pretty light weight, so it makes sense to run locally. But the language server is often rather heavy weight, e.g. requires compiling all project dependencies, so it makes perfect sense to run this on a beefy remote machine (connected to wall power).
Which Microsoft extension specifically is that? There are quite a few MS ones that have Codium equivalents which are effectively identical, though I don't use the one you're referring to.
You get all that for free with a terminal in Linux. And KDE has all kinds of tools that remotely work with SSH. Dolphin can, for example, treats a remote SSH connection like a local file system.
It basically runs everything on the remote machine. So when you hit F5 to debug, the code is actually (transparently) running on the remote machine. It's pretty cool.
Not even close to what this does. It basically runs a headless version of VSCode on the remote machine, with all of the necessary extensions, and your local version of VSCode controls it.
Yes, this is different. Vim is a TUI application which can easily run over vanilla SSH. VSCode is a GUI, which cannot. VSCode Remote runs the editor in a client/server mode, with all the UI running on the client and everything else seamlessly running on the server. There's none of the typical latency you get by running heavy operations such as full-text search on a mounted remote filesystem because they're run on the server.
That will run both the backend and the frontend on the remote server, while VS Code SSH will only run the backend on the remote. ssh -X is very slow for a complex GUI across a non-local network.
First off, VSCode is a text editor, not a complex GUI (or at least it shouldn't be but hey who knows). Second, the point is that you have been able to achieve funcrionality through means available using only a terminal, and vim/ed/nano wince forever. And additionally, do quite a bit more with things like the FISH sessions in KDE as early as 2002, probably much earlier still with other tech.
I've been using vim over ssh for 13+ years, but switched to VSCode + "Remote SSH" this year for a few reasons:
- Keystrokes and edits are instant (not just predicted), even on a high-latency internet connection. (Since ~2007 I've been constantly annoyed by what's called "bufferbloat", and I want to be more resilient to a not-perfect internet connection because I don't control internet latency at coffee shops, etc.) (Mosh is annoying, having to set up special firewall rules to allow UDP ports, etc, and doesn't fully solve the problem.)
- VS Code is also easier to pick up where I left off if I lose the connection. (Yes, can be mostly solved with screen/tmux/byobu, but annoying to manage that.)
- Nice typing support, autocomplete and code navigation. I can command+click functions to jump straight to their actual definitions (not just something named the same thing). I get more instant feedback, catching more errors before actually running the code. (I use Python + pyright/pylance, and I suppose vim has some plugins for this too, but it's nice having something officially supported by the editor. I'm also guessing VS Code is way more powerful.)
- Easer to deal with multiple open files and switching between files in a projects. Uses many of the same keyboard-shortcuts as browser tabs. (I suppose vim has this functionality, but I never learned it.) Project-wide find/replace is also really really nice. (Easy to toggle between regex and case-sensitive modes, etc. Easier than "pie": perl -p -i -e 's/this/that/g' $(git ls-files))
- I can drag local files to the remote server really easily, and I can also right-click->download any file I see.
- Files open in the editor automatically update contents on screen if their content changes on the file system (unless there are unsaved changes).
Downsides so far are:
- VS Code is pretty memory hungry on the server and uses multiple node.js processes that probably don't share a lot of memory despite sharing tons of dependencies. (So, yes, bloat.)
- Remote SSH plugin isn't open source, and kinda just downloads and runs closed-source code on the server. I trust Microsoft more than some open-source projects to not abuse this though ideally I'd prefer to apt install something that Debian or Ubuntu has vetted.
- Annoying having to install a local client. Maybe we'll get a fully-featured browser-only version of it someday, but from what I've gathered it's not there yet (probably harder to lock down security-wise too).
They are not the exact same experience. VSCodium does not offer remote development over ssh. There are other addons that only come with VSCode, but the ssh difference was the main one for me, not the extensions.
The model Microsoft is following here is called the "open core" model, where the core part of a product is open source, and then some extensions to it are proprietary. It's the same model that Chrome itself, that VSCodium is built upon, operates with. And also Android.
It's their choice fundamentally. They pay for all the VS code developers, so from a moral standpoint, they don't have to release source code at all (outside of general immorality of proprietary software but that's something different). They still decide to release it and IMO they should be lauded for open sourcing at least parts, and enabling DFSG-compatible rebuilds to exist.
I interviewed with the VSCode team at Microsoft Zürich (didn't get the job because there were more senior candidates that already contributed to the open source repo, fair game). I have to say I'm super impressed that a small team in Switzerland managed to build and maintain it! Coming from that point of view it's imo totally okay that there are some proprietary parts. If it doesn't generate revenue in one way or another, we wouldn't have it. FOSS is cool and all but someone has to pay the devs eventually.
Your comment seems to suggest VSCode is mostly developed by a small team in Switzerland. VSCode is also significantly developed in Redmond (at the Microsoft HQ near Seattle).
Yes, Redmond got involved later due to the immense success. Doesn't take anything away from the fact that the core is being developed by a small team in Switzerland.
The open core model is when a product is open source and extensions are paid and proprietary. The extensions often include features that are essential to the usage of said product.
There's nothing "open core" about Microsoft shipping binaries with telemetry.
Selling binaries is a something even GPL foresees. You can view telemetry as the price: if the product is free, you are the product. This has become a predominant business modell since most users seem unwilling to pay for sth that you can get for free. Sure MS won't need the money but I guess the dev team will probably have to still provide such kind of value. What would IMHO conflict with free software is however not the presence of telemetry but the lacking presence of it in the public sources (if that is true at all, often this even has to be removed by community forks). Is telemetry actually so intrasparent in the official sources?
As far as I can tell, most people are not free to install AOSP on hardware they have paid for since the bootloader is locked.
Even those who purchase hardware where the bootloader can be unlocked, it takes much deeper technical knowledge to install a third party OS than, say, a third party OS on a PC. And that is assuming someone else built the OS for you.
You bought the car. You're free to put whatever fuel in it that you like, but anything other than our own Super Xtreme CarFuel Plus is not supported (and will likely total your vehicle).
A bit more seriously: there are shades of grey. Just because they gave you something for what you paid doesn't mean it was a) fair, nor b) what was (effectively) advertised. Legalese around "you really just bought X" doesn't necessarily put everything in the clear.
i.e. when you buy an Android phone, it seems reasonable for people to expect that to come with a functioning Android-based OS. Just because you can install a different OS on it doesn't mean the default one isn't subject to criticism.
I see it something akin to the smart tv market where you buy the hardware but it also collects and uses data about everything you watch. The data collection aspect allows them to sell you that tv for less than they would if it were a "dumb" tv.
Most of the extensions are open source and you can see the telemetry being collected, which is used to understand feature usage and diagnose bugs. The suggestion (with no evidence) that the telemetry is somehow insidious is FUD.
Right we've caught, let's see… {a thousand companies (including MS), governments around the word, and associated criminals} with their hand in the cookie-jar, over and over and over again, yet there's "no evidence." Billion-dollar databroker businesses non-withstanding.
MS was first in line for the NSA as well.
I don't think all the telemetry is particularly useful, but there is no reason to give MS the benefit of the doubt here.
I don't totally agree with you on this. Telemetry on open source extension is public and opt-out, but it is neither on the MS VSCode builds or proprietary extensions. Additionally, I just can't believe that Microsoft uses telemetry data just for bug fixing, even without evidences, but that's only my opinion.
> The open core model is when a product is open source and extensions are paid and proprietary. The extensions often include features that are essential to the usage of said product.
Outside of the paid part, that's precisely what Microsoft is doing. MS publishes a couple of proprietary extensions for VS code.
That's not open core. You're not prevented from using those proprietary extensions, are you? Those extensions aren't "open source", they have nothing to do with VSCode being "open core".
I could check using a proxy or by inspecting the source (it’s just JavaScript) but I don’t actually care about it that much to bother and I think we would have heard something if the switches were bogus, given that VSCode telemetry is such a contentious issue. That’s why I asked if there was other telemetry without a switch, because Windows is like that.
VSCode does not work at all for me without the "Remote SSH" extension. And the "Remote SSH" extension is proprietary and DRM-ed to be not work with the open source code.
I don't see how I'm stretching what "open core" means. This is just like any other open core stuff.
"Paid for" part, yeah you are right. I thought the orange site all agree I paid for Gmail, just not with money, but turns out I'm wrong.
> There's nothing "open core" about Microsoft shipping binaries with telemetry.
I don't get what telemetry has to do with open source? It's entirely possible to ship a binary that is 100% "open source" - that is reproducible from OSS code - but still has telemetry.
I was under the impression that VSCode originally had pieces of the open source licensed Atom editor, as well as other bits here and there. I haven't confirmed this to be 100% true, but I've seen articles like this
The so-called Atom pieces are Electron, hence the similar name; it started as a component named Atom Shell. Also:
> If there is open source licensed code within VSCode, then they actually do need to release the source code
Only if the license requires it (which it doesn't), unless you think all permissive open source code should be viral and proprietary projects consuming permissive licenses should open anyway.
It could not be immoral to follow the open core model but it is absolutely immoral to trick users to think that the binary they are downloading is open source when in fact is proprietary.
I don't see how it is immoral at all. It's not like they are adding some malware in the binary. From the sound of it, the only "closed" part is configuration, like the endpoints for telemetry API.
As far as I am concerned, telemetry is a good thing. Unless you are very paranoid, I don't see a good reason to disable it. Telemetry makes it possible for your usage patterns to influence the development of the product, which is beneficial for you as a user.
Being enrolled in a study should require prior informed consent. Terms of the data collection, including what data can be collected and how that data will be used, must be presented to all participants in language they can understand. Only then can they provide informed consent.
Harvesting data without permission is just exploitation. Software improvements and user engagement are not more important than basic respect for user agency.
Moreover, not everyone is like you. People who do have reason to care about data collection should not have their critical needs outweighed for the mere convenience of the majority. This type of rhetoric is often used to dismiss accessibility concerns, which is why we have to turn to legislation.
> Being enrolled in a study should require prior informed consent.
It's right there in the License Agreement that you accept when you install VSCode. And unlike some other EULA's, it's close to the beginning of the document, easy to read, describes data usage and explains how to opt out of it. I honestly don't see what more can they do to get user consent.
You might argue that many users don't read License Agreement and I would agree with you concerns IF this condition was unexpected and/or malicious. In this case it is neither.
> Harvesting data without permission is just exploitation.
Exploitation is just a word. I could also call your usage of VSCode "exploitation" because you are exploiting the work of MS engineers.
What matters is whether it does any tangible harm or not. In my view it doesn't.
> Moreover, not everyone is like you.
That's why I added a caveat "unless you are very paranoid".
> This type of rhetoric is often used to dismiss accessibility concerns
> That's why I added a caveat "unless you are very paranoid".
So everyone who disagrees with you has to be “very paranoid”? You may not agree with or understand the motivations of others, but summarily disparaging them is bad form.
I think part of the issue that the “very security conscious” people are wary of is trusting an entity like Microsoft not to quietly increase what data they are collecting beyond what is actually beneficial to users. I love the idea of using telemetry to improve products and I know that crash reporting, when introduced back in office, led to fixes for an absolutely staggering number of bugs (I worked at MSFT at the time and know that crash reporting led to legitimate and gigantic leaps forward in software quality), but I also think the agreement needs to be very very explicit about what types of data they will collect and include promises that they won’t be expanding this definition for other purposes. They really need to spell out, in plain and convincing language, that they understand this concern and promise not to violate that trust in order for me to check the “yes, collect my data to improve the product AND FOR NO OTHER REASON” checkbox.
It won't happen because the powers that be don't want it noticed much less spelled out in 24pt bullets. Even if there were some kind of enlightened CEO that set policy, it would just be a few quarters before (being replaced by a Balmer-clone) that said-policy would get thrown out the window.
The EULA you agreed to would no longer apply, and no software provides EULA diff tools.
"should not have their critical needs outweighed for the mere convenience of the majority"
I *strongly* disagree here. A small subsection of the population should not be able to impose their self-percieved "needs" on the remaining 99%. You're the individuals who care about this, it's your responsibility to put in the necessary foot work.
It's incredibly arrogant and presumptuous to try and argue that any overwhelming minorities desires should be seen as needs and imposed upon everyone else and drawing a comparison to accessibility is disingenuous at best. You aren't literally unable to use an application because they don't spell out every bit of minutia regarding their telemetry, nor are you born with physical/mental disadvantages that somehow necessitate your privacy policy desires.
No one is preventing you from monitoring your own network activity, sandboxing your machine, using a VPN, or a multitude of other steps you can take to monitor and protect your privacy.
I'm not blaming the victim because they aren't victims. They voluntarily choose to use software and are upset when it doesn't live up to their arbitrary standards, standards they themselves are doing nothing to reach when it's perfectly within their abilities to do so.
If you complained about how much you hate trackpads but refused to buy a USB mouse I wouldn't say that mice should be mandatory accessories bundled with every laptop sale, I'd say you should buy a mouse yourself or stop complaining about it.
Proprietary software is immoral in general, because it takes away the user's freedom to do their computing as they wish. If I cannot turn off a feature of a program I use, then the developers can do whatever the hell they want with my machine, especially if we count in auto-updates. I am not comfortable with that.
You know, there are people who consciously select proprietary software because, for example, they don’t want to deal with complexities of managing it. They simply don’t care. They value their relationship with a supplier and care only that it works.
Such dogmatic views like “proprietary software is immoral” do not help anyone. You have a choice not to use any of it but don’t cross off people who choose otherwise.
Software engineers in vast majority do not live from donations. You are lucky enough to make it from open source? Well, good for you! You are very privileged.
> they don’t want to deal with complexities of managing it
> They value their relationship with a supplier
There's nothing inherent about proprietary software that makes it convenient. Convenience is completely orthogonal to freedom. I get reminded of that every time I hear Windows-using friends' stories about their files getting deleted/drivers uninstalled/audio cards burned after Windows Update. Meanwhile, the free software world has been getting better and better as the time goes by. GNU/Linux just works for me nowdays.
> Such dogmatic views like “proprietary software is immoral” do not help anyone.
Such views are not dogmatic, they are based on very practical arguments - for me the most important argument is "I don't want to run programs whose behavior I cannot change in case I need to". I don't want to let another person, let alone a corporation, run a program on my machine unless I (have a way to) know what it does.
And such views they help everybody, because proprietary software gives developers unjust power over their users. Owners of the computing machines ought to have control over what computation their machines do, it's their natural right by being owners of their computing machines. The sooner we get rid of proprietary software, the better it is for everyone, except the poor megacorps that will have to find yet another way to extract money without bringing value.
> Software engineers in vast majority do not live from donations.
Software engineers can work regular day jobs, and still develop free software. Red Hat for example.
Not one of your arguments has convinced me that proprietary software is not completely immoral.
> There's nothing inherent about proprietary software that makes it convenient. Convenience is completely orthogonal to freedom. I get reminded of that every time I hear Windows-using friends' stories about their files getting deleted/drivers uninstalled/audio cards burned after Windows Update. Meanwhile, the free software world has been getting better and better as the time goes by. GNU/Linux just works for me nowdays.
But they have choice, no? They are free to use any existing alternative. So why do you care?
> Such views are not dogmatic, they are based on very practical arguments - for me the most important argument is "I don't want to run programs whose behavior I cannot change in case I need to". I don't want to let another person, let alone a corporation, run a program on my machine unless I (have a way to) know what it does.
Great for you. So you made your choice, there's plenty of software you can modify to choose from. Why does it bother you that some people do not care about that, whatever their reason is?
> And such views they help everybody, because proprietary software gives developers unjust power over their users. Owners of the computing machines ought to have control over what computation their machines do, it's their natural right by being owners of their computing machines. The sooner we get rid of proprietary software, the better it is for everyone, except the poor megacorps that will have to find yet another way to extract money without bringing value.
You know, I do a lot of open source code but I can see the other side of the coin. Which brings me to your last point:
> Software engineers can work regular day jobs, and still develop free software. Red Hat for example.
Do you? People who can do that are the lucky ones. But there are a lot of jobs out there depending on some proprietary software built by some (mega)corp that is lucky enough to have some paying customers who are happy to pay for it. They maybe don't care about their freedom because it's irrelevant to them. They care that it works the way things are advertised and someone does support for them.
> Not one of your arguments has convinced me that proprietary software is not completely immoral.
Why wouldn't I care? What kind of person wouldn't like to make the world a better place for everybody? Free software makes this world better for everybody.
> Why does it bother you that some people do not care about that, whatever their reason is?
It doesn't bother me, I support personal freedom to use proprietary software. What I don't support is proprietary software itself.
> Do you? People who can do that are the lucky ones.
Right now, they are. But it doesn't have to be that way. This might sound idealistic, and it is, because free software is about freedom, which is in itself an ideal. I am quite aware that proprietary software is still widespread. That doesn't mean I can't believe in a future without it.
> I wasn't even trying.
Then, what's the point of us communicating in the first place?
I would like to understand one more thing regarding your point of view: do you find licenses prohibiting commercial use without a payment also immoral?
As in, do you believe that all software should be source available, free to modify and distribute?
> do you find licenses prohibiting commercial use without a payment also immoral
They are in contradiction with basic freedom to use the program for any purpose you wish, so yes. Imagine borrowing a hammer from a friend and having police knock on your door because you haven't paid the hammer making company a license fee.
But you do understand that even Red Hat has paid, licensed SKUs and the reason why Red Hat can support its “contribute and sell services” approach is partially because of their licensed products.
You do understand that if your expectation for all proprietary products to disappear was to become true, you most likely rendered all software engineers to work for free. Because, let’s face it, who is going to pay for their time if there’s nothing to gain in return?
With the hammer. Well, your friend bought the hammer. Someone paid for it. Who pays in your model?
> You do understand that if your expectation for all proprietary products to disappear was to become true, you most likely rendered all software engineers to work for free. Because, let’s face it, who is going to pay for their time if there’s nothing to gain in return?
That is a fairly weak argument. Is there any reason why you consider the status quo to be the only way for software engineers to earn money? Is there really "nothing to gain" from software, unless we rent-seek per-user license fee?
Even if that were true, I'd gladly trade software engineering salaries for getting rid of proprietary software. It might just be the case that software engineers are overpaid, and the money comes from mistreatment of users.
> With the hammer. Well, your friend bought the hammer. Someone paid for it. Who pays in your model?
Maybe my friend. Maybe my friend's friend. Maybe nobody. Maybe we all donated to the HammerSoft inc., it doesn't matter. What matters is we have the software and we have freedom to use it in any way we wish.
If you're saying that software wouldn't exist without extracting money from per-user license fees, that's completely false, as proven by the large body of Free Software that already exists.
> That is a fairly weak argument. Is there any reason why you consider the status quo to be the only way for software engineers to earn money? Is there really "nothing to gain" from software, unless we rent-seek per-user license fee?
You act like I'm trying to convince you. I'm just asking.
Services come to mind. But as I said, even a company you put here as an example of that model provides paid, licensed software. Support is another one. But software isn't equal software. Do you think software running on medical devices should be free and open source? Should the operator of a medical device have a freedom to download a fork from github, compile and run on a device? An airline running a fork of an ECU software?
> Even if that were true, I'd gladly trade software engineering salaries for getting rid of proprietary software. It might just be the case that software engineers are overpaid, and the money comes from mistreatment of users.
Okay, we are all rushing to provide you with the free software you demand because of your "freedom". What about the "freedom" of all the software people to make a living? At the end of the day if they have paid customers who see the value in their software-they voted with their wallet-why does it bother you?
> Maybe my friend. Maybe my friend's friend. Maybe nobody. Maybe we all donated to the HammerSoft inc., it doesn't matter. What matters is we have the software and we have freedom to use it in any way we wish.
But with a hammer, if you and your friend want to use a hammer at the same time, you have to have two hammers.
If both of you have only one hammer, only one of you can use it at a time.
I get that you can borrow the hammer to your fiend without paying a license fee. But when you borrow your hammer, you can't use it.
> You act like I'm trying to convince you. I'm just asking.
I thought you were presenting an argument, sorry. In that case:
> You do understand that if your expectation for all proprietary products to disappear was to become true, you most likely rendered all software engineers to work for free.
Definitely not for free, but their wages might just get a little lower. This is all speculation, of course.
> Because, let’s face it, who is going to pay for their time if there’s nothing to gain in return?
There are many ways software engineers can be paid. Rent-seeking is one way, and it's the worst possible, because rent-seeking generally does not bring any value, only extracts it.
I'll skip the rest of the argument to get to the core:
> But with a hammer, if you and your friend want to use a hammer at the same time, you have to have two hammers.
> If both of you have only one hammer, only one of you can use it at a time.
> I get that you can borrow the hammer to your fiend without paying a license fee. But when you borrow your hammer, you can't use it.
Look at it this way: software is inherently different from physical objects - it's just information, and the effort to duplicate software is almost zero. So if my friend has a piece of software which makes his life a little better, he can share the software with me with almost-zero effort and make my life a little better, too. The more people we share the software with, the more lives we make a little better, at almost zero cost.
Now businessmen, who are used to selling products and earning money through pure scale, are trying to fit a square peg into a round hole - they are trying to turn software into a physical object, i.e. they are artificially increasing the effort needed to "copy" the software through licenses and law.
It obviously will never work (completely), seeing how widespread piracy is, even in this modern digital witch-hunt age. But it is making the world a much worse place, restricting natural capabilities of software (its ability to be shared with zero effort) with artificial restrictions.
Hopefully the above explanation will make my perspective clearer to you.
> Rent-seeking is one way, and it's the worst possible, because rent-seeking generally does not bring any value, only extracts it.
That is debatable. If someone pays for the software and uses it to create more value with that software than what they paid, how is that "extracting only"? I mean, I give you an example: I pay $180 for OmniGraffle. I create few drawings used for a training. I charge, I don't know, throwing a number in the air, €5k. I am a very happy customer. Or, I buy a mac with macOS, there's some inherent cost for the OS included in the purchase. I use this laptop for daily work and my salary is, say, €100k net. I don't feel that's a bad deal.
I'll skip the rest of the argument to get to the core:
> Look at it this way: software is inherently different from physical objects - it's just information, and the effort to duplicate software is almost zero.
Once it's there, sure. But what about the time it took to create it in the first place? Maybe there's a team of 50 people working on something for a couple of years? They like to get paid for their work. Look at this from the other side: if nobody would be paying those people, there's would probably be no software!
> So if my friend has a piece of software which makes his life a little better, he can share the software with me with almost-zero effort and make my life a little better, too. The more people we share the software with, the more lives we make a little better, at almost zero cost.
Except of those 50 people who never got paid for their work. Maybe they are now looking for tomato picking jobs. Whatever it is they do, maybe even consulting, they're not writing that software you want to have for free.
> It obviously will never work (completely), seeing how widespread piracy is, even in this modern digital witch-hunt age. But it is making the world a much worse place, restricting natural capabilities of software (its ability to be shared with zero effort) with artificial restrictions.
Yes, people want to get paid for their work. If you don't want to pay, it's a status quo for you - there are alternatives. And here's a question for you: if there aren't alternatives, ask yourself "why are there no alternatives?" Is it that nobody is interested in building those alternatives for free?
> Hopefully the above explanation will make my perspective clearer to you.
> Once it's there, sure. But what about the time it took to create it in the first place? Maybe there's a team of 50 people working on something for a couple of years? They like to get paid for their work. Look at this from the other side: if nobody would be paying those people, there's would probably be no software!
Most programmers work for a wage. They don't own the software they write - their employer does. Whether or not their employer is rent-seeking does not affect a programmer's income.
> Except of those 50 people who never got paid for their work.
Why wouldn't they be paid for their work? What if my friend paid a person or two (not 50) to write the software for him? "Free software" doesn't mean "made for zero price" - it means "without artificial restrictions".
> Yes, people want to get paid for their work. If you don't want to pay, it's a status quo for you - there are alternatives. And here's a question for you: if there aren't alternatives, ask yourself "why are there no alternatives?" Is it that nobody is interested in building those alternatives for free?
I don't understand this question. There are many alternatives to common proprietary software, and the number of alternatives gets higher with each day.
You seem to be stuck on the argument that "without proprietary software, programmers will not get paid". That is completely untrue - most programmers work for wages, and they don't own the software they write. From their perspective, whether or not the software is free or proprietary, they get paid the same.
> Most programmers work for a wage. They don't own the software they write - their employer does. Whether or not their employer is rent-seeking does not affect a programmer's income.
Their wage is paid from the income made by the employer. If the employer doesn't have a business, these people have no work to do. Hence, no salary. We can go and discuss that, sure, they can have another job. But as it stands today, if the employer has no business, they would have no job.
> What if my friend paid a person or two (not 50) to write the software for him?
He's free to do so and there are people who will happily take this up and write the software for your friend. There are people on GitHub who will do this for sponsorship.
> There are many alternatives to common proprietary software, and the number of alternatives gets higher with each day.
Indeed. Which is great. So why are there so many people out there who still prefer paying for proprietary software and are happy to do so?
> You seem to be stuck on the argument that "without proprietary software, programmers will not get paid".
No, it's exactly the opposite. I'm saying: there's free software and proprietary software. Some people select free. Other, for whatever reason, select proprietary. It's cool, both sides make sense. What's wrong with that? Let the people choose what they want as long as they're happy with their choice. That's exactly why I pointed out the dogmatic approach to "Proprietary software is immoral in general", especially the "in general". What I'd find okay to be immoral, is forcing people onto proprietary software. But as long as people have the choice? Let them be.
> No, it's exactly the opposite. I'm saying: there's free software and proprietary software. Some people select free. Other, for whatever reason, select proprietary. It's cool, both sides make sense. What's wrong with that?
Nothing is wrong with the fact that humans can choose to use proprietary software. I think we have repeated this argument several times already. What is wrong is proprietary software itself.
> That's exactly why I pointed out the dogmatic approach to "Proprietary software is immoral in general", especially the "in general". What I'd find okay to be immoral, is forcing people onto proprietary software. But as long as people have the choice? Let them be.
Proprietary software is immoral, because it takes away user's freedom.
Whether or not it is forced upon is not relevant for its immorality, because once a person starts using proprietary software, they lose control over their computing. That's what makes it immoral. What happens before and after that is completely irrelevant to the argument.
Just as selling addictive drugs like heroin is immoral, because it enslaves people, through psychological/physical dependency. Of course, people should have the choice to put whatever they want into their own bodies. But that does not make heroin dealers any less immoral - their profit is derived directly from their users' enslavement.
Whether people should have freedom to enslave themselves in general is a completely different discussion that has nothing to do with software.
> Such dogmatic views like “proprietary software is immoral” do not help anyone. You have a choice not to use any of it but don’t cross off people who choose otherwise.
Saying that proprietary software is moral is just as dogmatic, no?
Immoral is an extreme form of perverse and malevolent morality, or the lack of it.
Moral simply means "all the spectrum of things that are not immoral", or not immoral, which is a much larger category with a lot more nuances.
Immoral is also a subjective judgment, morality changes according to time, place, culture etc
Let's talk about ethics next time
So labeling something you don't like immoral is as dogmatic as labeling the abortion immoral just because 3 thousand years ago some guy wrote it in a book of fiction, while thinking that is not immoral means, in the majority of the cases, having no such strong opinion on other people's decisions, which we would consider the "obvious" choice not the dogmatic one.
> At least most dictionaries would disagree with your definition,
what definition?
moral comes from Latin moralis, which translates to "manners" or "behavior"
in this context software cannot be immoral, only people can, things have no moralis.
In this context, again, considering it immoral can be a dogmatic position, NOT considering it immoral it's not
Nobody said that proprietary software is virtuous, but simply that it is not immoral.
On the other hand, it is perfectly possible (and happened) that people developing free software have little or no morality (see Hans Reiser and Reiserfs)
> Moral" - in the discussed context - doesn't simply mean non-immoral
The context is: is not considering VS Code immoral dogmatic?
The answer is no.
Being neutral about it is part of not considering it immoral.
What an absurd statement. Next you'll say private property it "immoral".
Open source software is wonderful and I love when companies create and support FOSS. That said, to say it's immoral not to give away the work you produced/paid to produce is ridiculous. You're not taking anyone freedom away by providing proprietary software. As I believe another commenter replied, they're free to not use it or develop the software on their own.
If it's too difficult for them to replicate or for a competing FOSS product to exist, then it probably is complex enough to warrant payment.
> What an absurd statement. Next you'll say private property it "immoral".
No, absolutely not. Private property is a precursor to free software. I own a computing machine, therefore I have a natural right to control what my computing machine will compute.
> That said, to say it's immoral not to give away the work you produced/paid to produce is ridiculous.
You don't have to give anything away. Free Software means you can share your program with whoever you want, including nobody.
> You're not taking anyone freedom away by providing proprietary software.
That would be true, if proprietary software meant "no source code available" (that's usually called Freeware). But in reality, there are laws like DCMA that actually do restrict your freedom, in a literal sense.
What makes software different from any other labor, intellectual property, or physical property? Should a musician not be able to charge for their music? An artist for their art? An architect for their designs? A mason for laying the bricks?
You do own your computing machine, which means you have the right not to use proprietary software. That doesn't mean that proprietary software itself isn't moral if the user chooses to run it. You seem to believe that any software which isn't free is also abusive, when that's clearly not the case. Many software companies that develop proprietary software are profitable and are so without abusing their users.
DCMA only "restricts your freedom" so far as someone else intellectual property is concerned. If that software had never been created there wouldn't be the "freedoms" surrounding it to restrict. It's also usually illegal to buy a painting and then sell prints of that painting so your freedom is likewise "restricted". While I agree that some parts of DCMA aren't ideal, the broad argument of proprietary software "restricting your freedom" because of it is fallacious.
> What makes software different from any other labor, intellectual property, or physical property?
Nothing, and that's the whole point! If I buy a house, I can repaint it, tear down a wall or do whatever I please (as long as I stay within the boundaries of the law).
If I buy a painting I can move it, hang it upside down, improve the mysterious smile by adding a moustache with a magic marker or make whatever changes to it that I see fit.
If I buy a record, I can sample it, mix it however I please, listen to it backwards so I can listen to the subliminal ALL HAIL SATAN message it hides.
However, if I buy a piece of proprietary software I can do... nothing, except tick or untick some boxes in the settings menu that the developer bothered to put there.
That's fair for software that's a one time purchase. But most modern software is subscription based, and is more akin to renting an apartment where you're more restricted in what you can modify.
Legally, I agree that we should be able to modify whatever software we purchase so long as we don't redistribute it. I don't believe, however, that the engineers should be required to hand over the source code for us to do it.
Car mods are usually legal, but no one is demanding schematics from the manufacturer to help them go about it.
The user (of the proprietary software) is forced to execute on his machine whatever computation that software tells him to. He has no way of knowing what that computation does or modify it. In this case, developer holds unjust power over the user because the developer can make the software do whatever he wants, and even change the behavior of the program by auto-updating it over the network - and the user is completely powerless against the developer.
Yes, he can choose not to be a user (of the proprietary software). That does not make proprietary software any less immoral. Being able to refuse to be a part of a pyramid scheme doesn't make pyramid schemes any less immoral.
Your saying that this being a possibility means all proprietary software is immoral is like saying that since some businesses are pyramid schemes, all businesses are immoral.
Spyware is immoral, I agree. That doesn't make all proprietary software immoral and collecting relevant usage data doesn't make it Spyware.
> Your saying that this being a possibility means all proprietary software is immoral is like saying that since some businesses are pyramid schemes, all businesses are immoral.
No, I'm not saying that. I'm saying that proprietary software is immoral because it takes away an important human freedom - the freedom to control our own computation. You're said "ok but what if someone agrees to use proprietary software?" then I said "that does not make proprietary software any less bad".
> Private property is a precursor to free software. I own a computing machine, therefore I have a natural right to control what my computing machine will compute.
A couple things:
1. You don't need ownership to have rights related to privacy or control. You don't have to be a homeowner to have a right against people invading your home. The hackers who started the free software movement were not primarily computing on devices they personally owned.
2. Personal ownership of computing devices is not necessarily what the term 'private property' refers to. Personal ownership of computing devices is very much possible without private _property_: https://en.m.wikipedia.org/wiki/Personal_property#Personal_v...
> You don't have to be a homeowner to have a right against people invading your home.
"Your home", as in: a home you have ownership rights to. You may only be renting those rights for a limited time, but your right not to have your home invaded is still grounded in the rights of ownership you hold in the home.
There are no "rights related to privacy or control" without ownership.
> Personal ownership of computing devices is not necessarily what the term 'private property' refers to.
"In some economic systems, such as capitalism, private and personal property are considered to be exactly equivalent." — Your Wikipedia link
So in the systems which matter there is no difference. Only broken economic systems such as socialism, Marxism, and left-anarchism attempt to draw a distinction between personal and private property. Personal property is just that part of private property that those in power (whether a lone dictator or an egalitarian collective) doesn't consider useful or significant enough to be worth taking for itself.
> Proprietary software is immoral in general, because it takes away the user's freedom to do their computing as they wish.
Proprietary software happens in the context of a transaction between two willing parties. There's nothing immoral about it.
Forcing proprietary software on large scale (companies, governments) could be classified as immoral, but then it's not about proprietary software - the same could be said about forcing pink socks on everybody.
Software is basically a recipe + the resulting "meal". When I go to a typical restaurant, I also have no freedom to do the cooking as I wish. I'm served with a product whose "source code" I usually don't even know. As long as I agree to this beforehand and I'm not deceived, I can't see how it's inherently immoral. Being uncomfortable with something doesn't necessarily make that thing immoral if it's not forcefully imposed on you.
Mortgage credits, student loans (and there are major ethical systems that actually consider them immoral, eg. Islam generally prohibits charged interest).... Or military enlistment contracts... There are plenty of examples where you voluntarily sell your freedom away - and the agreement makes backing out rather non-trivial. It's just not called slavery - because it isn't quite that, "voluntary slavery" is a bit of an oxymoron (who's doing the enslaving?).
Just because users are not restrained by force does not mean they are not in some way coerced to use the software. Social media is useless without other people also using it. If closed-format document sharing is common in your community, you may have to choose between using proprietary software and not participating in your community.
The point is, the end result, people using proprietary software, is bad. People may choose to be use proprietary software, and that's their right, just as they can choose to smoke cigarettes and drink alcohol. But that doesn't make proprietary software any less bad.
1. Harmful or unhealthy is not the same as immoral. If whisky distilleries and wineries are immoral, too, then at the end of the day, what isn't?
2. I won't get cancer or liver problems because I haven't seen the source code of my washing machine's programmer/timer. I wouldn't read it even if it was available (despite being a programmer myself), because my time is limited, and I don't see the benefit as worth the effort.
3. There is a difference between actual abuse and potential for abuse. Is unprotected sex immoral in and of itself? You don't know if your partner doesn't have an STD (just like you don't know whether some non-transparent piece of software doesn't spy on you). It's a matter of trust, and yes this trust is often violated. But does it make the unprotectedness immoral in and of itself?
4. "Just because users are not restrained by force does not mean they are not in some way coerced to use the software. [...] If closed-format document sharing is common in your community, you may have to choose between using proprietary software and not participating in your community."
But the same is true for an open format, if it's common in your community, isn't it? :) You don't freely choose to use it (by the standards you just set), if you are socially coerced into it.
1. Well, present me your personal definition of morality and I will explain why proprietary software is immoral from your personal definition (or why is it moral - which would mean that your moral axioms are different than mine, which could shine light to the core of our disagreement).
2. You are being shortsighted. What if your washing machine misbehaves, and the company that manufactured it went out of business years ago and cannot provide support? What if you have a programmer buddy that could fix your washing machine for a bottle of beer, yet you're forced to spend hundreds on a new one? What if a dictator implements a surveillance device inside a washing machine, using it to spy on whistleblowers and lock them up? There are countless scenarios where free software matters. Just because you don't personally care, doesn't mean you won't care some day, if the situation arises. Just because you have nothing to say right now, doesn't mean you don't need free speech.
3. Sex has nothing in common with software distribution.
4. I am now convinced that you are trolling. When format is open, there are usually quite a few free implementations, and you can easily (pay someone to) implement your own, if none of the free implementations are satisfactory. You are not forced to run a proprietary program that may or may not be bundled with malware, depending on the developer's mood.
The reason the latter is immoral is because common sense tells us no rational person would enter a contract to slavery under reasonable circumstances. That is not true for software.
LOL. I always wonder what kind of people say that kind of thing? Who are these people on hacker news? Do they live in a real world? Do they ever use Windows/Mac, Office/Google Docs, or maybe just Google? Do they use an iPhone or Android phone? Seriously?
Android is open source and you can run it without Google Play Services just fine. Would I prefer a Linux phone (or maybe no phone), sure? But I live in a society that demands apps sometimes.
Just because you are forced to interact with immoral things that doesn't mean they suddenly become moral.
Libertarians who think taxation is theft still pay taxes. The local restaurant owner will pay the local goons their protection money - shockingly without thinking the protection scheme is a moral one. Many people buy goods manufactured in China, even if they don't support Government oppression (at least not to the extent that's going on there).
Humans are complex creatures. You can disapprove of something while still being (more or less) forced into participating in the activity, without imploding in a puff of logic.
It is good only if it is "opt in". But in the wild we see that lot of software doesn't even provide an opt out and doesn't warn about telemetry when installing or starting a program.
If it is such a good thing, why developers prefer not to disclose its usage?
Why? This isn't a product marketed to kids using dark patterns or something. People who feel like you do can easily opt out.
>If it is such a good thing, why developers prefer not to disclose its usage?
Maybe because they feel that it's not that big a deal. They could also "disclose" that the app uses X amount of harddisk space or memory, or that it was built by developers who are running Windows as their primary OS. That might be a deal breaker to some, but most people probably don't care.
Why? This isn't a product marketed to kids using dark patterns or something. People who feel like you do can easily opt out.
IANAL, but if you make the product available in the EU, you are required to make telemetry opt-in if there is personally identifiable information, or you'll violate the GDPR. Note that according to interpretations of various EU bodies, PII also means information that could be correlated to persons, like randomly generated identifiers (not just obviously PII information like an e-mail address or IP address).
I think that is somewhat naive. The general approach of big tech has been: let's just break the rules until we get a slap on the wrist. It's not like privacy authorities are going to charge them with 4% of the annual turnover the first time. Besides that, they probably have bigger fish to fry than some program that is used by a tiny subset of the general population.
As someone working in big tech, this is very far from truth. In any questionable case there are endless legal and privacy reviews that catch 99% of possible transgressions. What you see is the 1% that slipped through this process.
> Besides that, they probably have bigger fish to fry than some program that is used by a tiny subset of the general population.
That's exactly the reason why MS would be on the safe side and not break any laws in this case. They could be a bit more daring if it benefitted them, but in this case there's literally no benefit except improving the software that they are giving out for free.
> If it is such a good thing, why developers prefer not to disclose its usage?
In my experience it's usually very prominently disclosed. In case of VSCode it's literally the 2nd section in their License Agreement, not to mention help pages, highly visible settings etc.
>It's not like they are adding some malware in the binary.
They are though, telemetry is malware.
>As far as I am concerned, telemetry is a good thing. Unless you are very paranoid, I don't see a good reason to disable it.
Oh.
Well I guess I disagree. Telemetry is malware and a bad thing. Unless you can examine what's being sent and have the ultimate choice of what's shared and when. The only reason to collect data surreptitiously is if you're a creep and up to no good.
You can: telemetry code is open source. For a more detailed reports like crash reports you usually can see the full report and approve it before sending.
Microsoft has been caught disregarding consent and engaging in dark patterns... too many times to list here. There's also no way to keep on top of what tens of thousands of employees are doing, or what a present or future CEO might decide.
These blanket statements are therefore not compelling.
It's been ages since I last used VSCode but I do recall the C# debugger being nonfree, and only licensed for Visual Studio branded software (which would exclude your own builds of code). I also recall a post of someone being unable to use the Python extension because they had an 'unofficial build' of code. So unless things have changed a lot since I last used it, it would seem that the program itself is open source but some extensions that you sort of need in order to get on with your work are non-free.
Yes, they are built specifically to not work outside of Microsofts binaries:
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
Pick one and only one. Any form of telemetry should be clearly documented - what it does gather, when, and in what events, and disabled by default(opt-in model). And module gathering it should be open source.
It shouldn't be something that's based on trust, trust that it won't be abused.
There were enough leaks, or news that, under guise of 'telemetry', a lot of unrelated data was gathered, without consent.
Frankly Microsoft has been open in this regard, but as you seem to generalize, i'll allow myself to do it too.
It is clearly documented and the code is open source.
When X does something bad under guise of Y, it doesn't mean that Y is bad, it means that X is bad. If I introduce myself as a plumber and then rob you, you shouldn't blame plumbers.
So either you accept that this telemetry is just telemetry and then you shouldn't have a problem with it, or you are claiming that MS is doing something malicious under the guise of gathering telemetry, and in that case you need to provide some evidence to support it.
> From the sound of it, the only "closed" part is configuration, like the endpoints for telemetry API.
I don't want to mention things I'm not 100% sure of but aren't fairly critical components of the editor itself not open source?
For example the Remote Containers feature and certain LSP related functionality are closed source? I remember there being some chat about this on HN where the general sentiment was they are benefiting from open source for a lot of LSP related features but decided not to open source some functionality they've added to their LSP implementation?
best reason? it's laggy on my computer. it's not a good user experience for me. it's clear that a non telemetric solution just performs better, atleast on my end.
I am pretty sure telemetry is sent asynchronously and shouldn't affect editor's performance. Also, if you have your doubts, you can easily opt out. It's very visible in the Settings.
It's interesting they see a noticeable difference. I don't think it's the calls themselves that cause the latency, probably all the code trying to figure out every single thing you're doing within VS Code to send over.
It’s fundamentally an issue of trust and unsurprisingly Microsoft still hasn’t changed from its “embrace, extend, extinguish” days: already there are add-on that only work with their official VSCode binary (e.g. the remote code sharing add-on).
So enjoy the freebies but keep in mind the predatory interests underneath. ;)
No, they want to monopolize computing. And actually, yeah they do kind of have a monopoly on text editing, everyone who isn't a programmer uses Microsoft Word. Which they did by using EEE. You could import different formats into Word but good luck exporting it.
It's not only about Telemetry. The branded version has also Powershell features that aren't available in VSCodium, e.g. the remote container development isn't possible in the open source version
They've poured millions and millions of dollars into it and telemetry is there partly to make it a better product and what you do is talk about moral and expectations?
It's hard to call it immoral when it's free and it's easily compilable. I'm a commie, so very critical of corporations. But, of all the immoral actions in Silicon Valley, this isn't one of them.
That one is closed source. It's kind of oddly designed - it ssh:es in to the remote host to download some binary from MS servers, executes it and then communicates with it using SSH TCP forwarding.
"Some binary" = the same version of VS Code (maybe without Electron and some other parts).
Makes sense as you need to - edit files, run tasks and terminals, and run extensions which access the remote filesystem (eg Jump To Definition taking you to header files installed in system folders) - basically everything you need VS Code to do when you run it locally.
The alternative would be running VS Code as a webserver remotely and the local VS Code Electron just acting like a browser window pointing at your server. It probably wouldn't feel as responsive.
Does SFTP let you launch processes? And if so, which ones are you going to launch - are you going to use system grep to implement searching the open folder? There's a lot of different versions of grep out there!
The way the VSCode extension works (doesn't just rely on SFTP to sync files and doesn't require anything to be preinstalled on the remote server) is closest to Transparent Remote Access, Multiple Protocols in Emacs.
Emacs' version is more flexible and a little more quirky. I would guess that like many VSCode features, Emacs was the inspiration here.
They do work with Code-Server (VSCode in Browser) though, which also works on top of the open source parts of VSCode if I'm correct? I wonder how that worked.
Code-Server works surprisingly well anyways, but with VSCode built on Electron I guess it's not that much of a surprise.
Is there an actual reason or just "reasons"? Because those extensions are extremely useful and enabling. I honestly am not sure how to live without them at this point. I use all three of the remote development extensions on a daily basis.
> I honestly am not sure how to live without them at this point.
That's exactly why. I prefer not to have a workflow which depends on proprietary software. What are you going to do if MS breaks your workflow at some point in the future and you've become dependent on it?
Not that everyone has to do that, but it's totally possible to have a FOSS workflow, and I prefer to work that way.
>> I honestly am not sure how to live without them at this point.
> That's exactly why. I prefer not to have a workflow which depends on proprietary software. What are you going to do if MS breaks your workflow at some point in the future and you've become dependent on it?
The comment you quoted is hyperbole. What is the actual worry or problem here? No other tool has the convenience of VS Code right now, so am I supposed to just use something else that has reduced functionality for me because of some nebulous worry? What's the specific worry? Because I don't see an actual one beside some strange commitment to FOSS software.
If Microsoft suddenly deletes VS Code or requires some inordinate amount of payment to keep using it, both unlikely scenarios, then I would just use something else. It's not like my world would suddenly end, my software would stop working, and I would forget how to write software. In such an unlikely case, the inconvenience would be both that VS Code goes away but then also that nothing else has such useful features.
Yeah I think it's always fine to use the most expedient tool for the job. Personally, when I am choosing what to invest my time in, I would rather choose FOSS tools which I know to be independent of corporate interests.
I admit it's a somewhat abstract risk, but what makes me hesitant about proprietary tools is not any one thing, but how you can gradually get embedded in a proprietary workflow. Maybe now it's only remote/ssh, but maybe next you're using some feature that's built on top of that, and a year down the road you're in a position where you would have to refactor your whole project structure and CI setup to use a different set of tools, and maybe convince your team to do the same.
And maybe it's a bit philosophical, but I'm not wild about how MS and others blur the lines between what's open and what's proprietary.
It's all about what you invest in. I've been working with FOSS tools for years, and it takes a while to get your workflows figured out, but I would say I am pretty fast and productive now
You don't know what they're doing and can't know updates are and will stay benign. Anyone signing an NDA that uses it is irresponsible/negligent, unless it is a controlled security exception (or firewalled in some way - but if it can't connect out half the point of the editor is gone).
Are we talking about the same Telemetry that can be turned off? If you work in such an environment, I imagine you can only use approved, audited software - so you don't have an option.
Exactly. And it's not like switching to a third-party product is anymore secure. Imagine justifying to your security and IT teams that instead of using a Microsoft product, you'd rather use a product forked from it that's developed by random people.
I actually think the opposite is security theater. I think the security question is a bit of a wash in general, but I think that in this case, yes, the Microsoft product is likely more secure. How many full time employees are working on VS Code versus VSCodium? FOSS software is not this paragon of security. And the existence of VSCodium is due to telemetry that basically reports nothing, can be inspected, and can be turned off. I don’t see where the security threat is.
This is nonsense, because it patently is security theater. Earlier I was addressing the fact that to look good to a judge or lawyer, you need to do things that are dumb but very strict. That has nothing to do with reality and we shouldn't start pretending it does: The OSS is likely better in every way than what you'll buy (even if it's just because it does the same thing but is much cheaper).
> telemetry that [...] can be inspected
The telemetry cannot be meaningfully inspected, because it may change at any time. You know what it has sent just now, not what it'll send 5 minutes from now.
> telemetry that [...] can be turned off
You cannot know that it was turned off. Historically, MS doesn't respect your choice to turn it off once and will just turn it back on later for whatever reason. Aside from that, you cannot inspect the binary in a meaningful way so you don't know what it will do 5 minutes from now.
This is a terrible take. Why on earth would you trust a closed source, corporate solution more than FOSS sostare? The FOSS solution can be audited and the closed source solution can not. Your opinion is incorrect.
"The Visual Studio Code Remote Development extensions and their related components use an open planning, issue, and feature request process, but are not currently open source. The extensions share source code which is also used in fully managed remote development services like GitHub Codespaces and their related extensions. Given that these services also will support other proprietary products (for example Visual Studio IDE), the extensions are available under a Microsoft pre-release license like other service-based, cross-product extensions such as Visual Studio IntelliCode and Visual Studio Live Share were during their preview periods."
I do a bit of arm development that runs via ssh build servers.
Do actually use VSCodium by default but still need a copy of VSCode to play nicely with all this stuff. It's a weird situation, I'd like to go full codium but it's just not possible in my case hey.
TBH, those extensions are biased enough that it's difficult to integrate them into the company-wide workflow. It works okay-ish for personal uses, but still feels kinda awkward.
The binary license is different, and you can't reverse-engineer it. So it comes to whether you trust MS or not, which does not cut for some people that would like to run or trust only FOSS software.
Regarding "So it comes to whether you trust MS or not" - yeah, If you use Linux because you don't trust MS is okay, but running this on Windows because you don't trust MS... Useless.
As to those who say: but telemetry is ON by default! Well, if such this is a concern to you and you find this build useful, then you most certainly know to check for this stuff.
> Obviously these builds are for purists and that's okay.
They're also for busy people. If you use these rather than the ones supplied by MS, you don't have to worry about what MS might try to slip in their next binary. I'd say it's more that the people using the MS binaries are the purists that want the "genuine thing" rather than just using VSCodium.
> Yeah - what's more likely - random member of noncommercial OSS build slipping in something malicious or Microsoft doing the same ?
Microsoft, the company that made Windows 10? Microsoft, the company that made Edge? Yeah, I'd trust a random maintainer on the internet over MS any day.
> You may not reverse engineer, decompile or disassemble the software, or otherwise attempt to derive the source code for the software
Check `5. SCOPE OF LICENSE.`
VSCodium fixes that, it removes all the proprietary bites and branding. The only downside is that, as far as I know, you can't access a plethora of tooling that would require the proprietary bits.
If they don't want us to find out what their software does (the definition of reverse-engineering), it's safe to assume it's malicious, or will be.
Edit: In other words, if you bought a sandwich, and the EULA for that sandwich forbade you from examining what's in it, how it was prepared, and what effects it has on you health - would you eat that sandwich?
you might be surprised to know that food (for example bread) can't simply be reverse engineered by looking at the ingredients.
many brands also use NDAs to protect their trade secrets, example: Coca Cola.
So people who know about it, can't legally divulge what they know.
It is the same with software, the only difference is that software can be reverse engineered and made indistinguishable from the original, while assuming we could reverse engineer Coke recipe, it would never be Coca Cola, because only Coca Cola can make Coca Cola.
The EULA is probably simply protecting MS from VS Code clones, if they ate not authorized copies, MS is not responsible. It is probably standard when distributing code that is not open and can't be inspected.
> The EULA is probably simply protecting MS from VS Code clones, if they ate not authorized copies, MS is not responsible.
So you have some sort of source for the claim that, if one does not legally forbid reverse-engineering, they can be held "responsible" for unauthorized copies?
Also of note is that in the U.S. most End-User License Agreements (EULAs) specifically prohibit reverse-engineering. Courts have found such contractual prohibitions to override the copyright law which expressly permits it (Bowers v. Baystate Technologies, 320 F.3d 1317 (Fed. Cir. 2003)).
In other words, for your purposes, it sounds like it would be illegal to integrate features from a reverse-engineered program into another program for commercial or non-commercial use. If you were trying to enable interoperability (again, see Section 103(f), noted above), that would be different.
The point is not the being responsible part, the point is that if they do not prohibit it the law permits it under certain circumstances.
By explicitly denying it companies can claim plausible deniability.
Plausible deniability of what? So far nothing indicates that this is anything but an attempt to contractually deprive users of their rights. There is no extra liability that Microsoft would be taking on.
I don't make the rules, if in USA courts have decided that that such contractual prohibitions override the copyright law companies will use them.
Even if there is virtually no risk for them, they will protect themselves because they can and the law gives them the right to override user's rights.
At least VS Code is open source and everybody can compile it and inspect it, except the proprietary bits from MS. Which sounds a lot better than old MS.
Anyway, nobody complains that they can't reverse engineer AWS.
Cloud computing is much more dangerous for users' right, and yet...
There's no warranty so abiding by the EULA is meaningless. That's only there so Microsoft covers their ass because lawyers exist and they justify their salary by doing things that "reduce the probability of Microsoft getting sued". You can reverse engineer the binary all you want.
Copyrights can be enforced even for free products or for meritless motivations. Some thinks it only applies to paid IP or limited distributions but technically there’s no such requirement.
Probably not allowing them to publish that information? However, if you can state general facts from how telemetry works without going into detail on how you got that information, I doubt they'll be able to convince a court that you did anything illegal.
In the end, you can just monitor network traffic and verify telemetry is switched off that way.
Copyright omly regulates copying and redistribution, not use. So the act of reverse engineering itself is not illegal under copyright. There might be concerns with contract law however, although many arguments such as unconscionability could be used against it.
Imagine your tv says in the EULA you can't open it. The only way the TV company knows this and you can get any consequence out of doing it is if you want to activate warranty. In any other scenario they have no clue. You can apply the same thing here. There's no way for Microsoft to know if you reverse engineer a binary in your machine to learn about it, and since you're never gonna send them the binary for repairs, you're good to go.
If nobody finds out about an illegal thing that you did, it doesn't immediately become legal.
Imagine you send a GDPR wipeout request to a company. You have no way to check whether they really delete all your data, but I hope you agree that it would be illegal for them to not do it.
It's statically linked - which is fine, as long as they allow relinking of the LGPL parts and don't add any restrictions on those (which this EULA goes directly against)
Devils advocate: so why are you more trusting of these other binaries? Microsoft has reputational risk, if something nefarious are in these other binaries - no "organization" is really to blame.
I still see VSCode make connections to dc.services.visualstudio.com and az764295.vo.msecnd.net with telemetry and updates disabled.
Github issues relate these connections to extension black lists and extension recommendations based on my workspace rather than specific "telemetry", but I doubt the pipelines at MS care about that distinction.
I'm not sure why I should trust VSCodium more than I trust Microsoft. There were supply chain attacks coming from open source community and none that I can think of coming from Microsoft.
Maybe I'm being a bit naive, but the telemetry is supposed to help the VSCode developers to improve the product, right?
It feels a bit strange when some of us want the benefits of what this telemetry may give (a better product, perhaps?) while not willing to conceive information to improve it.
Maybe it's similar to how ads work. I use an ad blocker, but because I feel ads make the product worse, not better.
On the one hand, I sorta agree with you and I find some of the kneejerk anti-telemetry perspectives to be maybe overly paranoid. On the other hand, I do think there's a valid concern here because the telemetry is closed source.
Short of reverse engineering the official binaries and/or inspecting what it sends back to Microsoft, there's no way of knowing what it's actually collecting, which is understandably concerning given Microsoft's history. And you'd have to do that for every release, since any update could expand the scope of what they gather.
Personally, I don't quite care enough to bother doing something about it, but I can see why folks who are inclined to distrust Microsoft would not want to trust them on this.
Telemetry is also not the only solution to the problem of improving a product. For something like a code editor, I cannot imagine what they can learn from telemetry that the cannot also learn from methods like user interviews.
User interviews are slow, unreliable compared to millions of devs submitting telemetry, and take a significant effort on both sides to conduct.
Telemetry can alert of bugs, crashes, incompatibilities on certain platforms, hardware & software. You can see which extensions are most used, how often the settings are changed, which ones are most often changed, for example:
how many % of the devs change their font? To which one do they change it? can we change the default to that if say.. 80% of the devs prefer it to the other default.
They can also run a/b tests testing new features and gather info without having to poll thousands of devs about it.
> It feels a bit strange when some of us want the benefits of what this telemetry may give (a better product, perhaps?) while not willing to conceive information to improve it.
I don't think this is representative of the mentality, though. Just because you would benefit from the product improving and would like to see it improve doesn't mean you have to agree with any means of doing so.
While I understand there are benefits to telemetry, I don't think it's fair to make it out like it's the only way to improve a product or that there are no comparable alternatives. Much less that anybody being allowed to opt-out completely ruins the benefits of telemetry.
If anything, if you're in favor of telemetry in VSCode, you should be pushing for (clear and verifiable) opt-out, as that means your own data and use cases get a bigger say.
Maybe it has to do with Microsoft's history of collecting too much information for profit and ignoring user feedback that has disillusioned people into denying it?
I stopped using Code-OSS and Vscodium after this bug. For the longest time, the "solutions" suggested in that issue tracker were disabling CORS validation.
I wanted to like VSCode, but when I found out that both the Python language server and the remote SSH editing plugin are only available in the MS-blessed binaries, I quit using it and went back to vim. At least that's everywhere.
Not the one you asked. But I just install lunarvim when I want a fat IDE. It has many of the bells and whistles like lsp and linter preconfigured. It's started with a different command, lvim, so I can still fire up normal vim on a rust file if I just want to read it or whatever. I used to use coc.nvim, but lunarvim has easy integration for several languages and it's very painless to set up. I'm not customising the normal vim anymore, the linux distribution's defaults are fine. There are other vim 'distributions' with IDE like features besides lunarvim.
This was my pain point regarding 'making the leap to VIM'. I wanted something that was easily installable and reproducible. with PyCharm I can download a software and that's it. With VSCode, if I wanna develop in Rust, I install rust-analyzer with 2 clicks and that's it. Coc-nvim has always been a world of hurt that has been putting me off the 'vim-ide' train for quite a while.
Thank you for informing me about things like 'lunarvim'. I'm gonna check it out now!
I do not use the language server with vim yet. I have a few dozen plugins that I use for syntax highlighting, Ctrl-P, airline, etc. I think my python highlighting comes from vim-polyglot. However I have been wanting to get better autocomplete working. YouCompleteMe is not bad but nothing really competes with VS, especially for TypeScript.
Can you please elaborate on working remote with ssh? How exactly does it work and what do you do? Are you sshing into a server and work there with your VSCode GUI? I only have connected it to WSL2 yet (by simply calling code from the terminal).
Local VSCode attaches to a remote VSCode backend. So you see the remote file system, remote shells and remote extensions running in the local editor. This works for both remote hosts and containers and is cross platform; you can develop on a remote Linux host/container using your Windows desktop, for example. This is invaluable for developing inside containers with isolated tooling, for instance.
It isn't fragile; it just works and is so transparent that it's easy to get confused about where you're actually working.
That makes me wonder how I never heard of the integration before. This is going to take away so much pain from my workflow when working on Servers. I’ll take a look at it. Thanks for the explanation!
The remote developer extensions in Visual Studio Code allow you to run VS Code as if it's on that machine. So, the integrated terminal, file system, and all VS Code extensions all behave as if they're on the remote computer (because they are).
The killer feature really is the fact that your extensions work seamlessly on the remote computer. Without the little tag in the bottom left showing you where you're at (on your local machine, a container, or a remote machine), there's basically little that lets you know you're on a different computer aside from some hints (like the terminal's available).
Eclipse has a similar feature called RDT for a very long time. It can either work over standard SSH or via its own userspace daemon.
I don't remember how it works in detail, but if my memory serves me well, you develop the code locally, and it pushes it and builds it there, and runs it. At the end of the day, you use your Eclipse installation on the local system, but develop at the remote system transparently.
I've used it 5-6 years ago, but didn't use it recently since I didn't need it. However, it's a very mature system and doesn't limit what extensions or plugins you use. It's just an overlay.
I'm using Eclipse since its inception, and probably won't migrate away ever, but it's nice to see alternatives. Also, I'd never touch VSCode due to plethora of reasons, but these are my own reasons and this comment box is not the right place for them.
right, conceptually similar. the difference is that for vscode-remote, your local machine only runs a thin client. Everything else - extensions, linting, etc - runs on a headless process in the remote environment.
Yeah, it's implemented inversely, it seems. To enable collaborative development possibly. The thing is, collaborative development was not even a dream when Eclipse and RDT was first built, so they work well for their respective scenarios.
The nice thing is, Eclipse is extremely portable in terms of configuration and installation, so collaborative development is not a big hassle on the Eclipse side possibly.
Lastly, Eclipse has added "Compile to Container" target, so it's actually pretty usable for modern development in today's world.
The thing is, linting your code is usually the IDE's job, but it kinda requires access to various stuff used for build, which is why the "push build to remote" model sometimes does not work or behave weirdly.
For example, if IDE want to do smart things it may need to read all jar in your class path, are you going to download the entire class path from the remote then? Also, that's Java and things are easier, what if the artifact is not cross-platform and client runs on Windows with the remote side being Linux?
I have tried that before (local Mac, remote Linux using various tools). It's much much worse, trust me. Ensuring everything is synced after a save but before you run a command is difficult, reconnecting after sleep is unreliable, it's much slower, more tedious to set up, etc. etc.
Fair. I generally develop on fixed workstations with wired connections, so SSHFS is as reliable as local. But mobility has its own problems, you're right.
Yeah I mean I don't want "fine", I want a modern graphical IDE with autocomplete and error highlighting and build system integration and a proper debugging GUI and go-to-definition and refactoring and a file and class browser and tooltips and ...
Don't worry I know you can't do that with just SSH and tmux or whatever.
Neovim has a built-in language server (ALE and others do the same in other editors) and since it's based on the spec that VS Code put forth, the autocomplete and features are basically identical as is any go-to-definition. Debugging in a tmux split is, in fact, "fine" which is really all you need. I'm not sure what build system integration means--my editor is agnostic to the build system and I would hope it stays that way.
If you're asking for your editor to run a browser window under its hood and chew up your battery for tooltips on mouse hover instead of inputting a short key macro on cursor, then I don't know what to tell you.
I used and loved VSCodium for a while, but as a Windows user, I found it was incompatible with the Remote SSH plugin that makes development on WSL2 a breeze. Is there any news on this front or an alternative users have found?
EDIT: Just scrolled down to read the rest of the comments, and see this is still the case. :(
Windows 11 wsl2 is supposed to be able to run gui apps (without needing hacks). It should therefore be feasible to run vscodium on wsl2 itself and develop that way. I used wsl2 for a bit and it was really nice but it had the side effect or reminding me how much I missed running Linux and how much I didn't want to upgrade to Windows 11.
Have you considered switching to a Linux desktop environment? Unless you need Windows for some reason, Linux is generally the best development environment in my experience.
I actually do run Linux on my work PC, but I prefer Windows to every Linux DE I've tried (including GNOME, KDE, Budgie, MATE, and XFCE, although XFCE is by far my favorite), so I'd prefer to stay on Windows if I can.
I've found the opposite (although I do run Windows 10 LTSC). Most Linux distros I've tried break between releases, driver issues galore, UI aesthetic and performance inconsistencies across apps that use GTK/QT/Electron/etc. I love Linux, but as a desktop, it's really nowhere near as consistent or cohesive as its corporate counterparts.
I guess it depends on your priorities. I've had a very good experience with Pop in terms of polish, and after mostly switching to a Linux desktop Windows is unbearably noisy as an OS to me.
I also used Pop, but had visual glitches & lag with GNOME after an update. YMMV I suppose.
Windows is indeed noisy as hell out of the box; it takes probably a day's worth of tweaking to get it to a usable state. Easier done with an LTSC release, hence why I stick to that.
Eh? I've run the OSS builds of vscode and had no trouble using the extensions marketplace. The only difference is a few specific extensions like remote code, the telemetry destinations, and the branding material.
You may not have trouble using the VSCode extensions marketplace, but it's technically against the license to use it from anything that isn't the official VSCode.
That's a simple piece of software, and I doubt it would make a difference if it were open sourced: it would still run on their servers under their control.
Why is it, when people have legitimate complaints about something on hacker news (in this case the fact that what is delivered as a binary is not what you see as source code), people are so quick to side with the tool for being trustable?
How do you know that flag does anything except attempt to hide sending of telemetry? Or not even that, simply logging that you would prefer not to have telemetry taken.
The EULA explicitly forbids you from attempting to reverse engineer the binary, so you’re literally taking this on blind faith.
Don’t you find that troubling?
Even if Microsoft didn’t have a murky track record with telemetry in their operating system (being randomly turned back on or never being completely turned off): the default position should never be to trust.
It is very interesting how everyone rants about trust, but they are perfectly happy running their 'open-source' code on closed-source CPUs (Intel, AMD x86-64, Apple M1, etc) with closed-source firmware, and raves over how they 'don't know what a flag does', and how they want or even have 'full control' of their computers and the code that runs on them, which is not remotely true.
At the risk of running into a slippery slope, unless one single-handedly:
- audits the entire codebase for some open-source OS;
- audits the entire specification for an open-source ISA, and an open-source implementation of said ISA, such as RISC-V BOOM;
- locally compiles the audited codebase on the audited CPU, targetting the audited ISA;
one cannot claim to say 'I want to know what that flag does'.
For all we know, Intel might have NSA backdoors and might 'phone home' to some server. I understand the idealism behind 'trust is earned', but at some point, trust has to be given, because unless we are willing to make some serious compromises, we will never be in full control of the complete hardware-software stack.
To be perfectly fair, people are extremely displeased with x86 hardware back doors. So it’s not exactly the same as the way you present it.
Though I agree overall, I’ve read the code (and compiled) the operating system I use day to day, but that seems to be uncommon apparently, and I’m not above just trusting some package maintainer.
That said: trust is still earned, and easily lost.
There’s a lot to indicate lost trust in Microsoft (despite the fact that I did say in my parent comment that it’s separate from the point).
I'll be straightforward and say that as a whole, I do not trust an operating system in which one of the first configurable options it presents me are whether I want to toggle my 'advertising ID' on or off.
As a result, quite honestly, I wouldn't trust any product produced by that company.
On the other hand, why are so many so quick to jump on the distrusting side? For example, people on here lost their minds with the Warp terminal having telemetry, but none of it includes any of the terminal input or output, which makes it harmless. But telemetry apparently equals some horrific deed. These exact same software developers likely lace the hell out of their apps and systems with telemetry, a mention of which that is probably buried in some user agreement somewhere.
Microsoft publishes a detailed article on what Visual Studio Code telemetry is, how to disable it, and even how to view the telemetry events going out.
I'm not really sure jumping through hoops and developing and maintaining a crippled open-source app is the sane, default response here. It's likely a waste of time and a very, very, very small percentage of Visual Studio Code users will use it.
>How do you know that flag does anything except attempt to hide sending of telemetry?
I don't but neither does anyone who runs VSCodium because they also run a random binary from the internet without having any idea whether that binary is in fact compiled with the source code provided, and I have the suspicion nobody who runs it has read that code either.
This is classical security theater where people will run binaries from basically anonymous people on the internet and claim this is more trustworthy than running something provided by Microsoft.
I'm sure we're in a minority but some of us do actually build things like this from source (common for Gentoo, Arch, Guix, and NixOS) and do a quick cursory glance of source changes on every upgrade/rebuild. For a flag like this I may dive into the code of the version I'm running and take a look what's going on.
So with a sample size of one I can tell you that "nobody" is false.
Even not doing that, just the fact that I can know that it's built from a known tag from master on a public high-interaction git repo makes it a completely different story than downloading some arbitrary binary.
> This is classical security theater where people will run binaries from basically anonymous people on the internet and claim this is more trustworthy than running something provided by Microsoft.
With a large enough group of "anonymous people" [0] inspecting the code, the chance for a security hole, intentional or otherwise, lowers [1]. Notice that this is NOT a guarantee by any means -- it's a chance. [2]
Contrast that to a blob of binary code with a EULA stating you aren't allowed to inspect it. There are obviously non-malicious reasons for doing that, but it doesn't (and shouldn't) sow trust. So some people don't trust it. They are not irrational for doing so.
In terms of probability, I would put my money that Microsoft is overall better than the median set of developers at writing code with fewer technical bugs. However, I would also bet that they are more likely to intentionally add in more telemetric data than they let on, and/or misrepresent what toggles and settings actually change.
Whether I actually (can) read even a single line of code does not change any of that. Just the fact that someone can view your code has a large effect on how you write it [3].
We can talk all day about whether specifically VSCodium meets some threshold of actual reviewers/auditors, but that's not the point.
[0]: There are established lines of trust via things like: comment history, other projects, and even other commits. FOSS devs aren't (always) just purely anonymous.
[1]: "Many eyes make all bugs shallow"
[2] This also says nothing like "all FOSS is created equal" or that "projects with thousands of contributors are magically more secure".
[3]: And yes, of course that could mean they just obfuscate it more. But that still takes more time and effort, reducing the chances/number of cases, and increases the chance of detection.
I don’t though; so this effort is somewhat beneficial. Despite the fact that it’s really lacking in some features.
Though: that is quite telling to be perfectly honest. Some components can’t be replicated without proprietary elements- which indicates that there’s a lot more binary blobs than normal.
I’ll admit to not looking at the code, as I do not currently use vscode.
> Why is it, when people have legitimate complaints about something on hacker news (in this case the fact that what is delivered as a binary is not what you see as source code), people are so quick to side with the tool for being trustable?
GitHub Codespaces is a paid service and they don't want any competition. Charging for Visual Studio every two years is old hat. Charging companies for their IDE by the developer-hour, now that's Thinking With Cloud.
Partly. They've also said that they used some code from Visual Studio in some of it so I guess getting corporate permission to open it is not trivial.
For the Python one at least it's not as bad as it sounds - the Pylance extension is closed source but the core type checker Pyright is open source (and much much better than MyPy).
While part of the C/C++ extension is MIT licensed. At runtime the extension downloads binary blobs which have a lot more restrictive license. See https://github.com/microsoft/vscode-cpptools/tree/main/Runti... . This effectively makes it illegal to use the extension in non official Visual Studio Code builds like VSCodium. The situation is similar with C# extension.
There are alternative non Microsoft language servers for C++ and probably other languages which are fully open source and can be used in open source VSCode builds. But unfortunately some extensions depend specifically on the Microsoft language support extensions. For example Platform IO can't be published on OpenVSX due to this. https://github.com/platformio/platformio-vscode-ide/issues/1... . Similar with Unity debugger extension depending on microsoft C# extension.
What's the point of using open source build of VScode with all the proprietary Microsoft stuff removed just to later install the same the binary blobs manually? If you are fine with that might as well run the official Microsoft VSCode build the normal way.
Having some of the telemetry removed in VSCodium doesn't automatically remove it from the microsoft extensions. Taking into account that the official way for disabling telemetry in microsoft extensions depend on the telemetry setting in VSCode itself, having unsupported(and forbidden by microsoft license terms) combination of extension with vscodium seems like higher chance of disabling mechanism partially failing.
As for PlatformIO, luckily at least the project compilation and toolchain setup (which is the most important part of PlatformIO) can be done with commandline tool independently of any editor extension.
Not sure about C++ but the Python extension definitely isn't completely open source. That code appears to be for the extension client, but the code for Pylance isn't open (which provides completions etc.). The code for Pyright (the type checker) is open source though.
Yes, this is very concerning. I'm glad that other people are starting to notice this trend of closed extension tooling and product choices such as the Docker extension only supporting Azure registries for example.. ;-)
Does this mean we can modify this to ship/distribute our own VS Code flavors?
what are the limitations of VSCodium? I see from the comments, SSH doesn't work, which was a big feature and some extensions not working (any ideas on which and why?)
Been a while since I've looked at this. It used to be that settings sync was a Microsoft-only feature, and that still seems to be the case. Are there any independent implementations of settings sync?
I don't know if others are doing the same, but I'm trying to wean myself off of vscode/vscodium in favor of neovim. My main issues with vscode are bugs and performance. The vscode undo history constantly gets corrupted, performance with large files is terrible, extensions can be a mixed bag, vim integration is not consistent and performance in general is sluggish.
On the other hand, I've been trying out Lunar vim and it has feature parity with vscode and suffers from none of the issue I mentioned. My only issue is taking the time to learn how to do a dozen or so operations that I have not investigated in Lunar Vim yet. Lunar vim is blazing fast when paired with Alacritty. Once I get around to filling the final few knowledge gaps I have, I'm done with vscode.
I'd still rather support a project like (Neo)Vim or Emacs that isn't developed under the auspices of a corporation (whose mantra is embrace, extend, extinguish), and have proven staying power. We've seen IDEs and text editors come and go through the revolving door of public opinion for decades, but Vim and Emacs have both continued to hold strong as tools you can use over the course of your entire life, and they've continued to get better and better as technology has improved.
I feel like people just woke signal their concern for privacy without understanding it.
There are definitely some things that should be focused on privacy, however many modern great products (both hardware and software) got to that state specifically because data was collected and product was refined, all without any evidence of nefarious use.
Personally, I look forward towards the day when I can open up VSCode, type commands in plain English, and it spits out working, correct code.
I guess it always depends on how much you value the IP of your code. But for many projects, I find Copilot too valuable to avoid it because of telemetry/privacy reasons.
And I guess if you work on anything open source, leakage of source code isn't a concern anyway.
> vi/vim is nice but I find the convenience of VSCode - auto complete, show inf doc etc - very useful
You can have all of that on vim. On neovim, you can even setup LSP with the same LSP servers that VSCode uses [1]. The learning curve is steeper but if you like vim/neovim keyboard-centric features, it is worth it.
The only thing I miss from VSCode is maybe the debugger, not because you can't have one, but because it is a bit tedious to set it up and more error prone. So sometimes I use VSCode as a debugger, but I'm pretty happy with my config on neovim (imports, auto complete, docs info (or "hovering"), definitions, go to definition, rename a symbol, etc., you can have all of that with LSP).
I use emacs. I don’t code in Rust but for my occasional Python work I’ve found emacs works better than even Pylance (which isn’t available on vscodium anyway)
Occasionally also using code-server, I am interested in some workflows that the vscode architecture allows. Not an emacs fanboy, just don’t think I should tie myself too strongly to vscode and found emacs generally better for how my brain functions.
I have absolutely no use for a code editor with a typing latency as high as vscode. Anyone who has not read https://pavelfatin.com/typing-with-pleasure/ is doing himself a disservice.
Sans for Java, for which IntelliJ IDEA still holds a little bit of an edge in terms of syntax highlighting, lots of people are moving to VSCode. Besides all the nice little features (like jumping through code, markdown render, e.t.c) it has 4 big advantages.
First, VSCode remote SSH extension is EXTREMELY useful - any computer you can SSH to you can edit code directly on with any extension.
Secondly, terminal integration is super nice. You can configure keybinds specifically for the terminal (and in general, they are pretty well set up default). So for example if you are using remote SSH extension from windows to linux, the terminal functions just like under native Linux.
Thirdly, for data science dev, native Jupyter support is super nice.
Fourthly, the remote SSH integration also works extremely well with Windows/WSL2, which is arguably the best way to have a "dual boot" system today. You get the widest range of software/games that you can run, with almost no drawbacks in comparison to running native Linux. You can do all your dev in WLS2 nicely with VSCode, just like you would under Linux, including things like docker, CUDA for ML, e.t.c. Even graphical linux apps work now.
VSCode with remote ssh is the main reason I'm not on Linux anymore. I always liked Windows more for everyday use (I know that's a rather unpopular opinion here) but needed Linux for development work.
With remote SSH it feels like I'm developing on Linux (I use a small VM for that) without having to change my OS. Plus, it makes switching between machines much easier.
> VSCode with remote ssh is the main reason I'm not on Linux anymore.
WSL mostly did it for me. I can go from playing games on the platform that’s received the most attention (which is nice when a Linux port is broken or for some reason doesn’t play nice with proton) to programming and hacking in a familiar environment.
The exception is when I’m screwing with Linux specific hardware, as WSL doesn’t have USB or PCIe pass through afaik.
I do. And countless of developers I know, who were perfectly professional when I last checked. Many developers don't need multi-monitors. I understand if you need/want it but calling "who even use Vscode professionally" is kind of unthoughtful.
Sounds like something that should be handled by your WM. Expecting your IDE to handle "multi-monitor support" (precisely what functionality are you even expecting here..?) sounds less professional, if anything :P
I think they mean tearing an editor (or other panel) out into another window to move to their other monitor.
Currently you can open another window, but it comes with its own explorer, terminal, problems, test runner, etc. Soon you'll have the same file opened twice in different screens, and... bleh.
But you can just drag it across two screens and divide it up along the border? From my experience that works fine as long as your screens have the same resolution.
True, you can divide the editor into two (or more) splits, and also divide the bottom part (Terminal/Debug Console/Problems). If you're the type that doesn't move windows around often, that could work.
Perhaps there is some hidden configuration for this. But did you try to have separate windows of vscode on monitors with different DPI or set different scale manually? There is a shared thing going on between running instances. I can't have one window 100% and other 150%.
Huh? I am not a big fan of VSCode (for other reasons [0]), but I have its windows on multiple monitors all the time. Works fine. Can't even understand how a program could stop that working.
[0] It chews enormous amounts of CPU and RAM, and periodically gets into a state where it won't open the "Open file" dialog for unknown reasons. And occasionally renaming a file brings up something like "Running 'Rename file' participants..." which hangs for 15+ minutes. Absurd.
What languages/plugins/processes are you using? I'm a TypeScript/React/React Native dev and Vscode is butter smooth with very minimal CPU and RAM usage (after offsetting the Electron overhead).
Why would you offset the Electron overhead? Plenty of other editors don't use web tech, so it doesn't make sense to give VSCode a free pass for choosing to use it.
Anyway, I tried running with no plugins for a while, and still had the problems (open file dialog failing, and random occurrences of "running file rename participants" hanging for a long time) occasionally. It happens sporadically on both my M1 MacBook Air running macOS and my Threadripper workstation running Linux, even with no shared config and only editing local files, so I am pretty sure it's just buggy VSCode. I found numerous old bug reports about similar issues. All closed without resolution after being ignored for months.
Edit: oh, and about the CPU and RAM, this is mostly an issue on my MacBook — VSCode is the only software I have ever found that will make it noticeably lag sometimes. I can always close it and open it again with the same files and it will work perfectly for another few days.
Interesting, I never hat this specific problem. We use VSCode(ium) in two ways:
- Locally on the double-wide screens on Linux, no multi-monitoring needed.
- On Windows Servers in tiny and ugly remote desktops of our customers, no multi-monitor available.
If you can't find an extension when using VSCodium then please send a pull-request to this repository https://github.com/open-vsx/publish-extensions with the identifier and that will help grow the ecosystem of open tooling.
ICMYI - We blogged more about this over at:
- https://www.gitpod.io/blog/cloud-ide-history
- https://www.gitpod.io/blog/openvscode-server-launch
- https://www.gitpod.io/blog/open-vsx
If you got any questions lemme know. <3