US and China are both super power. Don’t be naive that they would be doing things differently.
751 karma · joined May 2, 2014
US and China are both super power. Don’t be naive that they would be doing things differently.
I don't think it's a stretch to state the risk of tiktok being mass propaganda machine, from India's perspective.
Additionally, I don't take this as a particular politically charged statement against China, as quite a few replies stated. The reason is that China and India are on a very delicate geopolitical environment. The history is long and ambiguous. The current rivalry is subtle and dangerous. You just cannot give any chance in this situation. After all, China do not have any foreign social network services anyway. There is no reason to gift the opponent an potential upper hand.
The Pandora's box was formally opened in the Arab spring already. It was a well intended start, followed with an ugly development and messy prospect left for generations to suffer and struggle.
Now the whole idea of social networking services as an actual helper of connecting people with different cultural background roughly reduces to nil. That really was a buffer.
Lastly, I don't think it makes sense for any sovereign government to force their country's corporation to serve them directly.
That would immediately destroy any chance of those organizations to expand beyond their home country. Someone might argue Chinese firms are OK to that because they had a big market already. That's a totally unreasonable imagination on Chinese business men's brain structure. I never encountered any such Chinese business man who believe loyalty to CCP is higher than their profit. Other argument is that Chinese law can coerce, but all the laws are saying the company ought to corporate when necessary for the security of the country. I cannot imagine any sane political personnel can convince anyone else that offensive propaganda in peace time is necessary for national security. At least I did not see any such behavior or even minor behavior with hint of such reasoning from past history.
* Borg is primarily for managing hardware resources. K8s, in comparison, is for managing applications. I often call them a complementing twins. They both are container based cluster manager, but their focuses are opposite. I also use "machine oriented" for Borg, and "application oriented" for k8s.
* Borg emphasize on scheduling capabilities, performance, and scalability. And various integration capabilities for wiring together the base line software foundation, and interfacing with hardwares. For example, SDN, security, name service, needs to hook up with Borg, to interact with all applications.
* K8s emphasize on modeling application semantics and how to map them into containers. K8s provides abstractions for on boarding apps and a lot of toolings.
In summary:
* K8s is considered a layer on top of Borg, if it can ever be incorporated into Google production.
* As of now, there is nothing in sight that can be considered next generation Borg. Just like there isn't any next generation Linux. Software like Borg, and Linux, can only be supplanted, not succeeded. Their vast amount capabilities defy succeeding. In other words, if one want to build a better Borg (or Linux) they are doing it wrong. K8s did not try to better mesos or open stacks, or Borg perse, it's just a different thing.
Edit: There are numerous difference between Borg and kubernetes. Send me an email listed in my profile, if you are really into the gory details. We can setup some discussion.
Disclaimer: was borgcfg owner 2016-2019.
Beginning: Slow and almost no return. Slow being a lot of intellectual effort to lay the foundation. No return being the foundation does not do anything useful, yet.
Middle: Fast and linear return. Building on a sound foundation allow adding feature that is simple and with high quality; and the return is linear to the effort.
End-of-life: Slow and almost no return. Bloated software eventually is dragged down by historical burden (tech debt, legacy features, etc.). Massive effort is needed to add feature, and the return is almost painful to stand.
A lot of recent software took the approach of forced update to extend the middle life. Like the chrome today is considerably different thing than its beginning. Py3 tries to demolish its historical legacy, and embrace new foundations.
mpvl@ is the main author of borgcfg and one of the two designers of BCL (borg config language). I was maintaining borgcfg 2017-2019, and naturally had occasions to chat with him. I was fortunate to learn the existence of CUE a while ago, and was convinced that its theoretical foundation is solid. That foundation is simply not there in most config languages. CUE (along with Kustomize) appears to me to be the 2 major new ideas of addressing the flaws in BCL, and other template/inheritance-based config languages.
I am very eager to see how the community and industry react to CUE.
There are other means to share build artifacts or code across language boundary, not necessarily through availability from OS distros. For example, Docker registry solves this issue with container images and overlay FS.
I think one way or another, Google's model has been proven to work for large-scale (probably the largest C++ code base on earth) c++ code base. In that I have my full confidence of adopting Google's proven approach.
disclaimer: Work at google, but not the c++ team
This absolutely modernize the nation. It's no small feat to educate 1BB+ people in a few decades. The nation's unity is once again at an unprecedented level.
This is not without its cost. Modern Chinese pronunciation is considered less appealing to ears, meaning that many sound disappears in the new system. The resultant language often sounds more dull compared to historical system.
The written language is less artful. The traditional written language is no doubt a more appropriate subject for Chinese Calligraphy.
I guess the global momentum to move to a more latin-based language is not going to be stopped. But it's nevertheless a saddening event to see a nation's historical root is altered significantly in a short period of time. This did not destroy the root, it's still there. But the changes are more artificial and more brutal.
I worked at Amazon for 1 year. They use semver for everything. I think that's one of a few technical superiority I missed since left. I am curious about its problems.
The article did not say much. As for the suggestion given in the article, I cannot help to think that one can always release a number based on a semver to external customers. That does not prevent semver being used internally at all.
> a general trend towards literally forcing things to adopt semver
This statement assumes that semver is bad if forced universally, which may or may not be the case.
Your comment include no fact that this is bad. When you mentioning rust, you also did not say anything why semver is bad.
I mean, if someone put an arbitrary number there, and users are screwed because of author fails to maintain the correct contract, at least people can go to there and point out that the contract is broken. Removing semver does not do anything good. It just give the author an possible excuse, i.e., if users are screwed, the author can claim that he/she never meant to make its software backward compatible. For that, semver also provides the same mechanism, i.e., bump a major version number. At lease users know that they can expect a breakage.
I think you simply miss the idea of linearizability...