bcrl

Small (10cm x 10cm) 2 layer PCBs only cost about $2 these days ($6 for 4 layers), which makes more complex designs possible for hobbyists. However, I am impressed at the hand soldered build by the author! Prototyping on breadboards is so much more accessible with CPUs that are only clocked at a few / tens of MHz and don't have thousands of pins... Looks like hours of fun!

Given that the stated plan of Micron is to focus on 3D scaling, keeping per-mm^2 production costs low makes perfect sense. When Samsung introduced their first volume V-NAND flash, the 2D feature sizes were larger than leading edge NAND flash because of the tolerances inherent in producing 90 layer flash (aspect ratio matters!) as well as the cost of production equipment. That trend has continued as it is cheaper to produce flash with more layers than to compensate for difficulties arising from decreasing amounts of charge kept in ever smaller cells.

In layperson DRAM-speak this translates to the following: rowhammer attacks are mitigated at the hardware level by increasing the size of and spacing between adjacent cells. At some point further feature size scaling makes it no longer be possible to produce 4F cells that are sufficiently robust against rowhammer type attacks to meet Micron's internal reliability targets. This would be akin to when Intel hit the power wall with the Pentium 4 in the early '00s forcing a change in engineering direction away from merely scaling clock speed.

With Micron's insight into the DRAM order pipeline, management likely has to factor in the chance of oversupply in the next couple of years as significant, which makes the shift in direction even more sensible. DRAM price crashes are a regular occurrence in the industry which lead to anti-dumping tariffs and legal battle in the 1990s (as well as Intel's shift away from DRAM towards complex logic devices in 1985). I'm pretty sure Micron's management is consciously working to avoid a repeat of that protracted legal battle.

I'd rather have an engineering problem over a legal problem any day of the week.

The EEVblog teardown of the DH800 shows that the ADC is a custom Rigol part. Whether it's a rebadged ADC or not is unclear, but I have my doubts that the price point of the Rigol can be hit with off the shelf components from the North American supply chain.

Most people don't have an idea just how expensive high speed Analog to Digital Converters are, yet modern wifi radios often have 2 or 3 at a price under $30. Going to Digikey right now, an ADC capable of 14 bits at 350MSPS is over $200 (quantity 1), and that doesn't come with all the other supporting hardware needed to build a radio. The magic of volume production of hardware in quantities of millions is quite something.

Progress in science assumes a certain level of signal to noise ratio in papers. Decreasing the signal to noise ratio in published results will eventually overwhelm the ability to successfully disseminate newly obtained knowledge. This is already happening in the open source community with maintainers being pushed to the point of burnout by AI slop. The same thing is now beginning to happen in other fields.

This is only going to get worse in the foreseeable future.

And most importantly:

4. No guilt when violating human standards of ethics.

Have you ever heard of overhead? When running a technician type job, a 5x cost multiplier on materials / labour is extremely reasonable. I ran an FTTP ISP, and the minimum cost of a service call started at $250, with labour (at $25/hour) frequently being only $50 of inputs to that cost (1/5th of the cost). Every service call has to cover the cost of the travel time (easily 1+ hour), fuel, vehicle, insurance, tools, and materials. Plus there is dead time when a tech isn't being fully utilized. That means billing 5x to 10x the labour cost just to break even.

Having AI robots do the work does not materially change or reduce that basic cost structure, as labour is one of the smaller inputs to the cost of the service call.

I get that people on the outside of the service industry looking at 5x or 10x markups see them as being "ridiculous", but that is because they aren't looking behind the scenes to see how the sausage is made. The service industry is nothing like tech where the marginal cost of delivering software drops as the number of the users (and developers) increases. A single truck equipped with the required tools can only be used for so many service calls in a given week, and swapping out the human with a robot isn't going to change that. Moreover, increasing utilization significantly beyond 8-12 hours per day seems unlikely to happen as there probably isn't much appetite in the general population to meet and greet a service robot into their home at 3am then explain and show what the issue is that needs to be resolved. There's no way that a 3am service call can cost 50% less than daytime service call.

In contrast, the marginal cost overhead of spinning up one more software developer for big tech is almost nothing. You might spend $2000 for a computer and another $1000 for a desk and chair for them to sit on, and virtually everything else (data centers, servers, networks...) is shared infrastructure. That's nothing compared to trades where you have to buy a truck and outfit it with tools for $100k to support 1 employee. [The bucket truck I have cost $125k, and equipping it with the bare minimum of tools required was another $25k on top of that.]

Sometimes I wonder if anyone has done the basic napkin math to figure out if pushing AI into certain jobs is going to be even remotely economically viable. Personally I view this as a symptom of the larger problem that there are very few "good" ideas left for VCs to throw piles of otherwise idle money into, which directly leads to a kind of VC slop where unprofitable ideas get subsidized and offered to the general public "for free"... until it isn't. Then we'll be stuck with monopoly AI HVAC firms and their 27B stroke six forms making everything miserable for us.

It is somewhat disappointing that Global Foundries basically stopped participating in the leading edge process node race around the time of the split with AMD. The world is in a rather precarious place with virtually all eggs in the TSMC basket.

[ Intel has yet to prove that it can sustain itself as a foundry for third parties, and until they do, I have a hard time believing the massive culture shift required across the whole company can be achieved without splitting the company up into separate parts. Samsung has fallen behind, but at least they have diversity across a variety of markets including HBM. Neither have leading edge fabs in Europe, so everything continues falls back on TSMC. ]

$220 is irrelevant to Google. The bot farms spend more. Hence, the small honest customer is not worth supporting when the large malicious customer will generate orders of magnitude more revenue. Viewed through the profit incentive, the end result makes perfect sense.

Perverse incentives will only change when regulators are made to care.

No. DKIM signatures were designed to work when emails are forwarded. I run a couple of Linux related mailing lists, and the DKIM signature continues to validate specified headers and the body of the email when forwarded or resent via mailing lists. Dealing with that quirk happened a decade ago, and it is why most mailing lists no longer add headers or footers to emails with instructions on how to unsubscribe.

I think the difference between Google's DMARC policy for gmail.com and google.com says it all:

  bcrl@home:~/electronics/vrm/lm5017/test-lm5017-isobuck$ host -t txt _dmarc.gmail.com
  _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]"

  bcrl@home:~/electronics/vrm/lm5017/test-lm5017-isobuck$ host -t txt _dmarc.google.com
  _dmarc.google.com descriptive text "v=DMARC1; p=reject; rua=mailto:[email protected]"

Muscle memory and awful connectivity in remote places (well, not even that remote for me) is what so many GUI apps undervalue, and I don't think the author of the article has ever thought of or encountered this. I loved TUIs back in the '80s and '90s when convention was so consistent across applications that muscle memory transferred seamlessly. Plus one could use a mouse to select menu options or the keyboard (like the many Microsoft programming environments like QuickBASIC, QuickC, Microsoft C as well as competitor products like Turbo Pascal and many others).

The low bandwidth / high latency lossy link problem is still a major issue. Cell phone service is sufficiently shitty in the area I live in that I have to use mosh to get a usable remote connection many times a year. Mosh is also quite useful while travelling! Got a crappy connection on a train or airplane? No problem. I have so much muscle memory with the mutt email client that nothing else has ever come close. Where's the equivalent of mutt's limit command in Thunderbird?

Try getting a usable VNC session when your cell phone hot spot is hitting 2-30 second ping times (yes -- thirty seconds) with only a handful of packets getting through.

Version 2 of the Amiga's operating system did a great thing in version 2 of AmigaOS which explicitly spelled out what conventions to apply (see Amiga User Interface Style Guide at https://archive.org/details/amiga-user-interface-style-guide). Modern GUIs that have weird meaningless buttons are infuriating. Even moreso when they lack obvious keyboard shortcuts.

Every additional level of abstraction in computers has resulted in bloat that makes software less efficient and more bloated. AI is merely continuing to accelerate the tread.

The real issue at hand is that humans need to decide to start resource constraining AI before it consumes the entire world.

Deaths per terawatt-hour of nuclear is still lower than any fossil fuel per https://ourworldindata.org/grapher/death-rates-from-energy-p...

ECC tends to be too expensive to be used widely in hardware data paths. Most of the time hardware will use a parity bit as checking it is far less costly (both in terms of gates and power). Parity bits are usually sufficient, as the purpose is really limited to identifying hardware failure. The CRC should prevent delivery of a corrupted packet provided the hardware doesn't cheat and blindly recompute it.

Exactly this. Spammers have the technical competence to overcome any technical hurdle, so using evidence of technical competence achieves nothing.

If it were possible to charge $0.25/email for delivery, I'd be more than happy . However, I'm sure large tech firms will need to say that is "too hard to implement at scale".

It works at small scale when you self-select for technical competency. It does not work at larger scale when that self selection is no longer possible.

My scale is that I ran an ISP for ~500 users before the network was disassembled last month. At that scale, you will encounter people that make mistakes with their email setups. When the people who make mistakes are customers which DMARC prevents delivery of emails, it is an issue as those are exactly the people for which I want to see the emails from.

I get more spam with valid SPF and DKIM via Google's own mail servers than DMARC blocks.

It says something when even gmail doesn't use DMARC as a signal that an email is valid, as gmail regularly blocks legitimate mailing list emails with completely valid signatures and non-spam content from a reputationaly sound IP.

The problem DMARC was supposed to solve (impersonation to reduce spam) isn't solved by DMARC.

Then you don't deal with email in the real world. DMARC prevents legitimate emails from people in the real world from being delivered because people make mistakes with their email systems. Passing DMARC is not a signal that the email isn't legitimate; it's merely a sign that someone correctly set up their mail server to modern standards. The email might be an impersonation, or not. There's no way to know.

DMARC does absolutely nothing to prevent the kind of impersonation that occurs in the real world. It doesn't block homoglyphs or or typo-squatting or all the other forms impersonation that matter. It has failed at preventing impersonation.

Just a few days ago I had a phishing email from an elderly woman I had previously done some work for. The message passed DMARC and everything else, and the domain it was sent from was valid. But it was not legitimate; it was an impersonation of her which became obvious once the content was read.

DMARC is noise, not signal. It has to be ignored in the real world as it provides virtually no value beyond blocking emails pretty randomly because someone made a mistake when rotating their DKIM keys or one of a million other mistakes that do happen.

Sadly the article doesn't really touch on whether or not DMARC accomplishes anything truly useful. When I enabled DMARC for ingress email on one of my own mail servers, it ultimately ended up regularly blocking a handful emails from customers, yet virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks.

The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender. Signatures are purely a technical measure which provides no information on the trustworthiness of the sender. The end result is that email scoring still has to be content based, and the signature check technologies are pure noise with no useful signal for the purpose of determining if an email should actually show up in my inbox.

The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.

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.

Postfix has a far better security track record. Exim has a steady stream of CVEs.

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.

All you need are NAND gates.

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...

BitKeeper tried to do that. Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community.

"Those who cannot remember the past are condemned to repeat it".

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.

Please name a computer science program that has an ethics component.

Yes, I wish software developers were more like actual engineers in this regard.