Recent submissions

Comment · 11 hours ago
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!
Comment · 4 days ago
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.

Comment · 18 days ago
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.
Comment · 19 days ago
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.
Comment · 21 days ago
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.

Comment · 22 days ago
And most importantly:

4. No guilt when violating human standards of ethics.

Comment · 22 days ago
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.

Comment · 1 month ago
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. ]

Comment · 1 month ago
$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.

Comment · 1 month ago
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.
Comment · 1 month ago
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]"
Comment · 2 months ago
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.

Comment · 2 months ago
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.

Comment · 2 months ago
Comment · 3 months ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton