The AI boom is worse for DRAM fab planning than the crypto boom was for GPUs. It's way way way bigger, somehow has huge money behind it, and DRAM fabs are investments with usually no less than 5 years latency from starting to build any particular one until the first memory sticks show up on a best buy shelf, while planning for the factory to produce continuously for 20+ years in normal times to turn profit if one calculates in lending rates/interest.

They are not curtailing themselves in a market as lucrative as the current one; they probably boost their marginal work planning impacts to productivity via predictive maintenance like actions to err on the side of more productivity due to the immense profit each Gigabit they can deliver this year makes them. Literally like over half of what a consumer pays today at best buy could be expected to be just profit of the factory based off of the non-artificial supply limits and the huge AI demand pushing out all but the wealthiest home-PC demand...

There have been multiple RAM price fixing scandals in the past so my default position is strong skepticism in this matter. I am sure they have various "explanations" but I will wait before believing them.

See ndriscoll's answer; but besides that there should at least be a feature to tell your local app that a road in question is not to be considered private for yourself; imagine it telling you to go around a long way instead of cutting through your private driveway road that accesses your parcel from both bottom and top road, when you don't technically have the destination on your parcel (say, going to the neighbors across the bottom street straight from work which has you come by the top street first).

Same problem for pedestrian plaza structures btw. Though there it's arguably worse as it has a good chance of affecting routing choice not just user presentation.

It's sadly easy to confuse "take public transit" with "driving a train" on the UI :( Given that for most other modes it's used by the driver.

We should push the typically publicly funded (and via that path: the big single entity that pays you the largest (single) share of your income as a transit company gets to dictate a LOT if they try and it's inherently close to free) to literally just publish the real time traffic information as open data for at most a fee (if getting directly from the source, not any aggregator/CDN) equal to AWS's bandwidth charges for the traffic itself. With a license that allows others to just offer caching proxy access with no stipulations other than maybe some reasonable amounts of attribution. Because sadly many places routing with no schedule awareness increases "typical" journey times by >50% for a decent chunk of the ridership base.

On that note, I should see how open data my municipal utility's EU-forced-outcrop of a "mobility" branch handles it's real time data, because I did notice (from ads in the busses at the doors where they put what are essentially D2C "press note"s) about a year or two ago that they started offering a mobile browser usable (without giving any permissions to the site, at least above default android Chrome) live position tracker for their bus fleet.

Could be useful to do some predictive modeling on it together with the schedule to enable streaming commands to one's earbuds (if one's just listening to music while on the way) about haste (/lack thereof)/catching a different station.

Like even just telling me if I catch the bus at the closer station when leaving home or if I should walk to the other branch line which is about a minute further to walk (and that entire minute is uphill) but has the bus scheduled to depart 3 minutes later. They connect shortly after at a transfer/crossover where the routes alternate between physically crossing and merely briefly meeting up at the same "named stop" with just two driveways separating the nominal positions at the sidewalk the busses park alongside to open their doors.

I don't have the mind to check that real-time position map for the duration of the shared walking path between home and the "fork in the road" where I have to choose between the two bus stops, while analyzing the moment on the map to identify if it's getting held up in traffic (shorter) or actually stopping at the stop it'd have to be at (AFAIK pretty much exactly) for me to not need to run (but only walk with purpose on my mind) to still catch it at the closer station. That's particularly relevant because leaving on time with margin for retying shoelaces or stuffing mail in a backpack and aim for the father station makes me catch the closer station exactly once it's a little bit delayed (on the order of 60~90 seconds).

I'd probably want it so I tap the phone to one out of a couple NFC tags in the hallway that tell my device what kind of thing I'm about to do; be that leaving for shortly or for longer (latter case it can also cut the heating until I give it an ETA of when I'll be back; due to good insulation the savings of less thermal flux due to less temperature Delta between inside and outside are not worth having to remember to give it an ETA to have it back up to temperature before I arrive).

That’s a could.

I'm looking to switch from feeding the default android "recorder" app's .WAV into Gemini 3 Pro (via the app) with (usually just) a `Transcribe this please:` prompt; content is usually German voice instructions/explanation for how to do/approach some sysadmin stuff; there does tend to be some amount of interjecting (primarily for clarifications(-posing/-requesting)) by me to resolve ambiguity as early as possible/practical.

If e.g. parakeet can be run on my phone in real time showing the transcript live:

- with latency low enough to be "comfortable enough" for the instructor to keep an eye on and approve the transcribed instructions

[not necessarily every word of the transcript, i.e., a commanded "edit" doesn't need to be applied in the outcome as long as it's nature is otherwise clear enough to not add meaningful amounts of ambiguity to the final "written" instructions]

by glancing at the screen while dictating the explanation (and blurting out any transcription complaints as soon as that's possible without breaking one's own string-of-thought or spoken grammar too much)

, I'd very happily switch to that approach instead of what I was doing.

Bonus if there's a no-bulky-or-expensive-hardware way to accommodate us both speaking over each other so I won't have to _interrupt_ his speaking just to put a clarifying comment (on what he just said) in the transcript for him to see and sign off, where the at least "only" briefly interrupts his thoughts right while he actually reads my transcribed words (he doesn't have to hear them, and it's better if he won't; I can probably get him to put on earmuffs to not hear me louder than he hears his thoughts, and a sufficiently-smoothed SNR meter for specifically his voice should take care him regulating his volume while the earmuffs mute it and I occasionally talk over him)...

IANAL.

Presuming (I haven't checked myself) the git author information supports this, it should be fine to treat this as licensing the code it specifies under MIT; based on that license name being (to my understanding) unambiguous and license application being based on contract law and contract law basically having at it's very core the principle of "meeting of the minds" along with wilful infringement being really really hard to even argue for if the only thing that's separating it from being 100% clearly licensed in all proper ways being not copying in an MIT `LICENSE` template with date and author name pasted into it.

Just crypto tie them to the server/site and let them do it, CRLs were an issue due to distribution to every device, not because of a hastable like sparse set structure being too much. Also this isn't every connection, but only every time you (attempt to) verify your age.

E.g. the German ID card can all on it's own, just using a server certificate configured/parametrized for this and signed by the government, do a simultaneous pseudonym passkey mint and age gate check. That way you could easily block ID reuse; note that the passkey is locked to the card not the person as it's cryptographically derived from the pair of the card's private internal key, and the server's private key that goes to the certificate.

Access to this part of the card is secured by PAKE between the transport layer (TLS) encrypting and user interface providing NFC reader (for example phone with the app, or dedicated hardware) using a PIN.