Reading through the comments, there is a bunch of misunderstandings about USB4. Given the poor quality of the press coverage on it, I am not surprised. So let me clear things up.

#1 - USB4 is almost identical to Thunderbolt 3
USB4 is actually an "alternate mode" that gets negotiated via USB PD. The protocol and electrical signaling for USB4 is completely different and totally incompatible with USB3. USB4's protocol and signaling is an exact copy of Thunderbolt 3. USB4/Thunderbolt 3 follows the OSI model; it has a generic data transport physical layer and flow control protocol; on top of that you can tunnel many different protocols. Just like how you can tunnel TCP/IP, IPX, AppleTalk, NetBIOS, etc. over Ethernet; You can tunnel PCIe, DisplayPort, and Ethernet data packets over the USB4/Thunderbolt 3 physical layer. USB4 adds one very important thing that the original Thunderbolt 3 lacked... in addition to PCIe/DIsplayPort/Ethernet USB4 can also tunnel USB data packets. Other than that, the only difference between USB4 and Thunderbolt 3 is that Thunderbolt 3 has a different Alternate Mode ID number. Backward compatibility with USB3 devices is achieved by not activating the USB4 alt mode. USB1/2 has dedicated pins on the USB-C connector, that gives backward compatibility all the way back to 1994.

#2 - USB-C is a fundamental requirement
Since USB4 is an alternate mode, and alternate modes do not exist for the older connectors (USB-A, Micro-USB, etc.) it is technically impossible to implement USB4 on top of USB-A.

#3 - USB4 hubs are going to be crazy complex (aka spendy for the first couple years)
The USB4 specification requires USB4 hubs to be backwards compatible with both USB3 AND Thunderbolt 3. Moreover, when running in USB4/Thunderbolt 3 mode, all hubs are required to support PCIe and USB traffic. That means that every hub needs to implement not only a USB hub, but a PCIe switch as well. The Thunderbolt 3 compatibility requirement also means that every hub needs to have an integrated XHCI controller, since Thunderbolt 3 can't tunnel USB packets natively USB traffic has to be converted to PCIe traffic to go over the Thunderbolt bus.

USB4 devices are not required to support Thunderbolt 3 backward compatibility however. This is going to result in some pretty weird behavior. If you plug a USB4 only device directly into a Thunderbolt 3 USB-C port on a laptop... it won't work. But... if you plug a USB4 hub into that Thunderbolt 3 port, and then plug the USB3 only device into the hub... it will work!!! This will be mitigated somewhat by the fact that most USB4 devices will probably support backwards compatibility with USB 2/3, but still be prepared for lots of confusion from less technical users.

#4 - PCIe Tunneling is a standard feature, and its secure
Since USB4 is the same as Thunderbolt 3, PCIe tunneling comes standard. And no, this a NOT a security issue. Microsoft implemented support for IOMMU assisted IO Virtualization in WIndows 10 1803/RS4, so the "Thunderstrike" security issue has been fixed. Apple did a similar fix on macOS ~8 years ago. No idea what Google's plans are for implementing IOMMU support in Android/Chrome OS, so there is a chance that PCIe tunneling will be disabled in firmware on stuff running on Google OSes... hopefully not as that would just be one more compatibility headache for everyone.

This is one of the few western teleconferencing apps that seems to have decent encryption and is able to connect users inside and outside of the Great Chinese Firewall. For that reason we use it for some of our meetings with customers in China. Guess we will have to find another one since Verizon will likely try to paint them red.

While it's good to see the immediate problems with processing unemployment claims getting solved, don't for a moment think that IBM is doing this out of the goodness of their hearts. It would be very bad for IBM if people started to realize they needed to modernize old business applications like this unemployment claim processing system. IBM makes an obscene amount of money providing computers that can run software written in the 1960s/1970s.

Considering hardware alone, performance per $ on commodity Xeon/EYPC x86 servers cost about 90% less than a IBM z mainframe. Don't forget that IBM charges an arm and a leg for software licenses on mainframe vs. inexpensive Linux on x86. The high availability of mainframes isn't a differentiator anymore either. You can get 99.999% uptime on x86 with virtualization, clustering, microservices, docker, kubernetes, etc. AWS is living proof of that. The only reason to spend $300,000 on a small z series instead of $30,000 on a small x86 rack is because hiring 10-20 software engineers for 5 years to modernize your business software costs ~$10,000,000 fully burdened. Software like this tends to be so tightly customized to a specific business workflow that lots of custom code is involved and updating the system is non-trival.

The destroyed wafers (aka lost product) are probably due to abrupt power loss to the diffusion furnaces. Diffusion furnaces are used to diffuse gas phase dopants into silicon wafers. These dopants are used to modulate the electrical properties of the silicon, making it possible to construct transistors. Because the temperature gradients in diffusion furnaces need extreme uniformity, the only way to build a diffusion furnace is using electric heating coils (burning fossil fuels for heat would not give the needed temperature uniformity). Because the furnace needs to operate at >1000C, each furnace typically uses >1MW of power constantly, so backup power is basically impossible.

Now when power is lost, the heating coils shut down, resulting in uneven doping of the wafers inside the furnace... rendering them useless. Restarting the furnace and getting it back up to the correct temperature takes days.

Yeah it won't cease to exist, but from an information security standpoint we can't keep using something that isn't getting security fixes. I totally agree with you Py 3.x is much better than Py 2.x. The problem is we have a lot of Python code that is over 10 years old now that has largely been neglected on maintenance yet still actively used every day. This experience has served as a reminder to me of why IBM is still sells a low volume of mainframes every year.

Corporate IT issued a blanket statement that they are just going to uninstall Py 2.x everywhere on Jan. 1 and if you haven't upgraded your code yet then too bad. I'm sure much mashing of teeth will ensue.

You are 100% correct, it is technical debt. There are some parts of the company that haven't been very good at paying that debt down. This mandatory Python 3.x upgrade just happened to bring it to the forefront.

I work at a Fortune 500 that has over 1 million lines of Python code that only exists within our company intranet. We don't license it to anyone else for the most part. The vast majority of it is Python 2.x, and it uses a ton of old versions of libraries that have had API changes. Some teams like my own have been mostly proactive on getting our stuff upgraded but that does not seem to be the case for most of the company. Its going to suck.

It is very rare to see a single online review or editor these days who isn't "influnced" in some way. Honestly you really can't trust anything you read to have any integrity anymore. I'm sure this is yet another paid shill. Especially when if it involves anything related to China right now.

Activision-Blizzard's rule-set for tournaments is so incredibly restrictive that basically if some exec decides he doesn't like your face you get banned and lose your prize money. They explicitly forbid the formation of player's associations like MLB or NFL Players. It is so lop-sided against the players that it is hard to consider "e-sports" as an actual professional sport at least for Activision-Blizzard games. I personally consider the players nothing more than poorly paid contract employees in Blizzard's PR department.

Needless to say I 100% support the effort to get Overwatch banned in China; these guys don't care about anything unless it impacts their wallets.

Thankfully PyPy still supports Python 2.x syntax and since its a complete re-implementation of the interpreter it is unlikely to share security issues with CPython. I work at a Fortune 500 and PyPy is our plan for legacy Python software support.

Hear me out, but a refresh rate > 60 Hz really does help with coding. I have been coding on a 100Hz monitor for a few months and the reduction in screen tearing while scrolling through code and moving windows around has been noticeable and I have had significantly less eye strain.

Of course resolution is the first priority, but if you have the budget for it I would highly recommend getting a monitor with high resolution and high refresh rate.

My browser choice largely depends on whether I'm at home or work. At work, plan A is Chrome, largely because we have a lot of internal intranet websites that work great in Chrome but don't work in Firefox (I know it sounds weird, but a lot of stuff doesn't render correctly in Firefox.) Take Slack for example, Slack voice and video calls work in Chrome but not Firefox. Chrome happens to also be really good at general web browsing. Plan B is IE11, because its the only web browser that still gets security updates and will run Java and Silverlight applets which a few older intranet sites use.

At home I use Chrome and Firefox pretty interchangeably. Its kinda crazy, but Chrome is basically the new IE now... its the only web browser that consistently works with almost every website you throw at it.

The headline states that all Intel CPUs from the last 8 years are affected. This is incorrect... Coffee Lake Refresh, Whiskey Lake, and Cascade Lake all have hardware fixes for this problem with zero performance impact as reported by Ars. The hardware fixes done in the latest chips for Spectre/Meltdown are also effective against this new exploit. Intel has also already released a microcode update which resolves the issue for Sandy Bridge and newer processors.

Surely nVidia's decision to enable their older cards to run ray tracing has nothing to do with Crysis demoing real time ray tracing on AMD GPUs a couple days ago. As Cryengine has shown, real time ray tracing can be done in software without the need for specialized hardware accelerators. This kinda makes the main selling point of the GeForce 20 series more or less moot.

AMT doesn't need VTd turned on to access the network, so keeping VTd off for that reason does absolutely nothing. AMT has its own dedicated side band access to the network hardware. AMT only works with Intel networking gear (NIC/Wi-Fi) so the AMT firmware has all the drivers for the NIC built in. Actually, VTd HELPS mitigate AMT concerns because with it turned on AMT is unable to execute arbitrary DMA reads/writes to system RAM, VTd limits AMT's DMA to only the ranges of RAM that the OS allows.

By the way... there is a much better way to "stop Intel AMT"... just don't buy a system that is "VPro" branded. If the system doesn't have VPro then AMT isn't even present... it gets permanently fused off at the Intel factory. Intel has a special sticker for VPro, so labeling of systems is very clear: https://www.laptopmag.com/articles/intel-vpro-faq