I always wonder why people usually choose to neglect privacy issues about Apple.
First, there was Apple scanning photos to check for child abuse[0] (that obviously got no attention on this site), then there was this one - Apple uploading hashes of all unsigned executables you run.
Do people really accept that company's "privacy" selling point?
Electricity. In some places, electricity is still largely produced in thermal power plants, which do pollute a lot. In France and Norway, I guess most of their electricity is from nuclear and water?
> We didn't go out of our way to deliberately break anything.
> But we do occasionally turn symbols that aren't meant to be used outside the kernel into GPL-only, because they have some internal implementation issues.
SCTP is a good protocol itself, but there are lots of NAT devices/firewalls/other strange middleboxes that do not play nice with SCTP. These devices only recognize TCP and UDP, and they tend to drop everything they do not know.
This is not something very easy to fix - not as easy as fixing Cisco devices that hijack 1.1.1.1, or upgrade enterprise-grade MITM firewalls that don't know and block TLS 1.3.
Can't you just encapsulate SCTP in UDP? Isn't that the reason we have UDP in the first place? If a middlebox will pass QUIC, it should stand to reason that it'll pass SCTP over UDP, since they're both oddball UDP protocols.
If you do SCTP in user space with UDP encapsulation, most of its benefits disappear (and you have to do that - also because of Windows).
It's standard only on paper. There is only one significant user space implementation (usrsctp). It's used both by Chrome and Firefox. I don't think it has much use outside of that. And, I don't think other browsers implement data channels (which require SCTP).
Browser implementations will probably never have to interact with kernel implementations (which are not really used outside of telecoms). There is really no reason to make them talk the same protocol. It's likely better to use two different protocols tuned to those specific uses:
You only need to do UDP encapsulation on the client side (and then again, you can easily fallback to the kernel acceleration on supported platforms). On the server side, SCTP has a BSD sockets API already, and with some creative ethernet bridging, you can convince the kernel to unencapsulate your SCTP packets (doing this right now in a project for WebRTC, so I know it's possible). This is a one-time investment that can be made open-source and can be done in userspace. Of course, a kernel patch to encapsulate SCTP in UDP shouldn't be that difficult either.
There's two sides to networking -- client and server. Your arguments may make sense for the client, but they do not make sense for the server, IMO.
> There is only one significant user space implementation (usrsctp)
That's right, but there are others (one was posted a while back) independent implementations, and the kernel implementations (BSD, Linux, likely others) are indeed different.
Unlike ConnectBot, Termux is not a terminal, it's a customized linux environment (think of a chroot without really changing root directory), which provides its own linker and libraries (so it's not advised to run android system tools in Termux, thus not a terminal).
I'm not sure you're not trolling, but in case you have serious concerns, node.js 4.0.0 incorporates the history of io.js. io.js defined 1.0.0 in early 2015.
