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.
2.4 GHz is unreliable for me these days due to interference from bluetooth headphones and hearing aids that other people are using. The issues tend to only show up during extended periods of video streaming, and having looked at a bunch of traffic captures over the holidays, it seems to be limited to certain streaming services sending very large bursts of traffic at extremely high rates (likely from servers with 100+ Gbps interfaces using TSO to reduce CPU usage). That makes me think that the regularly paced bluetooth interference from real time audio streams limits the maximum viable burst size of a 2.4 GHz wifi radio.
Yes, this happened a bunch more over the Christmas holiday when we had an extra 3 or 4 younger family members all listening to music and videos over their bluetooth ear buds and headphones, which made it much easier to track down as it was quite a rare intermittent failure with only a single bluetooth device being active.
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.