bcrl
Joined 6 years ago
Joined 6 years ago
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.
This is only going to get worse in the foreseeable future.
4. No guilt when violating human standards of ethics.
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.
[ 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. ]
Perverse incentives will only change when regulators are made to care.
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]"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.
The real issue at hand is that humans need to decide to start resource constraining AI before it consumes the entire world.