jpgvm

I was going to argue but:

> That code runs against a register file and a model of the PSP's memory.

From the project README. That to me, is an emulator.

The walk is usually work too, just instead of staring at the screen and trying to think I take a walk and actually think. So when I get back I can provide input to the robot that will result in meaningful output.

Companies that pay people to hit enter instead of using auto-approve/bypass are going to lose to companies that pay people to think and produce results, regardless of how much time they spend in front of the screen or how many prompts they input.

It's generally also just less typing if you are using long running agents, you can input the goals, steer it a bit then go for a nice walk and check in again on it in 30-40mins. I hope we can normalise this workflow as it will be much better for everyones health and longevity in the field.

IMO LLMs are the best thing to happen to coding in my ~15 years of being in the game.

I wager they have probably added on another 5-10 years to my engineering career as I was contemplating getting out before they showed up.

Have also been convincing some friends that have "gone woods" over the years to put the woodworking tools down for a day or two and give them a go. So far so good, a few folks have found the spark again and it's been awesome to see them make digital things again too.

Honestly that just makes GLM the better model, sorry.

What are they censoring that matters to programmers?

Honestly Rails being finished it's that bad. If you aren't writing the code by hand what benefit is it really bringing to you now?

Rails niche was fast setup/low starting out costs and relatively constrained/medium maintenance costs. To get this you traded performance and type system. The latter usually resulted in increased maintenance costs as test suites ballooned to compensate.

These days fast setup is simply a product of AI, every ecosystem now offers fast setup. Maintenance costs are now about how token efficient it is to find and fix problems. Test suites are going to be huge everywhere now but there is some chance languages that require less to accomplish more will win on token efficiency and be favored.

Humans aren't the dominant factor in programming language design or selection anymore, that is a fact at this point it just hasn't sunk in for everyone yet.

We are only ~6mo in to agents being good enough to write code. A year from now our profession will be entirely changed. Agents will get better (how much? don't know) but importantly they will definitely get cheaper and access will be broader. Which is really the point DHH was trying to make.

Access and economics are finally going to do what no-code failed to do, which is democratise software. Maybe not to the point that everyone writes code or even that shit programmers are good, but it will enable shit programmers to write Rust which was literally impossible 6mo ago and they will have better programs as a result.

Which is the other thing he touched on. Good programmers are going to excel here and great programmers are going to dominate. I'm already seeing the 10x programmers hit 100x and 1000x with more access doesn't seem out of sight. It's also restoring the will to create in a lot of people that lost the passion for the mechanical part of programming, unlocking the experience and skill of these people that were otherwise considering cashing in the bag is huge.

So yes. Rails is done but what is coming next is way more exciting. I'm with DHH here, be glad it happened but get moving on where things are going to be instead of clinging to the past.

I hope it's called Mar Sara.

The important thing here is they have a bonding method working for stacking DRAM with logic and apparently also solved the thermals well enough too.

Logic is usually rated to run up to 110*C but DRAM processes aren't rated for such high temperatures and perform worse the hotter they get in terms of retention etc.

There are also some novel approaches here in terms of banking choices and impact on refresh times as a result.

The end result that matters for normies is that if this process is turns out to be a success it will challenge and perhaps beat HBM.

That in turn matters because this process is vastly more wafer efficient than HBM for the same bandwidth. Which in theory would ease supply on DRAM wafers.

Except it is also more efficient in terms of energy/bit/s so very likely what will happen is chips will still target the same TDP and just use even more of this rather than consume less wafers because that is just how AI is today.

Disclaimer: I work for a competing company that also makes AI inference chips.

Probably the biggest/most interesting of the annual semiconductor conferences, held in August each year at Stanford.

Depends on how well they translate that effort into promotions or company switches into better positions.

I averaged around 18mo to either a promotion or a move in my 20s, mostly off the back of working harder (to get the promotions/comp increases) and working smarter (to work out when they aren't coming and jumping somewhere else).

If this makes sense for someone has a lot more to do with their ambition/desire and ability to work the system than anything else. It also helps a ton if you are also legitimately very good at what you do. Then it's pretty easy because you are just demanding you are paid commensurate with impact.

Simply doing overtime and having hustle doesn't cut it though, you actually need to be able to leverage it into career progress or it's just wasted life.

They are slow walking it because you simply can't build the generation fast enough anyway. It's also why you are seeing a lot of project with their own generation plants on site, either stuff like the SpaceX/X/AI (I dunno what you call it man) datacenters - i.e very adhoc methane stuff or proper LNG generators ala Meta.

This is mostly an America problem right now because that is where everyone wants to build the DCs and it's the market with the most stagnant generation: https://en.macromicro.me/collections/26367/electricity/14247...

I actually happen to know a lot about this! I have been in and around datacenters for ~16yrs and I work on direct liquid cooled hardware at $DAY_JOB.

Back when I was running my own startup I moved to Mascot, Sydney to be near Equinix SY3 that was being built which we had bought a decent chunk of committed capacity in. Mascot was originally an industrial area but was gentrified a lot over the last 20ish years but the datacenters, meat packers etc are all still there. It really adds to the charm of the place in a lot of ways, warehouses/factories that have been converted to cafes and breweries. Which is to say I don't think living near a DC is bad at all, they aren't very loud and they just look like big warehouses with lots of lights, cameras and no windows. Oh and security dudes.

Anyways. Yes. The hardware I am working at $DAY_JOB is all direct liquid cooled. The coolant that actually cools the hardware is closed loop, it's not expended. Which means you don't actually use any of it and it's considered good for the entire life of the hardware.

I normally don't directly talk about $DAY_JOB things because there are pretty strict rules so I can only use publically referenced sources but you can read a little bit about the coolant we use in this article [1].

The facility loop though is usually what people are worried about. A lot of datacentres that were built in low humidity environments use evaporative cooling which does indeed use a ton of water. However most data centers in more humid environments don't and either use loops that recycle the water but dump the heat (i.e rivers/lakes) or use closed loop systems with radiators etc. It's worth mentioning though that evaporative cooling is extremely power efficient vs most closed loop solutions so there is a tradeoff here. I don't think Google could achieve their fleetwide PUE (Power Usage Efficiency, basically measurement of how much power goes to things in a DC that isn't a computer) numbers without relying on it heavily.

Given the difficulties getting DCs approved in much of the world right now and the backlog on generation capacity (i.e power) almost all modern DCs are being built to use as little water as possible.

To give you an idea I think evaporative cooling of the type you would find in a state of the art Google DC with a PUE of ~1.1ish might use 1-1.1L of water for every kWh of actual equipment load (this is a back of the napkin estimate, don't hold me to it).

Conversely true closed loop will use approximately zero.

So yeah, evaporative is a big waster of water especially at GW scale.

1: https://www.tomshardware.com/tech-industry/data-centers/nvid...

NIMBYs are the enemy of all that is good in the world.

No datacenters isn't about AI or even resources like water or power, it's mostly about real-estate and housing prices as usual.

If we listened to NIMBYs we would have no new infrastructure, no high density housing, no public transport.... oh wait.

I vastly prefer Sol. It does what I tell it to almost exactly, pretty much every time.

I work on very low level stuff (think RTL/FPGA, firmware, software where optimising for nanoseconds is just normal).

For me Sol is the only cost effective model available. Fable 5.1 is indeed good and vastly better than original Fable (which refused to work on most of my stuff for 'safety' reasons).

It's very good at this sort of low level stuff to the point that I really can't understand/relate to people having a good time with Opus (which comparatively performs extremely poorly on my particular workload).

I also just don't like how lazy Anthropic models are. They will do 10% of what is asked and then summarily declare victory.

Sol on the other hand is more like "one of us", slight touch of the 'tism, extremely pedantic, will go to the edge of the known universe if that is what it takes to prove/fix/build what you asked for or run out out of credits trying.

It's a personal and workload dependent thing. For me right now Sol for 99% of stuff because Fable 5.1 still burns through $5k in credits a day.

The plane was a significant factor but you really shouldn't look past the calibre of expertise in the cabin on this particular flight.

> 5 pilots were in the cockpit of this flight. In addition to the normal crew of pilot-in-command and co-pilot, there was an experienced relief pilot and two additional check captains; one was being trained as a check captain (CC) and the supervising CC, who was training the CC.

Captain Richard Champion de Crespigny had 35 years of flying experience at the time of the incident.

That is an insane amount of flight experience in the cockpit and all of the reports state this was a very significant factor. i.e by allowing distribution of the task load, plenty of time for one of the pilots to compute landing calculations manually etc.

THe A380 is a flying tank no doubt, but it wasn't the sole factor here - I think most people would agree this one was a shared victory.

We would probably be fine, but much slower.

However if everyone else stopped using AI we would be broke, so please don't do that.

Hiring middle-management from large companies has to be the biggest startup killer.

Doubly so if they are mediocre to start with and triple so if they bring with them their legion of yes-men.

Can't manufacture anything in America if all your inputs are tariffed out the wazoo.

The so called "visa runs" are for getting around not having the appropriate visa.

I was on a proper employment visa 8 years, never needed to leave the country.

Usually what happens is you make the choice to do a Rust port or rewrite, you maintain the C++ for a while and then eventually the Rust port matches it on perf then the will to maintain the C++ version falls off a cliff.

Seeing this at $DAY_JOB already. I suspect soon at $DAY_JOB the only 2 low level languages approved for greenfield will be Rust and Ada/SPARK.

It's actually both. DRAM manufactures operate on a boom bust cycle and by 2023 there was significant oversupply. This meant even leading up to that they had already decided not to invest in further capacity explicitly to recover profit on their existing lines.

So a lack of builds coupled with AI boom at the same time created a perfect storm with no new capacity coming online for years after demand rapidly escalated.

I built my first "real" GUI app recently with the help of Codex, as in actually looks and feels good.

I used GPUI and the one-dark theme from Zed and it's super smooth, the code is super easy to understand and I love the way it looks.

Not quite as simple as the VB6 and forms apps of my youth but as a Rust dude I definitely grokked it easily and was surprised how much of it I was able to do myself once the agent had helped with wiring up the scaffold.

It really isn't.

Poor correctness guarantees, especially w.r.t concurrency. Nil pointer. Why.

LLMs are like a magnifying function. Whatever you put in you get back 10x over.

In the case of Go, in goes verbosity, Nil pointers, poor concurrency and synchronisation primitives (or poor performance of the safe ones, leading to sync.Mutex everywhere anyway). Also Go prioritises local readability over global understandability which is a poor tradeoff for LLMs with limited context windows.

So the LLM generates absolutely monstrously huge amounts of very hard to review very likely incorrect code.

No thanks.

Rust > Go.

In goes powerful, terse type system. Strong correctness guarantees not just around memory and pointers but also data races. A tendency towards using the type system to model invariants instead of relying on procedural guards and runtime assertions etc. Producing denser code is an LLM feature, it increases context window efficiency. Similarily the typesystem takes something that the LLM can spend a bunch of thinking tokens on to create a powerful global constraint. This fixes the global reasoning/context problem by pushing it back onto the typesystem.

Depending on the quality of your robot you will get different quality of code out but the ceiling is much higher. With Go better robots don't help much, even the highest quality robots output insanely verbose Go. Sort of just like with people... sort of like the language was designed as a lowest common denominator tool...

For a seasoned Rust programmer the output probably won't be hard to review, it will be easy to look at the types and either say "yeah that should probably be correct" or "no robot, do better".

You simply can't actually review the output of the slop cannons with Go, there is too much, looking at a struct tells you almost nothing about how correct the thing likely is, etc. The tests don't help either because there is going to be 10x the usual amount of those too so trying to review those for correctness is the same Sisyphean endeavour.

Iran is on a level so much worse than even Afghanistan.

In Afghanistan, there are some mountains, but they are in the middle. The Taliban fucked off into the mountains and they couldn't do jack.

Iran on the other hand is a plateau fortress lined by mountains on all (accessible to US/western allies) sides. A land invasion of Iran means no supply lines and no way out. The words "one does not simply" come to mind. It is essentially the ultimate meat grinder unless you can win decisively in days, which is impossible because the entire apparatus you are trying to destroy is distributed within aforementioned mountains and operates with decentralised/autonomous command that has been preparing for this exact eventuality (being invaded by an opponent with vastly more firepower and overwhelming air superiority) for the last 40 years. Not to mention absolute fucking hellscape it will be for troops on the ground with FPV drones and Shahed flying into clusters of US marines and being broadcast on Telegram.

A land invasion of Iran is empire suicide. You can't win, you can't go home and you are left with just pouring an infinite amount of resources and lives into the most asymmetric and geographically hostile theatre of all time.

> harder to do on other architectures that themselves aren't fully deterministic though

The TLDR here is that Groq LPUs are completely deterministic hardware, including for floating point.

Disclaimer: Formerly of Groq, now of NVIDIA, still working on LPUs.

They can be deterministic. We did this at Groq, if you sent a request with exactly the same input token, seed and temperature value you would get precisely the same result every time.

This is harder to do on other architectures that themselves aren't fully deterministic though.

If you do good work you should at least take the time to review the slop that details that work for slopiness. Otherwise it's hard to take it seriously. Especially the prefill section.

Damn I am not the only one then.

Also entirely on STM32 now too which is rock solid and the easiest embedded programming has ever felt. probe-rs, defmt, embassy w/async HAL. Life is good man.

Definitely wash the panels.

However if you are using a string inverter you will want to wash all the ones on the same string in one go if you can, you don't really want them generating different voltage or you will miss out on a lot of power.

If you want a massive MacBook anyway then it's great. They are decent for local LLMs, awesome for local image models and it's a MacBook so AppleCare+ has your back. IMO it's a no brainer if you wanted a MacBook anyway but it's a poor choice if your reason to buy it is to run LLMs.