The people actually making the GNU stuff aren't happy with RMS either. We need to extricate it from the FSF & RMS, not embrace a takeover by Google.
This Tweet was deleted by the Tweet author. Learn more
Conversation
Replying to
Quote Tweet
GNU projects and the free software movement are *far* bigger than one individual.
Demanding people stop using GNU software due to association is just the mirror take of those claiming the FSF can't survive without him.
He is not that important. Hold him accountable.
Show this thread
1
1
25
And I'm not exaggerating here - many of the big alternatives are essentially controlled by Google, and Google pays folks who RT harassment of trans children to work on it.
3
11
Replying to
what of the less obvious things don't have direct alternatives? autotools is a good example I think. and I guess gdb.
2
Replying to
LLVM has a debugger, but see my above remarks. Autotools lacks a direct alternative because most of what it does is just wrong and doesn't need to be done at all.
2
2
7
Google is far from controlling LLVM. They were contributing a comparable amount to GCC, binutils, etc. back when they still used it and before they'd decided to migrate to LLVM.
The binutils replacements were a lot more focused on macOS and Windows before caring about Linux too.
2
LLVM donated their branding to a stupid toy project of Google's just because Google wanted them to. They are controlled by Google.
1
The libc project fits into the overall ambitions of LLVM beyond Google.
They're very open to incubating those projects and accepting substantial code drops from big companies.
LLD and LLDB are pretty good examples. Originally, it wasn't clear LLD would do serious Linux support.
2
They have a much different attitude than most projects. They'll accept support for an entire architecture that's not an open platform and can only be used via proprietary development tools. It's a lot more corporate-friendly than even the Linux kernel approach.
2
The attitude towards out-of-tree code is very comparable between Linux and LLVM. To some extent, both projects see code churn breaking out-of-tree code as a positive. A major difference is LLVM doesn't expect you to open things up beyond the code you submit to get it upstream.