[edit] Retracting my unnecessary jab around the moderator's comments being modified several times and their moderation leaving a lot to be desired. The latter was rude and uncalled for.
That shouldn't be significant unless:
1. There is a significant serialization/deserialization delay, which I don't think will be the based on my naive understanding of the tech
2. Buffering in time periods even relevant to discussion should really only occur under specific circumstances (like during overutilization)
1. The consequences of having millions of unemployed people with bills to pay and no income are too much for a nation, let alone politicians in an election year. My bet is that the payments will be extended or replaced with something as the alternative is not viable.
2. WFH has already started normalizing, and will shortly become a differentiating perk offered by companies. I don't suspect that may of the people living in tech hubs would choose to continue doing so if they had the opportunity to live anywhere they wanted (of course while considering COL adjustment).
Yes, I would imagine so. HK seemed to be the only conduit through which trade with the west could flow smoothly. It will be interesting to see how this plays out.
And you're probably right. Hong Kong's status made it home to a lot of the financial engineering of commerce between China and the west. With it losing its status, I think a lot of the financial machinery in HK is about to come undone. Singapore will likely benefit, to some degree, from this move. The world and China may need to find new markets and suppliers in the short term.
This is an amazingly ignorant viewpoint, and I'd bet the farmers in Vietnam of the 1960's and Afghanistan of the 2000's would likely care to differ. Insurgencies undermine the advantages of expensive weaponry.
And if we're talking about a civil war or insurgency within US borders: An army fighting on its own soil and against its own citizens is surrounded on all sides and can't maintain secure supply lines.
This, sadly, is so accurate. That, or the fact that as difficulty levels increase, the game just gives the AI opponents crude modifiers - they don't get smarter, they just get cheat codes.
>It's entirely possible to say "we need to work harder, or take a risk, or be bold" while understanding where your colleagues are at in terms of what they need to do that, or what has or hasn't been communicated to them about how that will happen, or how things have been done in the past to change them.
Great leaders, in my experience, haven't asked these questions or pushed performance in this way - they led their reports through soft management to come to the conclusion that it was necessary to increase performance. They framed questions that led people to the conclusions they had already made. Of course, this also requires that the reports are capable enough of being led in the right direction.
Yeah, it's an interesting approach. They're basically allowing you to define packet processing with P4 on their Tofino family of chipsets:
https://p4.org/
That said, there's only so much you can do in a chip before considerable tradeoffs are going to be made. They're not going to offer the same level of flexibility you get out of a general purpose CPU, but may not have same the restrictions of most fixed pipeline chips - their product sits somewhere in the middle. Also, P4 seems to sit in a space complex enough to make it unreasonable for most network shops - it's not for your average enterprise or service provider network.
For many years, the most popular routing platforms (i.e., boxes built by Cisco) performed IP packet forwarding and management functions on the same processor (often a RISC architecture). In cases where packet rate was high, it was possible for devices to become unresponsive or lose critical protocols responsible for sharing routing information.
In the last 15 years there has been a hard move away from these architectures. Almost no packets are forwarded by the same processors running management and control plane functions anymore. This is mainly because the required traffic rates today need dedicated silicon purpose built for the task (the Broadcom Tomahawk3 can do 12.8 Terabits/sec above a relatively small packet size).
I don't know how things will shake out for the Linux world and x86 packet forwarding given the trend and lack of real performance in the kernel. Right now, your best bet when it comes to Linux and high network throughput/packet processing requirements is to just bypass the kernel entirely with DPDK, a "smart" NIC, or XDP.