3 ms·
developer/vendor lock-in is done at the SDK level: gcc(via c++), glibc(via manic abuse of versioning + a hard dep on gcc), etc.
by sylware 3y ago
developer/vendor lock-in is done at the SDK level: gcc(via c++), glibc(via manic abuse of versioning + a hard dep on gcc), etc.
- mschuster91 3y agoEveryone can fork gcc and glibc, they are fully open source. In any case the question remains why one would want to... there are alternatives for both of 'em (musl/dietlibc for glibc, llvm for gcc). As long as you keep to the POSIX/C/C++ standards and don't use vendor-specific attributes (or at least abstract them away via macros), you shouldn't run into issues using another kernel, libc or compiler.
- sylware 3y agoYou missed the point. Any fork is deterred by the massive size and complexity of those. c++ is adding several orders of magnitude on complexity (there are no reasonable comparison to make between C syntax complexity and c++ syntax complexity). All that is part of the developer/vendor lock-in. This is how Big Tech has vendor locked some open source software. That's why generic "open source" is hardly less worse than corpo binaries, because it includes grotesquely and absurdely massive and complex software. We need lean, functional enough, open source, SDK included.
- photonbeam 3y agoRed hat’s lock-in is in certifications for various software and situations. Suse is a genuine competitor in this space