4 ms·
Terrible arguments. Golang and Android Studio are both open source, and you could compile them yourself. Telemetry can be turned off in Android Studio, and you
by nwah1 4y ago
Terrible arguments.
Golang and Android Studio are both open source, and you could compile them yourself. Telemetry can be turned off in Android Studio, and you can use stuff like flatpaks to isolate the software from your system, and completely turn off networking permissions if you don't trust the settings.
- nwah1 4y agoAlso, you end up with very similar questions for non-corporate languages like Nim because you don't really know who created the software, what their motives might be, and whether the binaries you are receiving are really what the source code says it is. Reproducible builds help, but once you are going down this path of verifying instead of trusting, then it doesn't really matter who built the software.
- giaour 4y agoI have seen this perspective a lot in government and adjacent entities. For them, commercial software and corporate open source has a clear financial motive. If they can't identify why a project exists and continues to receive support, they see a security risk, either via direct compromise or project abandonment and the associated supply chain rot.
- numbsafari 4y agoand they aren’t wrong to do so. Browser plug-in author gets bored and sells out customer base is a well tread story. Takeovers of well known packages are another. Most of these ecosystems do not offer proper sandboxing for the things we take from them, so it’s easy for things to grow an appendage that abuses our prior assumptions. Apache’s Java ecosystem is full of consultant abandonware and tripwires.
- kube-system 4y ago> Browser plug-in author gets bored and sells out customer base is a well tread story. Not even just "get bored" but, just a plain matter of incentive. Salaries are a strong incentive against undermining your employer's work. Now, of course, there are people who are incentivized because they are altruistic and good at heart, but that's very difficult to measure. It's much easier to demonstrate aligned interests monetarily.
- AnimalMuppet 4y agoBut that concern exists on the other side just as much! Companies get compromised, companies abandon projects. And companies, even though they make money from a project, decide that they could make more money by having it ship them data on the side.
- giaour 4y agoTrue, but I wouldn't say "just as much." An ongoing financial relationship usually means that the purchaser can expect reasonable advance notice if a project is getting discontinued. And in more sensitive agencies, if the government purchases software, they generally have the name and contact information of who they can arrest if the purchased item becomes or is found to be malware.
- JackFr 4y agoObligatory reference: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
- AnEro 4y agoI agree, but I do think that you have to think of the ecosystem of the language if the major cooperation steps away or dials back, maybe thinking of them more like 'dependency'. Go lived through community alone, how well will twitters projects hold up without their involvement because I imagine it's not very lean for twitter to spend time on. I think this argument is better had for frameworks and JavaScript libs. Have caution about who you trust, especially in this new phase of everyone pivoting around AI/BI applications
- jonathankoren 4y agoThis is the real threat. So much “open source” technology is just free community editions of closed source software. If any of these companies decide to change course for any reason, you’re screwed. Who’s going to pick it up? You? No, you were coasting along on someone else work, you don’t have a good expertise or slack to support it. But someone who law will right? Nah. They’ll just shrug and pivot, as will you. Maybe I’m just bitter, but I’m on my third “open source” text editor because of machinations inside megacorps suddenly deciding shutdown perfectly fine projects.
- wizzwizz4 4y ago> Maybe I’m just bitter, but I’m on my third “open source” text editor because of machinations inside megacorps suddenly deciding shutdown perfectly fine projects. Advice for choosing a text editor: • Avoid Electron. • Avoid custom-looking GUI toolkits. • Avoid IDEs, unless they're highly-modular with a rock-solid, simple base. • Avoid complicated build toolchains. I'm using Geany at the moment, which… almost meets the third criterion, and does meet the fourth. If Geany support stops, I'd vaguely be able to make changes to it; the code's written in C, licensed GPLv2+, and it's well-documented. (If GTK2+ or Scintilla support stop, of course, no dice; I don't understand any of that area of my software stack well enough.) Of course, there are things I want it to do that it doesn't; Geany isn't perfect for my workflow. Better than trying to write my own, though!
- stonemetal12 4y agoSame holds true of any software you didn't build yourself. EMACS devs get collective brain fog and start using VS Code tomorrow? I can't support that, same goes for Vim or just about any other editor out there.
- yazzku 4y ago"Terrible arguments. [...] and completely turn off networking permissions" So it basically goes back to what the OP argued, right?
- nwah1 4y agoNo. OP argued that you should not use the software because it might phone home, and the author doesn't think the tools should phone home for any reason. Yet, with flatpak you can specifically turn off networking permissions just for that app, and thus remove the concern. Also, similar concerns would exist for non-corporate software, so the corporateness is irrelevant to whether to use a free tool which you have full ability to inspect and compile yourself.
- yazzku 4y agoI don't know why you'd run a flatpak you don't trust with all that permissions micromanaging. That's the kind of thing you do when reversing malware, not when using everyday tools. The idea that that kind of flatpak even exists already portrays a very sad state of software. Corporateness is also not entirely irrelevant, since the incentives are different, and 'corporate' is highly correlated with proprietary, spyware-ridden software. Also, the author talks about corporate languages (and then throws in the tools too), which have their own different set of problems.