The first issue is that protobufs arent a standard. That inherently limits anything built on top of them to not be a standard either, and that limits their applicability
Also depending on the environment you run in, can code size bloat vs alternatives can matter
Give me something that isn't based on protobufs at wire / request level. CBOR with CDDL for a fully standards based approach that can work at any size of the stack
That's the whole point, source tars when properly versioned don't change. And you can get unchanged versions from any mirror in the world. sha256 of linux-2.6.10 release is 404e33da7c1bf271e0791cd771d065e19a2b1401ef8ebb481a60ce8ddc73e131, it wont change
This is a false choice. "Vendoring" is much more of a mess than this is, and second, there's no reason to rely on these on the fly tarballs for anything, when proper versioned software releases exist.
Github has pretty much a one-click ( or one API call ) workflow to create properly versioned and archived tarballs. Just because lots of people try to skirt proper version management doesn't mean you should commit the world into your repo
I've lost count how many misguided bids of taking x86 to low-power they made. Also the apparent unshakeable confidence that ARM will never become viable on server and desktop.
Somehow those promos have to get done right ? Couple of OKRs, a few perf cycles, launch, and move on. Also great perf stories for people who took care of sunsets
Nah, this is bunk. The cost of code sharing on top of something like Ionic is next to nothing. And for every platform specific feature you can just plumb in whatever plugins you want.