It's easy enough to write a bit of Verilog to perform partial updates on the CRC to only compensate for what has changed. I did so for an FPGA project I implemented a number of years ago when processing VLAN tags and doing IP forwarding.
That said, there are lazy hardware designers that just slap on a block to recompute the CRC and replace the old one with the new. An experience I had years ago at Red Hat taught me that the hard way as a shiny new Cisco ethernet switch IT deployed ended up costing us weeks of frustration and delayed a release when it caused bit flips in NFS packets during stress testing. The switch was so awesomely advanced that it recomputed the CRC on the bit flipped packets causing kernel builds to fail. <sigh>
The U7 Lite only does 2x2 MIMO. Compared to 4x4 MIMO in the U6 LR, the U7 Lite therefore does a much poorer job at beamforming (directing the energy of the signal towards the device).
Personally, I find it better to have multiple low end access points (like the TP-Link Archer C80 which has 3x3 MIMO on 5 GHz) deployed to achieve excellent coverage in a house. Sadly, the U7 line is a bit too expensive for that. Plus, I'm loathe to deal with UniFi deployments now that I am well versed in the glass jaws in the platform.
There really is space in the market for a product line that is basically what UniFi is, but done "right". Ie: can be debugged or you can fix it without an internet connection or recover the system when the owner forgets the password and lost access to the email account used for 2FA. UniFi is an absolute nightmare the moment anything goes even slightly wrong.
What precisely is the moat surrounding AI that SpaceX is using to justify this kind of spending spree? I don't how SpaceX and other AI companies will be able to keep the weights of their AI models private in the face of interest by virtually everyone in the world. It would be absolutely trivial for a nation state to walk into a data center using a state issued security certificate to seize a few of the physical servers running the cloud services of OpenAI / Grok / Claude. Copying the weights is trivial. Infiltrating a company with spies as new hire coders to gain access to source code is also trivial.
This is really starting to feel like the pets.com era again.
The US' ongoing hostility towards Canada is decimating the relationship. The auto sector chaos inflicted by the US has destroyed decades of cross-border integration that benefited both countries, and it is now resulting in the cancellation of major projects (like the Honda $15 billion dollar Ontario EV project being scrapped). The trust Canada had shared with the US as relationship that benefited both countries is gone.
The sad thing is that the relationship probably cannot be rebuilt anytime soon. It will take decades to restore trust that was damaged in a few short years. Canada is forced to diversify and build closer relationships with less volatile nations across the world. This is probably good for Canada in the long term.
Personally, I find the predictable network names feature infuriating 100% of the time. Changing the name of network interfaces made nothing better, and actively made things worse for systems with a single NIC (virtually none of the systems I use with a single nic use the same name). Network interface configurations could already be bound to MAC addresses rather than names, and that had been implemented even before the enpXXX style names came into being.
Persistent ethX names were far better to me, and we had those before enpXXX via udev. At least then when I logged into a random system with a single NIC it was called eth0. With 2 NICs they were eth0 and eth1. Simple to predict, no thinking required (unless the system already had bound those names to other MAC addresses).
Usability dies by a thousand cuts. Forcing needlessly complex behaviour onto people with simple use-cases is not an improvement.
McDonalds actually seems to have learned to take latency seriously. When their touch screen ordering systems were first deployed, the delay between tapping on an item or button was quite noticeable. These days the systems respond nearly instantaneously. I'm very glad there are people inside such a large organization that pay attention to that aspect of usability.
Now if only every other website on the internet would learn that latency matters...
There were more ~26+ years ago. gcc and egcs had some subtle register allocator bugs that would get tripped up under heavy register pressure on i386 that were the bane of my existence as a kernel developer at the time.
Software was already far down the bloat path by the time the Core 2 Duo came out, so the upgrade didn't make all that much of a difference in feel given how much latency was caused by software performing random reads off a disk. That's why SSDs made such a huge difference.
Back in the MS-DOS days, the amount of data needed to be read off a disk while the OS booted was negligible, so a second or two on a fast 486 felt amazing compared to the incredibly slow grind of watching code execute on an 8086 or slow 80286. Software was still in the space of having to run tolerably on an 8086, so the added resources of a newer faster machine actually did improve the feel of the system.
Many of the merge lanes in California are insanely short compared to those in the rest of the world. The worst are the ones that have merge immediately before an overpass and exit immediately after where merging and exiting have about the width of the overpass to change lanes. I found those infuriating when I used to visit friends in the Bay area. The pattern where I live is the opposite (long exit lane before the overpass and a long merge lane after) and provides far better margins of safety.
It's plausible that the AI companies have given up storing data for training runs and just stream it off the Internet directly now. It's probably cheaper to stream than buying more SSDs and HDDs from a supply constrained supply chain at this point.
Given the tectonic shift in priorities for Linux kernel development over the past decade, I'm willing to bet that many key developers would be open to a microkernel architecture now than ~25+ years ago. CPUs now have hardware features that reduce the overhead of MMU context changes which gets rid of a significant part of the cost of having isolated address spaces to contain code. The Meltdown and Spectre attacks really forced the security issue to the point where major performance costs to improve security became acceptable in a way that was not the case in the '90s or '00s.
Please read the article in full. The GPU die where all the computations occur and the majority of power is spent will remain on TSMC.
TSMC plans their A14 process to be in high volume production in 2028. It will include backside power delivery introduced in their A14 process (expected 2026/2027 high volume production), which means it will be quite competitive with Intel.
"The GPU die will remain with TSMC, but portions of the I/O die are expected to leverage Intel's 18A or the planned 14A process slated for 2028, contingent on yield improvements."
Reading between the lines: Nvidia will most likely design a TSMC version of those I/O die portions in case Intel fails.
Intel has a decades long reputation of failing its attempted foundry customers. Whether or not Nvidia's ownership stake is sufficient to overcome the inertia within Intel that has resulted in those failures remains to be seen.
Thanks for publishing your blog! The articles are quite enlightening, and it's interesting to see how semiconductors evolved in the '70s, '80s and '90s. Having grown up in this time, I feel it was a great time to learn as one could understand an entire computer, but details like this were completely inaccessible back then. Keep up the good work knowing that it is appreciated!
A more personal question: is your reverse engineering work just a hobby or is it tied in with your day to day work?
Ah yes, the "things are bad; we shouldn't try to fix them" argument. That isn't a philosophy which I subscribe to. People should very much consider the ethical implications of releasing software they created to the general public.
That said, there are lazy hardware designers that just slap on a block to recompute the CRC and replace the old one with the new. An experience I had years ago at Red Hat taught me that the hard way as a shiny new Cisco ethernet switch IT deployed ended up costing us weeks of frustration and delayed a release when it caused bit flips in NFS packets during stress testing. The switch was so awesomely advanced that it recomputed the CRC on the bit flipped packets causing kernel builds to fail. <sigh>